Roger Browne <[EMAIL PROTECTED]> wrote:
> >     HLL Private Namespaces
> >         HLLs should use a namespace with an underscore and the lowercased
> >         name of the HLL to store any private items. For instance, Tcl should
> >         use the "_tcl" namespace to store the subroutines that make up the
> >         compiler.
>
> Is it the intention that Parrot will enforce that these names are kept
> private?

Nope.

ParTcl is written in PIR. Other compilers may also be written in PIR.
There are two things we want to avoid: conflicting symbols between
different compilers and conflict symbols between compilers and
user-defined code.

If compilers don't place their symbols in a namespace other than the
root namespace, two compilers may end up defining different symbols
that have the same name. ParTcl has a compile() sub, for instance. If
another compiler were to introduce a compile() sub in the same
namespace, things would break. So we need to put these somewhere.

You've suggested putting these internal subs under "tcl". But what
happens if the user tries to define a compile() sub in Tcl's root
namespace? Now we have the some problem: 2 different symbols with the
same name. We can't just change the internal sub to be _compile(),
because the user could also define a _compile(). We could prefix all
user-defined subs with some char, but that's a far amount of work.

Which is why I've suggested private HLL namespaces for compiler internals.

> If so, it would be good to say so.
>
> If not, then the HLL can store its private stuff however it wants (under
> its own first-level namespace), and define "import_into" so that it will
> refuse to share its private stuff. In that case, the HLL is responsible
> for keeping its own private stuff private, and there is no need for the
> spec to refer to unenforced private namespaces.

I don't think you'll really be interested in importing the guts of the
Tcl compiler into your program. But if that's what you really want,
I'm not going to stop you. (And neither should Parrot.)

--
matt diephouse
http://matt.diephouse.com

Reply via email to