[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summer of Code Recap
|
From: |
Amirouche |
|
Subject: |
Re: Summer of Code Recap |
|
Date: |
Mon, 28 Aug 2017 23:39:00 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
Héllo,
Le 28/08/2017 à 20:56, Ian Price a écrit :
1 Introduction
==============
As many of you are aware, I have been working on compiling Guile
Scheme to JavaScript this summer, as part of the Google Summer of
Code. This post serves to bookend my work for the year.
[...]
2 Project Aims
==============
For a full introduction to the project, you can of course refer back
to my [project proposal], but very briefly my hopes for this summer
were:
1. To rewrite the previous version of my compiler from the [previous
CPS representation] to use the new representation ["CPS Soup"]
representation.
2. To completely port ice-9/boot-9.scm (our basic "prelude") to
JavaScript, and in particular, to support the [Guile Module
system].
3. To handle Proper Tail Calls by use of the [Cheney on the MTA]
strategy.
4. To include a new `guild' script for bundling compiled JS files with
their dependencies.
[project proposal] https://shift-reset.com/static/docs/gsoc-2017.pdf
3 What was Achieved
===================
[...]
3.1 Compile Guile CPS Soup to JavaScript
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
3.3 A linking script for JavaScript
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
4 What was not Achieved
=======================
4.1 Cheney on the MTA
~~~~~~~~~~~~~~~~~~~~~
[...]
6 What is next?
===============
Having recapped what was and what was not achieved, the next question
is: where does the project go from here? I have been asked about my
plans for all sorts of features, e.g. support for [Web Assembly], but
I think the following things are the most important to think about.
[Web Assembly] http://webassembly.org/
6.1 Inclusion into Guile
~~~~~~~~~~~~~~~~~~~~~~~~
The entire point of the project is to have something that can be
included in Guile proper. I have not spoken with Guile's maintainers
about incorporation into the main distribution, but I expect there
would be not be too many problems with moving the "official branch" to
the main repository.
Very important, but not before we know it can be useful.
6.2 All Guile built-ins in runtime.js
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Although I have included enough to get though boot-9.scm, this does
not include all of the built-ins we would want in our programs. Two
things I use very often which do not appear in runtime.js are ports
and bytevectors.
I don't mind not using ports and bytevectors. I am not using them in
BiwaScheme.
We would like most, if not all, Guile built-ins to be available for
those who need them, so these will need to be implemented. However,
this is a lot of extra code for some people who don't need it, which
brings us to a different issue...
6.3 Linking Guile Modules & Features
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In [a blog post], Andy Wingo lays out many tasks that he would like to
see in a future Guile. One of the most important of these, for us, are
under the headings "linking multiple modules together" and "linking a
single executable". To grossly simplify, we want to be able to link
various files into one single executable, which contains all and only
the code we need for our application.
I told you before, I think that this was not an important matter
because it can be handled by Javascript tooling for the time being.
Even if, I agree that in a ideal world, it must not require javascript
third parties except maybe for optimizations.
This would allow us to minimise the amount of code that
needs to be sent over the network, which is very important to web
developers.
You seem concerned by javascript web developers but not about
me in particular. As the maintainer of the only Scheme frontend
web framework, as a Guile user and the creator *one* of the most
successful Python -> Javascript compiler you could have consulted
me on what is best for GNU Guile in the regard of Guile -> Javascript.
That said, I am not surprised of your behavior nor the behavior of
your mentor, since it's not the first time you ignore me by mistake
or on purpose.
I think you should have asked me what would be best to prototype
the compiler.
Sorry, I will do nonetheless.
This is a large task, and one I don't know enough about at the moment
to attempt, but it is work that would benefit not just our JavaScript
compiler, but people who want to deploy regular Guile applications.
At least for javascript tooling is doing that for a decade. So, in my
opinion
this is not the most important matter. See "tree shaking".
[a blog post]
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
6.4 JavaScript Version
~~~~~~~~~~~~~~~~~~~~~~
I am not an expert in JavaScript, in fact, before this summer I
probably hadn't written it for two years, which means the code
certainly does not match up with the current best practices and
specifications. Further, all of my testing for this compiler was done
on [Node.js] v.6.10.3 only (this was the version available in the
Fedora 25 repositories).
The code should be vetted to determine precisely which modern JS
features are used (I believe proper tail calls, and ES6 Maps are the
main ones), and it should be tested on all major browsers. If
necessary, we should incorporate switches in the compiler to allow JS
users to compile for particular implementations, taking advantage of
particular modern JS features, or providing our own implementations of
those that are not supported (e.g. Cheney on the MTA).
This is overkill. babel [https://babeljs.io] or traceur [*] can do that
for us.
[*] https://github.com/google/traceur-compile
6.5 JS Integration
~~~~~~~~~~~~~~~~~~
[...]
6.5.1 JS calling Scheme
-----------------------
As it stands, you can perform some limited interaction from JavaScript
in a similar manner to how you would interact with Guile from C. For
instance, by using `scm_current_module', `scm_public_lookup', and the
`scheme.Symbol' constructor, one could look up a scheme function, e.g.
`iota', and then invoke it by `scheme.call'.
That said, C idioms are not JS idioms, and so we should work to
provide a much nicer API through the `scheme' object.
Not very useful, except if you achieve Javascript speed in Guile
compiled code.
6.5.2 Scheme calling JS
-----------------------
In the case of Scheme calling JavaScript, I think we should follow the
example of `(system foreign)', which provides an API for linking to
dynamic C libraries, and creating Scheme versions of C functions, and
automatically marshalling/unmarshalling C types to Scheme types. One
additional complication we would have with JS would be the presence of
exceptions, but I think these could also be marshalled into Scheme
ones without much trouble.
marshalling and unmarshalling types is a pain performance wise. I was
hoping
that calling Javascript functions would be native with zero overhead. It
seems
like it's not the case. I hope that at least string won't require
complex code.
7 Lessons Learned
=================
[...]
8 Wrapping Up
=============
If you are still with me, good on you. As the new semester is starting
I will be devoting much less time to this, and that will likely be
true till December, but I will make an effort to keep up with
guile-user and be on the IRC Channel to help the daring souls who want
to give this a go. My priorities will be documenting the ILs, filling
in missing builtins, and improving jslink. I especially want to see
basic IO and MiniKanren up and running, and for it to be convenient to
use Guile's builtin libraries.
Happy Hacking, Ian Price
I hope that in the future, you will be more inclusive.
Great achievement!