Another dotty idea
Larry Wall
bugging me about "long dot". It seems just a little too specific.
So here's another proposal. We've been saying forever that we don't
need start/stop comments. But maybe, just maybe, if they also cure the
delayed postfix problem, it's worth it. Suppose that, rather than something
traditional like /* ... */, we define our comment delimiters as
.# ... #.
Then instead of:
$x. .()
$x...
.()
we could instead have
$x.# #.()
$x.#
#.()
and that actually reduces down to $x() in either case. That is,
the dots look like dots but neither of them is a real dot, which works
for anything but .foo methods, which would have to be something like:
$x.#
#..foo
which is a bit unfortunate, but maybe we can fix it somehow by making
one of the dots real. Unfortunately that limits its use as a general
embedded comment. So maybe the trailing delimiter is wrong. Here's
anther idea: let people pick a delimiter:
$x.#( comment ).()
$x.#[ comment
].()
That would give us .#[...] as the general embedded comment form, and the
first dot is not a real dot, but any dot after the closing delimiter
would be a real dot.
If we make the delimiter anything following q/.../ rules, then
the one-liner form for lining up things gives us:
:foo.#. .(1,2,3)
:foobar.#. .(1,2,3)
:foobarbaz.#..(1,2,3)
If that's too ugly, I suppose would could make .\s short for .#. so
we could still write
:foo. .(1,2,3)
:foobar. .(1,2,3)
:foobarbaz. .(1,2,3)
Also returns .. and ... to being completely unambiguous.
Another approach would be to say that the #// mechanism works without
the dot, but that seems like asking for trouble. And it doesn't give
the mnemonic of a dot on either end.
$x#( comment ).()
or
$x.#( comment )()
$x#[ comment
].()
or
$x.#[ comment
]()
Which is actually okay for anything but regular methods:
$x#[ comment
].foo()
or
$x.#[ comment
]foo()
But I think it's just a little too easy to write #x by accident and
get x as the delimiter, so I'm leaning towards, .#// still.
Larry
Jonathan Lang
I'd put the dot inside the comment: "#.x", with x being an optional
quote delimiter (excluding dots). If a delimiter is included, the
comment is terminated by the matching quote delimiter; if absent, the
comment is terminated by the next dot.
$x#.[ ].foo();
$x.#.[ ]foo();
$x#. ..foo();
$x.#. .foo();
would all become
$x.foo();
The third form would be legal, if a bit illegible.
--
Jonathan Lang
Patrick R. Michaud
> Delimiter-terminated quotes. Really nice idea.
>
> I'd put the dot inside the comment: "#.x", with x being an optional
> quote delimiter (excluding dots). If a delimiter is included, the
> comment is terminated by the matching quote delimiter; if absent, the
> comment is terminated by the next dot.
But if one is going to go this route (and I'm not sure that we should),
then when the delimiter is absent have the comment terminate at
the first non-whitespace character.
In other words, "#" terminates at a newline, but "#.\s" terminates
at the next non-whitespace character.
This gives us:
$x#. .foo()
$x#. .()
$x#. ()
which still allows us to balance dots if we wish (but is not
required). Nicely, it still looks like we're inserting a comment,
since '#' already means 'comment'.
We can still have the delimited forms of this comment if we want,
but maybe this is a reasonable approach to handling dots.
Pm
Jonathan Lang
> But if one is going to go this route (and I'm not sure that we should),
> then when the delimiter is absent have the comment terminate at
> the first non-whitespace character.
...which makes "#.\s" good only for inserting whitespace where it
normally wouldn't belong. On the one hand, there's something nice
about
> $x#. .foo()
> $x#. .()
> $x#. ()
instead of
> $x#. ..foo()
> $x#. ..()
> $x#. .()
OTOH, wasn't the whole point to get away from "long dot is a special
case"? Though having the "long dot" as a special case of the
"delimited comment" concept, rather than being a "raw special case",
is more acceptable to my mind.
--
Jonathan Lang
Uri Guttman
LW> Okay, after attempting and failing to take a nap, I think I know
LW> what's bugging me about "long dot". It seems just a little too
LW> specific.
does this mean you are at the dawning of your dot.age?
<me ducks and runs>
i couldn't resist! :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Patrick R. Michaud
> Patrick R. Michaud wrote:
> > Jonathan wrote:
> > > If a delimiter is included, the
> > > comment is terminated by the matching quote delimiter; if absent, the
> > > comment is terminated by the next dot.
> >
> > then when the delimiter is absent have the comment terminate at
> > the first non-whitespace character.
>
> ...which makes "#.\s" good only for inserting whitespace where it
> normally wouldn't belong.
Well, even if we say terminate at the next dot, that's saying
that our inserted comments cannot contain dots in them.
But if we want to terminate at another dot, perhaps we should
explicitly specify an extra dot as the delimiter. We still get
some nice symmetries this way:
$x#.. ..foo()
$x#.. ..()
$x#.. this is a delimited comment ..()
$x#.[ this is also a delimited comment ].()
Thus "#.\s" just happens to mean that we're using whitespace
(or actually, the end of whitespace) as a delimiter.
Somehow I have the nagging feeling that Larry will once again
take these ideas and come up with something totally unexpected
and simultaneously awesome, as he often does. (At least, I hope
that's the case.)
Pm
Larry Wall
I really prefer the form where .#() looks like a no-op method call,
and can provide the visual dot for a postfix extender. It also is
somewhat less likely to happen by accident the #., I think. And I
think the front-end shape of .# is more recognizable as different
from #, while #. requires a small amount of visual lookahead, and
is the same "square" shape on the front, and could easily be confused
with a normal line-ending comment.
Larry
Jonathan Lang
> I really prefer the form where .#() looks like a no-op method call,
> and can provide the visual dot for a postfix extender.
Although inline and multiline comments are very likely to be used in
situations where method calls simply aren't appropriate:
.#(+-------+
| Hello! |
+--------+)
is something that I wouldn't be surprised to see.
> It also is
> somewhat less likely to happen by accident the #., I think. And I
> think the front-end shape of .# is more recognizable as different
> from #, while #. requires a small amount of visual lookahead, and
> is the same "square" shape on the front, and could easily be confused
> with a normal line-ending comment.
All true. But it avoids the headache of figuring out whether "..#" is
supposed to parse as a double-dot followed by a line-gobbling comment
or as a single dot followed by a delimited comment.
--
Jonathan "Dataweaver" Lang
Larry Wall
: Larry Wall wrote:
: > I really prefer the form where .#() looks like a no-op method call,
: > and can provide the visual dot for a postfix extender.
:
: Although inline and multiline comments are very likely to be used in
: situations where method calls simply aren't appropriate:
:
: .#(+-------+
: | Hello! |
: +--------+)
:
: is something that I wouldn't be surprised to see.
Obviously that's just a null method call on $_. :)
It's only a problem when some tries to write
.=#( ... :-)
: > It also is
: > somewhat less likely to happen by accident the #., I think. And I
: > think the front-end shape of .# is more recognizable as different
: > from #, while #. requires a small amount of visual lookahead, and
: > is the same "square" shape on the front, and could easily be confused
: > with a normal line-ending comment.
:
: All true. But it avoids the headache of figuring out whether "..#" is
: supposed to parse as a double-dot followed by a line-gobbling comment
: or as a single dot followed by a delimited comment.
One-pass, longest-token parsing says it has to be a .. followed by
a # comment. No headache, really. And nobody in their right mind
would write that anyway.
Larry
Jonathan Lang
> It's only a problem when some tries to write
>
> .=#( ... :-)
[tries to grok the meaning of "$foo.=#(Hello, World!)"]
[fails]
> : All true. But it avoids the headache of figuring out whether "..#" is
> : supposed to parse as a double-dot followed by a line-gobbling comment
> : or as a single dot followed by a delimited comment.
>
> One-pass, longest-token parsing says it has to be a .. followed by
> a # comment. No headache, really. And nobody in their right mind
> would write that anyway.
Many perl programmers aren't in their right mind. :)
Seriously, the question is which paradigm makes more sense: a null
method (dot precedes pound), or a special kind of comment (dot follows
pound)? The former emphasizes the "you don't have to put it at the
end of a line" aspect, while the latter emphasizes the "you can strip
it out without harming the surrounding code" aspect. IMHO, the latter
is the more important point to emphasize - especially since the former
brings so much baggage with it.
And I suspect that the confusion between # and #."" would be minor,
_especially_ with syntax highlighters and the like in common use.
--
Jonathan Lang
Damian Conway
> I really prefer the form where .#() looks like a no-op method call,
> and can provide the visual dot for a postfix extender. It also is
> somewhat less likely to happen by accident the #., I think. And I
> think the front-end shape of .# is more recognizable as different
> from #, while #. requires a small amount of visual lookahead, and
> is the same "square" shape on the front, and could easily be confused
> with a normal line-ending comment.
I'm not enamoured of the .# I must confess. Nor of the #. either. I wonder
whether we need the dot at all. Or, indeed, the full power of arbitrary
delimiters after the octothorpe.
What if we restricted the delimiters to the five types of balanced brackets?
And then simply said that, when any comment specifier (i.e. any octothorpe) is
followed immediately by an opening bracket, the comment extends to the
corresponding closing bracket?
Then you could have:
#[ This is a comment ]
#( This is a comment )
#{ This is a comment }
#< This is a comment >
#« This is a comment »
That would also mean that # is *always* the comment introducer
(and the *only* comment introducer).
As for gappy dotting, that would become:
$x#[ ].foo()
or:
$x.#< >foo()
as the coder prefers.
Though, frankly, every one of the alternatives proposed so far is so ugly that
I seriously doubt that anyone will actually want to use them (or maybe that's
the point! ;-)
Especially when there are cleaner alternatives for aligning postfixes already
standard in the language:
@another_array[ $idx ] = $hash.{ $key };
@other_array[ $idx ] = $other_hash.{ $key };
@array[ $idx ] = $another_hash.{ $key };
foo $obj: $arg = $get_foo( $arg );
barb $obj: $arg = $get_barb( $arg );
bazaar $obj: $arg = $get_bizarre( $arg );
Maybe we're trying too hard to let people have their postfix dotted space
(and eat it too).
Damian
John Siracusa
> I'm not enamoured of the .# I must confess. Nor of the #. either.
Thank goodness...I was beginning to think it was only me!
> Though, frankly, every one of the alternatives proposed so far is so ugly that
> I seriously doubt that anyone will actually want to use them
Agreed, especially...
> ...when there are cleaner alternatives for aligning postfixes already
> standard in the language: [...]
>
> foo $obj: $arg = $get_foo( $arg );
> barb $obj: $arg = $get_barb( $arg );
> bazaar $obj: $arg = $get_bizarre( $arg );
>
> Maybe we're trying too hard to let people have their postfix dotted space
> (and eat it too).
I could almost swallow #[ ... ] as a multi-line comment...almost. The
others with the dot just rub me the wrong way.
-John
Darren Duncan
>On 4/8/06 6:29 AM, Damian Conway wrote:
>> I'm not enamoured of the .# I must confess. Nor of the #. either.
>
>Thank goodness...I was beginning to think it was only me!
For the record, I agree with both of you, and that your proposed
alternatives are improvements. -- Darren Duncan
Sam Vilain
>I'm not enamoured of the .# I must confess. Nor of the #. either. I wonder
>whether we need the dot at all. Or, indeed, the full power of arbitrary
>delimiters after the octothorpe.
>
>
Agreed.
>What if we restricted the delimiters to the five types of balanced brackets?
>And then simply said that, when any comment specifier (i.e. any octothorpe) is
>followed immediately by an opening bracket, the comment extends to the
>corresponding closing bracket?
>
>Then you could have:
>
> #[ This is a comment ]
> #( This is a comment )
> #{ This is a comment }
> #< This is a comment >
> #« This is a comment »
>
>
This does mean that if you comment out blocks with s/^/#/, you mess up on:
#sub foo
#{
# if foo { }
#}
>That would also mean that # is *always* the comment introducer
>(and the *only* comment introducer).
>
>
I agree with this goal.
I propose this form: #* *#
As a leading * on a line is unusual, and it also has visual similarity
to multi-line comments in C.
>As for gappy dotting, that would become:
>
> $x#[ ].foo()
> or:
>
> $x.#< >foo()
>
>
For comparison:
$x#* *#.foo()
or:
$x.#* *#foo()
Larry Wall
: This does mean that if you comment out blocks with s/^/#/, you mess up on:
:
: #sub foo
: #{
: # if foo { }
: #}
Well, actually, that still works. To be certain though, you could always
use s/^/##/ or s/^/# /. Even better is:
=begin UNUSED
sub foo
{
if foo { }
}
=end UNUSED
And I don't really care if that's not what people are used to.
The whole point of Perl 6 is to change How Things Work.
Larry
John Siracusa
> Even better is:
>
> =begin UNUSED
> sub foo
> {
> if foo { }
> }
> =end UNUSED
>
> And I don't really care if that's not what people are used to.
> The whole point of Perl 6 is to change How Things Work.
Do you care that it's harder to visually pick out the commented-out portions
of a file at a glance using that syntax? I really don't want to give up
s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use
triple ### for the "thicker" parts in my little ASCII art comment header
thingies.
###
### Blah blah
###
## Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
## Ut et magna. Sed feugiat sollicitudin purus. Duis eget sem
## faucibus nibh dapibus sollicitudin. Sed egestas, nisl quis
## pharetra lacinia, libero urna tempus enim, non varius pede
sub foo
{
## bar();
## my $baz = blee();
## $baz--;
return 123;
}
No sir, I don't like it.
-John
Sam Vilain
>On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote:
>: This does mean that if you comment out blocks with s/^/#/, you mess up on:
>:
>: #sub foo
>: #{
>: # if foo { }
>: #}
>
>Well, actually, that still works.
>
>
Oh, true :-)
But this fragment dies:
#sub foo
#{
# bar { } unless baz
#}
Unless you consider the idea of balancing the {}'s inside the comment,
which I think would be just plain nasty.
The #* .. *# form actually has a natural follow-on I didn't think of before:
#[ This is a comment ]#
#( This is a comment )#
#{ This is a comment }#
#< This is a comment >#
#« This is a comment »#
While technically the same thing applies to code that uses these delimited, it means that the block I gave is now a parsefail. #-comments directly following closing braces are probably sufficiently uncommon for this not to be such a problem.
>To be certain though, you could always
>use s/^/##/ or s/^/# /.
>
>
I guess that works, but it breaks convention of # somewhat.
>Even better is:
>
> =begin UNUSED
> sub foo
> {
> if foo { }
> }
> =end UNUSED
>
>And I don't really care if that's not what people are used to.
>The whole point of Perl 6 is to change How Things Work.
>
>
Sure, but there is still the principle of least surprise to worry about.
Sam.
Larry Wall
: Larry Wall wrote:
:
: >On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote:
: >: This does mean that if you comment out blocks with s/^/#/, you mess up on:
: >:
: >: #sub foo
: >: #{
: >: # if foo { }
: >: #}
: >
: >Well, actually, that still works.
: >
: >
:
: Oh, true :-)
:
: But this fragment dies:
:
: #sub foo
: #{
: # bar { } unless baz
: #}
:
:
: Unless you consider the idea of balancing the {}'s inside the comment,
: which I think would be just plain nasty.
I don't see how that's different at all from the first example.
: The #* .. *# form actually has a natural follow-on I didn't think of before:
:
: #[ This is a comment ]#
: #( This is a comment )#
: #{ This is a comment }#
: #< This is a comment >#
: #« This is a comment »#
:
: While technically the same thing applies to code that uses these
: delimited, it means that the block I gave is now a parsefail.
: #-comments directly following closing braces are probably sufficiently
: uncommon for this not to be such a problem.
Yes, Audrey made that suggestion too, but I think it's uglier for
the envisioned uses.
: >To be certain though, you could always
: >use s/^/##/ or s/^/# /.
: >
: >
:
: I guess that works, but it breaks convention of # somewhat.
You may have noticed that I don't mind breaking conventions somewhat. :-)
: >Even better is:
: >
: > =begin UNUSED
: > sub foo
: > {
: > if foo { }
: > }
: > =end UNUSED
: >
: >And I don't really care if that's not what people are used to.
: >The whole point of Perl 6 is to change How Things Work.
: >
: >
:
: Sure, but there is still the principle of least surprise to worry about.
The problem with the Principle of Least Surprise is that you can use it
to justify just about anything by picking the right set of people. :-)
I freely admit that the current definition will surprise a few Perl 5
programmers. I'm more worried about what will look clean in 10 years.
Larry
Larry Wall
: Do you care that it's harder to visually pick out the commented-out portions
: of a file at a glance using that syntax? I really don't want to give up
: s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use
: triple ### for the "thicker" parts in my little ASCII art comment header
: thingies.
I think commenting out code with # is sufficiently antisocial that
you should probably do it with ########. Then it's *really* easy to
pick out your commented portions at a glance. Plus it won't interfere
visually with your ### blocks. And it has the additional advantage
of keeping your tabs lined up. :-)
Larry
John Siracusa
> I think commenting out code with # is sufficiently antisocial that
> you should probably do it with ########.
What's antisocial about it? What's the alternative for quickly commenting
out a few lines? Braced #[ ... ]# pairs are not as easy to "mindlessly"
place quickly as a few # at the start of each line.
-John
Sam Vilain
>: But this fragment dies:
>:
>: #sub foo
>: #{
>: # bar { } unless baz
>: #}
>I don't see how that's different at all from the first example.
>
>
“#sub foo” is parsed as a comment token
“#{
# bar { }” is the next comment token
then we get “unless baz”
Unless you are balancing {}'s inside the # blocks, like q{ } does.
Sam.
Austin Hastings
> Larry wrote:
>
> > I really prefer the form where .#() looks like a no-op method
> > call, and can provide the visual dot for a postfix extender. It
> > also is somewhat less likely to happen by accident the #., I
> > think. And I think the front-end shape of .# is more
> > recognizable as different from #, while #. requires a small
> > amount of visual lookahead, and is the same "square" shape on the
> > front, and could easily be confused with a normal line-ending
> > comment.
>
>
> I'm not enamoured of the .# I must confess. Nor of the #. either. I
> wonder whether we need the dot at all. Or, indeed, the full power
> of arbitrary delimiters after the octothorpe.
>
How committed are we to spaces?
If we impose an adjacent-space requirement on the range operators, we
could just repeat dots endlessly:
given ($x) { when (0 .. 9) {...}}
$obj..............method(); # These line up in proportional font. Sorry.
$newobj........method();
$longobjname.method();
Frankly, I don't line up my method calls like this, so it's not much
of a concern. But I also use spaces around operators, so I'm okay with
my coding style becoming syntax. :)
=Austin
Larry Wall
That is how it is specced, and why the first example works.
Larry
Austin Hastings
> I'm not enamoured of the .# I must confess. Nor of the #. either. I
> wonder whether we need the dot at all. Or, indeed, the full power of
> arbitrary delimiters after the octothorpe.
>
> What if we restricted the delimiters to the five types of balanced
> brackets? And then simply said that, when any comment specifier (i.e.
> any octothorpe) is followed immediately by an opening bracket, the
> comment extends to the corresponding closing bracket?
>
> Then you could have:
>
> #[ This is a comment ]
> #( This is a comment )
> #{ This is a comment }
> #< This is a comment >
> #« This is a comment »
This is a much better idea, disconnected from the question of putting
spaces in method calls. It's particularly nice if you say the magic
words "multi-line comment."
(Please, spare me the hand-wringing about pod.)
I'll even pay you a closing hash (]#, }#, )#, etc.) if you put it in.
For extra credit, make them nest.
=Austin