[svn:perl6-synopsis] r8573 - doc/trunk/design/syn

[autr...@cvs.perl.org]

Author: autrijus
Date: Wed Apr 5 22:30:44 2006
New Revision: 8573

Modified:
doc/trunk/design/syn/S02.pod

Log:
* S02: fix the three places where the old form:
$x .(...)
needs to be replaced to the new form:
$x. (...)

Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Wed Apr 5 22:30:44 2006
@@ -358,7 +358,7 @@
whatever was to their left. Whitespace is not allowed between a
variable name and its subscript. However, there is a corresponding
B<dot> form of each subscript (C<@foo.[1]> and C<%bar.{'a'}>) which
-allows optional whitespace before the dot (except when interpolating).
+allows optional whitespace after the dot (except when interpolating).
Constant string subscripts may be placed in angles, so C<%bar.{'a'}>
may also be written as C<< %bar<a> >> or C<< %bar.<a> >>.

@@ -449,9 +449,9 @@
&foo($arg1, $arg2);

Whitespace is not allowed before the parens, but there is a corresponding
-C<.()> operator, which allows you to insert optional whitespace before the dot:
+C<.()> operator, which allows you to insert optional whitespace after the dot:

- &foo .($arg1, $arg2);
+ &foo. ($arg1, $arg2);

=item *

@@ -1316,15 +1316,15 @@
pairs. To align values of option pairs, you may not use the
dot postfix forms:

- :longkey .($value)
- :shortkey .<string>
- :fookey .{ $^a <=> $^b }
+ :longkey. ($value)
+ :shortkey. <string>
+ :fookey. { $^a <=> $^b }

These will be interpreted as

- :longkey(1) .($value)
- :shortkey(1) .<string>
- :fookey(1) .{ $^a <=> $^b }
+ :longkey(1). ($value)
+ :shortkey(1). <string>
+ :fookey(1). { $^a <=> $^b }

You just have to put spaces inside the parenthesis form to align things.

[TSa]

HaloO,

autr...@cvs.develooper.com wrote:
> * S02: fix the three places where the old form:
> $x .(...)
> needs to be replaced to the new form:
> $x. (...)

> - &foo .($arg1, $arg2);
> + &foo. ($arg1, $arg2);

What is the reason for this change? I find the
old definition of whitespace before the dot much
more pleasing. The trailing dot looks somewhat lost
and does not link to the arglist visually while
the preceding dot in .() made it look like a
method that binds leftwards. Same asthetics apply
to postfix ops where

$x .++;

looks better to my eyes than

$x. ++;

Does the same apply for method calls?

$x. foo;

I've always seen the method dot as a kind of pseudo
sigil. A metapher that doesn't work with whitespace
between dot and identifier.
--

[Juerd]

autr...@cvs.perl.org skribis 2006-04-05 22:30 (-0700):

> Whitespace is not allowed before the parens, but there is a corresponding
> -C<.()> operator, which allows you to insert optional whitespace before the dot:
> +C<.()> operator, which allows you to insert optional whitespace after the dot:
> - &foo .($arg1, $arg2);
> + &foo. ($arg1, $arg2);

If done consistently, this destroys the sane multiline markup:

$foo
.bar(...)
.baz(...)
.quux(...)

And I'd really hate to be forced to use this instead:

$foo.
bar(...).
baz(...).
quux(...)

because then you lose visual indication that bar, baz, and quux are
methods (rather than functions), and the . and the end of a line is
visually lost and probably easily forgotten.

Plus, I don't like continuation characters at all.

Please reconsider.

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Damian Conway]

Juerd wrote:

>>+C<.()> operator, which allows you to insert optional whitespace after the dot:
>>- &foo .($arg1, $arg2);
>>+ &foo. ($arg1, $arg2);

> Please reconsider.

We can't. The problem is that:

foo .bar

has to mean:

foo($_.bar)

So the only way to allow whitespace in dot operations is to put it after the dot.

Damian

[Juerd]

Damian Conway skribis 2006-04-06 20:41 (+1000):

> >Please reconsider.
> We can't. The problem is that:
> foo .bar
> has to mean:
> foo($_.bar)
> So the only way to allow whitespace in dot operations is to put it after
> the dot.

Given the consequences of this constraint, I think that perhaps
(probably!) sticking to foo .bar having to mean foo $_.bar is a bad
idea. Parens could effectively break the method name parsing. I don't
like typing parens, but I still like typing parens much better than
breaking a few of the most important principles in my syntax style.

And in this case, I think it breaks almost everyone's syntax style, not
just that of a few.

[Ruud H.G. van Tol]

Juerd schreef:
> autrijus:

>> - &foo .($arg1, $arg2);
>> + &foo. ($arg1, $arg2);

> [...]
> Please reconsider.

Yes, please come up with a different character to
bridge/cross/hide/cloak/skip/zap the succeeding "not allowed"
whitespace.

