Compilation to js [Update]

Compilation to js [Update]

[Ian Price]

Hello guilers,

I figure it's time for an update on what I've been working on for the
past two weeks.

I have mainly been working on updating the compiler to go from the old
cps representation to the new cps-soup representation.

This had a few false starts, but on the third attempt, I think the
approach using the dominator functions in (language cps utils) is the
right way, and is giving the results I want. I intend to write a blog
post shortly explaining how dominators / cps-soup work and how to
compile from it for other people who may be interested in these low
level guile details.

Right now, you can find my code on gitlab[0] in the compile-to-js-2017
branch in the language/js-il and language/javascript directories[1].
What can you do with it? Well, I do not recommend trying to use this
seriously, since you will run into a large number of issues, relating
to residualising macros, missing prelude functions and possibly stack
overflows. That said, you can take some scheme files and compile them
with the usual functions, e.g.

(compile-file "/tmp/foo.scm" #:to 'javascript #:output-file "/tmp/foo.js")

You can see the output of mergesort (beautified) at
http://shift-reset.com/pastes/msort2017.js.html. In order to run it,
you will need to add the contents of runtime.js which can be found in
language/js-il. Other things you might try are non-local escapes with
call/cc and keyword/optional/case-lambda arguments.

What's next? Number 2 on my list from last time was
>  Complete porting boot-9 to js (in particular, the guile module system)
so this is what I intend to do. This will allow us to run much more
complicated programs, and you won't need to keep reimplementing
functions like map.

Another issue is with macros, which are not being residualised now
that their representation was changed, so I'll do that too.

Till next update,
Ian


[0] https://gitlab.com/ijp/guile/tree/compile-to-js-2017.
[1] Compilation to js-il is in language/cps/compile-js.scm

Re: Compilation to js [Update]

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Hi Ian,

Ian Price <ianprice90@gmail.com> writes:

> I think the approach using the dominator functions in (language cps
> utils) is the right way, and is giving the results I want. I intend to
> write a blog post shortly explaining how dominators / cps-soup work
> and how to compile from it for other people who may be interested in
> these low level guile details.

That sounds great!

> That said, you can take some scheme files and compile them with the
> usual functions, e.g.
>
> (compile-file "/tmp/foo.scm" #:to 'javascript #:output-file "/tmp/foo.js")

Is there already a clean way to run javascript functions from scheme —
for example accessing the DOM? That would directly allow pure Guile web
development.

> What's next? Number 2 on my list from last time was
>>  Complete porting boot-9 to js (in particular, the guile module system)
> so this is what I intend to do. This will allow us to run much more
> complicated programs, and you won't need to keep reimplementing
> functions like map.
>
> Another issue is with macros, which are not being residualised now
> that their representation was changed, so I'll do that too.

What does residualization of macros mean? (I feel I’m missing language here).

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Compilation to js [Update]

[Ian Price]

I would like to be able to access Javascript functions from Scheme,
possibly with a (system foreign) type API, but this is not a priority
at the moment. Getting as much of Scheme as possible working is the
main thing. On my list, you could put it as the unspoken 5th stage.


As for residualisation, it's not a technical term. More accurate
terminology would be serialisation of syntax objects. Maybe you can
interpret my use of "residue", as being partly negative, as residue is
something left over at the end of a process. Syntax objects are quite
big, (in one experiment I did today, it was half the size of the
output) and if possible, I'd like to avoid emitting them, where
possible, since this is going to be sent over the network.

Re: Compilation to js [Update]

[Mark H Weaver]

Ian Price <ianprice90@gmail.com> writes:

> As for residualisation, it's not a technical term. More accurate
> terminology would be serialisation of syntax objects. Maybe you can
> interpret my use of "residue", as being partly negative, as residue is
> something left over at the end of a process. Syntax objects are quite
> big, (in one experiment I did today, it was half the size of the
> output) and if possible, I'd like to avoid emitting them, where
> possible, since this is going to be sent over the network.

You might want to look at 'squeeze-syntax-object' in
ice-9/compile-psyntax.scm, which we use to reduce the size of
psyntax-pp.scm.  Unfortunately, this breaks 'datum->syntax' in the
general case.

     Regards,
       Mark

Re: Compilation to js [Update]

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]


Ian Price <ianprice90@gmail.com> writes:

> I would like to be able to access Javascript functions from Scheme,
> possibly with a (system foreign) type API, but this is not a priority
> at the moment. Getting as much of Scheme as possible working is the
> main thing. On my list, you could put it as the unspoken 5th stage.

ok. Thank you!

> As for residualisation, it's not a technical term. More accurate
> terminology would be serialisation of syntax objects. Maybe you can
> interpret my use of "residue", as being partly negative, as residue is
> something left over at the end of a process. Syntax objects are quite
> big, (in one experiment I did today, it was half the size of the
> output) and if possible, I'd like to avoid emitting them, where
> possible, since this is going to be sent over the network.

Ah, the residuum is something I know :)

Sounds great!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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