Re: Unary dot
Dave Mitchell wrote: > The top 20 'my $var' declarations in .pm files in the bleedperl > distribution: How *dare* you introduce hard data into this discussion! Next you'll be wanting to deal in actual facts rather than personal opinion and sheer guesses!! ;-) Thanks, Dave. Very illuminating. Damian
Re: Apo4: PRE, POST
> > [concerns over conflation of post-processing and post-assertions] > > Having read A4 thoroughly, twice, this was my only real concern > (which contrasted with an overall sense of "wow, this is so cool"). Larry and I discussed it over breakfast the next day, and concluded that there will be a LAST block *and* a POST block. With the appropriate semantics differences. Damian
Re: [A-Z]+\s*\{
On Saturday 19 January 2002 22:05, Brent Dax wrote: > > Is this list of special blocks complete and correct? Close and close. As of two days ago, Larry's thinking was: BEGIN Executes at the beginning of compilation CHECK Executes at the end of compilation INITExecutes at the beginning of run END Executes at the end of run PRE Executes at block entry. Inherited if block is a method. No side-effects allowed. POSTExecutes at block exit. Inherited if block is a method. No side-effects allowed. NEXTExecutes on (explicit or implicit) call to next() within current block CATCH Executes on exception within current block LASTExecutes on any form of block exit. Not inherited (c.f. POST), even if block is a method. Side-effects allowed. KEEPSpecialized form of CATCH. Executes on "control" exception in the current block UNDOSpecialized form of CATCH. Executes on non-"control" exception in the current block Damian
Re: [A-Z]+\s*\{
On Sun, 20 January 2002, "Me" wrote
>
> - LAST
> (Per Damian's last (LAST/POST) post.)
Yup.
> - FIRST?
> (Symmetry.)
No. We feel that such code just goes at the start of the block. Of
course, there's an argument that you might have several entry points to
a block (via C labels) and still want some code executed no matter
where you land inside. I'm just not sure we really want to support that
pathology. ;-)
> - ALWAYS?
> (Another plausible addition. Rounds out PRE and POST
> with invariant assertions that get checked twice, once at
> the time PRE does, once at the time POST does.
> Personally I'd leave this out until it became clear, well
> past p6.0, whether it was really worth it, but it seems
> worth mentioning.).
I feel the same way. Invariant checking in most Design-by-Contract
systems doesn't work that way, and has another purpose entirely.
Invariants are implicitly POST blocks that are automatically distributed
to *all* methods of the class for which they're defined, but which only
execute on transitions back to callers *outside* that class's hierarchy.
Perl 6 *will* have invariant checking, but I believe it should be via a
property on the class declaration:
class Positive
is always { $.value > 0 }
is always { $.feelings =~ /optimistic/i }
is always { $.polarity eq '+' };
Damian
Re: What can be hyperoperated?
Larry pondered: > Perhaps we shouldn't be using ; for this. That has occurred to me on several occasions but, checking my pockets, I find I'm fresh out of spare symbols to replace it with. We could always use colon, of course ;-) Damian
Re: What can be hyperoperated?
Simon wrote:
> Given hyperoperators, I wonder if we can actually drop map.
So:
@result = map { block } @data;
becomes:
@result = {block}^.(@data);
Hmmm.
Damian
Re: What can be hyperoperated?
> On the other hand, semicolon works out really nicely within brackets > for multidimensional slices, and the mathematicians like it. And I > don't know how the :: would fit in with other adverbial generalities. Yes, I think semicolon is the correct solution. We just have to explain that it's only allowed to be a "naked singularity" within a C. Elsewhere it has to be decently shielded by the "statement event horizon" of a pair of brackets. ;-) Damian
Re: What can be hyperoperated?
> Damian> @result = {block}^.(@data);
>
> But "hyperdot sort hyperdot" doesn't roll off the tongue as easy as
> "map sort map"!
H. You could always overload binary - to implement the sort.
Then it would be:
hyper dot dash dot
Otherwise known in Morse circles as:
hyper-r
;-)
Damian
Re: Perl6::Tokeniser
> Damian was meant to be writing Parse::FastDescent and then > Parse::Perl,but as we all know, he's a Very Busy Man. Indeed. But my 2002 Perl Foundation grant list those two modules (only!) as deliverables. I'd say they'll be delivered -- probably by Christmas ;-) Damian
Re: Unary dot
Allison wrote:
>
> > > "David Whipp" <[EMAIL PROTECTED]> writes:
> > >
> > > > Thus, the perl5 transalations would be:
> > > >
> > > > foo() => $self->foo()
> > > > .foo() => $_->foo()
> > > > &foo() => foo()
> > > > ...
>
> Alternative:
>
>$self.foo() => $self->foo() # and can be .foo() when $self is $_
>.foo() => $_->foo() # but might be altered by a pragma
>foo() => foo()
And welcome back to where we started! ;-)
However, having circumnavigated the alternatives, we now have a better
perspective on the trade-offs and hidden costs.
The original idea of topicalizing the invocant in methods was that it makes
very simple methods even simpler:
method name { .assigned_name // .std_name // "???" }
For anything more complex than "very simple" (i.e. anything with internal
topicalizers), one names the invocant explicitly:
method rank ($self:) {
given ($.status) {
when "covert" { return "Special operative" }
when "detached" { return "Field operative" }
default { return $self.actual_rank }
}
}
or, if the class has many such methods, implicitly:
use invocant 'invocant';
method rank () {
given ($.status) {
when "covert" { return "Special operative" }
when "detached" { return "Field operative" }
default { return invocant.actual_rank }
}
}
The problem that this discussion has highlighted is that using a
bare .foo in a method means the reader/maintainer has to track what
the current topic is in order to know who the current invocant is.
That would seem to be a (potentially expensive) hidden cost of this idiom.
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
-> $self
rather than just:
-> $_
That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.
Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.
Of course, the problem is then: what should the name of this topicalizer
variable be? The main options are:
$self
$me
$I
$this
$invocant
$object
$obj
And frankly, that's a very minor issue. Someone (i.e. Larry) should just
pick one and then we can all move on.
Damian
Re: Unary dot
Allison Randal wrote:
> H... this being the case, is there any reason we should ever need to
> name the invocant explicitly?
Yes. To make it read-writable.
Perl makes that much easier than most other languages, because you can pass
the invocant by (writable) reference, so you don't need to pass a separate
$parent pointer:
method Tree::delete(Tree $self is rw:) {
if $.left_child {
$.left_child.insert($.right_child) if $.right_child;
$self = $.left_child
}
elsif $.right_child {
$self = $.right_child
}
$.right_child = $.left_child = undef;
}
Damian
Re: Defaulting params
Piers wrote:
> one could always handle the first case
> more explicitly by doing:
>
>sub load_data ($filename; $version) {
> $version = 1 if @_.length < 2;
> ...
>}
Err...no. If you specify named parameters, you don't get @_.
It could be handled by overloading though:
sub load_data ($filename) { load_data($filename, 1) }
sub load_data ($filename, $version) {...}
Damian
Re: Defaulting params
> Ooh. Multiple dispatch is definitely in then? Not definite yet. That was a subjunctive "could". ;-) But I'm very hopeful, since it's hard to user-implement things like C unless you can give a subroutine several distinct signatures. Damian
Re: Unary dot
> One of the features I like about Eiffel is what Meyer calls the Uniform
> Access principle...It sounds as though Perl 6 is heading towards supporting
> this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
write:
class Foo { # version 1
my $.bar_attr is public;
}
then you'll get an automagically created lvalue accessor method that will allow
you to write:
my $foo = Foo.new();
$foo.bar_attr = 1;
and then later define a real C method to encapsulate it:
class Foo { # version 2
my $.bar_attr;
method bar_attr is rw($rvalue) () {
if exists $rvalue {
croak "Negative value" if $rvalue < 0;
$.bar_attr = $rvalue;
}
return $.bar_attr;
}
}
More interestingly, it may also be that, by default, the C (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
(not to mention legacy Perl 5 OO coders ;-)
Damian
Re: Subroutine variables are like underwear
Yes, subroutine variables *are* like underwear.
But parameter names *aren't* like underwear.
Because they're not (primarily) subroutine variables.
So they're like the labels on the knobs, dials, and buttons of your favourite
elctronic device. They're part of the *interface*, not (primarily) part of the
implementation. They should be chosen with care, and not changed on a whim.
I do, however, understand the desire to allow them to change, or to be
somewhat "fuzzy" (i.e. "filename" vs "file_name" vs "file"). And I agree that
it could
be a very useful facility.
But your proposed syntax is...err...less than ideal.
If we were to have this, I'd far rather we use the existing mechanism
for annotating variables. Namely: properties.
For example:
sub load_data ($filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
Damian
Re: Unary dot
> > $foo.{bar_attr} = 1;
> >
> > This would help Perl 6 support legacy Perl 5 OO code
>
> How? Perl 5 code doesn't use ".", and if Perl 5 code has to be changed
> anyway, why not change it "all the way"?
Because changing:
$foo->{bar_attr}
to:
$foo.{bar_attr}
is a generic, purely syntactic change and easily automated, whereas changing
it to:
$foo.bar_attr
is a semantic change (why does *this* particular instance change to a method
call, rather than a hash look-up?) and consequently *much* harder to get right.
> > (not to mention legacy Perl 5 OO coders ;-)
>
> I dunno, the "$foo.{bar_attr} calls a method" thing seems kind of pointless
> (and mildly evil) to me. It seems like a throwback to the bad old days of
> tied-hashes-as-oo.
Sure. *You* would never do it. Neither would I. But TMTOWTDI.
And if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Damian
Re: Unary dot
Luke Palmer wrote: > > More interestingly, it may also be that, by default, the C (i.e. > > hash-look-up) method of a class invokes the accessor of the same name as the > > key, so that: > > I'm a tad bit confused on the grounds of classes. Are we allowed to: > %fred = new Flintstone; No. Not as you envisage it. Perl 6 objects aren't hashes. > Or are class instances limited only to scalars? The former seems a bit > counterintuitive... Yep. Perl 6 usage in this respect will be like Perl 5 usage. The constructor of a class will return a reference, which will normally be stored in a scalar. The difference in Perl 6 is that the object is an "opaque type": not a hash, not an array, not a scalar, sub, regex, glob, but a mysterious, encapsulated, impenetrable something of type OBJECT. The C method of which I spoke is the perl 6 equivalent of the C method of a tied hash (but without having the overhead of tying anything). Damian
Re: Tagmem* (was Unary dot)
Juanma Barranquero wrote: > On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more > euphonic version of "mimeme": On quickly scanning that message I read the last word as "mini-me", which brought up some *very* unlikely associations! :-) Damian -- "So, Mr. Evil..." "It's Dr. Evil, I didn't spend six years in Evil Medical School to be called 'mister', thank you very much."
Re: named params, @_, and pass-by-reference
Trey Harris wrote:
>
> In a message dated Wed, 17 Apr 2002, Dave Storrs writes:
> > sub load_data ( \$filename; $version; @_ ) {
>
> I think you can do exactly this with
> sub load_data ( $filename is rw, $version, @_ ) {
>
> Yes? Or maybe
> sub load_data ( $filename is rw, $version, *@_) {
>
> to make sure @_ gets flattened?
Exactly so. The first version expects a single array (or array ref)
as its third argument; the second version expects a list (which it
flattens, then slurps) as its third argument.
Damian
Re: Loop controls
Miko O'Sullivan wrote:
>
> SUMMARY
>
> A proposal for a set of loop structures that simplify code that is based on
> loop iterations.
>
> foreach my $var (@arr) { ... }
> before { ... } # run before first iteration,
> # only if there is at least one iteration
Larry is still considering allowing a C block that would do this.
It would go inside the loop block.
> between { ... } # run between iterations, not before first or after last
This will be called a C block. It goes inside the loop block.
> after { ... } # run after last iteration,
># only if there is at least one iteration
This will be called a C block. It goes inside the loop block.
> noloop { ... }# run if there are no iterations
Larry has been mulling over whether various types of loop should be allowed to take
C blocks to accomplish this.
Damian
Re: Loop controls
Trey Harris wrote:
> So:
>
> for $results.get_next() {
> FIRST { print "Results:"; }
> print $_;
> NEXT { print ""; }
> LAST { print "Done."; }
> } else {
> print "No results.";
> }
>
> Do I have that right?
Yes. Presuming Larry decides in favour of C and C.
Note too that the NAMED blocks are order-and-position independent, so (whilst I
agree that the order you wrote them was clearest) you could also have written
(with exactly the same effect):
for $results.get_next() {
FIRST { print "Results:"; }
NEXT { print ""; }
LAST { print "Done."; }
print $_;
}
if you were inclined, or:
for $results.get_next() {
LAST { print "Done."; }
print $_;
NEXT { print ""; }
FIRST { print "Results:"; }
}
if you were insane. ;-)
> And "" won't be printed before "Done."?
It *will* be printed there, according to the current design. A C is
*always* called when the iteration leaves the block (whether it's coming
around again or not). By analogy, C is a terminator, not a separator.
That's necessary because Cs will be mainly used to do synchronous
clean-up on lexical values:
for @filenames {
my $fh = open $_ or die;
NEXT { close $fh }
...
}
Damian
Re: Loop controls
Allison wrote:
> As I was talking to Damian, he came up with a compelling semantic
> argument why we would want C blocks to follow, which is a question
> that needed to be faced since we rejected C.
Specifically, the semantic argument with that idea is that CAPITAL blocks
attach automatic behaviours to a surrounding scope, but the C behaviour
is specifically *not* associated with the surrounding block. Or rather:
specifically associated with the *not* of the surrounding scope.
Either way, that would make embedded Cs seem highly counter-intuitive to me.
> And the discussion of scope led to (what I think is) an interesting
> tidbit on NAMED blocks...
Which I presume was that the proposed usage:
while $result.get_next() -> $next {
# do something with $next...
ELSE {
if $next eq "xyz572" {
print "We defined this value, $next, as false for obscure purposes.";
print "No loop was executed. Just wanted to let you know.";
}
}
}
would actually be a (very subtle and nasty) bug!
The construct:
-> $next {...}
is, of course, an anonymous subroutine declaration. Hence C<$next> is a parameter,
the binding of which only occurs when the subroutine is invoked (i.e. on each
iteration). However, if the C condition fails, the subroutine *isn't*
invoked, so C<$next> isn't bound, so the nested C block (even if it were
fired off separately) wouldn't work as expected.
This leads me to conclude that a normal (trailing, un-nested) C is a
much more reasonable construct for a C -- and at least arguable for a C.
The argument in its favour is simply that it eliminates two not-unusual -- but
very annoying -- constructions involving repeated tests. Namely:
if (some_test) {
while (some_test) {
...
}
}
else {
...
}
and the more error prone (because it assumes C is idempotent):
while (some_test) {
...
}
unless (some_test) {
...
}
And it replaces them with a very DWIMish alternative:
while (some_test) {
...
}
else {
...
}
I haven't seen those annoying constructions used as often with C loops,
but I imagine they might well occur more frequently in Perl 6, where lazy
iterators will make C loops the preferred choice in a far wider range of
circumstances.
> And something just feels right about C blocks on loops. It fits in
> with that Perlish pattern of allowing structures that feel so natural
> you wonder why no other language ever allowed them.
Yes. That's one of Larry's greatest talents: doing the obvious-in-hindsight. :-)
Damian
Re: Loop controls
Allison wrote:
> > This leads me to conclude that a normal (trailing, un-nested) C
> > is a much more reasonable construct for a C -- and at least
> > arguable for a C.
>
> And C, I hope.
Sure. I always think of a C as just a C with delusions of
grandeur. ;-)
Of course, one would expect a compile-time warning on useless special cases like:
loop {
...
}
else {
...
}
Damian
Re: Loop controls
Aaron Sherman wrote:
> Of course it brings other less wholesome things to mind like "elsfor"
> and "elsloop" and "if ... elsfor" and "for ... elsif ... elsloop ...
> else", but why not?
Because Perl 6 is already...err...over-endowed with keywords, few of which are
as klunky as these would be. If we were to generalize to cascaded loops I'm
pretty sure we'd have to consider "else if", "else while", "else for" etc. instead.
> > But the aliased value, $_, is restricted to the scope of the C's
> > block, it isn't going to be accessible in the block associated with the
> > C (you would be getting some $_ from an outer scope).
>
> You're thinking of loops in a curious and convoluted way,
Err. No she's not. Allison is right on the money. She's thinking of
loops in the Perl 6 way (which is less curious and convoluted).
> Try this out:
>
> { loop-keyword [ conditional/declaration ]
> block
> { else-clauses ...} }
>
> The loop itself comprises an outer scope in which the conditionals or
> declarations exist. Then, each block comprises a sub-scope. In this way,
> there is no confusion, no special case, no violation of the rules.
Except the rule that there are no implicit scopes (except file scope).
> It becomes reasonable now to have:
>
> for @a -> $b {
> stuff using $b
> } elsfor @c -> $d {
> more stuff using $b and $d
> } else {
> yet further stuff with access to $b and $d
> }
Except that, as Allison subsequently correctly pointed out, the aliasing arrow
doesn't work that way at all.
Damian
Re: Loop controls
Aaron Sherman wrote: > > Er, what?!? Who said we're dropping "until"? Did I miss something? > > Well, if there's no while (replaced by generic "loop", per Apoc4) why > would there be an until? As Aaron himself has discovered, neither C nor C is being dropped from Perl 6. Incidently, even C is still allowed. We're just changing its semantics slightly (it no longer iterates once before the conditional check) so that it's consistent with the rest of Perl 6. > Ok, once more for those in the cheap seats (no offense, it's just a lot > of people seemed to have ignored the thread until now and jumped in > without the context), this is how we got here: > > 1. Larry says loops will have "ELSE blocks" inside them. No, Allison said that. And she was wearing her Devil's Advocate hat at the time. > So, the answer to your question is: yes, I do propose that there should > be an elsif, elsloop and elsfor. That's it. Three words, not an > expansive list of ever-more-complex words. and 'elswhile'. *Four* words: 'elsif', 'elsloop', 'elsfor', 'elswhile', and 'elsuntil'. *Five* words... *No-one* expects the Spanish Inquisition! ;-) Damian
Re: Loop controls
Aaron Sherman wrote:
> > while $result.get_next() -> $next {
> > # do something with $next...
> > ELSE {
> ># do something otherwise with $next
> > }
> > }
> > }
> Here's the code, expanded:
Unfortunately, that code isn't even close to the Perl 6 semantics of C loops.
> Is there any reason to do it the other way?
Yes. Good reasons. The most important of which is the notion
that there are no magic lexical scopes.
Damian
Re: Loop controls
Allison wrote: > I still don't like the idea of Cs on loops. I already do an > instant double take with C of "Where's the if?" (with visions of > old Wendy's commercials dancing in my head). It seems that a long string > of Cs (possibly separated by other long intervening sections of > code) would make the expectation even stronger when I was trying to read > through someone's code. But, that is a matter of habit and could be > retrained. I don't much like C on loops either. I suspect that when things get that hairy (which is not often) you probably do need an explicit overarching if/elsif/else (or, better yet, a switch statement). Damian, now having terrible visions of someone suggesting C ;-)
Re: Loop controls
> Two solutions to the problem of accessing 'what' returned false are:
>
> 1) don't allow it.
> 2) Alias the value of the while/loop/if conditional into a special
> variable.
>
> while( blah() ) {
> ..
> } else { print $COND; }
>
> It's ugly, but it works, and doesn't break the holy scoping rules.
It's also unnecessary. The Holy Scoping Rules actually work in your favour in
this case. In Perl 6 you can just do this:
while my $cond = blah() {
...
}
and C<$cond> is defined *outside* the block. So if Larry were to allow C
on loops, you'd be able to write:
while my $cond = blah() {
...
}
else {
print $cond;
}
Given how rarely this kind of thing is actually needed (I've *never* used such
a construct), I suspect that an explicit variable is adequate.
Damian
Re: Loop controls
Allison wrote: > The answer is the same, in any case: "When the condition in the > C has a false value, when the list/array in the C is empty, > or when the condition (2nd expression) in the C is met on the first ^ not > comparison." > > > Are the hordes of programmers yet-to-be that will be weaned > > exclusively on Perl 6 look scornfully on me for such opinions and say, > > "There goes another Perl 5 programmer, pass the Geritol"? > > Who knows what they'll think of us? They'll probably all be wearing > brightly colored latex body suits with communication/computation devices > embedded on every surface too. ;) I have the privilege of meeting a large number of Perl programmers on a regular basis and, as deeply as I admire and respect them all, there are VERY FEW that I want to see in latex body suits! ;-) Damian
Re: Loop controls
Miko wrote:
> I don't know if we're talking about the same thing, but I live using loops
> that declare variables in the test, so please exegize me. Which of these
> lines, if any, would cause a compiler error or warning?
>
> while my $cond = blah() {
> ...
> }
> else {
> print $cond;
> }
>
> print "The condition is: $cond\n";
>
> If none then you're seriously rocking my world.
Then I'm seriously rocking your world.
In Perl 6 a lexical variable is scoped to the block in which it's declared.
Since C<$cond> is declared in the block *containing* the C and C,
it's scoped to that block. So you can use it inside the C's block,
inside the C's block (assuming Larry allows such a construct), and in
the following C statement.
Damian
Re: Loop controls
> OK, will at least this statement still work as it does in Perl5? No. > Notice addition of parens. which, as you surmise later, have no effect on scoping issues. > If that changes, I for one will need to go rewrite virtually every script > and library I maintain, or let p52p6 do it for you. But, yes, it is a major and fundamental change. > My personal pain aside, it seems counter-intuitive to me. > $result gets my'ed over and over and over. Err...no it doesn't. It gets C'd exactly once: at compile-time. It gets *assigned* over and over again. > Even if the addition of the parens does make a difference, it doesn't look > quite logical to me. Parens in an evaluation are just grouping mechanisms, > not structural controls. Precisely. That's why they make no difference. Damian
Re: Loop controls
Luke Palmer wrote:
> Ooh! Why don't we have a dont command! With several variants:
> dont FILE
> dont BLOCK
>
> dont { print "Boo" }
>
> Would print:
>
>
You really *should* be more careful what you wish for Luke.
The following was just uploaded to the CPAN...
Damian
-cut--cut--cut--cut--cut--cut-
NAME
Acme::Don't - The opposite of `do'
VERSION
This document describes version 1.00 of Acme::Don't, released May 1,
2002.
SYNOPSIS
use Acme::Don't;
don't { print "This won't be printed\n" };# NO-OP
DESCRIPTION
The Acme::Don't module provides a `don't' command, which is the opposite
of Perl's built-in `do'.
It is used exactly like the `do BLOCK' function except that, instead of
executing the block it controls, it...well...doesn't.
Regardless of the contents of the block, `don't' returns `undef'.
You can even write:
don't {
# code here
} while condition();
And, yes, in strict analogy to the semantics of Perl's magical
`do...while', the `don't...while' block is *unconditionally* not done
once before the test. ;-)
Note that the code in the `don't' block must be syntactically valid
Perl. This is an important feature: you get the accelerated performance
of not actually executing the code, without sacrificing the security of
compile-time syntax checking.
LIMITATIONS
Doesn't (yet) implement the opposite of `do STRING'. The current
workaround is to use:
don't {"filename"};
AUTHOR
Damian Conway ([EMAIL PROTECTED])
BLAME
Luke Palmer really should be *far* more careful what he idly wishes for.
BUGS
Unlikely, since it doesn't actually do anything. However, bug reports
and other feedback are most welcome.
COPYRIGHT
Copyright (c) 2002, Damian Conway. All Rights Reserved. This module is
free software. It may be used, redistributed and/or modified under the
terms of the Perl Artistic License (see
http://www.perl.com/perl/misc/Artistic.html)
Re: Loop controls
So, after all our discussions, my thinking regarding alternate blocks for
loops is now running like this:
1. It would definitely be useful to be able to catch the failure of a
block to iterate.
2. This ability should be available for all three types of block: C,
C, and C.
3. The "obvious" syntax:
while condition() {
...
}
else {
...
}
is fraught with difficulty because C is already so closely
bound to C in the community consciousness.
4. Using C also encourages the expectation of C, C,
C, C, etc. But I don't believe the language can
comfortably bear the weight of such expectations. Or such keywords.
5. My preferred option would be to restrict the "alternative block" to
only being a simple block (i.e. no cascading), and to introduce it
with some other keyword.
6. C would seem to fit the bill rather nicely.
So, I guess if Larry were to ask my opinion, I'd suggest that we allow:
while condition() {
...
}
otherwise {
...
}
and:
for @list -> $next {
...
}
otherwise {
...
}
and:
loop ($i=0; i<$max; i+=2) {
...
}
otherwise {
...
}
I now confidently await Larry's coming up with an entirely different solution ;-)
Damian
Re: Loop controls
ralph wrote:
> I'm basically sold on Damian's conclusions. On the other
> hand the 'otherwise' clause still feels to me like a CAPITALS
> block.
>
> So, as a tweak, I suggest:
>
> while condition() {
> ...
> }
> NONE {
> ...
> }
Would you also change C to C? I think lowercase is more
appropriate because C would be a control structure, rather
than an event handler.
Making it a CAPITAL block is also a little inconsistent: the other CAPITAL
blocks attach behaviour to the *surrounding* block, not the *preceding* one.
Damian
Re: Loop controls
Luke Palmer wrote:
> I'd rather have an in-betweener block too. Loops like this are very
> common, and I hate doing "prefix" commas, if you know what I mean. I
> realize NEXT often used for cleanup, so maybe you could introduse Yet
> Another block, BETWEEN (or SQUEEZE).
>
> Or are we just going to have to deal with this fact?
We may just have to deal with the fact. Because there's a problem with
in-betweener blocks. Consider:
my $filename;
while get_next_filename($filename) {
FIRST { print "\n" }
my $fh = open $_ or die "Can't open $filename";
NEXT{ close $fh }
print extract_id($fh);
BETWEEN { print (-d $filename ?? "/," :: ",") }
LAST{ print "\n" }
}
This looks reasonable, but there's a bug.
The C block can't decide whether to execute until
it knows whether the loop is going to iterate again. And it can't
know *that* until it has evaluated the condition again. At which
point, the $filename variable has the wrong value. :-(
The example is a little contrived perhaps, but it might be a common
problem. For example, it happens here too:
loop ($n=$from; $n<$to; $n+=$skip) {
print $page[$n];
BETWEEN { print "Skipping to page $( $n+$skip )\n"; }
}
C<$n> is updated before the conditional test, but the C
block can't execute until after the conditional.
Don't get me wrong: I *like* the idea of a BETWEEN block.
I just think it's harder to get right (and *much* harder to explain)
than most people would expect.
Damian
Re: Loop controls
> Um... I know it's scary, but I can actually imagine using this (or
> something like this) in development. I'll occasionally work on a section
> of code I'm not ready to integrate yet. It would be nice to be able to
> syntax check it without uncommenting and re-commenting the whole thing.
> :)
Yes. That's what I do: produce modules that are the superposition of:
all('absurd', 'useful', 'scary')
;-)
Damian
Re: eval {} or carp "blah: $@"
Jim Cromie wrote:
> with p5, Ive often written
>
> eval {} or carp "$@ blah";
>
> it seems to work,
modulo any block that returns false :-(
> and it reads nicer (to my eye) than
>
> eval {}; if ($@) {}
>
> but I surmise that it works cuz the return-value from the block is non-zero,
> for successful eval, and 0 or undef when block dies, not cuz of magical
> treatment of $@.
No. C return the last evaluated value in the block, unless an
exception is thrown, in which case it returns C. The problem with
the C approach is that there are situations in
which the block can evaluate successfully but still return C.
On failure, C sets C<$@>, so careful programmers test it separately.
Of course, you *can* do that in a single statment if you want:
eval {} or @! and carp "$@ blah";
> I gather that ';' is unneeded in p6,
Err...no.
> and given that $! is the 'exception'al topicalizer,
Only inside an explicit CATCH block.
> is this construct no longer reliant on the last value in the eval block ?
In Perl 6 C becomes C and you'll still be able to write:
try { ... } // carp $!;
but that will trip up if the final value of the C block is C.
What you want is:
try {
...
CATCH { carp $! }
}
> put another way, does the 'topicalizer' reflect the exit condition of
> the closure ?
Only in a CATCH block.
Damian
Re: Loop controls
Miko O'Sullivan wrote:
> > Acme::Don't - The opposite of `do'
>
> Wonderful job, Damian! I'll get to work on the complementary Acme::TryNotTo
> module.
use Yoda;
do {...} or not do {...};
not defined try {...};
;-)
Damian
PS: that's valid Perl 6!
Re: Loop controls
Allison asked: Hmmm... would C not have the same problem as C? It also > "can't decide whether to execute until it knows whether the loop is > going to iterate again". Yes, it does. Damian
Re: Loop controls
Mike Lambert asked:
>
> > It's also unnecessary. The Holy Scoping Rules actually work in your favour in
> > this case. In Perl 6 you can just do this:
> >
> >
> > while my $cond = blah() {
> > ...
> > }
> >
> > and C<$cond> is defined *outside* the block.
>
> Question then. Does the following code compile?
>
> while my $i = getNextValue() {
> }
>
> ...
>
> while my $i = getOtherNextValue() {
> }
Yes, it compiles. But you get warnings about two lexical C<$i>'s being
declared in the same scope.
> Does it fail due to scoping $i twice within the same enclosing block, or
> is it sort of like a Scheme/OCaml interpreter where each definition
> creates a scoping for all the lines that follow it, and the second 'my $i'
> merely hides the $i scoped in the 'outer' scope.
The latter. As Perl 5 does now.
And yes, it's annoying.
However, it won;t be an issue in Perl 6. The correct idiom in Perl 6 will
almost certainly be:
while getNextValue() -> $i {
...
}
while getOtherNextValue() -> $i {
...
}
which generates no warning because each C<$i> is a parameter of the
corresponding loop block, and hence scoped to that block.
Damian
Re: Loop controls
Glenn Linderman wrote: > I've been watching this "Loop controls" thread with much interest. It > is clear that there is some convenience in the concept of specialized > blocks that execute FIRST or LAST or NEXT and BETWEEN has a large > appeal, considering the large number of loops where something must be > done every time except the first or every time except the last, except > that I have never done the statistics to figure out whether every time > except the last or every time except the first is more frequent, neither > have I figured out whether BETWEEN is more frequently needed at the > beginning or end of the loop body, and these latter two issues seem to > be what everyone is going around and around about, without stating them. > > I think much of the discussion has resulted because there are many more > conceptual meanings that could be useful, than there are suggested > keywords to fulfil the meanings. I'll try to list the many conceptual > meanings possible as I continue. Thanks for an excellent exploration of the solution space of CAPITAL blocks, Glenn. I'm sure Larry and the design team will find it invaluable when we (inevitably) revisit this issue. Damian
Re: Accessor methods ?
Aaron Sherman wrote:
> > What if I want my methods to be called C<.get_bar()> and C<.set_bar()>,
> > since a certain Perl OO specialist suggests this approach is best for
> > avoiding ambiguity in one's API?
>
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz() { .baz }
> sub set_baz($newbaz) { .baz = $newbaz }
Close. They'd probably be implemented like this:
method get_bar() { $.bar }
method get_baz() { $.baz }
method set_baz($newbaz) { $.baz = $newbaz }
Of course, there would need to be some way of simultaneously preventing the
automagic creation of accessors. That might be manual:
class Foo {
my $.bar;
my $.baz;
method bar is private {}
method baz is private {}
...
}
or per-attribute:
class Foo {
my $.bar is accessorless;
my $.baz is accessorless;
...
}
or (my favorite) global:
class Foo {
no accessors;
my $.bar;
my $.baz;
...
}
Damian
> I suppose there could be some magic like:
>
> class Foo is accessedby('get_','','r')
> is accessedby('set_','','rw') { ... }
>
> To declare that Foo has accessors with prefix "get_" and no suffix for
> read-only acces and prefix "set_" and no suffix for read/write access.
>
> But, I'm not sure how valuable this would be
Re: Loop controls
> Ok, now I understand the plan. In brief, in the following example $result
> is scoped to the block that encloses the whole loop:
>
>while (my $res = $search->getnext) { ...}
Yes. Because it's a lexical variable declared outside the closure controlled
by the C.
> However, in the next example, $res is scoped to the loop:
>
>while $search->getnext() -> $res { ...}
Yes. Because it's a parameter of the closure controlled by the C.
> Right? OK, that sounds cool. We still have loop-scoped variables. I'd
> like to suggest, though, that the first example would refuse to compile.
I don't think so.
> If the plan is to significantly change the behavior of something as popular as
> that construct (and I did some research, it's VERY popular, details
> available on request), it would make more sense to refuse to compile than to
> DWIDM (Do What I Don't Mean).
H. By the same argument we should refuse to compile the very popular
C<$var[$idx]> and C<$var{key}> constructs, since they no longer mean what
they meant in Perl 5.
I don't think that's the right answer. A construct like:
while (my $res = $search->getnext) { ...}
has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
reasonable than in Perl 5.
However, Miko has highlighted a genuine transition problem, and one might imagine
something like:
use warnings 'P52P6';
that would point out potential problems like this.
Damian
Re: Accessor methods ?
>
> I've recently come to the conclusion that I like my get/set methods to
> look like:
>
> method foo() { $.foo }
> method set_foo($self: $new_foo) { $.foo = $new_foo; $self }
>
> (Perl6 syntax obviously). I hope it's going to be possible to set that
> up automagically... (Yeah, I know, if/when Perl 6 gets macros...)
I suspect that there might be a module that would allow you to change how
Perl 6 autogenerates attribute accessors.
Damian
Re: Accessor methods ?
Aaron Sherman asked:
> > > sub get_bar() { .bar }
> > > sub get_baz() { .baz }
> > > sub set_baz($newbaz) { .baz = $newbaz }
> >
> >
> > Close. They'd probably be implemented like this:
> >
> > method get_bar() { $.bar }
> > method get_baz() { $.baz }
> > method set_baz($newbaz) { $.baz = $newbaz }
>
> Wouldn't those be the same?
Not quite. C<$.bar> is a direct access to the attribute. C<.bar> is a call
to the accessor. There might well be performance issues.
> ".bar" is the auto-created accessor for
> "$.bar", so they should do the same thing, no?
Presumably, but perhaps not quite as fast.
> And in the case of ".baz", I'm assuming that a public member will be
> given an "is rw" accessor, so that ".baz = $newbaz" will work the same
> as "$.baz = $newbaz".
That would be the plan, yes.
Damian
Re: Accessor methods ?
Chris Dutton wrote:
> Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
> with something like the following?
>
> method set_baz(type($.baz) $newbaz) { $.baz = $newbaz }
I'm not sure that Larry has considered precisely what can be used as
a type specifier in Perl 6. Your proposal seems very perlish to me
so I would hope so.
Of course, this would imply that C was an compile-time function, which
doesn't sit well with Perl's predominantly run-time typing. So it would seem
likely that there would need to be both compile-time and run-time versions
of C, or at least distinct compile-time and run-time semantics.
In which case one might need to write:
method set_baz(BEGIN{type($.baz)} $newbaz) { $.baz = $newbaz }
That's getting a little ugly, so maybe we'd "lift" the syntax from Eiffel instead:
method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
Hmmm.
Damian
Re: Accessor methods ?
Erik Steven Harrison wrote: > I've been playing around with Perl 5.6's lvalue subs. And (though at times > irritating to deal with) they're wonderful. It seems to me that the use of an > assignment operator is quite clear, and so there is no need for individual method > calls for retrieving and setting the attribute. > Will this exist in Perl 6? Yes. The attribute C<:lvalue> will become the property C. > In fact, as long as we're mulling over it, will subroutine attributes be > supported in Perl 6 Yes. Except they'll be called properties. See: http://dev.perl.org/perl6/apocalypse/2#properties http://dev.perl.org/perl6/exegesis/2 > and what kind of changes should we expect? Slightly different syntax. More easily user-configurable. More tightly integrated with the core language. Greater variety of standard properties available. Damian
Re: Accessor methods ?
Paul Johnson wrote:
> I've always found the word "like" to be very wishy-washy in a computer
> langauge. In what way is newbaz like baz? And just how alike are they?
> There must be a better way to describe this.
Perhaps:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
Damian
Re: "Attribute" vs. "Property"
David Wheeler wrote: > I just want to verify that I properly understand the use of these two terms > in Perl 6. and in the wider OO community, BTW. > * An "attribute" is a data member of a class. Yes. > * A "property" is a piece of metadata on a...uh...thing -- e.g., on an > attribute, on a class, or on a method. or on a subroutine, closure, or value. > Do I have it right? Yes. > So do I just need to turn myself around (at least when talking about > Perl), or is there a chance that the language designers would decide that > the way I use the terms is ever-so-much-better? ;-) Well, I suppose there's always a *chance* that we'd both completely reverse our careful thinking on this issue and ignore the common usage of "attribute" in the OO literature. But I do think it would be easier all round if you just went with our chosen terminology for Perl 6. ;-) Damian
Re: Perl6 currying
Larry Wall wrote: > We've pretty much settled on &div.prebind(y => 2) as the most informative and > least conflictive. and I'll demonstrate it in my next Conway Channel diary entry later today. Damian
Re: Half measures all round
Schwern wrote: > For what it's worth, I'm looking forward to porting my 50-odd modules to > Perl 6. In a lot of cases, I'll finally be able to remove some awful hacks. And I'll be porting most of my 30 or so (not the Perl6:: ones, obviously). There. Nearly 3% of the CPAN ported in two fell swoops! ;-) Damian
Re: Half measures all round
Brent wrote: > # And I'll be porting most of my 30 or so (not the Perl6:: > # ones, obviously). > > Why bother? You've already put P::RD and T::B effectively in the core! Not to mention Switch and Attribute::Handlers and Class::Contract and Class::Multimethods and Filter::Simple and Inline::Files. And eventually maybe even NEXT and Text::Reform and Quantum::Superpositions. Yes, my cunning plan is revealed: Perl 6 is nothing but a plot to reduce the number of modules I have to maintain! ;-) Damian
Re: Auto-capturing
Luke Palmer wrote: > I just read through A5 (wow, that's long), and I agree with most of it. > Some of it's really cool. Here's what makes me uneasy: The fact that a > grammar rule auto-captures into a variable of its name. > > Is this efficient? If I'm writing a syntax-directed translator, I usually > don't need to capture the rules. The rules are run for their side-effects. > I definitely see the win, but I see a lose in it too. Seems like an awful > lot of memory's going to be wasted if I'm matching a big file with one > C<$grammar.match>. > > Is there a way to tell it I to capture something from a grammar rule? > Should auto-capture really be default? Is someone going to tell me "well, > it's really not inefficient because ... optimizes " That would > relieve me greatly. There will be plenty of scope for optimization where perl can detect that the values returned named subregexes are never referred to. The easiest way to turn such optimizations on is to match in a boolean, string, or numeric context. > I am waiting eagerly for Exegesis 5 :) Me too. ;-) Damian
Re: A5: hypotheticals outside regexen
> Page 13 tells use about C decls. But it also says that the topic must > be a regex. Whilst it explains that this isn't really a problem, I'm not > sure that it justifies it. So perhaps someone can clarify why this > (hypothetical) code in not a reasonable generalization: Because Perl code doesn't backtrack (except within regexes). Exceptions and backtracking are quite different. If you want hypothetical *code*, put it in a regex. Damian
Re: A5: hypotheticals outside regexen
You have I how often that would have been useful. It's a great
> exception safety mechanism... like C++'s "resource aquisition is
> initialization" thingy, but without having to write a class for every
> variable.
Have you already forgotten KEEP and UNDO (that we introduced in A4/E4):
our $foo = 0;
sub do_something
{
KEEP { $foo = $foo + 1 }
commit();
}
sub commit
{
fail if rand < 0.3;
}
for 1..10
{
try { do_something() }
}
print "$foo\n"; # expect a value of around 7
;-)
Damian
Re: A5: a few simple questions
David Whipp wrote:
>
> First, a slight clarification: if I say:
>
> m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] /
>
> does this give me a hash of arrays? (i.e. is the rhs of a hash processed as
> a scalar context)
That's an error. The grouping bound to a hypothetical hash has to have
either exactly one or exactly two captures in it. To get what you want
you'd need something like:
rule wordlist { (\w+) [ , (\w+) ]* }
m:w/ %foo := [ (\w+) = () ] /
or just:
m:w/ %foo := [ (\w+) = ({ /(\w+) [ , (\w+) ]*/ }) ] /
> When I look at this, I see a common pattern: the join/split concept. It
> feels like there should be a standard assertion:
These are good ideas for assertions. If they don't become standard, it will
certainly be possible to write a module that makes them available.
> And a question about (I think something similar came up a few weeks
> ago): why isn't it , i.e. a list of the numbers of matches allowed.
> This seems to be the only place in perl6 where a list of numbers, as a
> range, isn't constructed using the .. operator.
Because a isn't a list of numbers. It's the lower and upper bounds on a
repetition count.
Damian
Re: A5: making a production out of REs
Rich Morin wrote:
> I'd like to be able to use REs to generate lists of strings. For
> example, it might be nice to create a loop such as:
>
>for $i (sort(p:p5|[0-9A-F]{2}|)) { # "p" operator for "production"?
>
> and have $i walk from '00' through 'FF'. Or whatever.
You mean:
$ch = any(0..9,'A'..'F');
for sort egs $ch _ $ch => $i {
...
}
where C is the (hypothetical) eigenstate operator on
(hypothetical) superpositions?
Even if Larry decides against superpositions, there will definitely be some
kind of non-quantum iterator syntax that supports these kinds of permuted
sequences.
Damian
Re: A5: making a production out of REs
> Rich sez:
>But make Damian use "es", rather than "egs" for the
>eigenstate ("is" :-) operator.
No, no, no! "any" and "all" are three letters, so the eigenstate operator has
to be as well. And since the eigenstates are *examples" of the possible states
of a superposition, "egs" is entire appropriate! ;-)
Damian
Re: A5: Is this right?
Brent Dax wrote:
> grammar Perl6::Regex {
> rule metachar { <[<{(\[\])}>:*+?\\|]>}
>
> rule ws { [<[\h\v]>|\#\N*]*}
Or just:
rule ws { [\s|\#\N*]* }
> rule atom { ( | \\ . | ) }
>
> rule modifier { (<[*+?]> \?? \:?) }
rule modifier { ([<[*+?]>|] \?? \:?) }
rule reprange { \< [ [, ?]? | , ] \> }
rule bound{ \d+ | }
There are also bits missing from the rest of the grammar (e.g. named captures).
I'll be showing a full regex grammar in E5.
Damian
Re: Apoc 5 questions/comments
Dave Storrs wrote:
> I admit I'm a bit nervous about that...so far, I'm completely sold on
> (basically) all the new features and changes in Perl 6, and I'm eagerly
> anticipating working with them. But this level of change...I don't know.
> I've spent a lot of time getting to be (reasonaly) good at Perl regular
> expressions, and I don't like the thought of throwing out all or most of
> that effort.
You won't be, Dave. Every feature you've learned is still there (except the
few insane ones ;-). You just have to learn the new syntax for them. And that
shouldn't be too hard since we carefully rationalized that new syntax --
specifically to make it easier to learn, remember, read, and predict.
> Somehow, this feels like we're trying to roll all of Prolog
> into Perl,
No. We're rolling in all of yacc/lex/RecDescent instead. ;-)
> For now, I'm just going to defer worrying about it until I see Exegesis 5,
> since past experience has shown me that there is a good chance that all my
> fears will be shown to be groundless once concrete examples are being
> demonstrated.
Good advice.
> Just to verify, this:
>
> s:3rd /foo<3>/bar/
>
> would do the 3rd, 4th, and 5th, correct?
Yes, but only if they were consecutive.And it would only replace them with a
single "bar". You probably want:
s:3rd:4th:5th/foo/bar/
> The u1-u3 mods all say "level 1 support". I assume this was a typo, and
> they should go (u1 => 'level 1', u2 => 'level 2', u3 => 'level 3').
Yes. That's being corrected on perl.com RSN.
> Can modifiers abut the delimiter?
>
> s:3x /foo/bar# most (all?) examples looked like this
> s:3x/foo/bar # is this legal?
Yes.
> -
>
> Can we please have a 'reverse x' modifier that means "treat whitespace as
> literals"?
I'll talk about that with Larry. If he were to approve it, it might possibly
be :W
> I am a little unclear on what the difference is between these two:
> my @foo = <$rx>;
> my @foo = m/<$rx>/;
In Perl 5 terms, the first is equivalent to:
my @foo; while (m/\G($rx)/gc) { push @foo, $1 }
The first is equivalent to:
my @foo; foreach (m/($rx)/g) { push @foo, $1 }
That is, the first one is implicitly anchored to the end of the last match, so
the matches have to be contingous. Whereas the second is unanchored, so the
matches can occur anywhere in the string.
> You could also use the {'...'} construct for comments, but then
> you risk warnings about "useless use of a string in void context".
>
> Could we automagically turn off that warning inside such constructs, when
> the only thing there was a string?
Depends how much Larry wants to discourage inline comments, I guess. ;-)
He's fairly strongly opposed to them.
> / pattern ::: { code() or fail } / # fails entire rule
>
> Farther down:
>
> A pattern nested within a closure is classified as its own rule,
> however, so it never gets the chance to pass out of a {...}
> closure.
>
> If I understand correctly, that means that this:
>
> / pattern ::: { $regex or fail } /
>
> would NOT fail the entire rule...correct?
As I understand it, it definitely *would*.
The code:
$regex or fail
has the $regex object in a boolean context, so it matches (if it can)
and returns true or false. If it fails to match the C fires off
a failure, which causes the closure to fail, which causes the top-level
regex to backtrack, whereupon it hits the :::, which causes the top-level
rule to immediately fail.
> When the entire match succeeds, the top-level node is returned as
> a result object The name of the result object is $0.
>
> If the name of the result object returned from a successful match is $0,
> where is the name of the currently-executing program stored?
In $*PROG or something like it.
> my &rx := /(xxx)/;
>
> Should that be a $ instead of a & on the rx variable?
That ain't a variable, friend, that there's a gen-u-ine subroutine!
And it's being bound to a regex!!
(It's really just another way to give a regex a name ;-)
> / $2:=(.*?), \h* $1:=(.*) /
>
> Does this imply that $1, $2, etc are now read-write outside of regexen?
No.
> How are 'fail' and 'die' different inside a regex?
C initiates backtracking within the current regex.
C throws an exception that will almost certainly propagate all the
way out of the regex.
> Can subroutines that aren't used in regexen use 'fail' to throw an
> exception? If so, how is it different from 'die' when used outside a
> regex?
As I understand it, it isn't (currently).
Damian
Re: formats and localtime
> >Unless you replace it with something better. (Postscript or TeX or ...) > >You'll have a hard time finding something that makes life so easy. > > How about a Format module that works pretty much exactly the same way > but isn't actually in the Perl core? I have a paper on that ;-) As soon as my brain arrives back in my native timezone, I'll will be putting forward an RFC (one of many) on modularizing C along the lines of my Text::Autoformat::form subroutine. Damian
Re: formats and localtime
> Of all the items up for change in Perl6, these two bother me the most. > Format less so than localtime, but I still worry about breakage. > > The original format stuff HAS to be kept. Don't document it so as not to > encourage its use. Play up Text::Autoformat::form if you wish, but there > will be way too much breakage/too little updateage if hundreds of old > web log scripts have to be ripped out upon installation of Perl6. Only if you simultaneously remove Perl 5! My (limited) understanding of the aims of Perl 6 were to start again with a clean slate and fix the things that are broken, or that could be designed better with hindsight. Backwards compatibily was to be fed to the lions. If that isn't the case, I'll be unsubscribing immediately -- if Perl 6 is to be a mere exercise in featuritis, I'm not interested. Damian
Re: formats and localtime
> Chuckle, chuckle. Gee I guess we need more voices like yours to remind > us what the goal is. I guess it is all too easy for any one person to > locate their one or two small pieces of Perl turf they don't want > touched. Problem is, when you add up all those little pieces, you end up > having to embed a full Perl5 interpreter inside the Perl6 interpreter > (a/la x86 cores in new architecture Intel chips) just to keep everyone > happy. But we also need the conservative voices to prevent Tom's apprehended Forces of Academic Bondage from holding the floor (though, like Nat, I'm entirely confident they won't sway Larry's vote :-) This discussion does raise an important point (probably OT for this newsgroup): we must ensure that Perl 5 and Perl 6 *can* co-exist easily. Damian PS: Probably best to ignore most of what I say in the near future...it's likely to be the jet-lag talking ;-)
Re: Random items (old p5p issues)
> On Tue, Aug 01, 2000 at 11:59:22AM -0400, Chaim Frenkel wrote:
> > Reduce (e.g. $x = reduce { sum } @list;
>
> I mentioned this to Larry on the Friday after the conference
> and his response was that he did think about it originally but
>
> $sum = reduce + @list; # assuming I got the verbal->syntax translation right
>
> was not easy todo. I was not even thinking of that but just some like
> sort where we have $a and $b (ala the List::Util::reduce function)
> But I must admit, this syntax would be nice for some operators
I had a paper on that.
The solution (which I with RFC RSN) is to provide a simple mechanism for
generating higher-order functions.
The one I proposed in the switch statement paper
(http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt) was
the __ meta-variable. Used in place of an operand or an argument, it
creates an anonymous subroutine that evaluates the corresponding
operation or subroutine, substituting elements of @_ for the
meta-variables.
In other words:
$incr = __ + 1;
is exactly equivalent to:
$incr = sub { $_[0] + 1 }
So you can additively reduce a list like so:
$sum = reduce __+__, @list;
There's a protoype implementation available as part of the switch.pm module,
which will hit the CPAN some time this week (assuming I don't actually
*die* of jet-lag :-)
Damian
Re: type-checking [Was: What is Perl?]
> >PS> Perhaps the best of both worlds would be > >PS> design-by-contract? A la Conway? > > > >Conway? Who's Conway? > > Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or > something, I think it was. :) According to the latest TPJ, he's "the Mad Scientist of Perl". Clearly a trouble-maker of the worse kind! > I think I'm missing the point. Why pull 'em out like that? Why not > just put the code in the body of the sub? Same reason that we prefer a while loop to goto: you collect in one place all the relevant information that allows you to assess the correctness of the subroutine. An even better reason is that, by decoupling the interface contract from the implementation details, you allow the conditions to be inherited by methods in a derived class, even (or perhaps *especially*) when the implementation is replaced. Rest assured that I will be putting in an RFC proposing these and other DBC constructs, as part of a suite of proposals for revamping Perl's OO mechanisms. Now, where did I leave that bucket of tuits??? > Though a good post condition would benefit from some sort of > unconditional catch of return, I suppose. Perhaps allowing > continue on the outer sub block... Argh, no! A good postcondition is either invisible to the client code, or makes its presence felt only through the effect of turning a bad final state (or return value) into an exception. It does *not* offer a last chance to monkey with the return value! Damian
Re: date interface (was Re: perl6 requirements, on bootstrap)
Nat observed: > Moving things to modules (a) does little for the size of Perl, and (b) > promotes Pythonization of the language (i.e., all programs begin with > 20 lines of `load this module, load that module, load the other > module'). Your criteria for moving to a module can't simply be > whether it's a system call or not, you must use something that takes > into account the hindrance and the payoff. Amen! Damian
Re: Object oriented Perl6?
> >Also read Damien Conway's "Object Oriented Perl" if you want to go further. > > Unlike the famous title by Hesse, in this case that would be spelled > DamiAn, actually. :-) Yes, I'm named after a leper, not the AntiChrist ;-) > I think I can with safely predict that sixth generation Perl will > *not* elevate OO programming to compulsory and exclusionary use, > as that would invalidate TMTOWTDI. I will join Tom in that that prediction. I will be putting forward a large number of proposals to improve Perl's OO facilities (When? Before Christmas! ;-), but I would *hate* to see Perl become just another OO language. Damian
Re: RFC for recursive regexps
> In perl5,
>
> /(??{ $FOO })/
>
> delays the interpolation of $FOO, so as to be able to have
> recursively defined regexps.
Of course, that example might in itself be sufficient reason
to completely redesign the regex syntax!
Damian
PS: I'll probably have a RFC on that issue ;-)
Re: RFC: Request For New Pragma: Implicit
> Let me reiterate my view of pragmas. They can warp the language any > way you please, as long as they don't impact other modules. I wouldn't > even mind if someone wrote a pragma that lets you program Perl in Latin. Now you're just being silly! ;-) Damianus
Re: RFC stuff
> Formats out of core > Switch statement > > Anyone want to put their name next to them? Me. Damian
Re: wanthash (Was: Re: date interface (was Re: perl6 requirements, on bootstrap))
> >This reminds me -- once there was a proposal to extend the wantarray > >functionality on p5p. Anyone remember? Anyone want to turn it into an > >RFC? > > It was Damian's, no? I certainly claim it and intend to RFC it. I already have improvements to the previous proposal in mind. The current proposal is at: http://www.csse.monash.edu.au/~damian/Perl/want.proposal But, by all means, send me any further suggestions. Damian
Re: wanthash (Was: Re: date interface (was Re: perl6 requirements, on bootstrap))
> > It was Damian's, no? > > I bet he has a paper on it. http://www.csse.monash.edu.au/~damian/Perl/want.proposal :-) Damian
Re: date interface (was Re: perl6 requirements, on bootstrap)
> > my $date = localtime;
>
> >And use $date->day (or month or year) later when you need to.
>
> But people *like* to be able to put things in simple variables.
> It's more convenient to type $day than $date->day for repeated usage.
Precisely. Hence my previous suggestion:
$day = localtime; # return date string in SCALAR context
$year = localtime->{year}; # return hash ref in HASHREF context
(@bits) = localtime;# return list in LIST context
This just relies on extensions to the context mechanism which I will RFC RSN
when I propose the new want() built-in to replace wantarray().
Damian
Re: wantarray() should be named wantlist() (was Re: date interface (was Re: perl6 requirements, on bootstrap))
Tad pointed out: > Due to the recent "rename local()" and "can't return an array" > discussions here, we should also consider "rename wantarray()" > as well. > > It should be named wantlist(), because it does not tell you > if it wants an array, it tells you whether you were called in > list context or not. It should just be want() because I intend it to do *much* more :-) > I will RFCify this within the next few days (unless someone > can shoot it down right now). http://www.csse.monash.edu.au/~damian/Perl/want.proposal Send me any suggestions (out-of-band). Damian
Re: RFC: lexical variables made default
> > Perl's similarity to English is one of the things that makes it Fun. > > OTOH, being fun (which I admit it is) is one of the reasons many > people don't want to think Perl is a serious language. > > Not saying we should eliminate all the fun; but keeping something > on the merit of it's being fun is probably at odds with the goal > of make Perl more widely acceptable. Someone want to RFC a "fun" pragma: #! /usr/local/bin/perl -w no fun; # for you! Actually, Tim Maher and I were discussing something not entirely dissimilar for the purpose of teaching: use Training::Wheels; or: no Weird::Stuff; Hm. I feel a paper coming on... Damian
Re: Recording what we decided *not* to do, and why
> I don't care particularly if you ignore dissenters. They can have > their own counter-RFC. All we're doing is making suggestions to > Larry, not regulating nuclear weapons or planning a space mission. I used to feel like that too, until folks from the space agencies of two countries told me they were using Parse::RecDescent. SCARY! Damian
Re: named parameters
> Reading through the docs for perl prototypes I see that there is a
> reference to "named parameters" being a possibility in future versions of
> perl.
>
> Does anyone have a more concrete example of what was intended there? (I'm
> assuming that since it was mentioned that there was a debate on the issue
> some time ago).
Intending to RFC a proposal for that too...
Dear Mum and Dad,
Having a wonderful time on perl6-language.
Please send more tuits!
Damian
Re: named parameters
I have an RFC coming on this. (I know, I know, I keep promising, but none appear. I'll unload the first 10 or so later today, the gods willing) Damian
Re: named parameters
> > Fair enough. If we were going to do it I would like to see it extend to:
> >
> > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
> >
> > }
>
> Is there an RFC for this yet? If not, I think there needs to be. I think
> this would be really cool.
I'll have a proposal out later today or tomorrow.
But others ought to consider putting one in too.
Damian
Re: RFC: lexical variables made default (revised)
> However, I do think there's something to be said for a "quick-and-dirty"
> script out of the box that can distinguish between sub{} vars and other
> vars ala C:
>
>$user = 'nwiger';
>sub whois {
>($user) = @_;# different var
># ...
>}
>print whois($user);
Are two extra chars really so much to ask?...
$user = 'nwiger';
sub whois {
my($user) = @_;# different var
# ...
}
Besides, named arguments will solve this (in fewer chars even :-)...
$user = 'nwiger';
sub whois ($user) {
# ...
}
Damian
Re: New Group proposed: subs (was Re: named parameters)
> I also hope that
>
>sub func : method {
>my( $self, $foo, @bar ) = @_ ;
>blah ;
>}
>
> will become:
>
>sub func : method ( $foo, @bar ) {
>blah ;
>}
>
> (with $self automatically supplied)
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Damian
Re: switch/case (c) vs. case (pascal)
> > Please, please, *PLEASE* read through Damian's fine paper on this > > entire matter before rendering judgment. > > URL? http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt Damian
Re: New Group proposed: subs (was Re: named parameters)
> What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= You took the words right out of my...err...fingers! Although, of course, it will be $ME in line with the usual practice of SHOUTING OUT MAGIC VARIABLES. Damian
Re: switch/case (c) vs. case (pascal)
> Damian Conway wrote: > > http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt > > Curried operators might be a nice way of generalizing the switch > syntax. When we write: I'm just about to post an RFC proposing exactly that (albeit with a quite different syntax). Damian
Re: New Group proposed: subs (was Re: named parameters)
> > One of my many RFCs will include a proposal for a $SELF variable along
> > those lines.
>
> Why not allow for the choice of the name of self, perhaps through a pragma?
>
> use self => 'self';
> use self => 'this';
>
> or something along those lines -- since it's currently up to the devleoper
> anyway. Somethign about a capitolized SELF is unappealing to my eyes.
$ME will be like other magic variables, so you can always write:
sub self {$ME}
sub this {$ME}
sub I{$ME}
sub one {$ME}
sub obj {$ME}
sub TheObjectThatThisMethodWasInvokedOn { $ME }
# and later
sub shout {
self->set_name(uc this->get_name);
}
Of course, these particular subroutines might be a good (and easy)
target for inlining optimization.
Damian
Re: Proposed sublist: flowcontrol
> > i think damian's influence on perl6 > > is our real triple top secret weapon. > > This realization has hit me on the head really hard. > My prediction is that Perl6 will have to be dual-credited. I doubt it: Lucifer doesn't get a by-line on the Bible. There's only one Larry. We're just fortunate that he's a sufficiently large value of one. Damian
Re: RFC 24 (v1) Semi-finite (lazy) lists
> From [EMAIL PROTECTED] Sat Aug 5 04:36:31 2000 > Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) >by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id EAA20410 >for <[EMAIL PROTECTED]>; Sat, 5 Aug 2000 04:36:31 +1000 (EST) > Received: from tmtowtdi.perl.org ([209.85.3.25]) > by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714) > with SMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Sat, 5 Aug 2000 04:36:28 +1000 > Received: (qmail 11194 invoked by uid 508); Fri, 04 Aug 2000 18:36:24 + > Received: (qmail 11182 invoked from network); Fri, 04 Aug 2000 18:36:23 + > Date: Fri, 04 Aug 2000 21:35:55 +0300 > From: Ariel Scolnicov <[EMAIL PROTECTED]> > Subject: Re: RFC 24 (v1) Semi-finite (lazy) lists > In-reply-to: Perl6 RFC Librarian's message of "4 Aug 2000 15:00:16 -" > Sender: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Message-id: <[EMAIL PROTECTED]> > Organization: Compugen, Ltd. > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > Precedence: bulk > Delivered-to: mailing list [EMAIL PROTECTED] > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald) > Lines: 57 > References: <[EMAIL PROTECTED]> > X-Authentication-warning: selena.compugen.co.il: ariels set sender to > [EMAIL PROTECTED] using -f > List-Post: <mailto:[EMAIL PROTECTED]> > List-Subscribe: <mailto:[EMAIL PROTECTED]> > List-Unsubscribe: <mailto:[EMAIL PROTECTED]> > List-Help: <mailto:[EMAIL PROTECTED]> > > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > [...] > > > This RFC proposes that the right operand of a C<..> operator > > may be omitted in a list context, producing a lazily evaluated > > semi-finite list. It is further proposed that operations on > > such lists also be carried out lazily. > > This would be nice, but I think should be folded into something more > general, like tieable first-class iterators. I'm still trying to pull > my thoughts together on this one, but lazy lists could be a special > case of iterators. I have an RFC coming on that :-) Damian
RE: RFC 22 (v1) Builtin switch statement
> Could a way be found to control the flow so that the next case (not always
> the one next in the order of the statment) could be executed? For example
> you have cases 1-10. You want all odd cases to also execute case 9 and the
> even cases to also execute case 10. So in case 3 you would say something
> like: pergo(9);
Not necessary.
switch ($val) {
case 3 { print "three"; goto odds }
case 4 { print "three"; goto evens }
odds: case __%2!=0{ print "that's odd" }
evens: case __%2==0{ print "that's even" }
}
Or for those who hate pasta:
sub odds { print "that's odd" }
sub evens { print "that's even" }
switch ($val) {
case 3 { print "three"; odds }
case 4 { print "three"; evens }
case __%2!=0{ odds }
case __%2==0{ evens }
}
Damian
Re: RFC 22 (v1) Builtin switch statement
> Does "goto odds" mean start evaluating all cases after the
> "odds:" label? Meaning that the below is equivalent to the above?
> I think this is what the original poster was asking; if not, I'd
> like to ask it!
That's exactly what it means.
>
> switch ($val) {
> case 3 { print "three"; goto morecases }
> case 4 { print "three"; goto morecases }
>
> morecases:
> case __%2!=0{ print "that's odd" }
> case __%2==0{ print "that's even" }
> }
Damian
Re: RFC 25 (v1) Multiway comparisons
> I suspect it already has a different meaning, based on operator > precedence rules, left to right evaluation, etc., but I strongly > doubt there is much use of it in that manner, and would encourage > this redefinition to be used instead. It's currently an error (even if you redefine operators so it should work!) It *does* have a different (and stupid) meaning in C, but let's not go there. Damian
Re: RFC 25 (v1) Multiway comparisons
> > > This RFC proposes that multiway comparisons such as:
> > >
> > > if ( 0 <= $x < 10 ) { print "digit" }
> > >
> > > should do what the user means.
>
> I think this should mean what it means in Icon, namely, that
> $x < $y evaluates to false if $x >= $y, and evaluates to
> "$y (but true)" if $x < $y. This allows the operators to be
> nested, i.e. $x < $y < $z would be ( $x < $y ) < $z, which
> performs the $y < $z comparison iff $x < $y.
I very much like Icon's failure model, but I was loathe to try and
graft it wholesale onto Perl 6. Doing it properly would require a
substantial rethink of the exception mechanism, flow control, the
nature of scalars, undef, etc., etc.
In the end I concluded that simple DWIMity on multiway comparisons
was enough.
But don't let that stop you counter-proposing the fuller mechanism. :-)
Damian
Re: RFC 22 (v1) Builtin switch statement
> This switch statement RFC seems to be built on the premise that the
> reason to have a switch statement is to remove a common parameter
> from the following limited form conditional expressions.
Yes. As I point out in the paper, that's the *nature* of a switch statement.
To distribute a test spatially, by factoring.
> However, while the table of 16 different ways in which two values
> could generate a match is interesting, it can only ever perform at
> most two operations per pair of types (depending on which type is
> found in which of the two positions).
Not so:
switch ($value) {
case 1 {...} # numeric equality
case "a"{...} # string equality
case $obj {...} # referential equality
case /pat/ {...} # pattern match
case %hash {...} # hash lookup
case [1..10]{...} # list inclusion
case __<100 {...} # subroutine return
}
Granted one would rarely want all these at once, but a non-trivial subset
is entirely plausible:
sub classify {
switch ($_[0]) {
case 0 { return 'zero' }
case \&odd { return 'odd' }
case [1..9] { return 'even' }
case /[a-f]/i { return 'hex' }
}
}
> I find it unlikely that the casual Perl programmer, and even many
> expert Perl programmers, will be able to usefully memorize the list
> of operations proposed for the type pairs. This inability to
> memorize the list will no doubt curl the corner of the switch page
> in the perl documentation.
No. The whole point is that they just DWIM.
> I think the fundamental purpose of the switch statement is to
> choose one (generally) of many cases, and that the factoring of one
> of the parameters is what gets in the way of having a rich set of
> matching operations.
Just selecting one from many alternatives is a cascaded if's job.
The defining characteristic of a switch the the factoring of some part
of the comparisons. And it's an important characteristic, because it
focussed the reader's mind on the commonality of the test.
> Hence, I think it suffices to have a single keyword for switch: not
> "switch", but "case". The block containing "case" would be the
> switch statement. "case" is simply a rename of "elsif" whose first
> occurrence in a block simply pretends to follow "if (0) {}".
If that's the consensus, let's just have elsif.
But I don't think that's the consensus.
I appreciate your comments, but I certainly intend to push ahead with
the proposed syntax -- as I proposed it. A very large number of people
like it as it is. If I'm wrong, let Larry kill it.
Damian
Re: RFC 23 (v1) Higher order functions
Thanks for the useful insights and pointers, Ken. Top stuff (as usual :-) I particularly liked the currying context and notions of explicitly marking curries. Obviously I'll need to de-jetlag a little more and run my brain over it again. However, implicit currying is so damn handy that I suspect that we'll just cheat and say that only pure assignment *doesn't curry*, so you have to write: my $summer = $sum += __; $root->traverse( $summer ); Or for the truly damned in the audience: $root->traverse( my $sum = $sum += __ ); Bwah-ha-ha-ha! Damian
Re: RFC 23 (v1) Higher order functions
> Unless I'm missing something here, you're not filling in the args correctly.
> I think you mean:
>
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ? $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die __
> : $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[3]
> ;
> };
Yup. Cut-and-paste errors. Serves me right for posting at 3am. %-)
> > Arguments other than the last can also be bound by the explicit use of
> > placeholders:
>
> What do you mean 'other than the last'. Isn't your example showing that
> _all_ the arguments can get bound?
Sorry, what I meant was that, you can bind trailing arguments, just by omitting
them. Non-trailing arguments have to be bound explicitly with an __.
Damian
Re: RFC 24 (v1) Semi-finite (lazy) lists
> > This RFC proposes that the right operand of a C<..> operator
> > may be omitted in a list context, producing a lazily evaluated
> > semi-finite list. It is further proposed that operations on
> > such lists also be carried out lazily.
> >
> Why only the right operand? What's wrong with @a[..1]?
>
> Of course then
> @negodds = grep { $_%2 } (..-1);
> needs to start at the top and work down, but that seems OK...
Possible. I'll add it in as a speculation and let Larry veto it :-)
Damian
Re: RFC 22 (v1) Builtin switch statement
> None of these perform more than one operation per pair of types. By doing the
> factoring, you are constraining the type and specific value of the left hand
> expression in your matching operation, limiting the set of operations that can
> be performed quite severely.
>
>[snip]
>
> In this proposal, it would be the commonality of the parameter, not the
> commonality of the test. The test includes parameters and matching operation.
> The type of the second parameter must be determined before the matching
> operation can be determined.
No. Because the switch value can be a curried function too, so you can factor the
operation as well:
switch ( $x < __ ) {
case 0 { print "negative" }
case 1 { print "unity" }
case any(2..9) { print "small" }
case @list { print "in range" }
}
> if ( $v == @foo )
>
> is clearly testing the size of foo against the value of $v.
That's not "clear" at all. It's a learned idiom that *isn't* obvious without
understanding. One might just as readily assume that comparison against
an array disjunctively distributes the comparison across the elements.
Of course, that way lies superpositions!
Sigh. We clearly differ irreconcilably on this issue. I suggest that you
counter-propose your version of case and we move on. Larry may well not like
either! ;-)
Damian
Re: RFC 22 (v1) Builtin switch statement
> Oh, the table thing. The switch statement is useful without learning the > complete table so I don't think complexity is a big problem. People can > learn what they need and ignore the rest. I agree with you that it might > be nice to have an array membership operator (like "in") so that you can > write: > > if ($x in [ 1, 2, 3 ]) ... if ( grep $x==$_, (1,2,3) ) ... Be nice if it would short-circuit in a boolean context though! Damian
Re: RFC 37 (v1) Positional Return Lists Considered Harmf
> =head1 TITLE
>
> Positional Return Lists Considered Harmful
>
> The solution is simple: return hashes instead of lists. Yes, one
> still has to know how the fields are named, so the proposed solution
> is still not perfect.
I *fully* support this idea. A suggestion though:
return hash (references) *as well as* lists.
I've proposed that the want() function will be able to distinguish
a HASHREF context (there the return value is used as a hash reference).
Retain the list return (which is convenient why one does know what
(caller(0))[4] does), and have the named return values returned via
a hash reference when such a context is active.
E.g.:
$package = caller; # scalar context
($package, $file, $line, $subname) = caller(0); # list context
$subname = caller(0)->{subname}; # hashref context
Damian
Re: Deep copy
> >Another one for my wish list: deep copying support built in. A devil
> >inside me thinks this should be a new assignment
> >operator. Damian? Sounds like this is up your alley. I want to do a
> >sanity check before taking up RFC space.
>
> Regardless of how this looks, it has some pretty significant ramifications
> for the internals. What, for example, should happen if you deep-copy a DBI
> object attached to an Oracle database?
I would say that encountering an "external component" such as a file handle
during a clone() should either shalow copy the component or else throw an
exception. Perhaps that should be configurable with a second parameter that
optionaly specifies a subroutine to be invoked on such a node (and whose
return value is used as the copied element):
# external component is fatal...
my $copy = clone($original, sub{ die "external component" })
# vs:
# external component is shallow copied...
my $copy = clone($original, sub{ $_[0] })
# vs:
# external component is deep copied...
my $copy = clone($original, sub{
system("cp $_[0] $_[0].clone");
DBI->connect($_[0].clone");
}
)
Damian
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
> On Sun, Aug 06, 2000 at 01:41:06PM -, Perl6 RFC Librarian wrote: > > > > $scalar = date; # scalar ctime date, same as current > > $object = date; # object with accessor functions (new) > > How are these distinguished? If $object is typed (my Date $object), then want() will be able to detect the difference. Damian
