On Mon, Sep 10, 2001 at 11:26:03AM -0700, Benjamin Stuhl wrote:
> > It's not a prioirty, but it's so much easier to walk the
> > correct path from the start. Since it's all Parrot, it's even easier.
>
> Hear, hear! I remember the pain in 5.005_5* of turning off
> PERL_POLLUTE. I expect that there may still be CPAN modules
> that won't build without manually defining it.
You are, of course, correct; I back down. However, if you care that
much, I'm going to make you prove it by implementing it. :)
As Nat identifies, the problem is with deciding what should and shouldn't be
exported, especially on platforms which require an explicit "exports" list.
For instance, the interpreter ops should never see the light of day; other
functions might need to.
So sorting out namespaces ought to be unnecessary in many cases. For instance,
since interpreter ops should never escape from an object, there should be no
need to explicitly rename them - we simply don't export them. (But are there
platforms where you *can't* tell the linker or ar to not export certain
symbols?)
I am in two minds here. I want to have Parrot_... prefices on functions
even if they're *not* completely necessary /pour encourager les autres/.
However, I don't want to go the way of opening up everything in a public API
righht now, because once you've exported a symbol for developers to use, you
can never take it away from them again - whereas if nearly everything's
private and not exported, you can always open it up later.
So on balance, I think I'm not going to do anything about the Great Renaming
Issue until someone (myself included) has either come up with a patch and/or a
good proposal for what the Parrot API should look like for embedders.
And by embedders, don't forget we also mean Perl 6 itself, since Parrot is
just an interpreter - it's got to be fed bytecode from *somewhere*...
Simon
