parse problem with subroutines?
David D Zuhn
only work with no whitespace between the sub name and the arguments.
sub numcmp ($a, $b) { return $a <=> $b };
$v = numcmp(1,2); # works fine
$v = numcmp (1,2); # fails with
$v = numcmp
I don't see anywhere in the canon that no whitespace is allowed
between the function name and the opening paren of the arguments.
E6 /Molecules/ states that whitespace is optional.
Attached is a test case suitable for pugs (t/subroutines/numcmp.t).
david d zuhn
z...@stpaulterminal.org
Carl Franks
> Running pugs r4158, I find that (some, at least) subroutine calls
> only work with no whitespace between the sub name and the arguments.
>
>
> between the function name and the opening paren of the arguments.
Synopsis 2:
Whitespace is not allowed before the parens, but there is a
corresponding .() operator, which allows you to insert optional
whitespace before the dot.
$v = numcmp .(1,2); # should pass
Cheers,
Carl
Carl Franks
> perl that ought to be made a bit clearer (it's not in the p5->p6 porting
> guide, for example).
Agreed.
I remembered this being discussed by Abigail. Found it here:
http://www.perlmonks.org/?node_id=346083
It references A12 - "methods":
Parentheses are required on the dot notation if there are any
arguments (not counting adverbial arguments). There may be no space
between the method name and the left parenthesis unless you use the
dot form of parentheses:
.doit # okay, no arguments
.doit() # okay, no arguments
.doit () # ILLEGAL (two terms in a row)
.doit.() # okay, no arguments, same as .doit()
.doit .() # okay, no arguments, same as .doit()
Carl
David D Zuhn
> Synopsis 2:
> Whitespace is not allowed before the parens, but there is a
> corresponding .() operator, which allows you to insert optional
> whitespace before the dot.
>
> $v = numcmp .(1,2); # should pass
The quoted text is in a paragraph describing explicit function
references and how to call through them.
If this is indeed a statement that all function calls, especially
the ordinary sort that are used most often, must be of the form "a(b)"
rather than allowing "a (b)", this is a pretty fundamental change in
perl that ought to be made a bit clearer (it's not in the p5->p6 porting
guide, for example).
david d zuhn
z...@stpaulterminal.org
Carl Franks
Shall I remove what I'd already added to the bottom of the file?
Carl
Carl Franks
> I didn't really realize that there was a p5->p6 porting guide until I
> saw this. I'll add something to the guide as above (plus subs).
I've already added a bit about method calls, but I'll leave it alone
for you to do arrays/hashes.
Carl
Jonathan Scott Duff
> If this is indeed a statement that all function calls, especially
> the ordinary sort that are used most often, must be of the form "a(b)"
> rather than allowing "a (b)", this is a pretty fundamental change in
> perl that ought to be made a bit clearer
It's not just function calls. Arrays and hashes require no whitespace
between the name and the subscript unless you use the dot form.
@a[0] # ok
@a.[0] # ok
@a [0] # WRONG
@a .[0] # ok
%h{'k'} # ok
%h.{'k'} # ok
%h {'k'} # WRONG
%h .{'k'} # ok
%h<k> # ok
%h.<k> # ok
%h <k> # WRONG
%h .<k> # ok
Also note that the dot follows the subscript so that the following are
also incorrect:
foo. () # WRONG
@a. [0] # WRONG
%h. {'k'} # WRONG
%h. <k> # WRONG
Unless I'm completely mistaken, in which case someone had better
correct me :-)
> (it's not in the p5->p6 porting guide, for example).
I didn't really realize that there was a p5->p6 porting guide until I
saw this. I'll add something to the guide as above (plus subs).
-Scott
--
Jonathan Scott Duff
du...@pobox.com