(For general interest)
2013/11/22 Marc Feeley feeley@iro.umontreal.ca
On Nov 22, 2013, at 1:40 AM, Mikael mikael.rcv@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