At 07:38 PM 9/26/2001 +0200, Samuele Pedroni wrote:
> > > > Would it not make more sense for Parrot types to be first-class
> > > >objects for the language being implemented? It seems this would make
> > > >things easier both for the upper-level runtimes and for
> > > >multiple-language applications.
> > >
> > > The variables themselves (scalar, hash, complex number, various objects)
> > > will be first-class objects. It's the lower-level stuff, like the
> vtables
> > > or GC data or thread information, that won't be. It'll still be exposed
> > > through the interpreter, but it won't be an object in the same way
> that a
> > > ruby/python/perl variable is.
> >
> > I think the terminology shows the difference between Perl and other
> > languages.
> > Perl uses the concept of "variables" and variables have some kind of types.
> > Most most OO languages uses "values" for the same purpose. The variables
> > just storage that contain values (either directly as immediates or
> > indirectly
> > as pointers).
>I agree. We faced this terminology problem when we started discussing
>of Parrot on Python-Dev. For example it was unclear how assignment
>would work:
> assignment into a typed PMC
> vs. assignment into a type-agnostic slot.
>
>Dan, can you explain how assignment will work for Perl6 mapping over Parrot,
>and what mechanisms will be there to be used by other languages?
When you assign to a PMC, the destination PMC's "assign to me" vtable
function will be called. If that function doesn't like the inbound type, it
throws an exception. The PMC flags section has a flag to note whether
typing should be enforced.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
