4 ms·

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 majo

by jpolitz 10y ago

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 http://stackoverflow.com/a/28730491

616c 10y ago
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 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.
- shriramkmurthi 10y ago
  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-cont-from-gen-stack-insp/ 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)!

by jpolitz 10y ago

616c 10y ago

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 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.

shriramkmurthi 10y ago
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-cont-from-gen-stack-insp/ 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)!