Piers Cawley <[EMAIL PROTECTED]> writes:
[...]
> > 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.
>
> Up to a point Lord Copper. That's not going to fly (easily) once you
> have a read eval print loop in place. I want to be able to do, say
>
> repl> (define (make-adder n) (lambda (x) (+ n x)))
> #t
> repl> (define add1 (make-adder 1))
> #t
> repl> (add1 10)
> 11
>
> in an interactive session, otherwise what would be the point?
Ah I see the point. There needs to be a way to get the lexical adress
from a string. Otherweise it would be really doubling of
information: One in the compiler to get the mapping
symbol => lexical adress, and one in the repl to get the mapping
symbol => value (which internally does something like symbol =>
lexical adress => value).
Anyway the lexical scope resolution at compile-time is some kind of
optimization that wont be in the first implementation. Always look up
a lexical via find_lex/store_lex
> >> > 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.
>
> Ah. Now, to my way of thinking this is the most important
> part. Functions are absolutely fundamental to Scheme and you might as
> well not bother until you've worked out how you're going to implement
> them.
Yes, functions are the heart of Scheme. Slowly some ideas on
implementing them come up. Your idea of using the 3 elements env,
arglist, sequence looks like the way to go. The scheme way would be to
use a list for that. The sequence would be convertet to an entry
point, as the function can be compiled in advance. The arglist may go
away when the lexical scope resolution at compile time is fully
implemented, because the only functions having access to the arglist
are the ones which are already compiled in this scope. I haven't
thought this through in detail.
> > 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.
>
> Not even close to enough.
Ack. Thinking a little more about it, I recognized you can't get
arround the environment pointer. But perl-subs will need this pointer
also, so it may be added to the sub.pmc
sub make_add { my $add = shift; return sub { my $x = shift; return $x
+ $add }}
$add_1 = make_add (1); print $add_1->(2);
> Unless you're going to have the
> Read/Eval/Print thing I showed above compile any functions down to
> parrot immediately, which would be fine, but we don't yet have the
> capability to create and execute parrot code on the fly, so that's a
> showstopper right there.
Read/Eval/Print-Loops use eval. Eval is not the simplest part of
Scheme, but it can be implemented in Scheme, compile to parrot with
the compiler, and then get used in a repl. Then the function will
definitly have the form :
(environments arglist sequence)
> But we *can* represent scheme functions as
> environments + arglist + sequence of forms already.
Ok, you convinced me.
[...]
> typeof is a *really* bad idea. Let the 'Object' PMC handle the
> multilevel vtable look up (in exactly the same way that one does
> lexical lookup in the environment chain) and method invocation. So,
> for instance, the bare Object would have no 'cdr' method, so to do
> C<< call_method Pn, 'cdr' >> would throw an exception. But then one
> could do
>
> pair_cdr:
> ...
> ret
>
> ...
>
> new P1, .Class
> new P2, .Sub
> set_addr I0, pair_cdr
> set P1["cdr"], P2
> set P1["classname"], "SchemePair"
> set P1["isa"], "SchemeObject"
> set P2["class"], P1
> ...
>
> set I1, 0
> set I2, 1
> set P3, "foo"
> call_method P2, "set_car"
> set P3, "bar"
> call_method P2, "set_cdr"
> call_method P2, "car"
> print P3 # prints "foo"
Intresting aproach. Doing Scheme object oriented. I have to think
about this approach another day.
> The thing is, we're going to need a Class/Object structure along these
> lines for Perl/Ruby/Parrot objects anyway, so even though scheme won't
> expose these PMCs to the end user, the effort in implementing them is
> definitely worth while. And I think the extra code organizing
> capability they give us is really important.
>
> Note too, that it wouldn't be hard to set up SchemeFunc, CompiledSchemeFunc
> and NativeFunc (he said, guessing at names) so that they all looked
> like Sub PMCs when it came to function call time...
>
> NB: I have a proof of concept scheme interpreter running in Perl that
> uses these OO techniques, and it works really neatly, which is why
> I've been thinking of doing the Parrot scheme interpreter in a similar
> fashion.
I would be very intrested to hear more about this interpreter
bye
juergen
--
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
