Much discussion has been made on IRC concerning
symbol names.

The request, mainly, is for imcc to handle sigil characters
from other languages which basically equates to exposing
a lot to imcc from the high-level language. I won't
argue how much of that is good or bad; I'd rather just try to
make imcc as friendly as possible.

The state of things:

1) Declared symbols can be handled pretty easily with any character
we want to support, imcc just has to track it. It just so happens
that we don't allow many non alpha characters at this time.

2) $ is currently used to denote a symbolic register ($I[0-9]+ is an int
register).
which is not pre-declared. It just pops up in the instruction stream and
imcc assigns a register.

It is possible that we can stick with $ for temporaries, but make imcc
check symbol tables first, and allow people to declare symbols with $
as well. This would solve some issues but might make for some
confusing looking code.

In reality it would not really be that confusing if you don't know your
variables the same convention as temporaries, but who can guarantee
that.

.local PerlString $str
.local PerlString $I123
$I123 = "help"
$str = $I123
$I124 = 1 + 2
$125 = $124 * 3

The $ no longer stands out as a temporary, so maybe we choose a different
character for temp registers (I have suggested using a period C<.>)

.local PerlString $str
.local PerlString $I123
$I123 = "help"
$str = $I123
.i124 = 1 + 2
.i125 = .i124 * 3

Another option is to use quotes for symbols with sigils, but since most
of our code will end up coming from Perl6, that won't be optimizing
for the common case.

Finally, I for one, support name mangling. Its arguable how much high
level compilers should expose to the back-end compiler. I think, though,
that most people prefer to be able to debug PIR code and see the
original symbols, and I sympathize.

This is just an example to stimulate discussion. I'd like to hear all sides
before making any decisions.

(And remember namespaces when considering solutions)

-Melvin