Piers Cawley <[EMAIL PROTECTED]> writes:
[...]
> >> 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> ]
That would be a possibility. The object-size increase would only be
33-50%. To get a working prototype this is ok. Not everything is an
object, but everything is an array.
The later way would be to have two PMCs SchemeSymbol and SchemePair,
both inheriting from PerlString (or maybe this will be renamed to
String). The only diffrence would be the type and maybe the stringify
function.
> (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 }
No, I don't think so. This would be a Scheme Interpreter written in
Perl, and compiled to Parrot, and not a Scheme program compiled to
Parrot. If language-independent means that you can write an
interpreter for any language the C is language independent too.
> > Lexicals are also missing. I haven't looked closely to that. Without
> > variables a language is not very useful.
>
> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
There is already a ScratchPadPMC. Where is it? It's not in classes/,
is it. As a first implementation a PerlHash is sufficent, (I actually
have a patch doing exactly this, it just needs a little polish. Maybe
I will submit it tomorrow). But most of the lexical scope can resolved
at compile time. parrot_assembly.pod describes an op fetch_lex_p_i_i
but this seems not implemented yet.
> > 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 }
I haven't thought much about this yet.
[...]
> 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.
I also think it would be possible to implement scheme. The major
show-stopper the access to aggregates has been solved.
> 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.
IMHO this is the way to go.
SchemeString, SchemeSymbol -> Kind of PerlString, just diffrent type.
SchemePair -> Special Class abusing pmc->data and pmc->cache.pmc_val
as car and cdr (this needs a custom mark function) but getting rid
of one extra indirection.
Envoirments -> The find_lex/fetch_lex looks promising.
Functions -> Subs should be enough.
> 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.
The diffrence would be the subtype. But AFAIK there is no way to get
this subtype from the PMC in bytecode. Maybe a subtypeof_i_p op is
missing. But this would lead to an extra indirection at runtime:
SchemeObject->vtable->subtype->vtable
For the primary objects of a language this should not be necessary.
> 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?
see above
b.
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
