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.)
Allison
