On Tue, Aug 17, 2004 at 06:02:13PM +0000, Smylers wrote:
: David Storrs writes:
: > 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).
It would depend on whether you declared
sub foo ($a, $b, $c)
or
sub foo ([EMAIL PROTECTED])
With the first declaration, for the second example $a would end
up with [1,2,3], because parens in a scalar context work like [].
With the second declaration, you'd end up with 1,2,3 in the array,
because parens in a list context flatten as they do in Perl 5.
(On the principle that parens are really only for grouping, to
tell the compiler when to ignore operator precedence. The fact that
scalar parens can work like [] is not really a fact about parens but
a fact about the comma operator within the parens.)
: 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.
Yes, though certainly someone will come up with a pragma to say something
like:
use mandatory_parens;
in which case, since the parens are mandatory on arguments, it wouldn't
be ambiguous to allow whitespace. But then you'd have to write all
your attributes as
$obj.attr()
: > > 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.
Mine 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!
In general, if I mean a literal "yada-yada-yada", I'll say that. But it's
not a big problem if you assume that C<...> always indicates pseudo code.
It's just that Perl 6 allows you to compile certain forms of pseudo-code.
: 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".
Yes, with an additional undertone of: "and maybe there should be a
warning for something so obviously screwy".
Or maybe we just require that a bare closure must start on its own line,
which would turn the above into a syntax error.
: > 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.
Especially since it'll be trivially easy to turn Perl into an awkward
language by saying:
use parens :mandatory;
or some such to re-institute C lexer semantics. That's not to be
confused with:
use parens :stickinthemud;
which presumably re-institutes the Perl 5 lexer mess.
But we'll just have to shoot anyone who makes a wisecrack like:
use parens :lisp;
Larry
