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?
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 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
Unfortunately, this mapping makes it expensive to implement some Gambit specific operations, such as ##subtype, ##subtype-set! and ##vector-ref. 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. A solution may be to have two modes (Standard Scheme and Gambit Scheme) so the user can select the best mode for his needs.
Marc