> 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?
Yes.
> 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).
Please! Let me argue that it depends on the app. For long running apps
like gmail, it makes sense to wait a little bit...
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?
forward.scm deviates a little bit from purely functional elm architecture in
the sense that XHR is done inline in update procedure (called controller)
instead of relying on a continuation.
If we want to replicate Elm, we may have to define a restricted subset
of Scheme that only uses immutable data.
That is not the issue. I don't remember using mutable 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.
Already looked into trampolines stuff where tail-calls are implemented using
transpilers from js to js nothing works (see traceur project from google another
example).
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.
That is not the bottle neck in forward.scm. Lack of tail calls is.
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.