Re: new sigil
On 10/20/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> Larry Wall skribis 2005-10-20 7:56 (-0700):
> > the new sigil is the cent sign, so ::T is now written ¢T instead.
>
> 1. What does it look like? I've never used a cent sign, and have seen
> several.
It looks like a lowercase c with a vertical line through it -- though the
vertical line is often slanted forward, so it looks like a c overtyped with
a slash ("/").
2. How can it be typed with X character composition, vim's digraphs and
> major international keyboards?
For vim, use CTRL-K C t
I can't address the other contexts.
=thom
"A painting in a museum hears more ridiculous opinions than anything else in
the world."
Edmond de Goncourt
Re: Dumb doc question...
On 8/16/06, Agent Zhang <[EMAIL PROTECTED]> wrote: On 8/17/06, Mark J. Reed <[EMAIL PROTECTED]> wrote: > Where can I find a pod2html that groks the p6 version of POD? I want > to format my fresh-from-svn copies of the doc... > ... And there're also an online HTML version of the Perl 6 Spec: http://dev.perl.org/perl6/doc/synopsis.html This version automatically updates from the SVN repository every few hours. Unfortunately, S29 is not available there -- it only provides a pointer to http://svn.openfoundry.org/pugs/docs/Perl6/Spec/Functions.pod and the pod file just isn't as pretty as the nicely formatted HTML available for all the other synopses. =thom "Adults are always asking kids what they want to be when they grow up because they are looking for ideas." --Paula Poundstone
S03 nit
[EMAIL PROTECTED] wrote:
> +++ doc/trunk/design/syn/S03.pod Fri Feb 2 01:07:36 2007
> +Both of these forms actually translate to
> +
> +if $filename.TEST(:e) { say "exists" }
> +
> +which which is a generic mechanism that dispatches to the object's
> +class to find the definition of C. (It just happens that
s/which which/which/
Which reminds me of an old puzzle:
Punctuate the following sentence so it makes sense.
Ann where Bob had had had had had had had had had had had a better
effect on the teacher.
[EMAIL PROTECTED] wrote:
> Nick++ noticed where I spaced out. Just glad someone's reading these
> things...
Yeah, some of us are reading these documents. I wish more of us
understood more of them. Myself, particularly. :-) I hope to get caught
up enough on current semantics that I can do more checking of meaning
and less picking of grammatical and spelling nits. Perl6 is growing in
ways I really like, but I'm having serious trouble keeping up!
=thom
I'll give you an exact definition. When the happiness of another person
becomes as essential to yourself as your own, then the state of love
exists. -- Jubal Harshaw to Ben Caxton in Stranger in a Strange Land
S03 regexp nit
[EMAIL PROTECTED] wrote: > Modified: doc/trunk/design/syn/S03.pod > == > ... > +Alternately, you can increment a submatch: > + > +$filename ~~ s[^.* <(\w+)> \.\w+$] = $().succ; > + Don't you want the leading .* to be non-greedy? I.e., shouldn't that read $filename ~~ s[^.*? <(\w+)> \.\w+$] = $().succ; instead? Because it seems like the way it's written would increment "my-xyz.txt" to "my-xyaa.txt" instead of "my-xza.txt", and I think the latter is what you'd want. Or did * become non-greedy while I wasn't looking? =thom There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it.
Re: Synopsis 26
I never could find the Pod-to-XHTML'd version of S26 -- the document attached to that email was S26.pod6, not S26.xhtml. I don't want to bug Damian, because obviously he has enough of life "happening", as it were. But is the XHTML'd version of S26 available anywhere? I haven't been able to find it, and I don't read POD as well as all you perl veterans =thom -- We would all like to vote for the best man, but he is never a candidate. On 11/22/06, Damian Conway <[EMAIL PROTECTED]> wrote: Many thanks to all those who offered feedback on the first draft, as a result of which you will see that there have been some major adjustments and some important simplications to the new Perl mark-up notation. The first release of (a Perl 5 implementation of) the parser is close to ready...within a week if life doesn't "happen" too much. I also have a prototype Pod-to-XHTML module implemented, in earnest whereof I have attached a Pod-to-XHTML'd version of the synopsis. Damian PS: As a few of you are already aware, I am in the midst of health crisis within my immediate family. This is likely to be on-going for the next month or more, so please accept my apologies in advance if my response-time is frustratingly slow.
Re: [svn:perl6-synopsis] r14360 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote: Modified: doc/trunk/design/syn/S09.pod == ... -my @calendar[12;*;24]; # "Month" dimension unlimited +my @calendar[12;*;24]; # day-of-month dimension unlimited/ragged There's another place in S09 where "Month" dimension unlimited needs to be replaced with day-of-month dimension unlimited/ragged It's in the section titled "Autoextending multidimensional arrays". =thom Punctuality is the virtue of the bored. --Evelyn Waugh (1903-1966)
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
Jonathan Lang wrote:
> 2. Getting block comments to hide POD blocks wouldn't require the POD
> parser to have a full implementation of a Perl parser. It would
> require the POD parser to have a _limited_ implementation of a Perl
> parser, one that's capable of identifying block comments. And IIRC,
> you already have to do something like this with respect to block
> quotes:
Actually, the POD parser would have to be a fairly complete Perl parser.
As your example shows:
>
> say :to(END);
> =begin POD
> blah blah blah
> =end POD
> END
>
> If I understand matters correctly, the "POD code" in the above example
> isn't POD code at all, but rather the content of a multi-line quote.
> So extending the POD parser's awareness of Perl syntax to handle block
> comments as well isn't much of a stretch.
If *I* understand matters correctly, Perl 6 will see that as identical to
say :to(END);
END
*because* we want the POD parser be simple, rather than an
almost-complete parser of Perl. After all, there are many ways to "hide"
POD-like text in Perl.
You might think, "Well, how hard is it to look for ":to(XYZ)" followed
by a line containing XYZ?" Going beyond the fact that there are actually
quite a few ways to spell ":to(XYZ)", Perl code that generates Perl code
will trip you up:
say "say :to(END);";
say "Here's my text";
say "=begin comment";
say "My auto-generated code even contains comments on it's strings!"
say "=end";
say "More of my text";
say "END";
You have to parse all string syntaxes to avoid that pitfall. And once
you take care of that issue, you have to handle the problem of parsing
Perl code that's trying to parse Perl code, looking for say statements
that use here-doc syntax containing POD comments:
my $checker = regex {
say \s* \: to \( \w+ \) ; $ # match a say with here-doc
(
.* $
)* # match any lines that don't start with $1
=for comment # match the beginning of an embedded POD comment
}
(No, I don't approve of the indentation of that example. But should your
program fail just because somebody doesn't follow good style?)
And once you've extended the parser to handle *that* case, Finagle's Law
dictates that someone will put the above code sample into a Perl string
literal!
In summary:
As your example pointed out, the POD parser would have to handle all the
various string syntaxes of Perl 6. Then, there is also regular
expression syntax that has to be covered. And who knows what else I'm
overlooking?
Compare that with the simplicity that $larry & $damian are promoting.
Yes, it'll be a pain to get the effect you *wanted* from
> say :to(END);
> =begin POD
> blah blah blah
> =end POD
> END
but the cost to the POD parser is just not worth it.
=thom
-
Finagle's Law: the perversity of the Universe tends towards a maximum.
Re: POD <-> Code entanglement
Thomas Wittek wrote: > I mean POD uses constructs like headlines, lists, blocks, italic etc. > which all describe _how it looks like_ and not _what it is_. I think Damian would take exception to that statement. He worked quite hard to make sure that POD describes _meaning_ rather than _appearance_. He even renamed B<> from "bold" to "basis", I<> from "italic" to "important", and U<> from "underline" to "unusual". All of those are fairly odd choices, with the possible exception of "important", but they were clearly made with an eye to backwards compatibility of POD while changing people's focus from how it looks to what it is. > A head3 might be the headline of a method documentation as well as one > introducing the contact information for the author of a module. > The directive doesn't have much semantics. > Other people might use head2 for documenting methods, what leads to a > pretty inconsistent look of the documentation. Well, I'd argue that head3 has plenty of semantics. It's a level-3 header. How that's rendered is decided elsewhere. I think the issue is not that head3 is insufficiently semantic, it's just that you want something that's even more specific. And POD 6 was designed with exactly that kind of thing in mind. You can, according to the existing S26, say things like: =Method the method synopsis goes here =begin Parameters =item foo is the fooiest parameter =item bar is the barstest parameter =end Parameters Furthermore, the Perl parser actually *keeps* the POD chunks, so you can access all that information in the context of the Perl parse. Damian and Larry were clearly laying the groundwork for exactly the sort of javadoc-ish features you are asking for. =thom - The supreme irony of life is that hardly anyone gets out of it alive. --Robert A. Heinlein [Job: A Comedy of Justice]
What is the origin of the nickname, "Texas quotes"?
From S02: The double angles may be written either with French quotes, «$foo @bar[]»||, or with "Texas" quotes, <<$foo @bar[]>>,|| as the ASCII workaround. I'm curious about the naming of "Texas" quotes. My guess is that the name is inspired by the existence of a town called Paris, Texas. That city's name might remind you of France, but isn't the real thing. Similarly, <>|| might remind you of «French Quotes», but they're not quite as elegant. Have I got that right? =thom Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. --Dr. Jubal Harshaw in /To Sail Beyond the Sunset/, by Robert A. Heinlein
Re: What is the origin of the nickname, "Texas quotes"?
Larry Wall wrote: On Thu, Dec 06, 2007 at 09:36:36AM -0700, Thom Boyer wrote: From S02: The double angles may be written either with French quotes, «$foo @bar[]»||, or with "Texas" quotes, <<$foo @bar[]>>,|| as the ASCII workaround. I'm curious about the naming of "Texas" quotes. My guess is that the name is inspired by the existence of a town called Paris, Texas. That city's name might remind you of France, but isn't the real thing. Similarly, <>|| might remind you of «French Quotes», but they're not quite as elegant. Have I got that right? Good guess, but no. It comes from the fact that Texas always bragged about how they were the largest state in the union, and had the biggest everything, including ten-gallon hats. That was before we added Alaska. Now if they pull that stunt we offer to carve Alaska up into 4 states, in which case Texas would be the 5th largest. But Texans still like to think big, and we love 'em all to pieces for it. Especially Patrick these days... :) Larry So, it's because <> is so much bigger than «this», "this", or 'this'? By the way, as a native Texan, I find offensive your claim that Texas*4 < Alaska. The truth is hurtful enough: Texas*2.1787 = Alaska I had to carry it out to 4 decimal places so I wouldn't have to round the last digit UP. :-) =thom
Re: What is the origin of the nickname, "Texas quotes"?
Chas. Owens wrote: Like a true Texan* (grin), he skewed the numbers to make Texas look bigger than it is. It is between 2.4** and 2.5*** when you include ... * I am resident of Virgina, so I have no axe to grind; I am just looking for a definitive answer. ** random sites on the Internet *** wikipedia: 663267/261797 = 2.5335 Ouch. But, back to Perl I didn't get an answer to my follow-up question: So, it's because <> is so much bigger than «this», "this", or 'this'? Chas. Owens wrote: *** wikipedia: 663267/261797 = 2.5335 As for skewing the numbers Actually, I just grabbed the land areas from the text of the two Wikipedia articles (570,380 /261,797~=2.1787). I didn't even notice that I was getting land area only. I didn't even see the "total area" that was conveniently available in the summary boxes. Really. I swear it. As a matter of fact, I've always been sensitive to the perception that Texans are braggarts. We had a family move to our area from California when I was young. They irritated me so much by their continual claims of California's superiority that I decided I never wanted to appear that obnoxious to anyone else, even if I am proud of my home state. Too many Texans are like a friend of mine who has a sign by his front door: "Never ask a man where he's from: if he's from Texas, he'll tell you; if he isn't, there's no point in embarrassing him." Makes me cringe, even if it /is/ all in fun. I told an Alaskan friend about that sign, and that's when he told me that if we didn't shut up about it, Alaska would split itself in half and make Texas the /third/ largest state. I suppose it's a measure of Texas pride that I was in my forties before I knew that Alaska was /that/ much bigger than Texas. =thom -- Numbers are like people; torture them enough and they'll tell you anything.
Re: Definition of Order in S29
Joe Gottman wrote: In the definition of cmp, S29 says the function "returns |Order::Increase|, |Order::Decrease|, or |Order::Same| (which numify to -1, 0, +1)". Shouldn't the enumerations and their numerical values be listed in the same order? Joe Gottman The enumerations and the numerical values are both in correct order. Since "abc" is less than "xyz", "abc" cmp "xyz" is being invoked with its arguments in increasing order, So it returns Order::Increase. That numifies to -1 because that's how "less-than" is usually encoded. =thom -- I wanna hang a map of the world in my house. Then I'm gonna put pins into all the locations that I've traveled to. But first, I'm gonna have to travel to the top two corners of the map so it won't fall down. -- Mitch Hedberg
What are "identifier extensions"?
S02 mentions "identifier extensions" in the section describing adverbial
pairs with non-identifier keys (see the table reproduced below).
What are identifier extensions? I'm guessing that : and :<+> are
both acting as identifier extensions in these examples:
statement_control:
infix:<+>
But what's really going on there? Are we effectively creating an
identifier with non-identifier characters, or what? I've been reading
such things subconsciously as operator definitions with precedence and
associativity modifiers. But modifiers ought to be written after the
modified quantity, as adverbs, so that would more properly be written as
if:statement_control
+:infix
except, of course, + isn't a valid identifier.
Another interpretation is that, for example, statement_control: is
the "if" token defined inside the statement_control grammar. Its
similarity to hash access makes it look likes it grabbing something from
out of a container.
And yes, I have tried to find in the synopses a discussion of the real
meaning of references like infix:<+>, but I've been unsuccessful. Can
anybody help me find the relevant synopsis?
And, if I've guessed wrong, and "identifier extensions" have nothing to
do with infix:<+> and friends, then what ARE identifier extensions?
Here's the table, reproduced from S02, the uses the phrase "identifier
extension":
Simple pair DIFFERS fromwhich means
=== ===
2 => <101010> :2<101010> radix literal 0b101010
8 => <123> :8<123> radix literal 0o123
16 => :16 radix literal 0xdeadbeef
16 => $somevalue:16($somevalue) radix conversion function
'' => $x:($x) arglist or signature literal
'' => ($x,$y) :($x,$y)arglist or signature literal
'' =>:identifier extension
'' => «x» :«x»identifier extension
'' => [$x,$y] :[$x,$y]identifier extension
'' => { .say } :{ .say } adverbial block
=thom
--
Larry Niven's Laws
#6: It is easier to destroy than create.
Bin Laden tore down the World Trade Center? Let's see him build one. If
human beings didn't have a strong preference for creation, nothing would
get built, ever.
interpolating complex closures
S02 says "A bare closure also interpolates in double-quotish context."
I presume that there are no restrictions on the code inside that
closure, but all the examples I've seen have nothing but expressions
inside the closure (though some examples, admittedly, do invoke subs
and/or methods).
Question 1: Does
my $s = ''
say "Fire in the hole!{
for reverse 1 .. 3 { $s = qq[$s $_]; }
$s
} BOOM!";
work? I.e., does it say this?
Fire in the hole! 3 2 1 BOOM!
I'm not arguing that embedding that much code in a string is good style.
I'm just asking if it's forbidden.
Question 2: Does C return the value of its last statement? In other
words, does this have the same effect as the previous example?
my $s = '';
say "Fire in the hole!{for reverse 1..3 { $s = qq[$s $_] }} BOOM!";
Question 3: Do quotes inside a closure inside a string get parsed
exactly as if they were in code, or do they screw up the scanning of the
outermost string? If the closure contains "real" code, then I should be
able to replace qq[$s $_] with "$s $_" in the example. Does this work?
my $s = '';
say "Fire in the hole!{for reverse 1..3 { $s = "$s $_" }} BOOM!";
# does this quote end the scan of string? -^
Escaping { $ @ % & in strings
S02 provides this example for treating curlies literally in a quoted string:
qq:!c "Here are { $two uninterpolated } curlies";
But can I escape them with a backslash? I was surprised that I couldn't
find anything in S02 which said either yes or no. Perhaps this falls
under the heading of "anything not specifically defined in the synopses
acts just like it did in Perl 5", and I should just shut up.
In the description of the :q (aka :single) adverb, there is mention of
the fact that you can escape the quoting character, as in
Q :q "The ubiquity of \"air quotes\" is really annoying to me";
and the description of :b (aka :backslash) indicates that it activates
the usual substitutions on \a, \b, \t, \n, \f, \r, and \e,
Q :b "Here's a BEEP \a and a newline \n;
but I can't find any discussion of whether "\p" is legal (presumably
identical to "p") or lexically illegal ("unrecognized escape sequence in
string literal"). And in that example, by p I mean any character p for
which S02 doesn't define the meaning of \p.
In particular, there's no mention of whether \ can be used to escape $,
@, %, &, or {. I would _assume_ that
"Here are \{ $two uninterpolated \} curlies";
means the same as the first example, above, but I can't find anything
that says so.
So, I would hope that
$fruit = 'apple';
$number = 7;
$money = 'peso';
say "set A = \{ $fruit, {$number+1}, \$money \}";
actually says
set A = { apple, 8, $money }
Does it? And, do I really need to backwhack the final (closing) curly?
say "set A = \{ $fruit, {$number+1}, \$money }";
Re: Musings on operator overloading
Larry Wall wrote:
On Wed, Mar 26, 2008 at 12:56:08PM -0600, Thom Boyer wrote:
Larry Wall wrote:
... In the
limit, suppose some defines a postfix "say" looser than comma:
(1,2,3)say
1,2,3say
1,2,3.say
I must be missing something. Wouldn't it be easier to write
1,2,3 say
since say was defined to bind looser than comma? Then you wouldn't need a
nospace unspace.
The part of Perl 6 that bothers me most is the whitespace dwimmery that
required unspace in the first place. I'd hate to see more of it.
Not that I have a better solution than the proposed whitespace dwimmery,
mind you.
How would you keep infix operators in a separate namespace from postfix
then? As soon as someone defines infix:<++> you're hosed, or we have
to throw out all term/infix distinctions that Perl has always had. How
would you parse
$x ++ /foo/;
It also completely destroys the current absolute distinction between
say(1 + 2), 3
say (1 + 2), 3
Larry
Yup. You gotta have some way to resolve those problems, and the
whitespace distinction does the job. And, as I said, I don't have a
better solution.
But that doesn't obviate my unease with whitespace being so very
significant to the meaning of a program. Perhaps it comes from exposure
to Fortran IV at an impressionable age -- a language in which nothing
changes if you remove ALL whitespace (outside of Hollerith constants,
that is). It might be fair to liken that exposure to the effects of
Thalidomide: perhaps my brain's been deformed.
But it's only an unease, and I recognize that it's a bias I acquired by
programming in so many different languages in which whitespace is
insignificant. I further recognize that Perl offers a lot of way-cool
stuff that wouldn't be possible with out whitespace dwimmery.
I *love* list operators. Being able to write, in Perl 5,
foreach_vertex $polygon, sub {
# executed once for each vertex, with the vertex in $a
print "point #", $n++, ": $a\n";
};
instead of
foreach_vertex($polygon, sub {
# executed once for each vertex, with the vertex in $a
print "point #", $n++, ": $a\n";
});
makes a world of difference to readability. And I'd be *tempted* to
resolve the the ambiguity in
say (1 + 2), 3
by treating that as
say(1+2), 3
and requiring (function-call, not list-operator) syntax like
say((1+2), 3)
if you want the other. But that would have a horrible effect. If I
started with
say $x*2, 3
and then realized I needed to add one to $x before doubling, I'd be
surprised by the resulting treatment of
say ($x+1)*2, 3
So you made the right call there, in my opinion. The whitespace makes
clear the programmer's intent, once you're used to list operators.
As for:
> $x ++ /foo/;
well, for that case, I can't even think of a BAD suggestion to make, so
whitespace dwimmery is again the best solution I know.
And yet that whitespace-is-insignificant meme keeps tickling my brain.
And what really cranked it up to poison-ivy level was the unspace. I
can't even explain why. I don't even *understand* why, myself, so I can
hardly speak on the subject in a cogent manner.
I suspect it's an emotional, irrational, reaction. I probably just need
to just scratch the inside of my skull with a wire brush until the itch
is gone. And quit bothering the list with my idiosyncrasy. After all,
it's an entirely artificial idea in the first place -- because,
to humans,
whitespace
really
DOES
matter;
it's
only
those
stupid
compilers
that feel
otherwise.
-
But the main point I was trying to make is just that I didn't see the
necessity of positing
1,2,3\say
when (if I understand correctly) you could write that as simply as
1,2,3 say
And if someone really wants to apply a C postfix operator in a string
interpolation, then let them say
say "blah {$x t} blah"
That seems better to me than saying that there's no tab character in
say "blah $x\t blah"
Backslashes in double-quotish contexts are already complicated enough!
=thom
Re: Musings on operator overloading
Thom Boyer wrote: Now, I think that $x.foo is a method call, even if there's a postfix: declaration in scope. And that's a problem, because, no matter what precedence postfix: was given, 1,2,3.foo is still going to mean 1, 2, (3.foo) instead of the desired postfix:(1,2,3) The way I wrote that, it sounds like I think postfix: isn't a method call, but of course it is. What I really meant to say is that, in 1,2,3.foo the precedence of foo gets changed to the precedence of dot. I don't actually know that that is true. Is it? And does dot always do that? If it does, then something odd happens. Consider infix:<*> and postfix:, where infix:<*> binds tighter than postfix:<+>, and both bind more loosely than dot. Then 1 * 2! # means (1 * 2)! 1 * 2.! # means 1 * (2!) Methinks one or more of my assumptions is erroneous, 'cuz that's just too ugly to live. =thom
Re: Musings on operator overloading
Thom Boyer wrote: And does dot always do that? If it does, then something odd happens. Consider infix:<*> and postfix:, where infix:<*> binds tighter than postfix:<+>, and both bind more loosely than dot. Then I meant "... tighter than postfix:, ..." 1 * 2! # means (1 * 2)! 1 * 2.! # means 1 * (2!) Methinks one or more of my assumptions is erroneous, 'cuz that's just too ugly to live. =thom
Re: Musings on operator overloading
Jon Lang wrote: Thom Boyer wrote: That seems better to me than saying that there's no tab character in say "blah $x\t blah" Whoever said that? Oops. I thought Larry did. But he didn't; I misread it. Whew. Somehow I managed to read Larry's words and get exactly the *opposite* meaning from what he actually wrote: Larry Wall wrote: > This may also simplify the parsing rules inside double quoted > strings if we don't have to figure out whether to include postfix > operators like .++ in the interpolation. It does risk a visual > clash if someone defines postfix:: > > $x\t # means ($x)t > "$x\t" # means $x ~ "\t" How embarrassing. Thanks for asking "Whoever said that?", because it forced me to go reread it. I think I'd better go reread the whole thing. More carefully this time. > Thom Boyer wrote: >> when (if I understand correctly) you could write that as simply as >> >> 1,2,3 say > > Nope. This is the same situation as the aforementioned '++' example, > in that you'd get into trouble if anyone were to define an infix: > operator. OK. Let me see if I get this. First, let me state my understanding of the issue with ++ (where ++ is actually a stand-in for *any* operator that is both postfix and infix): $x++ # postfix operator, because there's no whitespace $x.++# postfix (the dot is optional) $x ++# infix operator, because there's whitespace $x\ ++ # postfix: space isn't allowed, but unspace is $x\ .++ # postfix (the dot is still optional) Question: given ($x)++ # no whitespace, so postfix? is ++ postfix, or infix? Now, I think that $x.foo is a method call, even if there's a postfix: declaration in scope. And that's a problem, because, no matter what precedence postfix: was given, 1,2,3.foo is still going to mean 1, 2, (3.foo) instead of the desired postfix:(1,2,3) so Larry has proposed 1,2,3\foo # means: postfix:(1, 2, 3) as a way to get the desired meaning without having to resort to parentheses. So the point is that a nospace unspace acts like dot, in that it turns the following operator into a postfix operator. But it doesn't have the undesired characteristic that it turns an intended postfix operator into a method dispatch. Have I got that right, or am I still wandering in a wilderness that is completely disconnected from Larry's proposal? Final question: I think these are all equivalent. Are they? 1,2,3\foo (1,2,3)foo (1,2,3).foo postfix:(1,2,3) =thom
Re: Musings on operator overloading
Larry Wall wrote: The .++ form is still not a method (single) dispatch, just an alternate form of the postfix, which is a multi dispatch. But the postfix is a unary operator, right? So that'd be multi dispatch on one argument. How does single dispatch differ from multi dispatch on a single argument? =thom
Protected data member access considered harmful
Larry Wall wrote: How private is private? I wonder if what you've called private things are really more like "protected" in C++ (accessible by the derived class) and that 'my' attributes are really private, as are submethods. It's all confused. Who is allowed to access what? >>> No, private methods are not accessible from derived classes, unless >>> the base class explicitly trusts them -- See L12/"the exclamation >>> form may be used only in the actual class, not in derived classes". >>> >>> Cheers, >>> Audrey > > It is my understanding that even Bjarne thinks "protected" is a bad > idea these days... > > Larry I believe Mr. Stroustrup's deprecation of 'protected' access applies only to data data members, not function members: Fortunately, you don't have to use protected data in C++; 'private' is the default in classes and is usually the better choice. Note that none of these objections are significant for protected member *functions*. I still consider 'protected' a fine way of specifying operations for use in derived classes. -- Bjarne Stroustrup _The_Design_and_Evolution_of_C++_ Section 13.9 [Protected Members] So I understand Perl 6 will have no protected access for data members (though trusted access can be used to provide a similar back door). But does Perl 6 have protected access for methods? =thom
Re: static types, checking, conversions
Mark J. Reed wrote: It would behoove @Larry to examine the optional type constraints system proposed for Javascript:TNG (see link from firefox.com developers page). I therefore assume that they have done so, but others would benefit by doing likewise. :) Could you be a little more specific on where to find information on JavaScript's proposed system of type constraints? The firefox.com developers page (http://developer.mozilla.org/en/docs/Main_Page) has several links on JavaScript topics. The most promising one leads to http://developer.mozilla.org/en/docs/JavaScript, and, while that page has info on quite a few different versions of JavaScript, version 2 is not one of them. Of course, I'm only guessing that JavaScript 2 is what you might have meant by Javascript:TNG. (I can't find any mention of TNG or "Next Generation" on either of those pages, either.) =thom
Re: arrayref/hashref in spectest suite
Patrick R. Michaud wrote:
my $foo = [ 42 ];
my $bar = { a => 23 };
$foo[1] = $bar;
TSa (Thomas Sandlaß) wrote:
I would also opt for copy semantics whenever = is used for assignment.
But C<$foo[1] = $bar> *does* use copy semantics. The thing on the right
is a reference to a hash, and that reference is copied (by value) into
C<$foo[1]>.
It seems what you're really requesting is for the assignment operator to
auto-dereference references. But if you can't copy references, they
become pretty useless.
=thom
Re: r29129 - docs/Perl6/Spec
I'm curious about the change from "blorst" to "blast." I quickly figured out that "blorst" was derived from "BLock OR STatement" (as S04 used to say: "In fact, most of these phasers will take either a block or a statement (known as a I in the vernacular)). The best that I can figure for "blast" is "BLock And STatement." But using AND seems less correct to me. Furthermore, "blast" is less likely to google up the results I need. So, what exactly _is_ the derivation of "blast"? -- Forwarded message -- From: Date: Wed, Nov 18, 2009 at 9:34 PM Subject: r29129 - docs/Perl6/Spec To: perl6-language@perl.org Author: lwall Date: 2009-11-19 05:34:29 +0100 (Thu, 19 Nov 2009) New Revision: 29129 Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] as several folks have suggested, rename "blorst" to "blast" Modified: docs/Perl6/Spec/S04-control.pod === --- docs/Perl6/Spec/S04-control.pod 2009-11-18 18:51:35 UTC (rev 29128) +++ docs/Perl6/Spec/S04-control.pod 2009-11-19 04:34:29 UTC (rev 29129) @@ -1226,8 +1226,8 @@ our $temphandle = START maketemp(); In fact, most of these phasers will take either a block or a statement -(known as a I in the vernacular). -This can be particularly useful to expose a lexically scoped +(known as a I in the vernacular). The statement form can be +particularly useful to expose a lexically scoped declaration to the surrounding context. Hence these declare the same variables with the same scope as the preceding example, but run the statements as a whole at the indicated time:
Re: r29129 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2009-11-19 05:34:29 +0100 (Thu, 19 Nov 2009) New Revision: 29129 Modified: docs/Perl6/Spec/S04-control.pod Log: [S04] as several folks have suggested, rename "blorst" to "blast" I'm curious about this change. I quickly figured out that "blorst" was derived from "BLock OR STatement" (quoting the previous rev: "In fact, most of these phasers will take either a block or a statement (known as a I in the vernacular)). The best that I can figure for "blast" is "BLock And STatement", which seems to me like a less-descriptive name. And "blast" is less likely to google up the results I need. So, what exactly _is_ the derivation of "blast"? =thom
Re: Perl 6 Summary
On Tue, 02 Jul 2002 10:36:45 -0700, Erik Steven Harrisan wrote:
ESH> my $a = 'foo';
ESH>
ESH> pass_by_name ( sub { print $a} );
ESH>
ESH> sub pass_by_name {
ESH> my $a = 'bar';
ESH> &@_[0];
ESH> }
ESH>
ESH> Now, I have trouble keeping Perl 6 and 5 straight, but what I think
this does is
ESH> print 'foo', as the sub ref is a closure, and gets $a bound to it.
Fair enough.
ESH>
ESH> But in pass by name, expressions passed to a function aren't
evaluated until they
ESH> are used inside that function, and are evaluated in the context of
the surrounding
ESH> function. In a pass by name environment, the above code would print
'bar' as the
ESH> sub isn't evaluated until it is used in pass_by_name, and then it
gets pass_by_name's
ESH> value of $a. Understand? Isn't that weird?
If you s/my/local/ in your example, you WILL get 'bar' instead of `foo'. But
what you are
really describing then is dynamic scoping for variables, not pass-by-name.
BTW: I've never heard of "Jensen's Machine", but "Jensen's Device" is a
technique
used to implement pass-by-name.
To get a better feel for the weirdness that happens with pass-by-name,
consider this example:
sub check_it_out {
$_[0] = 0; #step 1
$_[1] = 7; #step 2
}
my @a = (0,1,2,3,4);
my $i = 2;
check_it_out($i, $a[$i]);
print join '', @a;
This prints '01734' under Perl 5, because the arguments ($i and $a[2]) are
passed by reference.
If the arguments to check_it_out() were passed by name instead, the result
would be '71234',
because step 1 would change $i to have the value 0, and *then* $a[$i] would
be evaluated in
step 2 (using $i's new value), causing the 7 to be assigned to $a[0] (not
$a[2]).
As Larry said elsewhere in this thread, Ruby doesn't have pass-by-name. And
I don't think
anybody seriously wants it anyway. I'm personally MUCH more interested in
Python's generators
.
A generator is like an iterator in that it can produce a series of values.
But unlike
iterators, when you ask a generator for the next value, it picks up
execution exactly where
it left off when it returned the last value -- including all it's stack.
This makes it much
easier to solve certain classes of problems (like the same-fringe problem:
given two trees,
answer the question "do these trees have the same leaves in the same
order?")
If you are interested in Jensen's Device, or if you would like to see an
example of how
pass-by-name MIGHT be considered useful, check out
http://www.cs.rit.edu/~afb/20013/plc/slides/procedures-07.html
or just google "Jensen's Device".
=thom
Re: Perl 6 Summary
Peter Scott wrote: > At 01:54 PM 7/3/02 -0600, Thom Boyer wrote: > >> I'm personally MUCH more interested in Python's generators >> <http://www.python.org/peps/pep-0255.html>. >> >> A generator is like an iterator in that it can produce >> a series of values. But unlike iterators, when you ask >> a generator for the next value, it picks up execution >> exactly where it left off when it returned the last >> value -- including all [its] stack. > > > Isn't that a coroutine? I thought they were already slated for P6. > *Rummage* Yes: > > http://www.yetanother.org/damian/diary_April_2001.html > Or if you like: > http://www.yetanother.org/damian/Perl5+i/coroutines.html > -- > Peter Scott > Pacific Systems Design Technologies Yes, coroutines are more than enough to implement generators (as Dan Sugalski has already agreed). And thanks for the pointers. I've been out of touch with the Perl community the last couple of years. It's been exciting seeing how Perl 6 is shaping up, but I'm having a hard time making up lost time. The postings to perl6-language often take for granted features of Perl 6 which I haven't been able to find in any of the apocalypses or exegeses, so I've been plowing through the archive trying to get more background -- but I hadn't yet made it back to April 2001! Knowing that coroutines are already under discussion WRT Perl, I was able to google the existence of RFC 31 and other references to coroutines in Damian's corpus. (Including a slide show from August 2001 titled "Perl 6 Prospectus", where it is in the "What we might see" section.) I've been unable to determine whether coroutines are really "slated for P6," as you suggest. Has there been any indication whether those suggestions have met with Larry's approval? =thom
RE: Regular and Context-Free languages
Steve Find said on August 09, 2002 6:24 PM: >Anyone happen to know where pushdown automata fit in this list? Can >they handle context-sensitive, just context-free, or some other >subset? Mark Reed said on August 09, 2002 7:60 PM: >To recognize a context-sensitive language I think you need a Turing >machine. I'm not aware of anything intermediate in power between >a PDA and a TM. A regular expression is equivalent to an FSM (Finite State Machine). A context-free grammar is equivalent to a PDA (Push-down Automata -- i.e., an FSM with a stack) A context-sensitive grammars is equivalent to an LBA (Linear Bounded Automata -- i.e., a Turing machine restricted to a given finite length of tape) An unrestricted grammar is equivalent to a TM (Turing Machine). [info from _Introduction_to_Automata_Theory,_Languages,_and_Computation_, John E. Hopcroft and Jeffrey D. Ullman]
RE: attr sigils?
Trey wrote:
> I'm wondering about how the sigil-invariance rule interacts with
> attributes.
>
> class Foo {
> attr $bar;
> attr @bar;
> method baz {
> return @.bar[$.bar]; # sigils disambiguate
> }
> method frob ($self:) {
> return $self.bar[$self.bar]; # uh-oh
> }
> }
>
>
Apparently I don't understand "the sigil-invariance rule." I'm trying to
understand why the return expression is correct in Trey's C.
My first reaction was that it should have been
return @self.bar[$self.bar];
so that the C<@> indicates that we're referring to C<@.bar> rather than
C<$.bar>.
But that can't be right, since it's C that's the start of the
expression, and it needs its C<$>. So then I realized that there are two
'types' that I think need mentioning: the _scalar_ self, and the _list_ bar.
So then I started thinking along the lines of
return @{$self}.bar[$self.bar];
and started feeling seriously ill. Of all the peculiarities of Perl 5, that
kind of stuff is what bothers me most.
If everybody's lack of comment on Trey's original formulation was because
there's nothing wrong with it (rather than, say, that everybody overlooked
it), then I'd have to conclude that I've completely misunderstood Larry's
pronouncements on the uses of sigils in Perl 6 -- or missed some important
implications thereof.
Is it fair to conclude that @.bar is inferred by the use of the [square]
subscripts following C? And can I take that farther and assume that
simply_impassible . x[0]
for almost any value of C, will be referring to a list
named C (or maybe I should say C<@x>), that came from some context
referred to by C ... and that this is true no matter what
sigils appear in (or, more to the point, at the beginning of)
C?
By the way...is this sort of question appropriate for this mailing list?
I'm really just a lurker -- and a recent one at that -- and I don't mean to
waste people's bandwidth. So, my apologies in advance if I've asked a dumb
question in the wrong place.
=thom
RE: rule, rx and sub
Damian Conway wrote: > Any subroutine/function like C that has a signature (parameter list) > that ends in a C<&sub> argument can be parsed without the trailing > semicolon. So C's signature is: > > sub if (bool $condition, &block); So what does the signature for C look like? I've been wondering about this for a long time, and I've searched the Apocalypses and the perl6-language archive for an answer, but I've had no success. It seems like C's signature might be something like one of these: sub while (bool $test, &body); sub while (&test, &body); But neither of these really works. The first would imply that the test is evaluated only once (and that once is before 'sub while' is even called). That'd be useless. The second would allow multiple evaluations of the test condition (since it's a closure). But it seems that it would also require the test expression to have curly braces around it. And possibly a comma between the test-block and the body-block. That'd be ugly. I can create a hypothetical "bareblock" rule that says: When an argument's declaration contains an ampersand sigil, then you can pass an "expression block" (i.e., a simple expression w/o surrounding curlies) to that argument. Is there such a rule for Perl 6? On the positive side, this would be an reasonable generalization of the Perl 5 handling of expressions given to map or grep. On the negative side, this rule makes it impossible to have such arguments fulfilled by evaluating an expression that returns the desired closure (i.e., the expression you type as an argument isn't intended to be the block you pass, but rather it is intended to generate the block you want to pass). In summary: assuming Perl 6 allows user-defined while-ish structures, how would it be done? =thom "The rowboat glided gently across the lake, exactly like a bowling ball wouldn't."
RE: L2R/R2L syntax (was Re: Everything is an object.)
-Original Message- Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote: > Actually I don't think you can define a grammar where two operators have > the same precedence but different associativity. Be it a pure BNF > grammar, or a classical yacc specification (using the %left and %right > declarations). You are correct in stating that in a classical yacc specification, you can't declare two operators to have the same precedence but different associativity. But that's because syntactically you can't express the idea. You'd have to do something like %left PIPE_LEFT_OPERATOR %right PIPE_RIGHT_OPERATOR Or you could put them in the opposite order. But, syntactically, they do have to be on different lines, and that makes them have different precedence. However, you could have the following productions in a yacc grammar: exprB: exprA PIPE_LEFT_OPERATOR exprA | exprA PIPE_RIGHT_OPERATOR exprA %PREC PIPE_LEFT_OPERATOR ; (or something close to that -- it's been a while since I actually wrote yacc grammars). I assume that the generated parser would act in a manner similar to the way it behaves when it catches you trying to chain together %nonassoc operators: it generates a parse error. And given the fact that (IMHO) "hello, world" ~> print <~ STDERR; is an abomination, a parse error would be just fine by me. But cooler heads might just decree that the shift/reduce conflict is to be resolved one way or another, so that A ~> B~> C~> O <~ X <~ Y <~ Z parses as either (A ~>B ~> C ~> O) <~ (X <~ Y <~ Z) or (A ~>B) ~> C) <~ (O <~ X <~ Y <~ Z) Neither is likely to be what you want, however. And given the level of difficulty that most people have with precedence and associativity rules, I think it reasonable to require the parens if you want to mix ~> and <~ like that. =thom There are 10 kinds of people in the world: those who understand binary, and those who don't.
RE: perl6-lang Project Management
On Wednesday, November 06, 2002, at 11:54 AM, Michael Lazzaro wrote: > On Tuesday, November 5, 2002, at 11:18 PM, Allison Randal wrote: > > Since you're interested in the management of the Perl 6 project, I'll > > let you in on some of it. Let's start with a step back into a bit of > > history: > > OK, let me pause for a second... pause, pause, pause... OK, I'm better > now. Please forgive me, I'm going to be quite forceful in my > evaluation of the situation here. To the point of making a Simon C. > post look mellow. Get ready for some spectacular virtual > coffee-mug-throwing here. I'm replying to your coffee-mug-throwing posting *very* late simply because I got so far behind on p6l that I had >1000 unread messages. Largely because of the "hellacious thread reworking operators." I just now got caught up to November 6th. I just want you to know how much I personally appreciate your efforts. I agree that we need to be creating some unified description of the current status. I'd be interested in helping, but one reading of your summary convinced me that I can't write anywhere near as well as you do. And, of course, it is discouraging to think about putting that much effort into a language description when that language is shifting so wildly, often on a day-to-day basis. Now, just before Christmas, I archived my unread heap, and starting time slicing between current postings and my archive. So I can see you're still actively participating in p6l, and I'm glad to see that. I still have November 6th-December 24th to read, so I don't yet know how others responded to your outburst. But it made me realize two things: (1) I don't want you to get discouraged, and (2) I haven't given you any feedback (let alone, appreciative feedback). You have been among the handful of posters whose messages I look forward to. Your messages are a breath of fresh air -- an island of sanity -- amid the quicksand shiftings of p6l. So please accept my thanks for the tremendous amount of time and productive thought you are sharing with us. And now, my unread pl6 archive has been reduced to 772 messages. Sigh. I wish I could beat back my anal-retentive tendencies long enough to be satisfied with the fine Piers Cawley summaries. But always want the fine-grained detail, too =thom Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing. --Dr. Jubal Harshaw (Robert Heinlein's _To_Sail_Beyond_the_Sunset_)
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody <[EMAIL PROTECTED]> wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
>
> That's going to be just plain confusing. Arguments to functions are
supposed
> to be on the right. And what's up with using them for assignment? That's
> making them even more overcomplicated and ugly. Do you care about
readability
> at all? It seems to me that ~> and <~ have no use except making perl 6
uglier
> and more complicated than it already is. They're completely unnecessary.
1) "Arguments to functions are supposed to be on the right."
Hmmm. If you use a mathematical context, I guess "supposed to" could be code
for "I've always done it that way". But certainly not "supposed to" in any
cosmic sense.
But what The Damian is proposing is much more like a Unix pipeline than
mathematics.
@a ~> grep {...} ~> map {...} ~> sort ~> @out;
makes much more sense when you see it as being much more akin to
cat a | grep ... | tr ... | sort > out
than
let out = sort(map {...} (grep {...} @a))
No, it's not like the math that is one of Perl's influences. It's like the
Unix shells, which is another of Perl's influences.
2) "And what's up with using them for assignment? That's making them even
more overcomplicated and ugly. "
If you read ~> and <~ as "stuff this thingy into that doohicky", assignment
makes perfect sense. They are plumbing connectors: sometimes they connect
the water softener to the water heater (one device to another), and
sometimes they connect to the water supply (a source) or the sink (a sink).
I don't see that as an overcomplication, but as a very straightforward and
obvious extension.
3) "Do you care about readability at all? It seems to me that ~> and <~
have no use except making perl 6 uglier and more complicated than it already
is."
I think ~> and <~ look pretty nice. They read well as a single symbol, they
make good sense, they make it possible to say more directly exactly what
your code means, they show the direction of data flow quite well, and the
"ripply water" look emphasizes the plumbing analogy.
=thom
Tom MacKenzie: Say, Jubal...how do you feel about astrology?
Jubal Harshaw: Never touch the stuff. Prefer brandy.
--Stranger in a Strange_Land
RE: Array Questions
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]] > But I don't know if these two > lines would really have the same result, ... > > $a = MyScalar; > $a = 'MyScalar'; Hrmm. Didn't Larry decree that there are no bare words, but that a class name will evaluate to the string representing the spelling of the class name? In otherwords, aren't those two assignments identical by definition? =thom "Never try to out-stubborn a cat." --Lazarus Long
RE: L2R/R2L syntax (was Re: Everything is an object.)
Paul Johnson <[EMAIL PROTECTED]> wrote: > When I later saw it using mutt in an xterm, the tilde was at the top of > the character, where I was more used to seeing it and it didn't look like > an arrow any more, nor did it look very good to me. Well, at least now I understand why some people didn't see the squiggly arrow immediately, as I did. It seemed so obvious to MY eyes, I couldn't understand what the big deal was. I have been (quietly) siding with the "let's use unicode characters as operators" camp. But this little brouhaha has me splitting into two universes: Universe 1 (anti-unicode): "If we have this much trouble seeing a tilde the same way, what are the chances that all these cool new operators will be visually comparable to all P6 coders?" Universe 2 (pro-unicode): "If we had a Unicode 'squiggly arrow' operator, then however it looks on everybody's display, it ought to at least look like some kind of squiggly arrow." We'll say goodbye now. =thom "Delusions are often functional. A mother's opinions about her children's beauty, intelligence, goodness et cetera ad nauseam, keep her from drowning them at birth." --Lazarus Long
RE: L2R/R2L syntax (was Re: Everything is an object.)
Andrew Rodland <[EMAIL PROTECTED]> wrote: > But you're missing the most important part! > I propose that these operators should be named "gozinta" ( ~>) > and "comezouta" ( <~ ), just so that we can say that perl has them. Not to > mention that the names work pretty well, for me. Here, here! All in favor, say "Aye"! 'Course, then I've gotta explain why $x = 7 ~> 63; doesn't evaluate to 9 :-) =thom "Be wary of strong drink. It can make you shoot at tax collectors...and miss." --Lazarus Long
Perltalk
Smylers [mailto:[EMAIL PROTECTED]] wrote:
> And an alternative
> spelling for the assignment operator[*0] doesn't strike me as something
> Perl is really missing:
>
> $msg <~ 'Hello there';
> $msg = 'Hello there';
I still remember the first time I saw a computer program, before I had
learned anything about programming myself. A friend showed me his first
Fortran program, and it included the following line:
N = N + 1
I stared at that in puzzlement for a long minute, and then said "That sure
isn't true for any value of N that *I* know of!" Then he told me that "="
doesn't mean "equals" in Fortran (no, *that's* spelled "EQ" :-).
I've always been bothered by this misuse of mathematical notation, which is
used in an incredibly bewildering array of computer programming languages.
On the other hand, I've never been a fan of the ":=" spelling of assignment,
either. I always thought that "<-" was much better, except for the pitfall
that humans are likely to misread "a<-5" as a comparison.
One of the most... er, *interesting*, dodges I've seen in this area is the
one used by Squeak (a Smalltalk variant). Squeak spells assignment with an
underscore ("_"), but the Squeak system *draws* it as a left-pointing arrow.
Hey, I know: let's not bother with Unicode...let's just reassign a few ASCII
control characters for Perl's use! :-)
I, for one, could live with "<~" as the only assignment operator. But I only
suggest it tongue in cheek.
Speaking of Squeak, I notice that Buddha Buck just posted a
Smalltalk-translated-to-Perl implementation of the if-operator:
> class True is Bool is singleton {
>...
> our True true is builtin;
>etc.
which even includes the notion that the implementation of True and False is
immutable, so that the code generator has a ghost of a chance of knowing
what to do!
That was followed by Austin Hastings' post:
> log $user onto $system.
> log $message to $stderr.
> l2x = log 2 * log $x; # Don't check my math, please. :-)
> ...
> sub log($n) { ... }
> sub log _ onto($user; &_ ; $machine) { ... }
> sub log _ to($message; &_ ; $stream) { ... }
which is a recycling of Smalltalk's "inject:into:"-style operators. I have
to admit that I *like* the idea of being able to define those kinds[1] of
operators; they can really add to the clarity of the code. I just don't want
to have to write the parser!
[1] What *do* you call this style of operator -- intermingled-fix?
Looks like we've got some Smalltalk fans here. What say we start a new
mailing list for designing Perltalk? :-)
=thom
Riker: "They were just sucked into space."
Data: "Blown, sir."
Riker: "Sorry, Data."
Data: "Common mistake, sir."
(The Naked Now)
RE: A proposal on if and else
Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote: > The tokeniser could send two tokens "else" and "if" whenever it > recognizes the keyword "elsif" -- so this isn't a problem. The primary advantage, to my mind, in using C, is that it eliminates the dangling-else ambiguity -- so splitting it in half removes almost ALL the value of even having an C keyword. =thom "More people worry themselves to death than bleed to death." -- _Tunnel_in_the_Sky_, Robert Heinlein
Re: A proposal on if and else
Smylers wrote:
Thom Boyer wrote:
The primary advantage, to my mind, in using C, is that it
eliminates the dangling-else ambiguity -- so splitting it in half
removes almost ALL the value of even having an C keyword.
Surely it's the compulsory braces, even with a single statement, which
eliminates that problem?
Almost. The compulsory-braces rule [a Perl 5 syntax decision I applaud]
means that
if test1 {
statement_A;
} elsif test2 {
statement_B;
} elsif test3 {
statement_C;
}
is equivalent in meaning to
if test1 {
statement_A;
} else {
if test2 {
statement_B;
} else {
if test3 {
statement_C;
}
}
}
So if "elsif" becomes "else" followed by "if" in the scanner, the result
is syntactically wrong _because_ the curly braces are required (a point
that I missed in my earlier post):
if test1 {
statement_A;
} else if test2 { # syntax error: missing open brace after 'else'
statement_B;
} else if test3 { # Oops, I did it again
statement_C;
}
And let's not anybody say, "Well, 'elsif' gets converted to 'else'
followed by '{' followed by 'if', then!", because that doesn't work. All
the closing right curly braces would still be missing.
So the compulsory curly braces make for a much more convincing argument
against an "elsif" --> "else if" conversion in the scanner.
Personally, I don't think anybody should be working this hard to make
if/elsif/elsunless/else writeable as a subroutine. I don't think it
should be put in that pigeonhole: it doesn't fit there very well.
If we really need the comfort of knowing that if/else/etc. is writable
in Perl 6, then we can all take comfort that it _is_ always possible (if
not as convenient) using the much more general grammar-extension mechanism.
=thom
