Jonathan Lang | 3 Jan 2008 02:58
Picon

Re: Multiline comments in Perl6

I've been putting a fair amount of thought into this.  Here's what
I've come up with:

Perl 6 has several instances where whitespace is required or forbidden
in order to better facilitate "Do What I Mean" programming: for
instance, by having the presence or absence of whitespace before curly
braces affect their meaning, you're allowed to omit the parentheses
around the parameters of the various control structures: e.g., 'if $x
{ ... }' is now valid, whereas in Perl 5 you would have had to say 'if
($x) { ... }'.  Likewise, the same technique lets you provide an
unambiguous distinction between an infix operator and a postfix
operator (IIRC).  So it isn't much of a stretch to require the use of
whitespace in order to distinguish between a standard "line comment"
and an embedded comment.

Except that that isn't what Perl 6 is doing.  All that it does is to
say "there's this one case where there's some ambiguity between line
comments and embedded comments; it's up to the programmer to remove
the ambiguity, through whatever means he sees fit."  In many ways,
this is the opposite of the above cases, and is more akin to how role
composition must be explicitly disambiguated by the programmer,
instead of having the compiler take a best guess.

I must admit: as nice as it is to be able to create an embedded
comment by wrapping the actual comment in brackets, the existence of
that one point of ambiguity is troubling.

--

What I like about the current embedded comments:
(Continue reading)

Jonathan Lang | 3 Jan 2008 05:09
Picon

Re: Multiline comments in Perl6

Jonathan Lang wrote:
> How about '~#', meaning something along the lines of "string-like
> comment"?  The idea is that the syntax that follows this would conform
> closely to that of string literals (i.e., quotes).  We might even
> consider loosening the restrictions on delimiter characters, allowing
> the full versatility of quoting delimiters, since there'd no longer be
> any danger of confusing this with a line comment.  So:

For the record: if this gets implemented as I'm describing above, I
will personally restrict myself to using bracketing characters as the
delimiters.  Non-bracketing delimiters have issues that, as a
programmer, I don't want to have to deal with: e.g., if I were to use
'~#/ ... /' to comment out a block of code, I'd have to be very sure
that said code doesn't do any division.  This is still a problem with
brackets, but less so - especially with the ability to double up (or
more) on the brackets.  E.g., '~#[[ ... ]]' pretty much guarantees
that I'll comment out exactly what I want to comment out on the first
try.

Oh, and I just realized: '~#( ... )' looks a bit like an
ascii-graphics thought bubble, as used in old text-based MUXs.  If
'~#' gets nixed, perhaps 'oO' would be a viable alternative?

  $x = oO(here's a comment) 5;

--

-- 
Jonathan "Dataweaver" Lang


Gmane