Comment by 616c | Hacker News Reader

Comment by 616c | Hacker News Reader

So, a question: last time I talked to one of the Brown PLT profs making this on HN (GH contributor log makes me think ... shriram?) this worked well in Chrome, but not well or not performant enough in Firefox. Has that changed?

(Here it is: https://news.ycombinator.com/item?id=9262770)

An admiring comment: the fact you encoded into the language unit tests close to functions, which is a style choice for some in Python but not mandatory, was very cool to me.

An admiring comment: you talk about multimedia-centric must be awesome. I am language major and failed programmer many times over. I started with C++ on Solaries boxes compiling with g++ over SSH; I was one of the few who started using Linux, not Unix mind you, in Poli Sci school so it was not so bad for me as everyone who would use VS and msvcc, forget to check g++ builds, and lose points (I still did miserably). When I saw samples where you have stdlib tools for integrating into things like Google Docs and Dropbox, I thought wow; these kids are going to learn to make stuff so early, and that is so liberating.

And finally, an obnoxious comment: as a Lisp wheeny, I wish Racket and its toolkit was fast enough, as one of the few who bought Conrad's book and never got around to really amazing Scheme usage.

Still, this is wonderful work. The idea of people building such full environments in JS, stacked on top of transpilers and compilers, is amazing to me as a novice. Not that it's possible, but that it works at all. Every time Pyret comes up, I smile.

Aaarr, keep hacking matey!

UPDATE: Add my previous Q&A and with shriram. You Brown PLT and Racket people are so approachable and smart, damn you !(He says ironically while shaking his fist.)

Thanks for the kind words!

Firefox performs better than it did, because the whole language has gradually increased performance, but still the worst of the major browsers. It's worth writing down a bit about that here, just for others to see and comment on.

We have some ideas that we suspect will mitigate the main issue in Firefox, which is that Firefox stack frames seem to be very large for compiled Pyret functions. This matters because Pyret's execution control works by (a) figuring out how many "typical-sized" stack frames fit before a stack overflow; this is a little tricky [1], (b) leaving breadcrumbs of metadata on each stack frame, and collecting them on an exception thrown when the limit is reached, restarting after yielding control to the browser's event loop. The issue is that the "typical" frame size for a Pyret function in Firefox means we only get a few hundred frames, and most idiomatic Pyret is implemented recursively, hence lots of pausing and collecting the stack.

It's clear that good support for safe-for-space tail calls is a simple way to mitigate a lot of the issue. We have a version of safe-for-space tail calls that avoids using unbounded space, but doesn't help (much) with speed.

Upcoming safe-for-space tail calls in JS provides one avenue for this that we'll be trying to take advantage of.

Actually compiling instances of Pyret tail recursion to JS loops is something we want to get working. It's a mildly nontrivial engineering challenge in the presence of dynamic annotation checks for return values (which muddy the definition of "tail call", especially since annotations can contain refinement predicates -- more function calls!), the desire to report faithful error information to students, and wanting to yield to the event loop often enough to not lock the page and get "busy script" errors. It's not extremely difficult, there's just enough tricky bits that it's on a branch right now and we're not totally satisfied with it yet.

Since we've largely focused on design of language features rather than performance for a long time now, there's somewhat of a backlog of these kinds of straightforward performance ideas that aren't in the system yet.

[1] http://stackoverflow.com/a/28730491

So, novice question: will Web Assembly help TCO? I know nothing of it really, but it seems like a long-term goal, not shortterm for the WA design team.

https://github.com/WebAssembly/design/issues/189

As an aside, I am a weak programmer, but I love what you guys have done with Racket, especially with incremental language building with #lang directives. I know you could not do that so seamlessly in Pyret, but I love your progessive lang building, progressive type addition. You get the practicalities of pedagogy in language learning by breaking it down into pieces; I wish more people got that and could have succeeded into steering me into double majoring in Arabic and CS. Ironically I was so weak at it after two semesters of C++ only for major intro courses, the enticement of crazy USG machine translation gigs my profs promised me scared me away with my impostor syndrome.

So why say this? How can people like me help with Pyret? I think its web browser JS transpilation are very interesting, and in this age of data visualization and rich multimedia interactivity, I think these tools are the future of language learning, university or not, whether people think it.

I see you guys went so deep with Racket for building blocks of abstract language building blocks, but the Racket people involved in Pyret are sweetening the deal with the notion of tools for practical incentivization with the wep API and media integration.

So, yeah ... sorry to brain dump there. Really enjoyed this post and the work of your lot over there.

Good question re. Web Assembly. The problem is we need much more than tail calls. Just as important is deep stacks, to enable a _functional_ style of “functional programming”. And that has definitely been a headache. Our current (clever) implementation strategy actually gives us tail calls as a consequence of the deep stacks, using a variant of Henry Baker's "Cheney on the MTA" (for those old enough to remember that) combined with the "stack reconstitution" technique we published in ICFP a decade ago [http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-...] and a few other things. But tail calls by themselves wouldn't be enough.

What _could_ we use help with? Obviously, we could use infrastructure help or porting to “platforms” (e.g., a REPL on top of Node), but those are huge commitments and require a lot of special knowledge. But I think a person with only a little time can still help.

Right now, I feel the language is still a bit impoverished. We want to make it really easy to get working with data, and that's still too hard. But pretty soon we're going to be putting out better support for tabular data manipulation. Actually use it to do some fun things with data; share your successes (when things work) and your experiences (when they don't)!

Reply on news.ycombinator.com