Compilation to JS [Update]

[Ian Price]

Hello Guilers,

I am long overdue an update on the state of affairs of guile-js
(the last was at the end of June).

Last time I spoke, I had completed task 1 (cps old -> cps soup), and
was starting work on task 2 (port boot-9[1]). I made a lot of headway
on this task, and would categorise it as "nearly done". I ran into
some trouble with my initial module representation, and this has been
blocking further progress, but I hope to have this remedied soon.

Those interested can read language/js-il/runtime.js in [2] to see what
the current "base" runtime looks like, but it is absolutely dwarfed by
the compiled output of ice-9/boot-9, which I do not recommend you look
at.

Due to time constraints, task 3 (Cheney on the MTA) is not going to be
accomplished before the deadline. I apologise for this, and would like
to add support for it after the summer, but in any case, we can all
take some comfort in the increased support for proper tail calls from
JS implementations is making this much less necessary.

As for task 4, I have written a script to "link" JS modules with their
dependencies, which should make it easier for you to test. For
instance, you might have a program merge.scm which sorts a list (e.g.
http://shift-reset.com/pastes/merge.html). You can compile this file
with guild in the usual way

  guild compile merge.scm --output=merge.js --to=javascript

which you can assemble into a "real" program by including the runtime [3]
with

  guild jslink merge.js --output=main.js --no-boot

and then run with node (other js interpreters are available). You will
not see any output because that file does not print anything, and
ports are a big thing that are not supported yet, but can you can
replace the initial (identity) continuation with one that prints the
return value (I should probably add a switch for this).

jslink is very rough, and I do not intend for this to be the final
interface for creating Javascript "bundles", but merely the simplest
thing works for now. Better solutions will come from getting all the
linker improvements Andy has suggested into Guile [4].

I still don't think this is ready for you all to play with, but once I
am happy boot-9 is in good shape, I will declare open season. From now
till the deadline, I intend to continue working on getting boot-9
done, and in documenting what is already done.

I will post a final summary of the project, including some of the
lessons from this project, missing functionality, known bugs, etc. in
a few weeks time.

Ian

[1]. Actually, It was a misnomer to refer to this work as porting,
since boot-9 is compiled like any other .scm file, what it really
involves is reimplementing guile builtins.

[2]. https://gitlab.com/ijp/guile/tree/compile-to-j-2017

[3]. Due to the aforementioned issue with boot-9, --no-boot is used to
prevent the inclusion of boot-9 and its dependencies.

[4]. https://wingolog.org/archives/2016/02/04/guile-compiler-tasks