Compilation to js [Update]
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]
Hi Ian, Ian Price 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 signature.asc Description: PGP signature
not being residualised
Another issue is with macros, which are not being residualised now What does residualization of macros mean? (I feel I’m missing language here). dude, me too!
Re: Compilation to js [Update]
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]
Ian Price 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: not being residualised
ff writes: > Another issue is with macros, which are not being residualised now >> >> What does residualization of macros mean? (I feel I’m missing language here). >> > > > dude, me too! Please post messages only if you have something useful to add, or a coherent question to ask. This is a good rule for any public mailing list. As I recall, Ludovic made a similar request to you on one of the Guix lists. Thanks, Mark
