This issue was not decided on, and in an attempt to fix this issue, so
this TODO can be closed, a proposition below.
Allison Randal wrote:
Matt Diephouse wrote:
I actually prefer the dot. I don't like the possible ambiguity between
types and local variables:
.local string MyClass
MyClass = '...'
$P0 = new MyClass # is this a type or a string?
At that point, what we're really talking about is sigils. So, why put
sigils on types instead of putting them on variables? And is dot
really the best sigil for types?
Capitalized variable names may be rare and/or bad practice, but it's
bound to happen. There was talk on #parrot about how this still
conflicts with macros, but those are rarer than variables.
If we're setting up a system to remove ambiguity, better to remove
ambiguity entirely than move to a slightly less common ambiguity.
Also, if we decide that anything starting with a dot that doesn't have
parens is a type, I could write:
$I0 = typeof $P0
if $I0 == .Foo goto bar
You can do that already.
Klaas-Jan Stol wrote:
A dot also indicates that this is not pure PASM, but rather PIR.
Except that the dot is required in PASM. Removing the dot was an added
bit of PIR syntatic sugar, intended to make it more human-readable
(and human-writable).
The dot implies the token is pre-processed by IMCC (the type is
looked up during parsing, IIRC), which is, IMHO, more consistent with
the other dot-prefixed tokens from PIR.
Except it's not consistent. To a certain extent type IDs act like
constants. You can:
print .String
Or, you can create your own constant and print it (PASM here):
.constant Foo 2
print .Foo
But if you try to create a constant with the same name as a type ID,
it is simply ignored:
.constant String 1
print .String
Prints "33" instead of the constant value "1".
It's an unfortunate conflict. (Not quite as unfortunate as the
variablename/methodname conflict, but still pretty awful.)
The proposal with respect to the dot-prefix is this:
* we keep the dot in front of Class IDs. (according to replies
above, more people are in favor)
* in order to get consistency, the ".constant <id> <value>"
construct from PASM should be removed. It makes me think a bit of
#define's in C, and both in C and in PIR we have a better alternative:
".const" <type> <id> "=" <value>.
Not only is the ambiguity removed, it's also "type safe", it removes
duplication of syntax (why have 2 ways to define constants?).
klaas-jan
