RE: Anachronistic Acronyms in Parrot?

[Hong Zhang]

> >   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).

Although Smalltalk fans like to praise everything is object, there is not
much real benefit to make everything as object, such as vtable.

Hong