[gambit-list] -target js
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?
> 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.
> 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
> - 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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list