> > > 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?
>
> Although Smalltalk fans like to praise everything is object, there is not
> much real benefit to make everything as object, such as vtable.
Agree. E.g. once you have a JIT you surely have to fake, for example
first-class stack frames.
regards.
