Apo 12
Austin Hastings
If it's not totally obvious to everyone, you should download a copy of A12
(I like the "printer-friendly" all-in-one-page version) as a hedge against
the almost-inevitable slashdotting.
Abhijit A. Mahabal
notation section:
$obj.method ($x + $y) + $z
From the earlier examples (like $obj.method +1), I got the impression that
you look ahead until you find a term or an operator. In the example above,
isn't ($x + $y) a full term, all by itself, and in that case would not
this mean ($obj.method($x + $y)) + $z, the same as the other call it is
contrasted with:
$obj.method($x + $y) + $z
What am I missing?
--Abhijit
Abhijit A. Mahabal http://www.cs.indiana.edu/~amahabal/
Larry Wall
: I do not understand one of the examples in the Use of methods/the dot
: notation section:
:
: $obj.method ($x + $y) + $z
:
: >From the earlier examples (like $obj.method +1), I got the impression that
: you look ahead until you find a term or an operator. In the example above,
: isn't ($x + $y) a full term, all by itself, and in that case would not
: this mean ($obj.method($x + $y)) + $z, the same as the other call it is
: contrasted with:
:
: $obj.method($x + $y) + $z
:
: What am I missing?
The distinction is not term/operator exactly. It's a four-way distinction
between
definitely a postfix op -> () hold arguments, otherwise no arguments
definitely a binary op -> there are no arguments
ambiguous -> require disambiguation
definitely a term -> treat method as list operator
where the last category assumes that the term indicates the first item
in an expression. (Note that a definite unary operator is the beginning
of a term.)
The basic underlying motivation is to allow methods a list operators:
$my.for 1..3 {...}
Now, we haven't actually defined what puts the method call into which
category. But the rather obvious poler opposites are
$obj.meth, -> obviously not arguments
$obj.meth $foo,$bar -> obviously arguments
If the rules get skewed one way or the other to eliminate the ambiguos
middle category, I'd say that we tend to give the benefit of the
doubt to the list, and you have to put a "stopper" like comma or a
right bracket or brace, or put explicit empty parens, if you want to
pass no arguments. But if we can unambiguously define what's ambiguous :-)
then it might be useful to force people to clarify what they mean, just
for readability.
Larry
Dan Sugalski
>On Sat, Apr 17, 2004 at 01:12:58PM -0400, Austin Hastings wrote:
>: If it's not totally obvious to everyone, you should download a copy of A12
>: (I like the "printer-friendly" all-in-one-page version) as a hedge against
>: the almost-inevitable slashdotting.
>
>
>Perhaps slashdot has decided they don't frontpage PhD dissertations. :-)
For that they leave it to lambda.weblogs.com to heap *educated* scorn
and derision on things. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Abhijit A. Mahabal
On Mon, 19 Apr 2004, Larry Wall wrote:
> On Sat, Apr 17, 2004 at 01:07:44PM -0500, Abhijit A. Mahabal wrote:
> : $obj.method ($x + $y) + $z
> :
> : >From the earlier examples (like $obj.method +1), I got the impression that
> : you look ahead until you find a term or an operator. In the example above,
> : isn't ($x + $y) a full term, all by itself, and in that case would not
> : What am I missing?
>
> The distinction is not term/operator exactly. It's a four-way distinction
> between
>
> definitely a postfix op -> () hold arguments, otherwise no arguments
> definitely a binary op -> there are no arguments
> ambiguous -> require disambiguation
> definitely a term -> treat method as list operator
>
> where the last category assumes that the term indicates the first item
> in an expression. (Note that a definite unary operator is the beginning
> of a term.)
> $obj.meth, -> obviously not arguments
> $obj.meth $foo,$bar -> obviously arguments
>
$obj.meth() + $bat -> obviosly not arguments
$obj.meth () + $bat -> obviosly not arguments
$obj.meth ($foo + $bar) + $bat -> ambiguous, likely to be list
$obj.meth($foo + $bar) + $bat -> $foo + $bar the argument
$obj.meth($foo + $bar), $bat -> list
Is that about the story so far? Or is the last example probably going to
be illegal without a space?
How bad is it to require space before arguments that are a list, so that
the no-space case is unambiguous?
> Larry
--Abhijit
Larry Wall
: (I like the "printer-friendly" all-in-one-page version) as a hedge against
: the almost-inevitable slashdotting.
Or not...
Perhaps slashdot has decided they don't frontpage PhD dissertations. :-)
Larry
Larry Wall
: > $obj.meth, -> obviously not arguments
: > $obj.meth $foo,$bar -> obviously arguments
: >
:
: $obj.meth() + $bat -> obviosly not arguments
: $obj.meth () + $bat -> obviosly not arguments
No, obviously arguments. Okay, I see the problem. What you're missing
is that in an earlier Apocalypse, we said that postfix subscripts
and argument lists may not have an intervening space.
: $obj.meth ($foo + $bar) + $bat -> ambiguous, likely to be list
No, obviously arguments.
: $obj.meth($foo + $bar) + $bat -> $foo + $bar the argument
Correct.
: $obj.meth($foo + $bar), $bat -> list
No, if you mean that $bat is the final argument to the method call.
Yes, if by that you mean the list is outside the method call. The
absence of a space makes ($foo + $bar) a postfix argument-supplying
operator. So this is parsed:
($obj.meth($foo + $bar)), $bat
: Is that about the story so far? Or is the last example probably going to
: be illegal without a space?
It's certainly not illegal, but it won't do what you want if you think
it'll pass $pat to $obj.meth.
: How bad is it to require space before arguments that are a list, so that
: the no-space case is unambiguous?
It may turn out that all the unambiguous cases do in fact require space
before the list (unless you use the explicit colon). However, that doesn't
necessarily make it beneficial to declare that
$obj.meth+1
is unambiguous in the other direction. I think if something is going
to be unclear to the *reader* of the code, we should probably not
make it easy to write it that way.
Larry
Larry Wall
: For that they leave it to lambda.weblogs.com to heap *educated* scorn
Hmm, well, in all their educatedness, they don't seem to have figured
out that the prototyping behavior they're looking for is actually
supplied by wildcard delegation in Perl 6...
Larry
Abhijit A. Mahabal
> is that in an earlier Apocalypse, we said that postfix subscripts
> and argument lists may not have an intervening space.
Oh, I see. Yes, I had missed that. Thanks for clearing that up.
--Abhijit
John Siracusa
Yeah, but did you see the story about that awesome new D language? It has a
native "dictionary" type!
-John
Larry Wall
Hey, it supports C syntax, so maybe we could compile Parrot in it. :-)
Larry
Aaron Sherman
Well, I think to be fair, it's going to take a long while for most of
the world to digest A12 and figure out how it does or does not deliver
their pet features / paradigms.
Prototyping in P6 would seem to me to be easy, but not quite the
default. You'd want an intermediary that did the MetaClass negotiation
as you "derived" from an existing object. Or will that be in the core?
Can you say:
my Object $obj1;
MyClassExtenderClass.add_a_print_method($obj1.metaclass);
my ::{$obj1.class} $obj2;
?
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Larry Wall
: Prototyping in P6 would seem to me to be easy, but not quite the
: default. You'd want an intermediary that did the MetaClass negotiation
: as you "derived" from an existing object. Or will that be in the core?
: Can you say:
:
: my Object $obj1;
: MyClassExtenderClass.add_a_print_method($obj1.metaclass);
: my ::{$obj1.class} $obj2;
:
: ?
How far you can take that will probably depend on the implementation of
the notification system within Parrot, which we have to rely on for any
kind of pull-the-semantic-carpet-out-from-under behavior modification.
Larry