Jonathan Worthington writes:
> 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". :-)
Hooray! That is precisely what sigils are for. No use in making a
"variable" sigil that shares its name with a register sigil.
On the other hand, we could define four sigils and do away with the
$S358 syntax, like so:
?foo # I register
+foo # N register
~foo # S register
$foo # P register
(I took the most Perl6ish representitave sigils I could think of...
doesn't matter what they are, really)
> 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.
I can envisage something like:
$'%foo' = new PerlHash
But is that all that more readable than:
$Hfoo = new PerlHash
I would say we should definitely go with something like this if
registers held more permanent values. But in writing my own compilers,
I've found that most of my register naming comes from prefixing a
constant string to an incremented counter. Lexical pads already let
you do this, and those are the ones that need to.
Bascially, I think the current system works fine, but it would be nice
to namespace locals somehow.
Luke
