Email list hosting service & mailing list manager

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 Lassi Kortela 31 Jul 2019 21:20 UTC

> You know, I've written a lot of Scheme library code recently, and very
> little of it relies on continuations (except for the occasional escape),
> tail calls (except the implicit use in 'let loop'), or macros.  Much of
> it could just as well be written in JavaScript or Python.  For me,
> Scheme is pretty much just an alternative syntax (that I prefer) for
> modern reasonably-functional languages.

I've always felt the same way. Continuations have the obvious l33t
factor and are probably very useful when doing low-level stuff like
implementations of other programming languages in Scheme, but for day to
day work they are rarely necessary. Kent Pitman once made an extended
argument that he'd rather not have continuations because they break some
guarantees about unwind-protect. (Then again, some FFI and
multi-threading tricks probably break them too.) John Carmack made an
argument that when a codebase grows and ages, every feature permitted in
the language will eventually be used in it (I think he made it as an
argument that C++ needs to be re-thought; it could be an argument for
Scheme).

Are there specific patterns of continuation use to address the infamous
"callback hell" in JavaScript? Personally, I don't like the look of that
new-style async/await code that is everywhere nowadays so anything
better than that would be very welcome :) Elm is currently an oasis free
of that stuff. More generally, as we have to deal with more and more
concurrent stuff, looking into synchronous programming languages for
inspiration is probably smart. I'd still like someone to write a "Lucid
Synchrone for plebeians" showcase. That language looks really cool.

As for tail calls, recursive code in Scheme just reads very very nicely
and makes it trivial to avoid common bugs with accidentally re-using a
variable (since variables are re-bound at each recursion step). It would
be really nice if we could write code for the browser using tail calls.

Part of me is thinking, "Let's just hack this together. How hard can it
be?" It sounds like so much fun. Most Scheme compilers already analyze
which calls are tail calls, so it should be possible to start hacking
from there.

Amirouche: Do you have translation of Scheme tailcalls to JS loops
working in Ruse Scheme already?