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