Re: Summer of Code Recap

[Amirouche <amirouche@hypermove.net>]

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!