Re: Please recommend a Scheme to transpile to browser-side JavaScript Lassi Kortela 08 Jul 2019 22:20 UTC
> Yes, it says defunct because I hitting depth limit with biwa for > small-ish apps. Do you mean the call stack limit due to lack of proper tail recursion? > Amirouche's other project <http://scheme-lang.com/cons/> apparently > uses > Chibi Scheme compiled in the way John mentioned, judging by the page's > source code. > > *If you are ok with the time it takes to load* the wasm file, I will > work on improving > that to allow to do XHR requests in the following days (promise!) Unfortunately I think the load time can be a deal breaker (for normal web apps; for a full interpreter like on that page, it's probably fine). Anyway, your work on these frontend libraries is very inspiring and we should definitely collaborate on something in this fashion :) Would it make sense to keep developing something based on forward.scm? If we want to replicate Elm, we may have to define a restricted subset of Scheme that only uses immutable data. Then our restricted-Scheme-to-JS transpiler can convert tail calls to for-loops or something. It would be easiest if Google Closure Compiler could convert tail calls but I can't find any mention of such a feature. The magic of Elm really boils down to two things: * Purely functional language for the user. * An (invisible) imperative kernel written in JS that repeatedly calls your pure-functional code in a loop to render successive views. Since your view generator is pure-functional, it can use a very fast virtual DOM implementation that relies on the fact that data is immutable. If we cannot assume pure-functional user code, things get a lot more complex in the kernel (and also interpreter-wise). I'm thinking of John's hot-off-the-presses draft SRFI 172 about the restricted subsets of R7RS. Also thinking of Owl Lips, a Scheme subset concentrating on immutable data.