Re: Revision of A12's lookahead notions
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
Re: Revision of A12's lookahead notions
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 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
Re: Revision of A12's lookahead notions
On Tue, Aug 17, 2004 at 06:02:13PM +, 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 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
Re: Revision of A12's lookahead notions
On Tue, 2004-08-17 at 12:54, Larry Wall wrote: > But we'll just have to shoot anyone who makes a wisecrack like: > > use parens :lisp; Surely that should have its own pragma: use parenths; -- c
