> 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
Quite so, tho I wasn't aware that the tools might not have a one-to-one
relationship with languages.
I was expecting Parrot to force code generating tools to specify the
namespace they want to work in.
I'm probably looking at this far too simplistically but I was expecting to
read something like this.
Naming Conventions
For interoperability, languages will use hierarchical namespaces; this
will be enforced using HLL Private Namespaces.
HLL Private Namespaces
HLLs must specify their private namespace using the
".hll_prv_namespace" directive
User Defined Namespaces
All HLLs will create namespaces within the HLL's Private Namespace.
This eliminates any
accidental collisions between languages.
I hope people will pardon me butting in. I'm not a language designer nor
even much of a language *user* anymore; I help people fit things together
that I don't begin to understand and I watch this list because I find the
way that people work together here interesting.
Mike
--
Mike Lacey
Project Manager
Partner Services
07717 458 268
On 02/12/05, Roger Browne <[EMAIL PROTECTED]> wrote:
>
> 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
>
>
