David Storrs writes:
> 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
You quote Larry's text about methods, then give an example using
functions! Your example is wrong: in the general case there must not be
whitespace between a function call and a left paren that is delimiting
its args. This is so that things like this behave themselves:
print (2 + 3) * 4;
That will be treated as:
print((2 + 3) * 4);
rather than the (pointless):
(print 2 + 3) * 4;
But in your example above they may actually evaluate to the same thing:
I think the parens in the second line are redundant (because the
precedence rules would cause things to be evaluated in that order
anyway) but benign (however I'm still shakey on exactly when lists need
to be splatted in Perl 6, so it's possible that I'm wrong and the parens
are actually treated like square brackets, passing in an array as a
single argument).
Regarding the question you actually asked, as to whether spaces are
permitted in method calls, there is no ambiguity: since method args have
to be surrounded by parens, there's no chance that in something like
this:
$obj.meth (2 + 3) * 4;
the arg could be anything other than 5. So perhaps spaces could be
allowed there, but for consistency with functions I'd prefer them to be
prohibited, and hence for the above line to be a syntax error.
> When you say "*no* arguments", does that mean that they do not get
> passed the implicit $self ref? (Or is that even relevant anymore?)
Things in the current object can now be accessed as C<$.thing> instead
of C<$self->{thing}>; this has nothing to do with the param list any
more.
> > 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($$$);
That isn't how parameter types are specified in Perl 6, anyway.
> .foo 1,2,3; # WRONG!
Yup -- by rule 2a you quoted above, a method call with arguments always
has to use parens.
> > 2d) Given 2c, additional arguments may occur as adverbs
> > whether or not there is an argument "pill":
>
> "pill" == parenthesized arg list?
That's my guess too.
> > 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?
It must be the former -- there can't be special rules just for the
latter! And if you look at the C<if> example Larry gives just after the
above para, it makes sense to mean any block.
> (Side note: This is my biggest problem with this operator--it makes
> discussions about pseudo- and/or skeleton code highly ambiguous.)
I agree!
> > 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?
I read the question mark as "well it must be a bare block cos it isn't
anything else, but I'm not entirely sure why anybody would put a bare
block there".
> > 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?
Yup.
> If the '1' wasn't there, then you'd have a legal statement (as per
> example above).
Yes; if the 1 wasn't there then the statement would exactly be one of
the preceding example, and therefore behave exactly as annotated in that
example! (How could it be anything else?)
> 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
Yes (as per Perl 5).
> (and maybe method)
Only methods without args (as per Perl 5).
> calls.Is this necessary?
Yes.
> Is it really that big an advantage?
Yes.
> 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 (). Totally
> unambiguous to the human and the parser, easy to comprehend,
> comfortable for people coming from basically any other language.
But there's no point in making Perl as awkward as some other language;
otherwise we could just use those other languages and not bother with
Perl. (Anyway, the first language I learnt was BBC Basic which didn't
require the parens either, so your statement isn't true for "any" other
language.)
> And it's only two characters.
But they're punctuation characters, and do add to the clutter. One of
the best things about Perl is that they can usually be omitted: almost
every script I've ever seen has many C<print> calls without parens.
Making them compulsory significantly raises the barrier to writing
really simple scripts.
Also, the more parens you have in a line the harder it is to spot
instantly which ones match up with which others (which is also why it's
important to get the operator precedence right, so that few parens are
needed for precedence overriding). If you put unnecessary parens round
function calls then it's less obvious which parens are actually doing
useful work in there, especially since chained function calls:
$text = join ' ', map { ucfirst }, split ' ', $text;
have instead to be written as nested calls:
$text = join(' ', map({ ucfirst }, split(' ', $text)));
Yes, I know that really they are nested, but with the paren-less version
I can treat them as though they are chained, which my brain finds easier
to cope with -- and if is inserted between two of the adjacent closing
braces at the end, it's hard to spot quickly exactly which paren closes
what and hence what the significance of the something is.
Smylers
