Larry Wall wrote:
> On 26 Oct 2002, Smylers wrote:
>
> : Larry Wall wrote:
> :
> : > print(length $a), "\n";
> : > print (length $a), "\n";
> :
> : Those look to me like they should do the same thing as each other.
>
> Sorry, they don't look that way to me.
Having slept on it, I'm not as scared about whitespace being significant
as I was yesterday. (Also I think there may be a precedent for this in
BBC Basic of all things[*0].)
> : What would be the harm in not having any special rule here ... ?
>
> The harm would be that we'd basically be reinventing Lisp syntax with
> precedence in place of some of the parens.
I have memories that before I went to bed last night I saw a good
example from Damian demonstrating the harm, but I can't find it this
morning.[*1] It went something along the lines of:
outer(foo(1), bar(2)); # A
being treated as though it were
outer foo(1, bar 2); # B
Personally I've got no problem with the way of getting the Perl 5
meaning of A being:
outer (foo 1), (bar 2); #C
It still feels a shame that there are two places the opening paren can
go (before and after the function name) and there are two meanings that
need to be distinguished (a single-arg function and a multi-arg function
with precedence around the first param) yet both bracket positions give
one meaning and there isn't a positioning that gives the second.
However I see that blatantly the rule is needed. Just because B and C
are possible doesn't mean that people won't try to write A, and it is
completely ludicrous for A to have the meaning of B rather than of C.
Also the rule means that sometimes you might pass fewer args to a
function than you'd intended. This often results in a constant in void
context, which can be warned against. Not having the rule just results
in precedence being different to that intended, which I don't think
could be picked up with a warning!
> ($obj.foo.bar.baz[3]{"finagle"}.each.subobj.print length $a), "\n";
>
> That's not so good. Unless you make method syntax different from
> functions. Which is also not so good.
Method syntax already is different from functions, in that methods
require parens. If functions always required parens this ambiguity
wouldn't exist. (Note I am definitely _not_ suggesting that they
should!)
> I do think that "." may be the wrong character to "eat" whitespace
> though.
>
> $hash .[$key]
> $hash _[$key]
You've convinced me. This sounds to be the best of anything I've seen:
1 It always does the right thing if you use whitespace in the way that
people nearly always do already, making things like this work:
foo (1 + 2), 3;
2 C fans can continue to have this working as they expect:
outer(foo(1), bar(2));
3 Lisp fans can put parens round the outside of function names and get
the behaviour they want (so long as they put a space the function
names).
4 There is a way of changing the behaviour should none of the above be
good enough for you.
> Reminds me of the old problem of what to use if we adopted the rule I
> keep hankering for that says a final } on a line ends the current
> statement.
I still reckon I could live with the consistency of always needing a
semicolon at the end of statements, including loops and sub definitions.
But again I can see why this would frustrate many people, and
continually getting compilation errors because of missing semicolons
would get tedious.
> A _ could be made to suppress whitespace interpretation there too,
> only on the other end of the bracket:
>
> $x = do { foo(); bar(); baz() }_
> + 2;
So if there's going to be a brace and line-break rule having a way of
overriding would be good. Having the same character used for overriding
all whitespace rules is also good.
Underscore is also the character used to suppress the meaning of
line-breaks in Visual Basic, I think, where there must be a space before
the trailing underscore. I note that any VB programmer trying that
here:
$x = do { foo(); bar(); baz() } _
+ 2;
would end up concatenating the character rather than adding the number 2
on to that expression. I'm wondering if that is too subtle? (I'm
hoping not, because I do like the idea.)
> Using _ rather than . would prevent it from being interpreted as a
> method call.
I think it's worth having that distinction.
*0 Most function calls required brackets, but they could be omitted
when calling built-in functions which took a single argument. However
if you did include them I'm fairly sure a space wasn't allowed.
*1 I'm hoping the reason for this is that Damian mailed me personally
and I deleted the message, assuming (wrongly) that it'd also be on the
list and I'd find it on the NNTP server later. Cos the alternative is
that I was dreaming about Damian sending me e-mails, and that's _really_
scary.
Smylers
