Re: A shorter long dot
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
Maybe you all write your code differently to me, but looking through a
load of my OO code I had trouble finding three method calls in a row to
any methods on any objects, let alone six calls to the same method name
on different objects.
If I saw code like
$xyzzy.foo();
$fooz\.foo();
$foo\ .foo();
$fa\ .foo();
$and_a_long_one_I_still_want_to_align\
.foo();
$etc\ .foo();
I'd probably take that as a pretty strong clue that I should really have
written
$_.foo for @things_to_foo;
or something.
I like lining up my code as much as the next programmer, and probably a
lot more, but I just don't see the need for this syntax which seems
ugly, confusing and unnecessary.
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
--
Markus Laire
Re: A shorter long dot
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Thinking about it a bit, I suppose the problem would be how to parse
something like
if $person eq %people {'john'} { ... }
which would be valid whichever way you parsed it, right?
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
I'm probably not seeing what the rest of the several useful
side-effects are, and I'm probably far too conservative, but given the
choice between the following I know which one I would choose.
if ($value eq $target) {
$monsters{cookie} = Monster-new;
$people {john } = Person -new;
$cats{fluffy} = Cat-new;
}
if $value eq $target {
%monsters.{'cookie'} = Monster.new;
%people\ .{'john' } = Person\.new;
%cats\ .{'fluffy'} = Cat\ .new;
}
if $value eq $target {
%monsters.cookie = Monster.new;
%people\ .john = Person\.new;
%cats\ .fluffy = Cat\ .new;
}
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Otherwise I'll hope that, as has happened a number of times before, someone
will decide that this is too ugly to live and will create something nicer.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: A shorter long dot
On 5/4/06, Paul Johnson [EMAIL PROTECTED] wrote:
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Yep, I think it's syntax error.
Note that {} here is a postfix (actually postcircumfix) operator, and
the decision to never allow whitespace before postfix operators seems
to be quite fundamental in perl6.
Some relevant sections from Synopses:
(These sections are quite long, so I'm not copy-pasting them here.)
From Synopsis 2 at http://dev.perl.org/perl6/doc/design/syn/S02.html
See the section starting with In general, whitespace is optional in
Perl 6 except
From Synopsis 3 at http://dev.perl.org/perl6/doc/design/syn/S03.html
See the section starting with List operators are all parsed consistently.
And Synopsis 4 at http://dev.perl.org/perl6/doc/design/syn/S04.html
is also related to this.
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Have you *recently* read the Synopses at
http://dev.perl.org/perl6/doc/synopsis.html
I'm currently re-reading them, and if you have some time (few days or
weeks :), I'd suggest reading them all.
--
Markus Laire
Re: A shorter long dot
Jonathan Lang writes: Larry Wall wrote: I don't see much downside to \. as a long dot. The only remaining problem that I see for the long dot is largely orthogonal to the selection of the first and last characters - namely, that your only choice for filler is whitespace. Why's that a problem? Folks want to be able to line stuff up, and to split statements over multiple lines. This is now possible. Smylers
Re: A shorter long dot
Jonathan Lang schreef:
When is the last time that you saw an underscore-only method name?
sub _{print$_\n};
--
Affijn, Ruud
Gewoon is een tijger.
Re: A shorter long dot
On Mon, May 01, 2006 at 01:15:58PM +0100, Smylers wrote: Jonathan Lang writes: Larry Wall wrote: I don't see much downside to \. as a long dot. Folks want to be able to line stuff up, and to split statements over multiple lines. This is now possible. You know, I'm still wondering who these folks are. Seriously. Maybe you all write your code differently to me, but looking through a load of my OO code I had trouble finding three method calls in a row to any methods on any objects, let alone six calls to the same method name on different objects. If I saw code like $xyzzy.foo(); $fooz\.foo(); $foo\ .foo(); $fa\ .foo(); $and_a_long_one_I_still_want_to_align\ .foo(); $etc\ .foo(); I'd probably take that as a pretty strong clue that I should really have written $_.foo for @things_to_foo; or something. I like lining up my code as much as the next programmer, and probably a lot more, but I just don't see the need for this syntax which seems ugly, confusing and unnecessary. But then again, as I said, I really don't see the problem that is being solved. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: A shorter long dot
On Saturday 29 April 2006 21:50, Damian Conway wrote: Is: $antler. .bar; $xyzzy. .bar; $blah. .bar; $foo. .bar; really so intolerable, for those who are gung-ho to line up the method names? I'm still wondering what's awful about: $antler.bar; $xyzzy.bar; $blah.bar; $foo.bar; -- c
Re: A shorter long dot
Austin Hastings wrote: Or, to put it another way: what hard problem is it that you guys are actively avoiding, that you've spent a week talking about making substantial changes to the language in order to facilitate lining up method names? That's a very good point too. Initially it's just a cute idea for filling in the 2-character method invocation gap, as well as making $x.+method and $x.:method line up, but it's probably not worth people's time in arguing this any further... Consider my suggestion retracted, and sorry for the disturbance in the force. :) Thanks, Audrey signature.asc Description: OpenPGP digital signature
Re: A shorter long dot
Damian Conway skribis 2006-04-30 9:49 (+1000): This would make the enormous semantic difference between: foo. :bar() and: foo :bar() And how is that very different from the enormous semantic difference between: foo. .bar() and: foo .bar() that already exists? I understand your point, and tend to agree with it, but it counts for both .: AND . .. PS: While I can understand the appeal to laziness, I'm not at all convinced by the argument: And it's a lot of work (many, many keystrokes!) to go back and change something. In vim, the exact number of keystrokes to realign the long dots of N lines is 7+N. If you plan it, sure. But without planning, you easily get to 12 and more. It's not just about the number of keystrokes, though. Having to go back itself is awkward. We need to be careful not to require the language to solve problems that are better solved with tools. I think we should be careful, and are careful, to support lots of tools. Many programmers prefer simple editors. Many programmers who use advanced editors, like to keep them at the default settings. And whenever you have to create a macro to do something that's common in a certain programming language, that programming language was badly designed. Let's not let Perl 6 be such a language. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
chromatic skribis 2006-04-30 2:06 (-0700): I'm still wondering what's awful about: $antler.bar; $xyzzy.bar; $blah.bar; $foo.bar; That's what I will do when current long dot stays, but I prefer to keep things left-aligned to the indentation level. These cascades look messy. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Yuval Kogman skribis 2006-04-30 2:58 (+0300): We need to be careful not to require the language to solve problems that are better solved with tools. On that point I agree, but I think it was a question of aesthetics... Juerd? Yes, it was about both aesthetics and the extra work involved. But mostly aesthetics and a bad feeling. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Jonathan Lang skribis 2006-04-29 19:08 (-0700): Is there a reason that we've been insisting that a long dot should use whitespace as filling? I don't know. foo.___.bar Would still have the problem of clashing with .. when there's no _ in between. foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. Perhaps whitespace can be allowed in numbers too: 5 000 000; 5_000_000; Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Audrey Tang skribis 2006-04-30 17:31 (+0800): Austin Hastings wrote: Or, to put it another way: what hard problem is it that you guys are actively avoiding, that you've spent a week talking about making substantial changes to the language in order to facilitate lining up method names? Sorry, I disagree strongly. Lining things up is an important aspect to how people use Perl. Consider my suggestion retracted, and sorry for the disturbance in the force. :) I still want to talk about it. Good arguments (about trailing dot being hard to spot, and about underscores) are made, and I think healthy discussion can lead to a much better solution than the current long dot. People who think it wastes their time, by now know what this thread is about, and can choose to ignore it. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
On 4/30/06 7:44 AM, Juerd wrote: Jonathan Lang skribis 2006-04-29 19:08 (-0700): Is there a reason that we've been insisting that a long dot should use whitespace as filling? I don't know. foo.___.bar Would still have the problem of clashing with .. when there's no _ in between. foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. No one's going to use either of these because they're ugly. Lining things up is at least partly about making things pretty for most people. -John
Re: A shorter long dot
John Siracusa skribis 2006-04-30 8:15 (-0400): foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. No one's going to use either of these because they're ugly. I am not going to use either of these because I think they're ugly. I don't think it's ugly. It's not any less tidy. $xyzzy.foo() $xyzzy.foo() $fooz.:foo() $fooz.:foo() $foo._:foo() $foo. :foo() $da.__:foo() $fa. :foo() My variable names aren't so long that I'm likely to have foo.___:bar, and $foo.__:bar is clean. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
I don't think it's ugly. It's not any less tidy. $xyzzy.foo() $xyzzy.foo() $fooz.:foo() $fooz.:foo() $foo._:foo() $foo. :foo() $da.__:foo() $fa. :foo() My variable names aren't so long that I'm likely to have foo.___:bar, and $foo.__:bar is clean. But it doesn't work across lines: $xyzzy.foo() $fooz.:foo() $foo. :foo() $fa. :foo() $and_a_long_one_I_still_want_to_align. :foo() $etc. :foo() -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: A shorter long dot
Juerd wrote: foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. When is the last time that you saw an underscore-only method name? Gaal Yahas wrote: But it doesn't work across lines: Take another look at my original proposal: I didn't suggest _replacing_ whitespace with underscores; I suggested _supplementing_ it[1] - so $xyzzy.foo() $fooz.:foo() $foo. :foo() $fa. :foo() $and_a_long_one_I_still_want_to_align. :foo() $etc. :foo() would still work, but so would $foo._:foo() $fa.__:foo() $and_a_long_one_I_still_want_to_align._ __:foo() $etc._:foo() ...and the latter five would be the recommended way of doing it. -- Jonathan Lang [1] This is a nod to TIMTOWTDI; technically, one could be as restrictive as requiring any block of whitespace in a long dot to begin with a newline (thus restricting its use to line wrapping and alignment of the new line) and still have a perfectly viable long dot syntax.
Re: A shorter long dot
On Sat, Apr 29, 2006 at 05:15:08PM +0200, Juerd wrote: : Larry indicated that changing the long dot would have to involve : changing the first character. The only feasible solution in the tiny : glyphs section was the backtick. I refrain from explaining why that : will widely be considered a bad idea. Only feasible? I think you guys give up too easily. I believe either or both of ¬ or \ qualify as feasible, actually: $xyzzy.foo(); $fooz\.foo(); $foo\ .foo(); $xyzzy.foo(); $fooz¬.foo(); $foo¬ .foo(); Neither of those are currently legal in infix position. The backslash has the advantage of hiding semantics, so it would mean hide any whitespace before the next dot (including no whitespace). The NOT operator can have similar semantics Here is some *not* whitespace. Actually, there is a postfix \(...), but that wouldn't interfere with a \. construct. Visually you'd never use \. in a place where there weren't also longer dots, so there's surrounding context indicating that \ is not trying to backslash the dot itself. Alternately, as with French quotes, the ¬ could be the primary form, and \ (or something like it, -| maybe) would be the Texas version. Backslash also has the advantage of making sense to a C programmer: $foo\ .foo(); even though it has been generalized to quote any whitespace, not just newline, so that $foo\ # comment .foo(); works. So of course the $foo\#[ comment ].foo(); also would work if you want more visual distinction on both ends of the whitespace. Larry
Re: A shorter long dot
Gaal Yahas skribis 2006-04-30 16:05 (+0300): But it doesn't work across lines: $and_a_long_one_I_still_want_to_align. :foo() Explain to me why it wouldn't work, please. I don't get it. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
Larry Wall skribis 2006-04-30 9:58 (-0700): On Sat, Apr 29, 2006 at 05:15:08PM +0200, Juerd wrote: : Larry indicated that changing the long dot would have to involve : changing the first character. The only feasible solution in the tiny : glyphs section was the backtick. I refrain from explaining why that : will widely be considered a bad idea. Only feasible? I think you guys give up too easily. ... in the tiny glyphs section. We could go with larger glyphs, like \, of course -- it just hadn't been considered yet. Actually, there is a postfix \(...), but that wouldn't interfere with a \. construct. There's prefix \, though: It creates a big difference between $foo \.bar and $foo\ .bar # currently the same thing But I don't think that's a problem. $foo\ .foo(); I've never liked continuation characters, but I could live with this limited application. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: A shorter long dot
On Sun, Apr 30, 2006 at 09:58:21AM -0700, Larry Wall wrote: Neither of those are currently legal in infix position. The backslash Backslash also has the advantage of making sense to a C programmer: $foo\ .foo(); So this also would be legal? $foo\ .foo(); ? (and therefore presumably the variant that is a bug in C or Makefiles: $foo\ .foo(); I don't mean that as a counter argument. It's an argument in favour. That space you can't see is a really annoying invisible bug in C source code that's sometimes hard to track down. Making it not-a-bug seems good.) Nicholas Clark
Re: A shorter long dot
On Sun, Apr 30, 2006 at 07:01:06PM +0200, Juerd wrote: Gaal Yahas skribis 2006-04-30 16:05 (+0300): But it doesn't work across lines: $and_a_long_one_I_still_want_to_align. :foo() Explain to me why it wouldn't work, please. I don't get it. This form certainly will. I hadn't read Jonathan's original proposal carefully enough, where he also shows how the other form could, if you allow mixing whitespace with the underscores. My bad. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: A shorter long dot
On Sun, Apr 30, 2006 at 06:33:01PM +0100, Nicholas Clark wrote: : On Sun, Apr 30, 2006 at 09:58:21AM -0700, Larry Wall wrote: : : Neither of those are currently legal in infix position. The backslash : : Backslash also has the advantage of making sense to a C programmer: : : $foo\ : .foo(); : : So this also would be legal? : : $foo \ : .foo(); : : ? That's a legal long dot but still a Perl syntax error because you've got two terms in a row. A postfix still isn't allowed to have space before it, so the backslash must be the first thing. : (and therefore presumably the variant that is a bug in C or Makefiles: : : $foo \ : .foo(); It does fix that bug, since \ quotes any whitespace, not just newline. : I don't mean that as a counter argument. It's an argument in favour. That : space you can't see is a really annoying invisible bug in C source code that's : sometimes hard to track down. Making it not-a-bug seems good.) Seems so to me too. I don't see much downside to \. as a long dot. Larry
Re: Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
On Sun, Apr 30, 2006 at 03:47:54AM +0300, Yuval Kogman wrote: On Sat, Apr 29, 2006 at 18:12:34 +0100, Nicholas Clark wrote: On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote: I get a message like this for every message that I send to this list. Trying to contact [EMAIL PROTECTED] did not result in response or change. Any ideas? Forward that message (with full headers) to [EMAIL PROTECTED] who will then apply the LART. As I figure I'm about to get one, I'll (also) forward mine. Just got one... By LARTing you mean forcibly unsubscribing? because the message was sent to me directly too... Yes, I believe that that's the usual solution to resolve the problem of any system that is sufficiently borked to be sending garbage to the list or the sender. I think that at times there have been utterly brain dead challenge response systems that have managed to repeatedly get themselves subscribed - they tend to get banned. (Seems totally reasonable, given that the perl.org sysadmins are volunteers, and have many better things to do than offer free consulting to the admins of badly behaved third party systems.) Nicholas Clark
Re: A shorter long dot
Larry Wall wrote: Seems so to me too. I don't see much downside to \. as a long dot. The only remaining problem that I see for the long dot is largely orthogonal to the selection of the first and last characters - namely, that your only choice for filler is whitespace. Although the C\. option opens an intriguing possibility of defining the long dot pattern as backslash, dot or whitespace (repeated zero or more times), dot: $xyzzy.foo() $fooz\.foo() $foo\..foo() $fa\...foo() $and_a_long_one_I_still_want_to_align\ ...foo() $etc\..foo() -- Jonathan Lang
A shorter long dot
16:50 audreyt Juerd: write to p6l and explain the .. conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.
Illustration:
$xyzzy.foo();
$fooz. .foo(); # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo(); # this lines up again.
So we use:
$xyzzy. .foo();
$fooz. .foo();
$foo. .foo();
which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.
However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.
Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
and propose .: as a solution,
That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.
So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)
and . : as an extension,
Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between.
So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.
$xyzzy.foo();
$fooz.:foo();
$foo. :foo();
Or, if you prefer:
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
Or, if you actually LIKE the extra whitespace that the current long dot
mandates:
$xyzzy. :foo();
$fooz. :foo();
$foo. :foo();
and . + as an generalization,
Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.
The dot-colon fixes another problem too. You couldn't line them up
anymore:
$foo.?bar();
$foo.baz(); # makes the ? look like part of the method name
So, now you can:
$foo.?bar();
$foo.:baz();
And an illustration with whitespace in between:
$xyzzy.:foo();
$fooz. ?foo();
$fo. *foo();
and coexistence/removal of . . as a consideration
If we have dot-colon, we could keep the old long dot too. That would
work well with my preference for ... as the first part of the old long
dot, as three dots stand out much better at the end of a line:
$foo...
.bar();
Though that isn't really dependent on the old long dot. It can live
separately. In fact, postfix ... could be a generic eat whitespace
and pretend it wasn't there operator:
$foo...
.bar()...
.baz();
$foo...
.:bar(); # with normal old long dot, would be :bar(), looking like
# a pair, not a method call.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
I get a message like this for every message that I send to this list.
Trying to contact [EMAIL PROTECTED] did not result in response or change.
Any ideas?
- Forwarded message from sbc sbc [EMAIL PROTECTED] -
From: sbc sbc [EMAIL PROTECTED]
Date: Sat, 29 Apr 2006 08:31:24 -0700 (PDT)
To: [EMAIL PROTECTED]
Subject: Re: A shorter long dot
Testing with sbc30k
[EMAIL PROTECTED] wrote:
16:50 audreyt Juerd: write to p6l and explain the .. conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable, is quite a lot.
Illustration:
$xyzzy.foo();
$fooz. .foo(); # doesn't line up, so we have to change the
# *previous* line!
$foo. .foo(); # this lines up again.
So we use:
$xyzzy. .foo();
$fooz. .foo();
$foo. .foo();
which is ugly and feels bad. It feels bad, because we're adding much
more whitespace (two character positions in total) than we had to
bridge. And it's a lot of work (many, many keystrokes!) to go back and
change something.
However, the whitespace in between cannot simply be made optional, as
then it would clash with the range operator. As ranges are even more
important than a sane long dot solution, the long dot had to change.
Larry indicated that changing the long dot would have to involve
changing the first character. The only feasible solution in the tiny
glyphs section was the backtick. I refrain from explaining why that
will widely be considered a bad idea.
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
and propose .: as a solution,
That's right, dot-colon. There are more glyphs available, but none of
them is nice like this. The basis is in regexes, where a colon means you
commit to have parsed the left side of the colon. That's how the colon
already reads in the indirect object notation, and the colon in
$foo.map:{...} can already be read.
So the actual solution is to make the method call operator not ., but
.:. Of course, a lone . still works and is the recommended style for
all simple method calls that don't have to be lined up. You can also
explain it as . still being the base operator, where .: is a special
form. Whatever you like best :)
and . : as an extension,
Of course, it wouldn't be a solution to the long dot problem if it
didn't allow an arbitrary amount of whitespace in between.
So, obviously, it does allow lots of whitespace in between. And, of
course, comments. If you really hate your future maintainer, you could
even put some POD in between.
$xyzzy.foo();
$fooz.:foo();
$foo. :foo();
Or, if you prefer:
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
Or, if you actually LIKE the extra whitespace that the current long dot
mandates:
$xyzzy. :foo();
$fooz. :foo();
$foo. :foo();
and . + as an generalization,
Of course, this works nicely with the operators it was inspired by, that
were also inspired by regex postfix operators: .*, .+ and .?. They
can also contain whitespace in our proposal.
The dot-colon fixes another problem too. You couldn't line them up
anymore:
$foo.?bar();
- End forwarded message -
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote: I get a message like this for every message that I send to this list. Trying to contact [EMAIL PROTECTED] did not result in response or change. Any ideas? Forward that message (with full headers) to [EMAIL PROTECTED] who will then apply the LART. As I figure I'm about to get one, I'll (also) forward mine. Nicholas Clark
Re: A shorter long dot
Juerd wrote: Audrey cleverly suggested that changing the second character would also work, and that has many more glyphs available. So she came up with and propose .: as a solution $xyzzy.:foo(); $fooz. :foo(); $foo. :foo(); This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( We've strived to eliminate homonyms from Perl 6. I'd much rather not introduce one at this late stage. For similar reasons, I'm strongly opposed to: foo. ?bar() foo. +bar() foo. *bar() since they're highly misleading if you happen to miss the dot. Damian PS: While I can understand the appeal to laziness, I'm not at all convinced by the argument: And it's a lot of work (many, many keystrokes!) to go back and change something. In vim, the exact number of keystrokes to realign the long dots of N lines is 7+N. And, if I found myself doing that regularly, I'd turn it into a macro and bind it to a key, so the number of keystrokes would be one. We need to be careful not to require the language to solve problems that are better solved with tools.
Re: A shorter long dot
On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote: This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( You're not counting the space around the dot, which counts. To me they look completely different We need to be careful not to require the language to solve problems that are better solved with tools. On that point I agree, but I think it was a question of aesthetics... Juerd? $foo. .bar; $ba. .bar; $x. .bar; $foo.bar; $ba.:bar; $x. :bar; Frankly I don't think there's *that* much of a difference - each has pros and cons. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpFJG3Gj3Rdx.pgp Description: PGP signature
Re: Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
On Sat, Apr 29, 2006 at 18:12:34 +0100, Nicholas Clark wrote: On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote: I get a message like this for every message that I send to this list. Trying to contact [EMAIL PROTECTED] did not result in response or change. Any ideas? Forward that message (with full headers) to [EMAIL PROTECTED] who will then apply the LART. As I figure I'm about to get one, I'll (also) forward mine. Just got one... By LARTing you mean forcibly unsubscribing? because the message was sent to me directly too... -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpKCtPumL5fF.pgp Description: PGP signature
Re: A shorter long dot
On Saturday 29 April 2006 16:58, Yuval Kogman wrote: On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote: This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( You're not counting the space around the dot, which counts. To me they look completely different Two invisible things look completely different to you? -- c
Re: A shorter long dot
On Sat, Apr 29, 2006 at 19:03:28 -0700, chromatic wrote: Two invisible things look completely different to you? If dots looked like this: then they would be invisible. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpjWtFYwS1YC.pgp Description: PGP signature
Re: A shorter long dot
Damian Conway wrote: Juerd wrote: Audrey cleverly suggested that changing the second character would also work, and that has many more glyphs available. So she came up with and propose .: as a solution $xyzzy.:foo(); $fooz. :foo(); $foo. :foo(); This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( We've strived to eliminate homonyms from Perl 6. I'd much rather not introduce one at this late stage. Is there a reason that we've been insisting that a long dot should use whitespace as filling? To me, foo. .bar shares a common problem with foo. :bar - in both cases, my gut instinct is to consider foo and bar to be separate entities, disconnected from each other - quite the opposite of what's intended. OTOH, this problem would go away if the filler was primarily, say, underscores: foo.___.bar or foo.___:bar visually look like foo and bar are attached to each other. Of course, without any sort of whitespace, there would be no way for a long dot to span lines; so you might want to allow newline characters as well. But then, you run into problems such as: foo. ___.bar being illegal, because the second line contains leading whitespace characters... Perhaps you would be best off allowing both whitespace characters and underscores as filler, and strongly suggesting that whitespace only be used to span lines: by convention, the only whitespace that ought to be used in a long dot would be something that matches /\n\s*/. With this in place, the distinction would be between foo.:bar and foo :bar ...very easy to distinguish. -- Jonathan Dataweaver Lang
Re: A shorter long dot
On Saturday 29 April 2006 18:29, Yuval Kogman wrote: If dots looked like this: then they would be invisible. Use a laptop with a speck of dust in the wrong place in slightly wrong lighting and the wrong four pixels might as well be invisible. Precious few of @Larry deserve the nickname Ol' Eagle Eye. This really doesn't seem like a place to argue for such subtlety when the difference in behavior is so large. -- c
Re: A shorter long dot
Damian Conway wrote: Juerd wrote: and propose .: as a solution $xyzzy.:foo(); $fooz. :foo(); $foo. :foo(); This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( Good (and floating) point. How about this: $antler.bar; $xyzzy.:bar; $blah. .bar; $foo. .bar; That is, introduce only the non-space-filled .: variant, and retain the space-filled long dot. Thanks, Audrey signature.asc Description: OpenPGP digital signature
Re: A shorter long dot
Audrey Tang wrote: Damian Conway wrote: Juerd wrote: and propose .: as a solution $xyzzy.:foo(); $fooz. :foo(); $foo. :foo(); This would make the enormous semantic difference between: foo. :bar() and: foo :bar() depend on a visual difference of about four pixels. :-( Good (and floating) point. How about this: $antler.bar; $xyzzy.:bar; $blah. .bar; $foo. .bar; That is, introduce only the non-space-filled .: variant, and retain the space-filled long dot. How about if we replace dot with - and then you can specify any number of dashes for alignment: $antler-bar; $xyzzy--bar; $blah---bar; $foobar; Or, to put it another way: what hard problem is it that you guys are actively avoiding, that you've spent a week talking about making substantial changes to the language in order to facilitate lining up method names? =Austin
Re: A shorter long dot
Good (and floating) point. Boom boom! ;-) How about this: $antler.bar; $xyzzy.:bar; $blah. .bar; $foo. .bar; That is, introduce only the non-space-filled .: variant, and retain the space-filled long dot. But do we really need *three* distinct forms of method call, in addition to the (easily alignable) indirect object syntax? Is: $antler. .bar; $xyzzy. .bar; $blah. .bar; $foo..bar; really so intolerable, for those who are gung-ho to line up the method names? Damian
