A shorter long dot
Juerd
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
Damian Conway
> 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.
Yuval Kogman
> 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 <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418
Chromatic
> 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
Jonathan Lang
> 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
Chromatic
> 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
Audrey Tang
> Juerd wrote:
>
>> $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
Austin Hastings
How about if we replace dot with -> and then you can specify any number
of dashes for alignment:
$antler->bar;
$xyzzy-->bar;
$blah--->bar;
$foo---->bar;
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
Damian Conway
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
Chromatic
> 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
Audrey Tang
> 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
Juerd
> 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
> 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
> 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
> > 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
> 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;
John Siracusa
> 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
Juerd
> >> 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.
Gaal Yahas
>
> $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 <ga...@forum2.org>
http://gaal.livejournal.com/
Jonathan Lang
> > 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.
Larry Wall
: 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
Juerd
> 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
> But it doesn't work across lines:
> :foo()
Explain to me why it wouldn't work, please. I don't get it.
Nicholas Clark
> 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
Gaal Yahas
> 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.
Larry Wall
: 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
Jonathan Lang
> 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
Smylers
> 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
Dr.Ruud
> When is the last time that you saw an underscore-only method name?
sub _{print"$_\n"};
--
Affijn, Ruud
"Gewoon is een tijger."
Paul Johnson
> 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 - pa...@pjcj.net
http://www.pjcj.net
Markus Laire
> 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
Paul Johnson
> On 5/1/06, Paul Johnson <pa...@pjcj.net> 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.
Markus Laire
> 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