Fwd: More flexible POD
Woops - forgot to reply all (I'm on an irritating mixture of lists
which set reply-to and don't, and I never remember which is which).
Sorry!
-- Forwarded message --
From: Matthew Walton
Date: Tue, Aug 11, 2009 at 7:10 AM
Subject: Re: More flexible POD
To: Jon Lang
I'm not sure what it should be, but I do believe that there should be
a solution which allows elegant mixing of code and Pod. I want to
document my APIs by attaching the documentation to the methods in
question, otherwise the documentation won't get updated when the code
does (and if the code at work is anything to go by, won't get updated
at all anyway, but you can at least make it as easy as possible for
the people who do remember).
Attaching blocks of documentation to bits of code is something that
Javadoc's syntax gets very right.
The trouble is, if we just allow arbitrary whitespace before the start
of a Pod block:
class A {
=head2 foo()
Frobnicates the widget.
=end
method foo() { ... }
}
(modulo accurate Pod directives - I'm a bit hazy on how it works now,
I keep thinking I should be able to say '=method', but maybe that's a
matter for the Pod extractor).
Do we run the risk of causing problems if somebody does this:
my ($several, $lengthily-named, $variables)
= something-which-produces-a-list();
and the parser thinks 'hang on a sec, that's Pod'. This is
particularly bad for programmers who don't put spaces around their
binary operators (hah! We could enforce it!) and may cause
confuzzlement.
I don't think footnote-like references in the code would help
programmers keep the documentation up to date or help them in reading
it to comprehend the code when they come to maintain it, which I think
are the two key reasons to put your documentation right there in the
code. If you did do it though, you'd have to use named references
(probably valid Perl 6 identifiers), because numbers are just a
nightmare.
Matthew
Re: Rukudo-Star => Rakudo-lite?
> Rakudo Zengi would be the most (in)appropriate, I think. Why do I get the sense that some in the community are suffering siege mentality? ;) I had thought of things like Zen, Zero, Catalyst, etc. But I love * | Star | Whatever. I love: o The word Star, regardless of its connection with Perl 6. o Insider reference to a cool feature of Perl 6. o Rakudo* as an alternate that invites footnote-fu. o Evoking "whatever works" instead of all of Perl 6.0.0. o Evoking "whatever" to invite ongoing definition of what it is. This latter point is the most exciting for me. "What is Rakudo Star? Well, it's..." I would love to see this meme encouraged, the notion that we all get to continuously (re)define just what Rakudo Star is. -- love, raiph
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
smuj wrote:
> Jon Lang wrote:
>> Here's a radical notion: use something other than '#' to initiate an
>> inline comment.
>>
> [snippage]
>
> Or maybe just don't allow "embedded" comments unless they are actually
> "embedded", i.e. if a line starts with a # (ignoring leading whitespace)
> then it's _always_ a line-end comment, no matter what follows the #, e.g.
That has the advantage of preserving a three-character embedded
comment. It has the disadvantage that you get differing behavior
depending on where the comment is on the line. As I see it, the whole
point of this exercise is to get rid of the gotchas, and not just to
shift them around - thus my ':#' proposal.
OTOH, you just (inadvertently?) pointed out that ':#<...>' is very
much like adverbial syntax; this could be quite useful if we ever find
a need for the parser to associate comments directly with code, in
that anything that can take an adverb could theoretically have a
comment associated with it. But that's a can of worms that doesn't
need to be opened yet, if ever.
> We could always have a Q form in place of #'s to achieve the above effect
> from S02, more like a funny heredoc, e.g.
>
> Q :#<<< # embedded
> sub foo # comment
> { # extends
> ... # to
> } # (wait for it)
# here!
>
> Maybe call it a "theredoc"! :-)
We can already do this using POD sections:
=begin comment
sub foo
{
...
}
=end comment
I don't see much need for a #-based multi-line comment beyond this.
But it _would_ be nice to be able to indent POD Sections in the same
way that you can indent heredocs. Especially if the former is
intended to be the standard means of commenting out blocks of lines.
OTOH, let's say for the moment that we choose to extend the analogy
between embedded comments and quotes: one could, in theory, do a
Heredoc-style comment:
:# <<< END
line 1
line 2
line 3
END
where ':#' is the comment-equivalent of 'q', whatever that turns out
to be. (I'm not sold on ':#'; but I _would_ like to see a two-symbol
token that begins with a non-'#' and ends with a '#', for conciseness
and clarity.)
Technically, this would also allow for the likes of ':#"comment"'.
But I agree with the gentleman from the original discussion years ago
that we should probably forbid non-bracketing characters when
delimiting embedded comments.
--
Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Jon Lang wrote:
smuj wrote:
smuj wrote:
Jon Lang wrote:
... the biggest potential stumbling block for this
would be the existence of a double-bracket that sees frequent use at
the start of a line. Query: does '<<' count as a double bracket, or
as a single bracket (since it's equivalent to '«')?
[S02] {Note however that bare circumfix or postcircumfix <<...>> is not a
user-selected bracket, but the ASCII variant of the «...» interpolating word
list. Only # and the q-style quoters (including m, s, tr, and rx) enable
subsequent user-selected brackets.}
Just to clarify on that quote from S02, what I was trying to say (if I
understand the synopsis correctly) is that << counts as either single or
double depending on context. If you stick a # on the front, then << will
count as a double bracket.
Thanks for the clarification. Either we change this so that '<<'
counts as a single bracket for inline comment purposes, or we live
with the risk of start-of-line inline comments '#<< ... >>' when
prepending #'s to comment out sections of code.
Or we leave it as is. Is it really _that_ big of a problem to retrain
yourself to type "# " instead of "#" when commenting out lines?
It would certainly annoy a lot of people, me included! :-)
Here's a radical notion: use something other than '#' to initiate an
inline comment.
[snippage]
Or maybe just don't allow "embedded" comments unless they are actually
"embedded", i.e. if a line starts with a # (ignoring leading whitespace)
then it's _always_ a line-end comment, no matter what follows the #, e.g.
#blah # line-end comment
#{ # another line-end comment
#{ # yet another line-end comment (YALC)
some-code-here #{...}# embedded comment
If we allow the following coding style from S02:
#sub foo# line end comment
#{ # okay, comment
... # extends
} # to here
then perhaps we should change the term "embedded comment" to "extended
comment".
We could always have a Q form in place of #'s to achieve the above
effect from S02, more like a funny heredoc, e.g.
Q :#<<< # embedded
sub foo # comment
{ # extends
...# to
} # (wait for it)
>>> # here!
Maybe call it a "theredoc"! :-)
Cheers
--
smuj
Re: Rukudo-Star => Rakudo-lite?
Rakudo Zengi would be the most (in)appropriate, I think. Larry
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Darren Duncan wrote: > Still, I like the idea of #...# also being supported from the point of > symmetry with '...' and "..." also being supported, not that this is > necessary. This is mutually exclusive with the practice of commenting out a bunch of lines by prepending them with '#'. -- Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
smuj wrote:
> smuj wrote:
>> Jon Lang wrote:
>>> ... the biggest potential stumbling block for this
>>> would be the existence of a double-bracket that sees frequent use at
>>> the start of a line. Query: does '<<' count as a double bracket, or
>>> as a single bracket (since it's equivalent to '«')? If the former,
>>> then there's a respectable chance of seeing a line that begins with
>>> '<<' which would comment out as an inline comment rather than an
>>> end-of-line comment. If the latter, lines beginning with '<<' would
>>> still comment out as end-of-line comments. Off the top of my head, I
>>> can't think of any other bracketing characters that are commonly
>>> doubled up.
>>
>> [S02] {Note however that bare circumfix or postcircumfix <<...>> is not a
>> user-selected bracket, but the ASCII variant of the «...» interpolating word
>> list. Only # and the q-style quoters (including m, s, tr, and rx) enable
>> subsequent user-selected brackets.}
>
> Just to clarify on that quote from S02, what I was trying to say (if I
> understand the synopsis correctly) is that << counts as either single or
> double depending on context. If you stick a # on the front, then << will
> count as a double bracket.
Thanks for the clarification. Either we change this so that '<<'
counts as a single bracket for inline comment purposes, or we live
with the risk of start-of-line inline comments '#<< ... >>' when
prepending #'s to comment out sections of code.
Or we leave it as is. Is it really _that_ big of a problem to retrain
yourself to type "# " instead of "#" when commenting out lines?
Here's a radical notion: use something other than '#' to initiate an
inline comment. I suggested before the possibility of '#:' as the
inline comment identifier; what if we reverse this, and require ':#'
instead? This would completely remove the risk of a start-of-line
comment being confused with an inline comment. It would be visially
lightweight. It would be short (four characters minimum). It
wouldn't require you to double up on anything. And the only danger
would be if you try to insert a comment immediately after a colon,
with no intervening whitespace - which strikes me as an _extremely_
bad practice which should be discouraged regardless. So:
# line comment
#(line comment)
:# syntax error (missing brackets)
:#(inline comment)
--
Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Jon Lang wrote: On Mon, Aug 10, 2009 at 3:36 PM, Darren Duncan wrote: Personally, I think that comments should have trailing # as well as leading ones, so they are more like strings in that the same character is used to mark both ends. You mean like the following? q[quoted text] qq(interpolated quote) s = "string" rx(pattern) The leading # in an inline comment is akin to the q|qq|s|tr etc. of the various pseudo-quote structures: it identifies to what purpose the brackets are being used. Yes, it is like you say. A trailing # would be superfluous. Okay, you make a point that the likes of q[] probably outweigh the use of '' or "" in non-trivial strings. Note that my proposal is orthogonal to other issues like double-leading # or whatever bracketing chars are used. Also note that if the # are treated more like delimiters, then potentially we could also have \# to escape literal #, same as we have \' or \" etc. Ugh. One of the reasons for the likes of q< ... >, etc. is to provide an alternative to having to escape the delimiter by allowing you to select a delimiter that won't clash. By making '#' a delimiter, you remove that ability. Still, I like the idea of #...# also being supported from the point of symmetry with '...' and "..." also being supported, not that this is necessary. On the other hand, if #...# were supported, I would still also want Perl to DWIM when one uses a line of hash-marks for a visual divider line, like ## (to 80 chars or something). -- Darren Duncan
Re: Rukudo-Star => Rakudo-lite?
Since I don't know anything about nuclear power plants, I think the BikeShed should be painted blue and called "Rakudo Whatever" or just "Rakudo". -Jason "s1n" Switzer
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
smuj wrote:
Jon Lang wrote:
On Mon, Aug 10, 2009 at 2:16 PM, Mark J. Reed wrote:
I still like the double-bracket idea. I don't much mind the extra
character; 5 characters total still beats the 7 of HTML/XML.
Agreed. As I said, the biggest potential stumbling block for this
would be the existence of a double-bracket that sees frequent use at
the start of a line. Query: does '<<' count as a double bracket, or
as a single bracket (since it's equivalent to '«')? If the former,
then there's a respectable chance of seeing a line that begins with
'<<' which would comment out as an inline comment rather than an
end-of-line comment. If the latter, lines beginning with '<<' would
still comment out as end-of-line comments. Off the top of my head, I
can't think of any other bracketing characters that are commonly
doubled up.
[S02] {Note however that bare circumfix or postcircumfix <<...>> is not
a user-selected bracket, but the ASCII variant of the «...»
interpolating word list. Only # and the q-style quoters (including m, s,
tr, and rx) enable subsequent user-selected brackets.}
Just to clarify on that quote from S02, what I was trying to say (if I
understand the synopsis correctly) is that << counts as either single or
double depending on context. If you stick a # on the front, then << will
count as a double bracket.
Cheers,
--
smuj
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 3:36 PM, Darren Duncan wrote: > Personally, I think that comments should have trailing # as well as leading > ones, so they are more like strings in that the same character is used to > mark both ends. You mean like the following? q[quoted text] qq(interpolated quote) s = "string" rx(pattern) The leading # in an inline comment is akin to the q|qq|s|tr etc. of the various pseudo-quote structures: it identifies to what purpose the brackets are being used. A trailing # would be superfluous. > Note that my proposal is orthogonal to other issues like double-leading # or > whatever bracketing chars are used. > > Also note that if the # are treated more like delimiters, then potentially > we could also have \# to escape literal #, same as we have \' or \" etc. Ugh. One of the reasons for the likes of q< ... >, etc. is to provide an alternative to having to escape the delimiter by allowing you to select a delimiter that won't clash. By making '#' a delimiter, you remove that ability. -- Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
As an addendum, I think it goes without saying that this is the simplest form of
what I proposed:
# This is a
comment. #
That denotes a complete comment, which could be broken over lines or not, and
the rules for parsing or escaping it would be exactly the same as a character
string literal, except for a lack of interpolation abilities, and literal # are
escaped.
That is essentially how I do comments in Muldis D, and it works quite well.
-- Darren Duncan
Darren Duncan wrote:
Personally, I think that comments should have trailing # as well as
leading ones, so they are more like strings in that the same character
is used to mark both ends.
So in combination with bracketing pairs, we could for example have this:
#{ This is a comment. }#
That also serves to make the comments more whitespace independent, like
with strings in general.
I think the trailing # may also resolve some other issues raised in this
thread.
Note that my proposal is orthogonal to other issues like double-leading
# or whatever bracketing chars are used.
Also note that if the # are treated more like delimiters, then
potentially we could also have \# to escape literal #, same as we have
\' or \" etc.
Having # at both ends makes it easier to see at a glance where comments
begin and end, and potentially it makes it easier to make a parser or
syntax colorer.
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Personally, I think that comments should have trailing # as well as leading
ones, so they are more like strings in that the same character is used to mark
both ends.
So in combination with bracketing pairs, we could for example have this:
#{ This is a comment. }#
That also serves to make the comments more whitespace independent, like with
strings in general.
I think the trailing # may also resolve some other issues raised in this thread.
Note that my proposal is orthogonal to other issues like double-leading # or
whatever bracketing chars are used.
Also note that if the # are treated more like delimiters, then potentially we
could also have \# to escape literal #, same as we have \' or \" etc.
Having # at both ends makes it easier to see at a glance where comments begin
and end, and potentially it makes it easier to make a parser or syntax colorer.
-- Darren Duncan
More flexible POD
Masak's Journal[1] identifies a couple of problems involving the
interaction of POD with block-form classes - one in the article
itself, and another in the comments that follow. The first is that a
mixture of indented block-form classes and non-indented POD is
visually very ugly. The second is that mixing POD and code is in
general problematic. In the latter case, a recommendation is made
that good practice would put all of the POD together at the end of the
file, rather than interspersed throughout.
These two issues seem to operate at cross-purposes: on the one hand,
if all of the POD is consolidated at the end of the file, then you
don't have to worry about how ugly it is to mix POD and indented code.
OTOH, do we really want to punish programmers for trying to mix the
two?
Assuming that we want to make life easier on programmers who like to
intersperse code and POD, one way to do this would be to replace the
"start of line only" rule for POD with an indenting rule not unlike
what is used with block quotes: if there's any leading whitespace on
the opening line of a POD section, then every line in that section
must start with equivalent whitespace. This complicates the POD
extractor, but not by much.
In terms of placing all of the POD at the end: one of the strongest
reasons for mixing POD with code is that you can easily identify what
code to which a given section of POD refers. Putting all of the POD at
the end lacks that ability. One possible solution would be to provide
some means for you to specify a "POD footnote" in the code, not unlike
the URL reference that I've got in this email: in the code itself, you
place an anchor (e.g., '#{{=[1]}}') which can then be referenced later
on by a POD section (e.g., '=[1] start ...'). This would provide an
easy way to switch back and forth between the POD and the related
code. Mind you, I'm not at all enamored with the specific syntax
suggested above. It's a quick-and-dirty hack intended strictly to
illustrate the concept.
--
Jonathan "Dataweaver" Lang
[1] http://use.perl.org/~masak/journal/39334
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Jon Lang wrote:
On Mon, Aug 10, 2009 at 2:16 PM, Mark J. Reed wrote:
I still like the double-bracket idea. I don't much mind the extra
character; 5 characters total still beats the 7 of HTML/XML.
Agreed. As I said, the biggest potential stumbling block for this
would be the existence of a double-bracket that sees frequent use at
the start of a line. Query: does '<<' count as a double bracket, or
as a single bracket (since it's equivalent to '«')? If the former,
then there's a respectable chance of seeing a line that begins with
'<<' which would comment out as an inline comment rather than an
end-of-line comment. If the latter, lines beginning with '<<' would
still comment out as end-of-line comments. Off the top of my head, I
can't think of any other bracketing characters that are commonly
doubled up.
[S02] {Note however that bare circumfix or postcircumfix <<...>> is not
a user-selected bracket, but the ASCII variant of the «...»
interpolating word list. Only # and the q-style quoters (including m, s,
tr, and rx) enable subsequent user-selected brackets.}
Cheers,
--
smuj
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 2:16 PM, Mark J. Reed wrote: > I still like the double-bracket idea. I don't much mind the extra > character; 5 characters total still beats the 7 of HTML/XML. Agreed. As I said, the biggest potential stumbling block for this would be the existence of a double-bracket that sees frequent use at the start of a line. Query: does '<<' count as a double bracket, or as a single bracket (since it's equivalent to '«')? If the former, then there's a respectable chance of seeing a line that begins with '<<' which would comment out as an inline comment rather than an end-of-line comment. If the latter, lines beginning with '<<' would still comment out as end-of-line comments. Off the top of my head, I can't think of any other bracketing characters that are commonly doubled up. -- Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 4:57 PM, Jon Lang wrote: > I'd recommend '#='; but if that > isn't already being used by pod, it should be reserved for use by pod > (and it's visually heavy). Commenting out lines that include pod will generate #= at the beginning of a line, which is tantamount to the problem we're trying to avoid. > What other symbols are reasonably easy to type, are visually > lightweight, and are unlikely to be found at the start of a line and > immediately followed by an open bracket? Hmm... how about '#.'? Too visually lightweight, IMO Almost disappears entirely in this font next to the heavy #, making the third and fourth lines below easily confusable. > #line comment > #.line comment > #(line comment) > #.(inline comment) Besides which, Perl 6 teaches us that $foo() and $foo.() are usually interchangeable. :) I still like the double-bracket idea. I don't much mind the extra character; 5 characters total still beats the 7 of HTML/XML. -- Mark J. Reed
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 12:25 PM, Patrick R. Michaud wrote:
> I'd be fine with the ##(embedded comment solution) approach (doubling
> the #'s), but it's much less visually appealing to me. I think I'd
> prefer to see a doubling of the bracketing chars instead of doubling
> the #'s -- the # is visually a "heavy" glyph and I'd prefer
> something a bit lighter.
>
> #((embedded comment))
> #{{embedded comment}}
I could definitely go with this. The only question lies in how often
you're likely to find a doubled open-bracket at the start of a line.
However, let me toss out some other possibilities for consideration:
If you want lightweight, another possibility would be to insist that
an inline comment must be preceded by horizontal whitespace; so "#{
comment }" would be an end-of-line comment, whereas " #{ comment }"
would be an inline comment. This is in keeping with the current
spec's use of whitespace to distinguish between a start-of-line
comment and an inline comment. Then again, perhaps that's a bit _too_
lightweight. And it adds to another problem that I have with Perl 6,
namely the variety of mandatory/forbidden whitespace rules. They are,
IMHO, a necessary evil, and should be kept to a minimum. Plus, when I
typed the latter one out in this message, the composition window
wrapped the line between the start of the quote and the #. One of the
lesser purposes of an inline comment is when you're passing code
through channels that might insert word-wraps into the code: an
end-of-line comment has the possibility of breaking, whereas the
inline comment handles it without complaint.
Another possibility: instead of "##" for an inline comment, how about
some other two-character pair that starts with a '#', where the second
character is a non-bracketing character that's unlikely to be found at
the start of a line? E.g., '#:' - the colon is visible, lightweight,
and is almost always tacked onto the end of something else. In this
approach, the minimum number of characters needed for an inline
comment will be four: the '#:' pair, an open-bracket, and a
close-bracket. (Compare to '#{{ ... }}', which requires a minimum of
five characters.) It also avoids the question of how much repetition
of the '#' is permitted. So:
#line comment
#:line comment
#(line comment)
#:(inline comment)
OTOH, :( ... ) is the Perl syntax for a signature; and it wouldn't be
unreasonable to find a signature at the beginning of a line. Far less
common than the current situation of finding an open-bracket there;
but perhaps too common to ignore. I'd recommend '#='; but if that
isn't already being used by pod, it should be reserved for use by pod
(and it's visually heavy).
What other symbols are reasonably easy to type, are visually
lightweight, and are unlikely to be found at the start of a line and
immediately followed by an open bracket? Hmm... how about '#.'?
#line comment
#.line comment
#(line comment)
#.(inline comment)
--
Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Patrick R. Michaud wrote:
On Mon, Aug 10, 2009 at 06:46:34PM +0100, smuj wrote:
Although I can see some minimal uses for embedded comments, I think in
general the cost/benefit ratio isn't enough to warrant their existence.
I could be wrong of course! :-) I'd like to know if anyone has made much
use of them in their code, and under what circumstances.
I've used embedded comments a number of times (especially in examples)
and found them to be incredibly useful. I'd be sad to see them disappear.
I'd be fine with the ##(embedded comment solution) approach (doubling
the #'s), but it's much less visually appealing to me. I think I'd
prefer to see a doubling of the bracketing chars instead of doubling
the #'s -- the # is visually a "heavy" glyph and I'd prefer
something a bit lighter.
#((embedded comment))
#{{embedded comment}}
Pm
Yep, I agree that #((blah)) is better than ##(blah). It's much easier to
pick out and far more difficult to create by mistake, so it satisfies my
notion of being "purposeful", whilst also lessening the possibility of
"gotchas"! It's also better because it's already valid embedded comment
syntax:
[S02] {For all quoting constructs that use user-selected brackets, you
can open with multiple identical bracket characters, which must be
closed by the same number of closing brackets}
The "special rule" disallowing embedded comments as the first thing on a
line could be done away with, easing the learning curve of those new to
the language, so this seems like a good idea all round -- unless you're
the poor soul who has to change the grammar yet again! ;-)
Cheers,
--
smuj
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 06:46:34PM +0100, smuj wrote:
> Although I can see some minimal uses for embedded comments, I think in
> general the cost/benefit ratio isn't enough to warrant their existence.
> I could be wrong of course! :-) I'd like to know if anyone has made much
> use of them in their code, and under what circumstances.
I've used embedded comments a number of times (especially in examples)
and found them to be incredibly useful. I'd be sad to see them disappear.
I'd be fine with the ##(embedded comment solution) approach (doubling
the #'s), but it's much less visually appealing to me. I think I'd
prefer to see a doubling of the bracketing chars instead of doubling
the #'s -- the # is visually a "heavy" glyph and I'd prefer
something a bit lighter.
#((embedded comment))
#{{embedded comment}}
Pm
Re: S05 (regex) Q:
Modifiers like :ratchet are lexically scoped, and therefore extend into any embedded or , I think. These days if you find yourself saying "surrounding context", you should usually ask yourself whether you mean "lexical" or "dynamic", and that often indicates the direction I'll be leaning on underspecced issues, especially if you assume I have a bias towards lexical unless dynamic is explicitly mentioned. I supposed it could be argued that the argument to a before or after is hidden from the outer lexical scope, such as in but I'd say that even there, the language inside the parens is still inherited from the surrounding language braid, which is a lexically scoped concept. The current outermost language is called $~MAIN (see S02) while the current regex language is called $~Regex. It just has to look outward a bit further to see what the current definition of $~MAIN is than it would have to look for $~Regex. But all the ~ twigil variables are working together to define the current lexical scope's language in an interwoven fashion. Which is why we call it a "braid" of languages. Larry
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Hiyas,
Carl Mäsak wrote:
In my post "Three things in Perl 6 that aren't so great" [0], I
outline three things about Perl 6 that bug me at present. Commenter
daxim made what seems to me a sensible proposal [1] for solving the
third problem, "Comments in the beginning of lines":
daxim (]):
] Let single # be used for commenting out, no matter what follows.
] Let ## (perhaps also ### and so on) switch on the special behaviour
] of brackets etc.
I just want to say that this makes sense to me, both from a Huffmanian
standpoint, and from the standpoint of the principle of least
surprise. It doesn't make embedded comments much more convenient,
because C<##(this)> isn't much more cumbersome to write than
C<#(this)>. And it solves the commenting-out-whole-lines problem.
Although I can see some minimal uses for embedded comments, I think in
general the cost/benefit ratio isn't enough to warrant their existence.
I could be wrong of course! :-) I'd like to know if anyone has made much
use of them in their code, and under what circumstances.
If they are to remain, I'd vote for the ## solution (as suggested by
daxim) in order to remove the "gotchas" that are bound to occur
otherwise. Embedded comments should be a "purposeful" thing! I wouldn't
go for "any string of #'s longer than one" as that would require people
to scan every line of #'s just to see if there was something on the
other #(end)
after an embedded comment.
In the aftermath of YAPC::EU, the question of embedded comments was
also touched upon, and another solution was discussed: leave things as
they are currently specced, but don't consider C<#{> the start of an
embedded comment -- in other words, all other bracketing characters
can still be used to make embedded comments, but the curly braces can
not. This, if I remember the discussions correctly, had two
advantages:
1. It makes it safe(r) for the user to think 'closure' when she sees a
C<{...}> block. Even in interpolated strings, it's a closure.
2. At least parts of the commenting-out-whole-lines problem would go away.
It's not worth the complication IMHO. I would vote, in order of preference:
1) get rid of embedded comments altogether
2) ## followed by _any_ opening bracket character is an embedded comment
It would be nice to hear p6l-ers' reactions on these two proposals. Be
warned, though -- this is a bit of a bikeshedding topic. :) Every one
and his dog is an expert on comment syntax.
I think that's something we can all agree on!! :-)
[0] http://use.perl.org/~masak/journal/39334
[1] http://use.perl.org/comments.pl?sid=43438&cid=69583
Cheers
--
smuj
Embedded comments: two proposed solutions to the comment-whole-lines problem
In my post "Three things in Perl 6 that aren't so great" [0], I
outline three things about Perl 6 that bug me at present. Commenter
daxim made what seems to me a sensible proposal [1] for solving the
third problem, "Comments in the beginning of lines":
daxim (]):
] Let single # be used for commenting out, no matter what follows.
] Let ## (perhaps also ### and so on) switch on the special behaviour
] of brackets etc.
I just want to say that this makes sense to me, both from a Huffmanian
standpoint, and from the standpoint of the principle of least
surprise. It doesn't make embedded comments much more convenient,
because C<##(this)> isn't much more cumbersome to write than
C<#(this)>. And it solves the commenting-out-whole-lines problem.
In the aftermath of YAPC::EU, the question of embedded comments was
also touched upon, and another solution was discussed: leave things as
they are currently specced, but don't consider C<#{> the start of an
embedded comment -- in other words, all other bracketing characters
can still be used to make embedded comments, but the curly braces can
not. This, if I remember the discussions correctly, had two
advantages:
1. It makes it safe(r) for the user to think 'closure' when she sees a
C<{...}> block. Even in interpolated strings, it's a closure.
2. At least parts of the commenting-out-whole-lines problem would go away.
It would be nice to hear p6l-ers' reactions on these two proposals. Be
warned, though -- this is a bit of a bikeshedding topic. :) Every one
and his dog is an expert on comment syntax.
[0] http://use.perl.org/~masak/journal/39334
[1] http://use.perl.org/comments.pl?sid=43438&cid=69583
Re: Rukudo-Star => Rakudo-lite?
Given the Japanese behind the name Rakudo, "rakudone" looks like a question: "Rakudo, right?" Beats "rakuod", though. On 8/10/09, James Fuller wrote: > how about > > 'raku' > > then the final version could be called > > 'rakudone' > > Jim Fuller > -- Sent from my mobile device Mark J. Reed
Re: Rukudo-Star => Rakudo-lite?
how about 'raku' then the final version could be called 'rakudone' Jim Fuller
Re: Rukudo-Star => Rakudo-lite?
Then you could be like TeX and have releases numbered with ever-increasing parts of an irrational number. On Mon, Aug 10, 2009 at 12:37 PM, Mark J. Reed wrote: > Wrong reply button... > > -- Forwarded message -- > From: "Mark J. Reed" > Date: Mon, 10 Aug 2009 07:36:52 -0400 > Subject: Re: Rukudo-Star => Rakudo-lite? > To: Gabor Szabo > > That has the same problem as lots of other themes - it puts a hard > limit on the number of releases before the One True Rakudo. > Maybe you could call it Zeno's Camel (project motto: "halfway done!") > and have releases numbered 0.5, 0.75, 0.875, 0.9375,... :) > > On 8/10/09, Gabor Szabo wrote: >> On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaud >> wrote: >>> On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote: On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote: > Perhaps it's worth asking what we might call the release after that > one. > "Rakudo not-quite-so-lite"? Rakudo ** (aka "Rakudo Exponentiation")? Though I think Patrick is optimistic that development will proceed exponentially enough that a single interim release will be enough to hold us over until Christmas. >>> >>> I'm not sure I'm quite THAT optimistic. :-) We may end up with >>> multiple interim releases in the Rakudo Star series before we reach >>> Christmas. (And yes, they may even be *+1, *+2, etc.) >>> >>> In some ways I'm starting to think of "Star" (or whatever designation >>> we end up using) as a label for a series of interim releases in the >>> same sense that NASA used "Gemini" as the label for the program >>> came between "Mercury" and "Apollo". >>> >>> In other words, "Star" may really end up being a designation for a >>> program of planned releases with certain major objectives that >>> cumulatively lead up to the ultimate goal of a "full Perl 6 release". >>> >>> The precise details are still a little ill-formed in my head at the >>> moment, but as they come together (and are expressed in planning >>> documents) I'll be blogging or writing about them appropriately. >>> >> >> >> my bikeshed would go along the lines of >> >> @rakudo[*-100] >> @rakudo[*-99] >> ... >> >> Gabor >> > > -- > Sent from my mobile device > > Mark J. Reed > > -- > Sent from my mobile device > > Mark J. Reed >
Fwd: Rukudo-Star => Rakudo-lite?
Wrong reply button... -- Forwarded message -- From: "Mark J. Reed" Date: Mon, 10 Aug 2009 07:36:52 -0400 Subject: Re: Rukudo-Star => Rakudo-lite? To: Gabor Szabo That has the same problem as lots of other themes - it puts a hard limit on the number of releases before the One True Rakudo. Maybe you could call it Zeno's Camel (project motto: "halfway done!") and have releases numbered 0.5, 0.75, 0.875, 0.9375,... :) On 8/10/09, Gabor Szabo wrote: > On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaud > wrote: >> On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote: >>> On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote: Perhaps it's worth asking what we might call the release after that one. "Rakudo not-quite-so-lite"? >>> >>> Rakudo ** (aka "Rakudo Exponentiation")? Though I think Patrick is >>> optimistic that development will proceed exponentially enough that a >>> single interim release will be enough to hold us over until Christmas. >> >> I'm not sure I'm quite THAT optimistic. :-) We may end up with >> multiple interim releases in the Rakudo Star series before we reach >> Christmas. (And yes, they may even be *+1, *+2, etc.) >> >> In some ways I'm starting to think of "Star" (or whatever designation >> we end up using) as a label for a series of interim releases in the >> same sense that NASA used "Gemini" as the label for the program >> came between "Mercury" and "Apollo". >> >> In other words, "Star" may really end up being a designation for a >> program of planned releases with certain major objectives that >> cumulatively lead up to the ultimate goal of a "full Perl 6 release". >> >> The precise details are still a little ill-formed in my head at the >> moment, but as they come together (and are expressed in planning >> documents) I'll be blogging or writing about them appropriately. >> > > > my bikeshed would go along the lines of > > @rakudo[*-100] > @rakudo[*-99] > ... > > Gabor > -- Sent from my mobile device Mark J. Reed -- Sent from my mobile device Mark J. Reed
Re: Rukudo-Star => Rakudo-lite?
On Mon, Aug 10, 2009 at 2:02 AM, Patrick R. Michaud wrote: > On Sun, Aug 09, 2009 at 04:35:42PM -0600, David Green wrote: >> On 2009-Aug-9, at 3:57 pm, Tim Bunce wrote: >>> Perhaps it's worth asking what we might call the release after that >>> one. >>> "Rakudo not-quite-so-lite"? >> >> Rakudo ** (aka "Rakudo Exponentiation")? Though I think Patrick is >> optimistic that development will proceed exponentially enough that a >> single interim release will be enough to hold us over until Christmas. > > I'm not sure I'm quite THAT optimistic. :-) We may end up with > multiple interim releases in the Rakudo Star series before we reach > Christmas. (And yes, they may even be *+1, *+2, etc.) > > In some ways I'm starting to think of "Star" (or whatever designation > we end up using) as a label for a series of interim releases in the > same sense that NASA used "Gemini" as the label for the program > came between "Mercury" and "Apollo". > > In other words, "Star" may really end up being a designation for a > program of planned releases with certain major objectives that > cumulatively lead up to the ultimate goal of a "full Perl 6 release". > > The precise details are still a little ill-formed in my head at the > moment, but as they come together (and are expressed in planning > documents) I'll be blogging or writing about them appropriately. > my bikeshed would go along the lines of @rakudo[*-100] @rakudo[*-99] ... Gabor
