Hi, > I don't like the leading C<.> option, what about having a leading _ for > temporaries instead and allowing any non-space, non-operator character > in symbol names, so _$foo would be a valid temp. This has the advantage > of not conflicting with symbolic registers. > But could it potentially conflict with labels, which also start with an underscore right now IIRC. I agree with the idea that non-alphanumeric should be allowed in symbol names, such as $, though. [1]
> The other option is to force registers to use a sigil that does not > occur in perl such as # # is currently used for comments. Of course, we can change this (and the underscore situation above if I'm right about it) if we really wanted...but... > Then all of the "normal" sigils (&, %, @, and $) would be available for use in variable names. It isn't just Perl we're dealing with. Other languages could potentially have other sigils. e.g. _ and #. Other languages have no sigils, in which case name mangling is certainly needed as a variable called I2, for example, would cause all kinds of "fun" if not mangled. I would go with the idea of having a sigil that is placed before all local variables, and another (different!) sigil for registers (of the IMCC-handled type). Anything without one of those is a direct register access. Or a syntax error. Clean, simple rules. What the sigils are is relatively immaterial if what is placed after them (for locals, not registers) can contains non-alphanumeric stuff. And whatever sigils a language wants can be put there. This way, name mangling can be "avoided" - though arguably we're defining a syntax that "auto-mangles". :-) Jonathan [1] (C|S)hould we potentially provide a "quoting" mechanism, e.g. for languages that want variable names containing characters that are not allowed due to IMCC syntax rules? Or is it up to the compiler to emit "compliant" names? And I'm too scared of unicode to mention unicode variable names.
