[gambit-list] -target js

Mikael mikael.rcv at gmail.com
Fri Nov 22 16:52:27 EST 2013

(For general interest)

2013/11/22 Marc Feeley <feeley at iro.umontreal.ca>

> On Nov 22, 2013, at 1:40 AM, Mikael <mikael.rcv at gmail.com> wrote:
> > Francois,
> >
> > Two Q:s:
> >
> > First, when you got a very basic sample app like a DOM-based hangman
> going, feel free to share code
> >
> > Second, how is the type mapping - fixnums, flonums, bignums all wrapped
> to JS double, Scheme string and vector to JS string and vector?
> (1)

> The data representation is customizable with two options for each type.
>  There is a "natural" mapping (Scheme number -> JS number, Scheme vector ->
> JS array, etc) and one which uses classes.
> (2)

> Note that the natural mapping may violate some of the Scheme semantics.
>  For example, JS numbers don't carry the concept of exactness, and JS
> strings are immutable whereas Scheme strings are mutable.  On the other
> hand the natural mapping may be useful in cases where some details of the
> Scheme semantics are not important (the generated JS code is easier to
> read/understand, the generated JS code can be more easily interfaced with
> existing JS libraries, etc).  A mapping which respects the Scheme semantics
> is:
> - Fixnums are mapped to JS numbers
> - Booleans are mapped to JS booleans
> - Symbols are mapped to JS strings
> - Vectors are mapped to JS arrays
> - Procedures are mapped to JS functions
> - Strings, characters, flonums (and other numbers), and pairs are
> implemented with JS classes

Wait, first(1) you suggest there's a customizable option, and then
second(2) you outline a holistic approach for Scheme-JS type mapping.

How is it? And if anything is configurable, where's the switch?

Unfortunately, this mapping makes it expensive to implement some Gambit
> specific operations, such as ##subtype, ##subtype-set! and

Didn't even hear about ##subtype* til now - Any use of JS turns out to be
for some special purpose anyhow, so that there's some real corner case of
Scheme execution in this environment that has a low performance is really
completely cool.

> ##vector-ref.

Wait, why, can't this just be ordinarily expanded to JS' variable[index]?

> So it may be necessary to implement non immediate data (vectors,
> structures, etc) uniformly with classes when using the standard Gambit
> runtime system.

> I haven't explored this aspect much, but it may be that supporting all the
> Gambit primitives isn't practical.

(same note as above re special purpose here)

>  A solution may be to have two modes (Standard Scheme and Gambit Scheme)
> so the user can select the best mode for his needs.

What would the difference be approx here?

> Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131122/d8eedeaf/attachment.htm>

More information about the Gambit-list mailing list