Rough thoughts on the Object Space
Stevan Little
So after reading fglock's Perl6::Value/Container modules, some p6l
backtracing and some discussions on #perl6 with Luke and autrijus, I
have arrived at a very early (read: probably wrong) thoughts for the
p6 Object Space.
I see this step as critical in the development of Pugs 6.28.0, and so
I wanted to start the discussion now.
When I speak of "Object Space" I mean it in the PyPy sense of the
word, a description of which can be found here: http://codespeak.net/
pypy/dist/pypy/doc/draft-dynamic-language-translation.html#object-
spaces.
Now, let me first start with a basic drawing, and use it to explain
what I am thinking. Here is the drawing:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/
Object_Space.jpg
Now, before anyone gets all up in arms that I have forgotten their
favorite p6 type, let me say that is not what the drawing is of, and
that it is purposfully incomplete in that sense.
Now, the drawing is to be read from left to right, with each section
being built upon the one which came before it. I will explain each
section in detail.
Core Runtime
This is the absolute bare minimum set of types which need to be
implemented on this level. These are *not* a list of the unboxed
types which will eventually be exposed to the p6 user, these are
runtime supplied types, for use in the runtime only (at least at this
point).
MetaModel Runtime
These are additional types which the runtime needs to supply in order
to support the Perl 6 MetaModel. It is possible (and very likely)
that these types will be implemented using the types in the Core
Runtime. However, this (probably) is not a requirement and these
types could be implemented natively for speed.
The "instance" type described here should be confused with the
"Object" type. Object (found in the meta-model level) is a class, the
"instance" type is just an opaque structure to describe an instance
of a class. It is a building block for the metamodel, just like
methods and attributes.
*NOTE*
At this point, we assume that a method dispatch mechanism is in
place. The details of which are not important at this point.
MetaModel
This is the object MetaModel, it provides classes, roles, modules,
packages and the base Object class.
Prior to this stage, we do not have any classes/objects available on
the user level. While the lower level types may (or may not) be
implemented in OO, but this has no correlation to the OO that the
user actually sees. The OO the user sees is implemented here.
Once this stage is complete, we are now ready to expose elements to
the user-level. In fact, Object is really the first user-level
"thing" which is exposed. Class, Package, Module and Role are meta-
level "things" and exactly how (and if) they get exposed to the user-
level is discussed at the end of this document.
Containers
The classic Perl Scalar, Array and Hash trio is implemented here.
These are container types, and for the most part, they "hold" the
other types found in the next level.
Boxed Types
This is a set of types (written using the meta-model), some of which
wrap primitive core runtime types, others which completely are
implemented here. I think that most of these will actually be roles,
and not classes. All these types are exposed in user-land.
-------------
Now, at this point, the Object Space should be completely
bootstrapped and ready for use. This is the end of the object space,
and the start of user-land.
I have a few other thoughts with respect to the user-level access to
the meta-model elements (Role, Class, Package & Module). I think that
these elements should be wrapped in roles, along with method and
attributes as well. The .meta level will then handle wrapping these
elements in their respective roles for use in user-land.
This means that when I do this:
my $m = Foo.meta.get_method('bar');
I get back the primitive 'bar' method wrapped in the Method role.
This Method role will probably gather some meta-information from
various sources (not just the primitive method itself), and allow the
user plenty of introspection capabilities.
Okay, thats all for now.
What do you all think?
Stevan
Stevan Little
These are some notes to add re: a short discussion with autrijus on
#perl6
The idea is that the interpreter/compiler is split into 3 parts.
- The first part parses the code, deals with flow control and syntax
stuff.
- The second part is the type engine. It has 2 phases:
phase 1: look at all type annotations and propagate them upwards
and downwards.
phase 2: standard type checking and inference
Then once all possible type information is squeezed out of the source
code, we go to the next part.
- Application-level (or user-level) code is then executed within the
context of the runtime (aka Object Space).
This is a very rough and high level view, and ignores little details
like macros, BEGIN blocks, etc.
Stevan
> user-level is discussed at the end of this document.
Larry Wall
: This is a very rough and high level view, and ignores little details
Yes, Perl 5 is conceptually a 3-pass compiler, but the passes have to
be interwoven to do the "literate compilation" thing that Perl demands.
Larry
Yuval Kogman
> Yes, Perl 5 is conceptually a 3-pass compiler, but the passes have to
> be interwoven to do the "literate compilation" thing that Perl demands.
But it's recursively interwoven.... If it was nonrecursive things
would be much uglier ;-)
IMHO, to ammend to stevan's mail, one fundamental step is linking.
This happens in the middle of the type checking phase - some type
info is extracted from a single unit, and other type info is
extracted from already compiled units that are being linked.
In Perl 5 linkage was completely ad-hoc, and was imperative, and
side effect reliant, as opposed to declarative:
*{$sym} = $subref;
The reason this part is fundamental is that it implies the
separation between the bits of code.
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!