Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 16:36 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 18:46 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 18:55 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 19:20 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 20:14 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (31 Jul 2019 20:49 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 20:51 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 20:55 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 21:00 UTC)
Re: State of Scheme in the Browser Lassi Kortela (31 Jul 2019 21:21 UTC)
Re: State of Scheme in the Browser John Cowan (31 Jul 2019 22:03 UTC)
Re: State of Scheme in the Browser Lassi Kortela (01 Aug 2019 09:40 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (01 Aug 2019 11:25 UTC)
Re: State of Scheme in the Browser John Cowan (01 Aug 2019 14:18 UTC)
Re: State of Scheme in the Browser Lassi Kortela (02 Aug 2019 10:24 UTC)
Re: State of Scheme in the Browser Amirouche Boubekki (02 Aug 2019 19:19 UTC)
Re: State of Scheme in the Browser Lassi Kortela (02 Aug 2019 20:42 UTC)
Re: State of Scheme in the Browser Arthur A. Gleckler (02 Aug 2019 00:55 UTC)
Re: State of Scheme in the Browser John Cowan (02 Aug 2019 01:17 UTC)
Re: State of Scheme in the Browser Arthur A. Gleckler (02 Aug 2019 01:28 UTC)
Re: State of Scheme in the Browser John Cowan (02 Aug 2019 02:28 UTC)
Re: State of Scheme in the Browser Lassi Kortela (01 Aug 2019 09:48 UTC)

Re: State of Scheme in the Browser Amirouche Boubekki 01 Aug 2019 11:24 UTC

Le jeu. 1 août 2019 à 11:40, Lassi Kortela <xxxxxx@lassi.io> a écrit :
> > You don't need await/async decorators in Scheme because we have ... call/cc!
>
> Can you (or someone else) share some patterns of continuation usage that
> would be useful for web programming (in the browser) if we can compile
> them into some form that's acceptable to JavaScript? I'm out of my depth
> here and don't know where to look.

Anytime one rely async behaviour, IF you want to avoid callback-style,
you need call/cc or at least an escape procedure.

>
> > Yes, tail *recursion* is easy to do with loops and jumps.  It's
> > *general* tail calls (to arbitrary procedures) that are hard.
>
> Would those be important for good performance in-browser? Almost all
> tail calls I use are tail recursion. Does this general tail call
> optimization you have in mind have something to do with translating code
> into continuation-passing style for compilation, and compiling that
> style into fast code?

WebAssembly will have tail-calls, it is already present in nodejs v12.
See Schism issues and recent PRs.

Ruse compiler does translate to cps and then use a trampoline to avoid
stack depth limit. It is slow but it works. The "counter" demo shows
acceptable speed performance both loading speed and execution speed.
Maybe memory could be better, but it is just getting started.

Speaking of demo, I am wondering what kind of demo could I create to
make it more obvious that this really works, and that performance is
not a problem?

--
Amirouche ~ amz3 ~ https://hyper.dev