Juergen Boemmels <[EMAIL PROTECTED]> writes:
f> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>> At 1:58 PM +0000 9/5/02, "Jürgen" "Bömmels" (via RT) wrote:
>> >The recent discussion of languages independence rememberd me of an
>> >very old patch of mine which implements scheme pairs. (January 2002).
>> >The languages/scheme directory did not change very much since then,
>> >but the key system totally changed since then.
>> >
>> >But neverless, I got it running. The dedicate SchemePair PMC is not
>> >necessary any more, I just used an Array of size 2.
>> >
>> >scheme now can create pairs with (cons) and lists with (list), print
>> >them using (write) and access its elements using
>> >(car), (cdr), (set-car!) and (set-cdr!). See lists.t for examples.
>>
>> Cool, applied. How far from "real" scheme are we?
>
> I think its quite far.
> The first thing is symbols and strings. But how do I represent them at
> parrot-level. PerlString maybe, but then how will they be distinct
> from each other. Or just leave out strings for a while.
Symbol: [ '*symbol*', "symname" ]
Held in a Hash (hashed on the string name).
String: [ '*string*', "a string" ]
Which means Pairs become: [ '*pair*', <car>, <cdr> ]
(Or, more likely)
{ type => '*symbol*', value => 'symbol', (vtable => ...)? }
{ type => '*string*', value => 'a string' }
{ type => '*pair*', value => [ <car>, <cdr> ] }
{ type => '*int*', value => 1 }
{ type => '*rational*', value => 1/2 }
> Lexicals are also missing. I haven't looked closely to that. Without
> variables a language is not very useful.
{ type => '*environment*' value => {scratchpad => aScratchPadPMC}
> lambda-expression: this may compile just down to a sub.pmc
> Functions like map, apply, list?, etc. have to be implemented.
{ type => '*function*', value => {env => anEnvironment,
arglist => aListOfSymbols,
sequence => aListOfForms} }
{ type => '*compiled-function*', value => aSubPMC }
All these types should possibly also carry a pointer to either a jump
table or a hash of type methods so, for instance the default car
becomes (in perlish pseudocode)
sub car ($thing) { $thing.{vtable}{car}.($thing) }
For bonus points things should be arranged so that 'vtable{car}' can
be any of a scheme function, a sub.pmc or a custom op. For tail call
bonus points it should be possible to alter the current continuation
before calling (or just to make a tail call to it as appropriate...)
> Macros, tail-recursion, eval, and call/cc are also needed to call it
> "real".
Oh yes: continuation: { type => '*continuation*',
value => aContinuation.pmc }
The empty list: { type => '*the-empty-list*',
value => '*the-empty-list*' }
etc...
Implementation is a simple matter of coding. I've been reasonably
convinced since PerlHashes became ready for primetime that one could
implement a full blown, if not necessarily very *fast* version of
scheme whilst maintaining one's own environments, continuations and
all the other good stuff, but lack of tuits has tended to get in the
way of implementing it.
Things would almost certainly be easier with full blown PMCs handling
dispatch for the 'thing' that a '*function*' points at, but not
entirely necessary. Another option is to make first class PMCs of all
the various types, but I'm not sure how one would go about
implementing 'mixed' vtables, where some things are implemented in C,
others PBC and still others in one interpreted language or
another. One option for that would be to have a single 'SchemeObject',
which as well as having a vtable implemented in C would first do
dispatch through its 'scheme_vtable' hash. Continuations, Integers,
Rationals, and other things which map directly onto existing PMC types
(and which don't need extra methods) could then just use their normal
PMC.
Thoughts?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
