Jeff Clites wrote:
That's it. No typing, no classification, no nothing.
By postpending a null character, below, you _are_ doing typing/classification, of course. And, what about subs?
I was kind of inspired here. Just stick with me.
As Larry said, it's best to prepend it. And then we can call it a sigil. And since we're name mangling, pick a printable character like ":" for the prefix, since we'll know the initial character is always really a throw-away encoding of the syntactic category. Then we're back to _exactly_ my scheme, with the syntactic category names as single characters, and as an implementation detail shoving the category and name together in a single string instead of keeping them separate. And of course this will all be awkward for languages with distinct syntactic categories, but without natural name mangling. And it will probably result in more intermediate strings being allocated.
At this point I think it went too far.
We don't need Larry, Matz, and Guido to agree on anything here.
I can agree here.
It just requires acknowledging that different languages have
different sets of syntactic categories, rather than pretending things are simpler than they are.
I have a little idea that sprang from all of this. Let parrot have sigils. Not perl sigils or anyone elses. The only reason Dan seems to what to mark namespaces with a null is not because it has to mean anything to a high level language. It's because parrot is going to do something special with them. (The unified namespace thingy, right?) If parrot is going to treat sub special on behalf of HLL that wants to cooperate, then fine. Give subs a sigil of some sort so parrot can tell. (I'm assuming that was a reason for the separation of code in the original proposal. If not that scrap the sub sigil.)
To be honest, even with the grand unified namespace I would guess a HLL could implement their own namespaces without a namespace sigil. They just wouldn't get the advantage of using parrot's namespace aware ops or interoperating with the languages that do. If a language wants the advanage of the parrot namespaces, then it's a compiler issue. Mangle away.
I would say have the sigil first in the name since it would speed up inspection. Have null (or some other (printable?) namespace sigil) for namespaces, a sigil for callable code if Dan wants parrot to do something smart with that, and others for things that parrot can treat special. (Files?) I think there probably ought to be a 'safe' sigil that simply tells parrot that it shouldn't assuming anything special about it. Likewise, symbols that don't start with a know sigil could be treated this way, with the added risk that maybe a later version of parrot might get a new sigil for some new set of ops.
Ofcourse this still falls apart if you have a symbol that is supposed to be many things at once. It was just a thought. Scrap langauge specific syntactic categories and just define ones that would allow parrot to provide useful/smarter behavior, like the unified namespace.
Dan (no, not /that/ Dan)
