Michael Lacey wrote: > I'd want to be able to write/use code from multiple HLLs without any danger > of them stamping all over each other's data.
As I see it, HLLs are just languages, and it's not the _language_ that "stamps all over" the data. It's really the code-generating tools that have the potential to mess about with data - and those tools don't necessarily have a one-to-one relationship with languages. Consider, for example, Perl 6.0 and Perl 6.1 - they will almost certainly use namespaces in a compatible way - but there is no way that Parrot can enforce that. Should Parrot force them to use different namespaces, or should Parrot leave that to the discretion of the Perl 6.1 tool designer? And what about some future "Python for Parrot" and "Iron Python for Parrot"? Should Parrot force them to both use namespace "_python"? Or should Parrot require them to use different namespaces? Or should Parrot just leave that to the discretion of the tool designers? > I'd assumed Parrot would be enforcing namespace integrity... If we can define some rigorous notion of "namespace integrity", then we can consider whether that integrity can be best protected by Parrot, or by HLL code-generating tools, or by language-neutral tools (for example some kind of "namespace lint" tool). In the meantime, I think the best we can do is to leave it up to each tool author to use the namespaces that they are competent to use. If a certain tool doesn't play nicely with the namespaces that it touches, then people will simply stop using that tool. Regards, Roger Browne
