comments as preserved meta-data (was Re: Embedded comments ...)
Eirik Berg Hanssen wrote: Moritz Lenz writes: In all other cases of quote like constructs are the semantics are explicit first (think of Q, qx, m, <, «), the delimiter comes later. Changing that all of a sudden seems very unintuitive and wrong. Thing is, comments are not quote-like. All of the quote-like constructs are expressions. Comments are not. Different things should be different, and comments should not look like expressions. Or so it seems to me, at least. On the contrary, I think that comments *are* expressions, *iff* they are preserved in the meta-data for code that you can access when introspecting the code, such as preserving documentation in the code meta-data, which it essentially is. I cite as prior art, for example, the FoxPro language, where the data-structure representation of code has fields to store comments, such as to further explain to people just looking at the code in the form of said data-structure what the thing is. Muldis D does this too, since homoiconic is a core nature and the data-structure version of code is just as valid as the string form that people normally write. So I propose, and the details could still be worked out, that whenever a comment appears in Perl 6 code, then depending on its relative location, then at parse time it is attached as a meta-data field to the most contextually relevant code structure, such as for whatever Perl statement it is next to, or routine it is inside of, etc. Mind you, this may overlap with desired uses of embedded pod, in Perl 6, but either way, the fact a programmer wrote a comment for some code implies that the comment is important, and as Perl code is transformed or alternately regenerated later such as Perl 6 code for debugging, or for translating to/from some other language, its nice to persist the comments through the process. P.S. My proposal also implies that a Comment would need a data type if it is retained in the meta-data. I propose naming the type "Comment", which is essentially a "Str" but with minor differences if or insomuch perhaps as a symbol/identifier is a "Str". Or it could be less like a Str in the whole but it would at least contain a Str as an attribute. -- Darren Duncan
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
jerry gay wrote: for the latest spec changes regarding this item, see http://perlcabal.org/svn/pugs/revision/?rev=27959. is everyone equally miserable now? ;) I'm quite happy actually -- #` or #+ makes no difference to me :-) S02 just got that little bit simpler, so the thread was worthwhile. Thank you O Great Decider!! Cheers -- smuj
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
jerry gay wrote: > for the latest spec changes regarding this item, see > http://perlcabal.org/svn/pugs/revision/?rev=27959. > > is everyone equally miserable now? ;) Already seen it. My latest points still stand, though: #`(...) is still vulnerable to ambiguity relative to #..., whereas `#(...), `#...#`, or (#...) don't share the same vulnerability. -- Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
> for the latest spec changes regarding this item, see > http://perlcabal.org/svn/pugs/revision/?rev=27959. > > is everyone equally miserable now? ;) > ~jerry Ha! :) I do indeed feel underwhelmed. I'll surely get over it but I may as well post why, even though Larry's presumably trying to stop the discussion. Sorry Larry. First, I had liked some of the ideas that had been posted in this thread. Quite a lot more than Larry's pick. Of course, I may well be missing complications he can see. Second, I had been mulling backtick, but was thinking on more radical lines than the one Larry's gone for. Again, perhaps he's got more up his sleeve that builds on what he's just committed. For a quick backgrounder, Larry had talked of reserving backtick for use as a user defined operator [1], Mark had suggested its use as a (tightly bound) comment [2], and James et al had suggested using it to declare units [3]. I've long been in Mark's camp about a lightweight and attractive docstring syntax being likely to be helpful for encouraging habits that would likely contribute to improved long term maintainability of code with comments, and was mulling that. -- love, raiph [1] http://markmail.org/message/zvn2hul6irggtrde [2] http://groups.google.com/group/perl.perl6.language/msg/7d10c6bc5d66288e?hl=en [3] http://www.mail-archive.com/perl6-language@perl.org/msg20819.html -- love, raiph
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Ben Morrow wrote: > This appears to be leading to a :comment modifier on quotables, with > some suitable shortcut. Perhaps 'q#'? Or are we not allowed mixed alpha > and symbols? It's probably a bad practice, if possible. > (I really want to suggest £, just to teach USAnians '#' isn't called > 'pound'... :) ) In all seriousness, there's another use to which I'd like to put '£'. -- Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
for the latest spec changes regarding this item, see http://perlcabal.org/svn/pugs/revision/?rev=27959. is everyone equally miserable now? ;) ~jerry
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
At 6PM +0200 on 11/08/09 you (Moritz Lenz) wrote:
> Ben Morrow wrote:
> >
> > However, I would much rather see a general syntax like
> >
> > (# ... )
> > {# ... }
> > [# ... ]
> >
> > with no whitespace allowed between the opening bracket and the #: this
> > doesn't seem to conflict with anything. Allowing <# ... > in rules would
> > also be nice.
>
> That severely violates the principle of least surprise. To me [#...]
> looks like an array ref which contains a comment, which is *not* what
> you propose (I think).
No, it wasn't. The idea was modelled after TT2's [%# ... %] syntax, and
other languages that mark comments just inside the delimiters.
> It also feels like a step backwards. In Perl 6 we try to make things
> clear from the beginning, not only from the second char on. Regex
> modifiers at the, anybody? or (?#...) as comments in regexes in Perl 5?
>
> In all other cases of quote like constructs are the semantics are
> explicit first (think of Q, qx, m, <, «), the delimiter comes later.
> Changing that all of a sudden seems very unintuitive and wrong.
This appears to be leading to a :comment modifier on quotables, with
some suitable shortcut. Perhaps 'q#'? Or are we not allowed mixed alpha
and symbols?
Ben
(I really want to suggest £, just to teach USAnians '#' isn't called
'pound'... :) )
r27959 - in docs/Perl6/Spec: . S32-setting-library
Author: lwall
Date: 2009-08-11 19:28:07 +0200 (Tue, 11 Aug 2009)
New Revision: 27959
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S04-control.pod
docs/Perl6/Spec/S05-regex.pod
docs/Perl6/Spec/S32-setting-library/Containers.pod
Log:
change embedded comment syntax to #`[...] and variants
define statement_prefix: to return Nil
more s/Capture/Parcel/ mods
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-11 16:14:19 UTC (rev 27958)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-11 17:28:07 UTC (rev 27959)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 6 Aug 2009
-Version: 172
+Last Modified: 11 Aug 2009
+Version: 173
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -135,7 +135,7 @@
Except within a string literal, a C<#> character always introduces a comment in
Perl 6. There are two forms of comment based on C<#>. Embedded
-comments require the C<#> to be followed by one
+comments require the C<#> to be followed by a backtick (C<`>) plus one
or more opening bracketing characters.
All other uses of C<#> are interpreted as single-line comments that
@@ -147,66 +147,35 @@
=item *
Embedded comments are supported as a variant on quoting syntax, introduced
-by C<#> plus any user-selected bracket characters (as defined in
+by C<#`> plus any user-selected bracket characters (as defined in
L above):
-say #( embedded comment ) "hello, world!";
+say #`( embedded comment ) "hello, world!";
-$object\#{ embedded comments }.say;
+$object\#`{ embedded comments }.say;
-$object\ #「
+$object\ #`「
embedded comments
」.say;
Brackets may be nested, following the same policy as ordinary quote brackets.
-There must be no space between the C<#> and the opening bracket character.
+There must be no space between the C<#`> and the opening bracket character.
(There may be the I of space for some double-wide
characters, however, such as the corner quotes above.)
-An embedded comment is not allowed as the first thing on the line.
+For multiline comments it is recommended (but not required) to use two or
+more brackets both for visual clarity and to avoid relying too much on
+internal bracket counting heuristics when commenting code that may accidentally
+miscount single brackets:
-#sub foo# line-end comment
-#{ # ILLEGAL, syntax error
-# ...
-#}
+#`{{
+say "here is an unmatched } character";
+}}
-If you wish to have a comment there, you must disambiguate it to
-either an embedded comment or a line-end comment. You can put a
-space in front of it to make it an embedded comment:
+However, it's sometimes better to use pod comments because they are
+implicitly line-oriented.
-#sub foo# line end comment
- #{ # okay, comment
- ... # extends
-} # to here
-
-Or you can put something other than a single C<#>
-to make it a line-end comment. Therefore, if you are commenting out a
-block of code using the line-comment form, we recommend that you use
-C<##>, or C<#> followed by some whitespace, preferably a tab to keep
-any tab formatting consistent:
-
-##sub foo
-##{ # okay
-## ...
-##}
-
-# sub foo
-# { # okay
-#...
-# }
-
-
-# sub foo
-# { # okay
-# ...
-# }
-
-However, it's often better to use pod comments because they are
-implicitly line-oriented. And if you have an intelligent syntax
-highlighter that will mark pod comments in a different color, there's
-less visual need for a C<#> on every line.
-
=item *
For all quoting constructs that use user-selected brackets, you can open
@@ -214,14 +183,14 @@
same number of closing brackets. Counting of nested brackets applies only
to pairs of brackets of the same length as the opening brackets:
-say #{{
+say #`{{
This comment contains unmatched } and { { { { (ignored)
Plus a nested {{ ... }} pair(counted)
}} q<< <> >> # says " <> "
Note however that bare circumfix or postcircumfix C<<< <<...>> >>> is
not a user-selected bracket, but the ASCII variant of the C<< «...» >>
-interpolating word list. Only C<#> and the C-style quoters (including
+interpolating word list. Only C<#`> and the C-style quoters (including
C, C, C, and C) enable subsequent user-selected brackets.
=item *
@@ -264,7 +233,7 @@
$number\ --;
1+3\ i;
$object\ .say();
-$object\#{ your ad here }.say
+$object\#`{ your ad here }.say
Another normal use of a you-don't-see-this-space is typic
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Moritz Lenz writes: > In all other cases of quote like constructs are the semantics are > explicit first (think of Q, qx, m, <, «), the delimiter comes later. > Changing that all of a sudden seems very unintuitive and wrong. Thing is, comments are not quote-like. All of the quote-like constructs are expressions. Comments are not. Different things should be different, and comments should not look like expressions. Or so it seems to me, at least. Rambling along ... In C++, all comments start with the same character, but it is the end-of-line comments that start off with it doubled up. And so C++ avoids these gotchas. Alternatively, if end-of-line comments required whitespace (or some other non-bracket non-# character class) after one or more # characters, it would not just resolve the gotchas: It would make the comments far easier to read as well. Meanwhile, a # sequence followed by neither whitespace nor brackets would be a syntax error, and I imagine that might make it hard to sell. Too late for Perl to go that way though. (Right? Yeah, right.) The only other way for Perl to avoid these gotchas and still retain the two kinds of comments seems to be if the two constructs start with different characters. Putting the delimiter first is one way of doing it. Reserving one more comment leading character would be another. Seems expensive though. :-\ So, are the more ways to design it with a different leading character? :#( ... ) has been suggested, and it is begginning to grow on me. :# ... #: could work, I suppose (it is not a quote-like expression, so doesn't need to look like it is) – but since the closer there starts with a #, I imagine that might run into similar trouble. An unspace-like \#( ... ) could perhaps work? ... though I get the feeling someone else has rambled along these lines before ... Eirik -- Ceci n'est pas une .sig.
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Ben Morrow wrote:
> Quoth markjr...@gmail.com (Mark J. Reed):
>>
>> 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.
>
> I much prefer double-bracket to double-#: double-# gets caught out when
> you do s/^/# on code which already includes line-starting # comments.
>
> However, I would much rather see a general syntax like
>
> (# ... )
> {# ... }
> [# ... ]
>
> with no whitespace allowed between the opening bracket and the #: this
> doesn't seem to conflict with anything. Allowing <# ... > in rules would
> also be nice.
That severely violates the principle of least surprise. To me [#...]
looks like an array ref which contains a comment, which is *not* what
you propose (I think).
It also feels like a step backwards. In Perl 6 we try to make things
clear from the beginning, not only from the second char on. Regex
modifiers at the, anybody? or (?#...) as comments in regexes in Perl 5?
In all other cases of quote like constructs are the semantics are
explicit first (think of Q, qx, m, <, «), the delimiter comes later.
Changing that all of a sudden seems very unintuitive and wrong.
Cheers,
Moritz
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Tue, Aug 11, 2009 at 8:59 AM, Jon Lang wrote:
> Ben Morrow wrote:
> > However, I would much rather see a general syntax like
> >
> >(# ... )
> >{# ... }
> >[# ... ]
> >
>
a preceding ':' (colon) makes it *notionally*
a null-label-block-comment-construct.
>
> > with no whitespace allowed between the opening bracket and the #: this
> > doesn't seem to conflict with anything. Allowing <# ... > in rules would
> > also be nice.
>
> That's rather elegant. It's no longer than the current embedded
> comment syntax, and avoids the start-of-line issue. The only
> complication arises when you prepend the brackets with a quote or
> pseudo-quote character:
>
> say q(# is this a string or a comment?); # DWIM -> string.
>
> --
> Jonathan "Dataweaver" Lang
>
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 10:31 AM, 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.
>
While I like the idea, ## occurs frequently in much existing code,
a more selective pattern would help.
like "#{" and "#}"
- explicit, DWIM block constructs
or qr/^\s*\#{3,}:[\[\{\(\<]/etc ..
- multiple-sharps makes the comment-block more visible
- any block-punctuation works (why limit it?)
This would clash far less with existing code,
and thus be usable there incrementally.
And this makes it a more portable, POD++ ish feature.
r27957 - docs/Perl6/Spec
Author: jani Date: 2009-08-11 17:08:49 +0200 (Tue, 11 Aug 2009) New Revision: 27957 Modified: docs/Perl6/Spec/S09-data.pod Log: Clarification of hash key sort order, based on S32 Modified: docs/Perl6/Spec/S09-data.pod === --- docs/Perl6/Spec/S09-data.pod2009-08-11 09:27:33 UTC (rev 27956) +++ docs/Perl6/Spec/S09-data.pod2009-08-11 15:08:49 UTC (rev 27957) @@ -1198,6 +1198,11 @@ a key object's value within the hash except by deleting it and reinserting it. +The order of hash keys is implementation dependent and arbitrary. +Unless C<%hash> is altered in any way, successive calls to C<.keys>, +C<.kv>, C<.pairs>, C<.values>, or C<.iterator> will iterate over the +elements in the same order. + =head1 Autosorted hashes The default hash iterator is a property called C<.iterator> that can be
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Ben Morrow wrote:
> However, I would much rather see a general syntax like
>
> (# ... )
> {# ... }
> [# ... ]
>
> with no whitespace allowed between the opening bracket and the #: this
> doesn't seem to conflict with anything. Allowing <# ... > in rules would
> also be nice.
That's rather elegant. It's no longer than the current embedded
comment syntax, and avoids the start-of-line issue. The only
complication arises when you prepend the brackets with a quote or
pseudo-quote character:
say q(# is this a string or a comment?); # DWIM -> string.
--
Jonathan "Dataweaver" Lang
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
smuj wrote: > Jon Lang wrote: >> 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. > > I think whatever the solution is, it must begin with a # -- anything else > will likely create even more gotchas. When inline comments begin with a '#', the main gotcha arises when you go to comment out a series of lines by prepending a # to each, and one of those lines begins with the proper series of characters to create an inline comment instead. If you add the condition that a line beginning with a '#' is automatically a full-line comment (or, as currently specced, simply complains about the ambiguity), you replace this gotcha with one where someone types in what he intends to be an inline comment, but forgets to indent it. Adding a secondary character after the '#' reduces the likelihood of this happening, but doesn't eliminate it. When inline comments begin with something other than '#', none of the above gotchas exist. Instead, the main gotcha occurs when you go to create an end-of-line comment at the end of a line that ends with whatever the first character of an inline comment is. A programmer who forgets to put whitespace between that character and the '#' will get an inline comment instead. IMHO, this is no different than any other case where the programmer mistakenly allows two different tokens to run together. As well, when programmers add comments to the ends of a series of lines, they generally lead off with whitespace intended to align said comments with each other; so existing habits would not cause difficulties as they currently do for commenting out lines. > Also, we have to realize that no > matter what sequence we choose for embedded comments, there will _always_ be > a chance of a gotcha, so all we can do is minimize the likelihood, as well > as making the gotcha easy to spot, whilst not making embedded comments too > difficult to use for those who like them. My argument is that starting an inline comment with something other than a '#' minimizes the likelihood of gotchas, makes gotchas easy to spot, and doesn't make embedded comments too difficult to use for those who like them. Is there anything that my argument missed? > My current personal favourite would be to keep things as they are with > regards to bracketing, but to introduce a + between the # and the brackets. This reduces the likelihood of ambiguity cropping up between an embedded comment and an end-of-line comment; but it doesn't eliminate the possibility. Reversing the order to '+#' _would_ eliminate any possibility of ambiguity at the start of a line; and the only thing you'd have to watch out for would be someone deciding to start an end-of-line comment immediately after a '+', with no intervening whitespace. As well, '+#' is just as easy to type as '#+'. Heck, while I like the bracketing idea, you could even say that any comment that begins with '+#' followed immediately by a non-bracketing character is an inline comment that will be terminated by the first '#+' sequence it finds: #end-of-line comment #(end-of-line) comment #+end-of-line comment #+(end-of-line) comment +# embedded comment #+ +#(embedded comment) I'm not picky as to the choice of the additional character; but if you're going to add it in, add it in where it will cause the least amount of trouble: just before the '#'. > I'd also change the terminology from "embedded" comments to "extended" > comments. toMAYto, toMAHto. -- Jonathan "Dataweaver" Lang
Re: More flexible POD
Being on holidays, it is not easy to follow threads closely, so if
I repeat things other people have said already, I apologize beforehand.
My responses may b late as well.
Two years ago, I discussed various options, which compared POD to features
in to other languages and suggested various syntaxes:
http://www.nntp.perl.org/group/perl.perl6.language/2007/07/msg27894.html
What I did not really find back in the (swift) scan of the whole debate
gongin on at the moment, is the need to maintain *error free*, *complete*,
and *consistent* documentation with *minimal effort*. So: the purpose of
documentation. This must be clear before syntax is being discussed.
"Error free" is simpler in Perl5, because subs have simple parameter
prototypes and we have no strict types. In Perl6, when the user
has more power in the parameter list, it is harder to document it
correctly by hand.
I have experiences converting two large existing modules from
'POD at the end' into 'intermixing POD and code'. I found many,
many mistakes in the POD probably because when changing the code
later, people do not see where the docs which need to be updated
are located.
POD at the end of the code to allow a logical flow of the docs has
some advantanges. IMO however, you mix two different needs of use
for documentation: you wish to teach the user and you need to describe
the API.
So, why not seperate those two purposes more clearly? My code
always has a rather short DESCRIPTION chapter, then the "use often"
detailed METHOD or FUNCTION description (interleaved with code)
and then a DETAILS (maybe a bad name) which is the training bit:
how everything interacts without going into the disturbing API
nitbits.
"Complete" is covered only partially by the "POD::Coverage". Of
course, it is detectable whether all methods/subs/rules are
described, but can you also check whether all parameters are
described in full?
"Consistent" documentation is something Perl5 lacks: have a look at
the way different (Core) modules describe their API. One of the
poorest parts is the complete lack of inheritance support for
documenting Perl. If you only write distributions with a single
functional package in them, then POD(5) suffices. When you do
more complex stuff (like the IO:: modules with inheritance etc)
then people start manually maintain lists of inherited methods and
named parameters in higher level man-pages. This is very hard to
maintain an stupid!!
"minimal effort" is crucial: when you want people to write documentation,
then it must create the most useful/beautiful result with minimal
effort. The need to rewrite method call parameters is one the of
useless and error-prone parts of the current POD design. Of course,
there must be a way to overrule the prototype when needed.
As example: my Mail::Box set of modules contain (with depedencies)
about 140 packages with 1150 documented methods and 200 error messages.
I use OODoc to improve PODs limitations which saves me the typing
of 700,000 characters(!) which pure POD would require.
The discussion with Damian, two years ago, is whether POD is a
second class sitizen, where it is a burdon to have it and code the only
important thing, or a first class sitizen. IMO (which is not generally
accepted in the Perl community, but in common in other languages) it is
the latter. IMO programming is solving a problem in a good way, which
means: it is only solved when "it works and is usable".
"it works"
. it does what we need it to do in our application
. it has regression tests to guarantee that the API works
"is usable"
. algorithmic documentation (where the code is unclear)
. api documentation
Code is IMHO not more important that docs or tests; they are different
view on the same problem. And most of use spend much more lines of text
on docs and tests than on the code (I guess three times as many lines
on docs as on code) So:we need a very light syntax for POD!
There are a few sources which could be used for POD:
1) information from the code
2) information from tests
3) interleaved documentation
4) end-of-file documentation
5) Separate file documentation
6) author, license, SEE ALSO, distribution, version facts
We need to have a standard way of translating those into a "document
tree". Then we can have different implementations to serialize that
into MAN, HTML etc. That latter part does not need an obligatory spec.
I use a template system for it. The current Perl6 specs do not follow
this model sufficiently.
If you agree that DOCs are first class language sitizens, then it must
be clear that the "short notation for often used syntax" rule applies.
#{{ or #{ are visually screaming far too loud. I would prefer a
simple /^\s*\`\s+/, but can think of many alternatives.
The link mentioned before refers to a more details spec with examples
to b
Re: Rukudo-Star => Rakudo-lite?
On Seg, 2009-08-10 at 22:06 -0500, raiph mellor wrote: > > Rakudo Zengi would be the most (in)appropriate, I think. > This latter point is the most exciting for me. "What is Rakudo Star? > Well, it's..." > A Beatles drummer ? -- Jose Celestino SAPO.pt::Systems http://www.sapo.pt - * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. signature.asc Description: This is a digitally signed message part
Re: Clarification of S04 closure traits
Sorry for the delay in replying, but I was busy with other things and I
wanted to give other people a chance to reply. Since noone has, might it
be possible to get the attached patches committed? I'm not familiar with
the protocol for such things so, again, I'm sorry if I've got it wrong.
Ben
--- S04-control.pod.orig 2009-08-11 08:43:36.0 +0100
+++ S04-control.pod 2009-08-11 09:03:42.0 +0100
@@ -1232,6 +1232,21 @@
before C, C, or C, since those are done at compile or
process initialization time).
+If an exception is thrown through a block without a C block, the
+C, C and C blocks will be run at that point, with
+C<$!> set to the in-flight exception. If there is no in-flight
+exception when these blocks are run, C<$!> will be C. The last
+exception caught in the outer block is available as C<< OUTER::<$!> >>,
+as usual.
+
+An exception thrown from an C block will abort the C
+queue, but one thrown from a C block will not. The exceptions
+thrown by failing C and C blocks cannot be caught by a
+C in the same block, which implies that C blocks are not
+run if a C block fails. If a C fails while an exception is in
+flight the C failure doesn't replace C<$!> but goes straight into
+C<$!.pending>.
+
For blocks such as C and C that are run when exiting a
scope normally, the return value (if any) from that scope is available
as the current topic. (It is presented as a C object.)
Index: S04-closure-traits/enter-leave.t
===
--- S04-closure-traits/enter-leave.t (revision 27955)
+++ S04-closure-traits/enter-leave.t (working copy)
@@ -2,7 +2,7 @@
use Test;
-plan 11;
+plan 19;
# L
# L
@@ -92,4 +92,92 @@
}), 1, 'leave triggers LEAVE {}';
}
+{
+my $str;
+try {
+ENTER { $str ~= '(' }
+LEAVE { $str ~= ')' }
+$str ~= 'x';
+die 'foo';
+}
+is $str, '(x)', 'die calls LEAVE blocks';
+}
+
+{
+my $str;
+try {
+LEAVE { $str ~= $! // '' }
+die 'foo';
+}
+is $str, 'foo', '$! set in LEAVE if exception thrown';
+}
+
+{
+my $str;
+{
+LEAVE { $str ~= (defined $! ? 'yes' : 'no') }
+try { die 'foo' }
+$str ~= (defined $! ? 'aye' : 'nay');
+}
+is $str, 'ayeno', '$! not set in LEAVE if exception not thrown';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+ENTER { die 'foo' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '()', 'die in ENTER caught by try';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+LEAVE { die 'foo' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '(x)', 'die in LEAVE caught by try';
+}
+
+{
+my $str;
+try {
+$str ~= '(';
+try {
+ENTER { $str ~= '['; die 'foo' }
+LEAVE { $str ~= ']' }
+$str ~= 'x';
+}
+$str ~= ')';
+}
+is $str, '([])', 'die in ENTER calls LEAVE';
+}
+
+{
+my $str;
+try {
+ENTER { $str ~= '1'; die 'foo' }
+ENTER { $str ~= '2' }
+}
+is $str, '1', 'die aborts ENTER queue';
+}
+
+{
+my $str;
+try {
+LEAVE { $str ~= '1' }
+LEAVE { $str ~= '2'; die 'foo' }
+}
+is $str, '21', 'die doesn\'t abort LEAVE queue';
+}
+
# vim: ft=perl6
Index: S04-closure-traits/pre-post.t
===
--- S04-closure-traits/pre-post.t (revision 27955)
+++ S04-closure-traits/pre-post.t (working copy)
@@ -9,7 +9,7 @@
# TODO:
# * Multiple inheritance + PRE/POST blocks
-plan 18;
+plan 25;
sub foo(Num $i) {
PRE {
@@ -125,4 +125,82 @@
lives_ok { $pt.test(2) }, 'POST receives return value as $_ (succeess)';
dies_ok { $pt.test(1) }, 'POST receives return value as $_ (failure)';
+{
+my $str;
+{
+PRE { $str ~= '('; 1 }
+POST { $str ~= ')'; 1 }
+$str ~= 'x';
+}
+is $str, '(x)', 'PRE and POST run on ordinary blocks';
+}
+
+{
+my $str;
+{
+POST { $str ~= ')'; 1 }
+LEAVE { $str ~= ']' }
+ENTER { $str ~= '[' }
+PRE { $str ~= '('; 1 }
+$str ~= 'x';
+}
+is $str, '([x])', 'PRE/POST run outside ENTER/LEAVE';
+}
+
+{
+my $str;
+try {
+{
+PRE { $str ~= '('; 0 }
+PRE { $str ~= '*'; 1 }
+ENTER { $str ~= '[' }
+$str ~= 'x';
+LEAVE { $str ~= ']' }
+POST{ $str ~= ')'; 1 }
+}
+}
+is $str, '(', 'failing PRE runs nothing else';
+}
+
+{
+my $str;
+try {
+{
+POST { $str ~= 'x'; 0 }
+LEAVE { $str ~= 'y' }
+POST { $str ~= 'z'; 1 }
+}
+}
+is $str, 'yx', 'failing POST runs LEAVE but not more POSTs';
+}
+
+{
+my $str;
+try {
+POST { $str ~= $! // ''; 1 }
+die 'foo';
+}
+is
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Quoth markjr...@gmail.com (Mark J. Reed):
>
> 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.
I much prefer double-bracket to double-#: double-# gets caught out when
you do s/^/# on code which already includes line-starting # comments.
However, I would much rather see a general syntax like
(# ... )
{# ... }
[# ... ]
with no whitespace allowed between the opening bracket and the #: this
doesn't seem to conflict with anything. Allowing <# ... > in rules would
also be nice.
Ben
Re: Rukudo-Star => Rakudo-lite?
Perhaps we could name the incomplete releases "Rakudo Bikeshed". Each release could be named after a popular color of bikeshed. The first one should definitely be called "Rakudo White Bikeshed". -j
Re: Rukudo-Star => Rakudo-lite?
raiph (>), Larry (>>): >> 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. Seconded. Well put. // Carl
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
Jon Lang wrote:
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.
I think whatever the solution is, it must begin with a # -- anything
else will likely create even more gotchas. Also, we have to realise that
no matter what sequence we choose for embedded comments, there will
_always_ be a chance of a gotcha, so all we can do is minimise the
likelihood, as well as making the gotcha easy to spot, whilst not making
embedded comments too difficult to use for those who like them.
My current personal favourite would be to keep things as they are with
regards to bracketing, but to introduce a + between the # and the
brackets. I'd also change the terminology from "embedded" comments to
"extended" comments. The + sign is a good mnemonic for "extended" IMHO.
It's neither too much of a heavyweight nor too much of a lightweight.
The +bracket sequence isn't "too" common -- or at least probably not
where you might want to introduce a comment -- and it keeps "extended"
comment syntax down to 4 characters, e.g.
say #+( extended comment ) "hello, world!";
$object\#+{ extended comments }.say;
$object\ #+「
extended comments
」.say;
#sub foo# line-end comment
#{ # ditto
# ... # ditto again
#} # what he said!
#sub foo# line end comment
#+{ # extended comment
... # extends
} # to here
Cheers
--
smuj