Maybe the "\", making "\<whitespace>" mean "s:s/\s+//".

--
Groet, Ruud

[TSa]

HaloO,

Damian Conway wrote:
> We can't. The problem is that:
>
> foo .bar
>
> has to mean:
>
> foo($_.bar)
>
> So the only way to allow whitespace in dot operations is to put it after
> the dot.

The obvious alternative is to make 'foo .bar' simply mean
'call foo and dispatch .bar on the return value'. The topic
comes into play only if there's no syntactical invocant.
Kind of last resort fallback to $_ before 'method on void'
error. Why should the dispatch on topic get such a privilege?

Note that a prominent, typical foo actually reads:

self .bar;

And a self($_.bar) is pretty much useless. In other words
wrongly huffmanized.
--

[Audrey Tang]

TSa wrote:
> Note that a prominent, typical foo actually reads:
>
> self .bar;
>
> And a self($_.bar) is pretty much useless. In other words
> wrongly huffmanized.

FWIW, I agree with both points. Some more points:

* I think both "say(.meth)" or ".meth.say" are more succinct/readable
than "say .meth" for "say($_.meth)".
* "say() .meth" is a parsefail according to the new rules, but can be
quite useful to align things up.

I committed r8573 only because of r8563 changed the dot/whitespace
interaction, which caused inconsistencies in other parts of the
example... The old interaction rules imho is quite easier to explain.

Audrey

[Larry Wall]

Okay, we could revert it, and .foo would remain term/operator sensitive,
and retroactively eat preceding whitespace when an operator is expected.
Just so you realize that it will make missing operators errors harder
to notice, particularly missing semicolon or comma. There have to be
some spots in the grammar that enforce synchronization by being syntax
errors, or we really will end up with a language that can parse line noise.

Another option would be to duplicate the . on both ends of the whitespace
when you want a delayed postfix:

say.
.foo.
.[32];

Somebody please point out all the downsides to this approach. But you're
only allowed to count "I'm not used to it yet" once. :-)

Larry

[Miroslav Silovic]

dam...@conway.org wrote:

> We can't. The problem is that:
>
> foo .bar
>
> has to mean:
>
> foo($_.bar)
>
> So the only way to allow whitespace in dot operations is to put it
> after the dot.
>
> Damian
>

I believe Larry's latest updates to Synopses allow for some syntactic
categories to be disabled in certain context, and to allow priorities
between categories. So would this make sense? --

- C<.bar> can be successfully parsed as both method call (postfixish
something?) and term
- when postfix is disallowed, such as at the beginning of an
expression or after a paren, C<.bar> is a term and means C<$_.bar>
- otherwise, it's a method call, and to get C<foo ($_.bar)> you have
to at least say C<foo (.bar)> -- requiring this actually seems more
readable to me.

Miro

[Juerd]

Larry Wall skribis 2006-04-06 9:01 (-0700):

> Okay, we could revert it, and .foo would remain term/operator sensitive,
> and retroactively eat preceding whitespace when an operator is expected.

Or change the definition so that something that looks like a method
call IS a method call, and that you have to put something else in
between (like parens) to avoid it.

So

.bar; # $_.bar
foo.bar; # foo.bar
foo .bar; # foo.bar
foo().bar; # foo.bar
foo(.bar); # foo($_.bar)
foo ~.bar; # foo(~$_.bar)
foo *.bar; # foo(*.bar)

That makes the parsing entirely predictible.

[David Green]

On 4/6/06, Larry Wall wrote:
>On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote:
>: TSa wrote:
>: > And a self($_.bar) is pretty much useless. In other words
>: > wrongly huffmanized.
>:
>: FWIW, I agree with both points.

I agree with those points too, but not necessarily the conclusion.
Sometimes Huffman is trumped by the principle of Knowing What the
Heck is Going On.

>Just so you realize that it will make missing operators errors harder
>to notice, particularly missing semicolon or comma. There have to be
>some spots in the grammar that enforce synchronization by being syntax
>errors, or we really will end up with a language that can parse line noise.

Yes. I like cute context tricks for their aesthetic elegance, but I
also like Perl 6's attempts to cut down on the number of rules I need
to memorise in order to parse stuff correctly in my head.

>Another option would be to duplicate the . on both ends of the whitespace
>when you want a delayed postfix:
>
> say.
> .foo.
> .[32];
>
>Somebody please point out all the downsides to this approach. But you're
>only allowed to count "I'm not used to it yet" once. :-)

Since my first thought was something like that, I'm already getting
used to it! Well, what I actually thought of was:
foo...
...[32]

...because the longer "..." draws more attention to the fact that
you're only seeing half the picture. But perhaps the pattern should
be more like ...+\s*...+ so you can say:

foo........................[32],
bar.........................[0],
sphygmomanometry.......[120/80];

-David "probably not serious about that" Green