On Tue, Aug 10, 2004 at 11:07:59AM -0700, Larry Wall wrote:
>
> 2) In the absence of evidence to the contrary, methods always
> assume they have *no* arguments. For methods:
>
> 2a) A method not followed by a left paren or colon has no
> arguments.
Just checking--whitespace doesn't count, right?
foo(1,2,3); # Func with 3 args
foo (1,2,3); # Same exact thing
When you say "*no* arguments", does that mean that they do not get
passed the implicit $self ref? (Or is that even relevant anymore?)
> 2b) As with multies, method declarations can have no effect on the
> parsing of methods. Unlike multis, the default is no arguments.
So, this doesn't work:
method foo($$$);
.foo 1,2,3; # WRONG!
> 2d) Given 2c, additional arguments may occur as adverbs
> whether or not there is an argument "pill":
"pill" == parenthesized arg list?
> 3) A bare {...} where an operator is expected always terminates the
> current list operator, and takes the precedence level back to statement
> level. That is, it pops all the implicit left parentheses of list
> operators with implicit right parentheses.
Is that a metasyntactic {...} or a literal y3 (yadda-yadda-yadda)
operator?
(Side note: This is my biggest problem with this operator--it makes
discussions about pseudo- and/or skeleton code highly ambiguous.)
> 3a) Note that an operator {...} cannot occur in the arguments of either
> a function or a method. Operator {...} is reserved for statement level
> control flow blocks.
> if blurk {...} {...} # 1st closure is arg, 2nd ifblock
> if blurk(1) {...} # closure is ifblock
> if blurk 1 {...} # closure is ifblock
> if .blurk {...} # closure is ifblock
> if .blurk {...} {...} # 1st is ifblock, 2nd is bare block?
Does that final question mark indicate uncertainty on your part about
how the language should be defined, or uncertainty on the parser's
part about what the code means?
> if .blurk 1 {...} # ILLEGAL
Just checking...this is illegal because 2c says that "[t]he only way
to pass arguments to a method is by an explicitly parenthesized list
or by adverb. Or by both." Correct? If the '1' wasn't there, then
you'd have a legal statement (as per example above).
> 3b) Term {...} cannot assume a comma after it if the next thing is
> a closure. Otherwise the first line under 3a breaks. The fifth
> line with a bare block is a bit problematic as a silent failure mode
> if the user expects the first block to be an argument to .blurk, which
> it isn't.
>
> 3c) Actually, despite the fact that I stated 3 in terms of
> precedence, as far as the parser is concerned 3 probably
> means that statement control things are parsed top down,
> and the bottom up expression parser simply stops when it hits
> an operator {...}.
>
> 4) Adverbs apply to the previous unparenthesized prefix, infix,
> or postfix operator, bypassing simple terms and other "pill"
> operators such as circumfix or postcircumfix.
>
> $a + $b :foo # applies to +
> $a + @b[2] :foo # applies to +
> $a + int($b) :foo # applies to int
> $a + (int($b)) :foo # applies to +
> @a.=sort:{ +$_ } # applies to .sort
> @a.sort(:quick):{ +$_ } # applies to .sort
> @a.sort:quick:{ +$_ } # both adverbs apply to .sort
Yoiks. This gives me the screaming willies. Couldn't we make it nice
and simple and say that adverbs must immediately follow (or
immediately precede, whichever you prefer, but pick one) their
operator?
$a +:foo $b # applies to +
$a +:foo @b[2] # applies to +
$a + int:foo($b) # applies to int
$a + (int($b)) :foo # WRONG!
@a.=sort:{ +$_ } # applies to .sort
@a.sort(:quick):{ +$_ } # applies to .sort
@a.sort:quick:{ +$_ } # both adverbs apply to .sort
Barring pathological cases where you pile up five or ten adverbs, this
seems like it reads clearer.
And while we're on the subject of making this simpler...there seem to
be a lot of cycles and contortions being devoted to making it possible
to leave the parens off of functions (and maybe method) calls. Is
this necessary? Is it really that big an advantage? Couldn't we just
make a nice, simple, easy-to-explain-and-remember rule that says "When
you call a func/meth, you always use (). Put whatever args you want
inside the ()." ??
Totally unambiguous to the human and the parser, easy to comprehend,
comfortable for people coming from basically any other language. And
it's only two characters.
--Dks
