Matt Diephouse wrote:
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
According to pdd21, each HLL gets its own hll_namespace.
PGE is really a form of HLL compiler, so it should have
its own hll_namespace, instead of using parrot's hll namespace:
.HLL 'pge', ''
I don't know that that's necessarily the case, but it's definitely an
option. You can just as easily argue that it's a library.
It comes down to a question of whether Perl 6 grammars are a high-level
language. Debatable, so I'd go with whichever is easiest to work with
both within PGE, and in code that uses PGE.
Within PGE, it comes down to whether you have to prefix every access to
a PGE module with the PGE namespace, or whether you can use the .HLL
directive to set a "default".
Outside PGE, it's a question of whether you can access the module
directly or have to take extra steps to reach it as a module outside
your current HLL. Or, if we say you can only directly access namespaces
within your current HLL, then it's a question of whether you can access
PGE modules in the 'parrot' HLL (so in the general case you only have to
work with two HLLs: your own and 'parrot'), or whether you have to work
with an arbitrary number of different HLLs to access core modules like
PGE and TGE. With this in mind, I lean toward putting PGE in the
'parrot' HLL.
But, agreed, the namespace pollution problem needs to be solved either way.
Now then, the 'PGE::' prefixes on the classnames were
just implementation artifacts of working in a globally
flat namespace -- as a high-level language PGE really
ought to be referring to its classes as 'Match',
'Exp', 'Literal', etc. So, if we're in the PGE HLL,
we ought to be able to drop the 'PGE::' prefix from
our classnames and namespaces.
So, here's the revised version of the code to create
the classes:
.HLL 'pge', ''
.sub __onload :load
$P0 = newclass 'Exp'
$P0 = subclass 'Exp', 'Literal'
$P0 = subclass 'Exp', 'Group'
$P0 = subclass 'Exp', 'CGroup'
$P0 = subclass 'Exp', 'Subrule'
$P0 = subclass 'Exp', 'Closure'
# ...
.end
This code fails when run from parrot, because Parrot seemingly
already has a class named 'Closure':
$ ./parrot ns.pir
Class Closure already registered!
current instr.: '__onload' pc 19 ( ns.pir:9)
$
So, this brings me to my question: What is the official
"best practice" pattern for HLLs to create their own classes
such that we avoid naming conflicts with existing classes
in Parrot and other HLLs?
This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
a relic of the past and I think it needs to change. I'm pretty sure
that HLL classes will have to go into the HLL's root namespace (this
needs to happen anyway to prevent namespace pollution). That leaves us
with the question of how to differentiate core PMCs from HLL PMCs. I'm
not sure how to handle that, but that's what a spec is for.
Aye, if a class is defined in an HLL namespace, it shouldn't also exist
in the 'parrot' namespace. I'd call this a bug, 'subclass' should
respect the current namespace (which should be set by the .HLL directive).
We discussed some of this briefly at the OSCON hackathon, when we
talked about changing the class internals so that a Class isa
Namespace. That discussion hasn't led to any changes yet as Chip has
been kidnapped by his Real Life (tm).
That's still a possibility, but it may also end up as Class is linked to
a Namespace. (Anonymous classes have no namespace, but may be associated
with a namespace at runtime.)
I think the object model needs a thorough going over in general
Yup. It's on the list right after I/O, threads, and events.
-- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO language has been implemented yet on Parrot; everything up to this
point has been either procedural or functional.
Ruby is a serious OO language, but it's not finished yet. For that
matter, Perl 6 is partially implemented. But, I entirely agree on the
core point that pushing these languages forward will help push Parrot
forward.
Allison
