[perl #41237] [TODO] PMC Class name IDs will require a dot in front

[Jerry Gay]

# New Ticket Created by Jerry Gay
# Please include the string: [perl #41237]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41237 >

from DEPRECATED.pod:

=head1 FUTURE changes

Not yet deprecated, but it's recommended to use the new syntax and
gradually change the old.

=over 4

=item PMC Class name IDs

... will require a dot in front

$P0 = new Integer => $P0 = new .Integer

this is a placeholder ticket for this proposed syntax, which is open
for discussion. currently, imcc accepts either syntax for pmc class
names.

i don't care which syntax imcc accepts, but i think it should only
accept one, and not both.
~jerry

[Allison Randal via RT]

> PMC Class name IDs ... will require a dot in front

My preference is to eliminate the dot in classname IDs. Lodge your
objections now, before it's made fact in 0.4.9.

Allison

[Matt Diephouse]

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?

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.

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

I know we're not optimizing PIR for human readability, but I've
written a lot of it, so I appreciate the little things. :)

--
Matt Diephouse
http://matt.diephouse.com

[Klaas-Jan Stol]

A dot also indicates that this is not pure PASM, but rather PIR. 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. One could also think about it like this:
the dot indicates the difference between a variable having a value
during compile time or runtime, or, in other words, a dot-prefixed name
is a variable during compile-time, and no-dot-prefixed name is a runtime
variable. So:

compile time:
.local pmc p
p = new .Hash # dot indicates ".Hash" is looked up during compile time
by IMCC

runtime:
.local pmc p
.local int hash_type
hash_type = find_type "Hash"
p = new hash_type # no dot means "hash_type" gets a value during
runtime (the previous statement in this case, but usually it may not be
as clear as this simple example)

Just a thought,
klaas-jan

[Patrick R. Michaud]

On Sun, Jan 14, 2007 at 11:58:10PM -0500, Matt Diephouse wrote:
> Allison Randal via RT <parrotbug...@parrotcode.org> wrote:
> >> PMC Class name IDs ... will require a dot in front
> >
> >My preference is to eliminate the dot in classname IDs. Lodge your
> >objections now, before it's made fact in 0.4.9.
> >
> >Allison
>
> 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?

Just to add my vote, I prefer the dot as well.

Pm

[Allison Randal]

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

[Klaas-Jan Stol]

This issue was not decided on, and in an attempt to fix this issue, so
this TODO can be closed, a proposition below.

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