Re: This week's summary
Hi Piers, Before you're deluged... > What's Ponie? Ponie is 'Perl On New Internal Architecture' Err, no, because then it would have been Ponia (presumably the singular feminine). The project is definitely Ponie (the neuter plural). And, for the record, the retro-acronym was actually: 'Perl on New Implementation Engine'. ;-) 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
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: Just reading up on Pike...
On Fri, 16 August 2002, Luke Palmer wrote: > I want superpositions too :). But, what would this mean? > > my all(str, int) $foo; > #... That you need some *serious* psychotherapy! ;-) Actually, it would mean that $foo can only contain values whose type is simultaneously C and C. That is, $foo can only contain something like C. Damian
Re: Just reading up on Pike...
On Sat, 17 August 2002, Nicholas Clark wrote: > But how on earth would you implement such a thing? :-) I imagine that type specifiers require that values assigned to the corresponding variable satisfy: value.isa(type). Using a superposition as a type means that the result of that test comes back as a superposition too. If that returned superposition is true, the assignment proceeds. Damian
Re: Just reading up on Pike...
Aaron Sherman wrote: > So, > > my all(str, int) $foo = $!; > > would be fine? I'd expect so. > I'm forgetting what has been said about $! Typically contains an object with both string and integer conversions. Whether convertability to both types is enough to satisfy a superpositional type is an interesting question. I suspect it *is*. Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote:
> I think this is a big step towards readability. It allows you to put
> whatever part of the expression wherever you want (reminiscent of
> Latin);
You didn't think Perligata was just for *fun*, did you? ;-)
> It's a shame <~ is ambiguous. It's a lexical ambiguity, which can be
> solved with whitespace
...and the longest token rule.
And, of course, it's no more ambiguous than the ~~ operator:
foo ~~ $bar # means: foo() ~~ $bar
# not: foo( ~ ~$bar )
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
Re: Deep copy
> That's cool. I can also see calling a package's CLONE sub if you're > cloning something blessed into it. I like it. And CLONE is preferred to the specified (2nd arg) handler. > Presumably it'd get the original > as a parameter and return the new thing, or something of the sort. Thinking about it, it should get a reference to the original and return a reference to the new value. Damian
Re: Deep copy
> I *really* like this idea. There should also be a default CLONE for > the majority of classes that just want ordinary deep copying on > whatever object representation they're using. UNIVERSAL::CLONE. Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
I think I opened a bigger can of worms than I intended :-) As MJD as pointed out to me in private email, if we are serious about this feature, we probably want to go the whole hog and look at Haskell's notion of list comprehensions. See http://www.haskell.org/tutorial/goodies.html specifically, section 2.4.1. NOTE: MJD didn't *support* any of this, he merely pointed it out. Personally, I intend only to update the RFC to include the *possibility* of (..$x) and (..). I'm reasonably sure Larry will kill the whole thing -- I think I might too, were I in his place ;-) Rather than continue to argue the details, why don't people post some examples of code where they feel these lazy lists might be useful, and let's see if there aren't already good alternatives. Damian
Re: RFC 23 (v1) Higher order functions
> > $root->traverse( $sum += __ );
>
> There's a syntactic ambiguity here. I assumed that __ "poisons" an
> expression so that an entire parse tree gets transformed into a
> closure. If you isolate the parse tree based on expression precedence,
> then I'm not sure why the += example works.
Sorry, I finally found a moment to sit down and clarify this point.
The error was not here but in:
__ < 2 + __ * atan($pi/__) or die __
That should of course have been:
__ < 2 + __ * atan2($pi, __) or die __
(I meant to write it that way, but my brain has a mind of its own sometimes!)
A __ only "poisons" an expression/sub call if it is a direct operand/argument.
So:
atan($pi/__)
is:
atan( sub{$pi/$_[0]} );
whereas:
atan2($pi,__)
is:
sub{ atan2($pi,$_[0]) };
I'll make it clearer in version 2 of the RFC.
Damian
Re: RFC 37 (v2) Positional Return Lists Considered Harmf
> The solution is simple: return hashes instead of lists. I still think returning lists *or* hashrefs according to context gives the same benefits *plus* backwards compatibility. Damian
Re: RFC 49 (v1) Objects should have builtin string SCALA
> >STRINGIFY would have my vote. "It's a string!!!". A string is a very
> >specific subtype of scalar.
>
> How about TO_STRING? Little less geeky.
AS_STRING. It doesn't convert, it translate.
Or just STRING. It's a verb to, you know ;-)
> How would this play with overload.pm? What if that also specifies a
> stringify routine? Which one should win?
Operator overloading is scheduled to be revamped.
It might well be that, rather than specifying q{""}, q{0+}, and q{bool},
we have:
package MyClass;
sub STRING {...}
sub NUMBER {...}
sub BOOLEAN {...}
H. Maybe even:
sub op+ {...}
sub op* {...}
sub op<=> {...}
#etc.
Shades of C++! ;-)
Damian
PS: This would tie in very nicely with my forthcoming multimethods proposal.
Re: RFC 23 (v1) Higher order functions
> But the expression
>
> __ < 2 + __ * sin(__ / 2) or die __
>
> curries to
>
> sub { $_[0] < 2 + $_[1] * sin(sub { $_[0] / 2 }) or die $_[2] }
>
> That's very odd.
No. You got it exactly right. :-)
> I really hope I'm missing something, but __ the way you use it
> is too magical. It's not DWIM but DWISHMIIKWIWD (do what I should
> have meant if I knew what I was doing).
Perhaps.
> Your original statement that an ad hoc curried expression stops
> at a simple assignment sounds fine to me. (It actually fits in
> very well with functional programming which avoids assignment.)
>
> If that rule is modified by an explicit subroutine prototype that
> establishes a curry context then I think we can make this stuff
> work.
Okay. I'll try that in the next version of the RFC.
Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Okay. I'll rework the proposal with the consensus syntax. Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
I concur with Mike. If we *have* to have a prefix (and I *still* prefer a naked __, gumble, grumble, pout), then I'd certainly rather ^ that &. What we *really* need are some more types of brackets: $range = Ç__È < ÇvalÈ && ÇvalÈ < Ç__È; ;-) Damian
Re: Language RFC Summary 4th August 2000
> >> It definitely is, since formats do things that can't be done in modules.
> >
> >Such as???
>
> Well, the easy binding of variables for later use. When one declares a
> format, variables in it are saved for later use without needing refs.
> Formats are sort of like a quote where the variables are referenced rather
> than interpolated when defined, with the values pulled (and possibly
> altered) when the quote is used.
What I'm planning to RFC is a simple format() built-in (probably in a pragma)
very similar to the form() subroutine described in:
I would envisage that the correct way to set up the kinds of
referenced-not-interpolated templates is by creating a subroutine or closure:
sub format1 {
format "> >>> [",
$bullet,
$text;
}
which you can then interpolate at need:
print format1;
Alternatively, one could make the format nicely parametric using higher-order
functions:
my $format2 =
format "> >>> [",
__, __;
and later:
print $format2->($magic_bullet, $special_text);
or partially fill it in:
my $format3 = $format2->($magic_bullet);
I'll get to work on the format RFC as soon as possible, so that you can
see what I mean.
> :) I promised Kirrily that I'd race you in the RFC count...
That's hardly fair on you: I can just pull any crazy idea out of my head
whereas *you* have to be able to implement yours! :-)
Damian
Re: Language RFC Summary 4th August 2000
> What I'm planning to RFC is a simple format() built-in (probably > in a pragma) very similar to the form() subroutine described in: http://www.csse.monash.edu.au/~damian/TPC/2000/Autoformat/paper.html Damian
Re: Language RFC Summary 4th August 2000
> It definitely is, since formats do things that can't be done in modules. Such as??? > If they yank formats out (which is just dandy by me) that means > that some means of providing format's functionality needs has to > be designed in. I'm working on it. Damian
Re: Treating filehandles like strings
...and as for matching regexen against streams, I have a more general proposal for matching against subroutines that should allow for that as a special case. Damian
Re: RFC 53 (v10) Built-ins: Merge and generalize C
> Can anyone come up with a good example when you'd want to use both these > parameters at the same time? Second "foo" after the last "bar": index $text, "foo", index($text,"bar",0,-1), 2); Damian
Re: RFC 54 (v1) Operators: Polymorphic comparisons
> > This RFC proposes that numeric comparison operators default to stringwise > > comparison when both arguments are non-numeric strings. > > > The problem with this, is that we're removing orthogonality from the > language. ROTFL. > Do we want to say: > $num1 == $num2 works > $string1 == $string2 works > $string1 eq $string2 works > $num1 == works > $num1 eq breaks? No, this last one still works. Damian
Re: RFC 54 (v1) Operators: Polymorphic comparisons
> This seems to be adding a special case. (I.e. only if _both_ are
> non-numeric will it switch to a cmp operation.)
Well, I'd prefer it to always switch, but I thought that might be argued
against. Since, *this* is being argued against, maybe I'll extend my proposal
:-)
> I currently fail to switch to 'eq' many times when I should, but the
> failure mode is obvious. Her the failure mode will be really strange.
I would claim that the failure mode is not obvious: "dog"=="cat" is true
I often need a generic comparison test (typically for equality of less-than),
and to get it one has to jump through hoops:
sub generic_eq {
my $failed;
local SIG{__WARN__} = { $failed = 1 };
return $_[0] eq $_[1] || $_[0]==$_[1] && !$failed;
}
I want generic equality to DWIM. I.e. are these the same (for some
reasonable value of "same").
And "dog"=="cat" is not a reasonable value of "same".
Damian
RE: Deep copy
> >There are a wide range of tricky problems associated with deep > >copy and deep compare. I like the idea, but circular references > >can make this problematic even without external things > >(filehandles, dirhandles, objects from non-perl sources) are > >thrown in. That needs to be taken into account when putting > >together the RFC for it, if someone even does. > > I don't want it to go undocumented; I can write an RFC since I > started the thread, or Damian can write it since he brought up > clone() before that. I defer to Damian. I'm polluting the mailing list enough, as it is! :-) Why don't you write it up and run it by me. Damian PS: I'd like to see it correctly handle cyclic data structures too!
Re: Safer OO inheritance
> I'm more in favor of a mechanism that makes it easy to build field
> names from the package name, for those rare cases where you want
> scoped fields. There were discussions about this a couple of years ago
> on p5p. For example:
>
> package Foo;
>
> sub new { bless { "${CURRENT_PACKAGE}name" => 'Simpson' ... }
>
> ...where $CURRENT_PACKAGE is a special variable automatically set
> to...guess what? ;-)
See the Tie::Securehash module for a variation on this theme.
Also note that I will be proposing something similar in my
general revamp of Perl OO (RFCs galore, probably next week).
Damian
Re: RFC 53 (v10) Built-ins: Merge and generalize C
> > $last = index $string, $substring, -1, -1; # last occurence > > Err... shouldn't that be > > $last = index $string, $substring, 0, -1 # last occurrence > $first = index $string, $substring, -1, -1 # first occurrence found ># in a perverse way > > Or am I seeing double negatives where I shouldn't? No. You're missing the fact that the third argument of rindex specifies the last character at which the match can be found (as opposed to index's third arg which specifies the *first* character from which to search) Damian
Re: RFC 55 (v1) Compilation: Remove requirement for fina
> Anyway, There is at least one case where you need this true value: if > the file accidently is empty (or equivalent). I've had that happen. > > A true value indicates that the file is indeed valid Perl. So is an empty file! :-) Damian
Re: RFC 55 (v1) Compilation: Remove requirement for fina
> On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: > > > > A true value indicates that the file is indeed valid Perl. > > > >So is an empty file! :-) > > That is precisely the problem. You won't get a syntax error if this > happens. > > Now, bringing in the million monkeys typing, again: the chances of > getting a corrupt file that yet is valid Perl source file, is *far* > greater, if empty files are allowed as well. > > Empty files won't return a true value. > > Say you accidently erase the contents of some module file. The > requirement of it returning a true value will immediately warn you where > things went wrong. So require and do issue a warning if they require or do an empty file. Better that than meaningless 1;'s at the end of every module. Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> As for the regexp issue, just to clarify there's only one ambiguous case
> we need to work out that I can see:
>
>/.*^foo/; # ok
But:/.*^foo/m; #ambiguous
> We could undo the ambiguity like so:
>
>/^{foo}/; # like ${foo} and @{foo} and %{foo}
>
> In fact, this seems built-in if we follow the same var conventions. We
> can make ^ bind to {} as tightly as we need.
That would be the right solution. And of course one could use the {} anywhere
necessary or desirable:
my $sin_deg = sin(180*^{_}/$pi);
Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> And there's no argument about having anonymous, positional, and named > placeholders in the redraft...? There's *always* arguments! ;-) Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. Damian
Re: RFC 55 (v1) Compilation: Remove requirement for fina
> If there's a warning if a require'd or use'd file is empty, that's more > than good enough for me. Already added to V2 of the RFC. Damian
Re: Things to remove
> Most of the requests for deletion seem to begin with, "This isn't > used..." > > To which, "*I* use it." is a very valid argument. Agreed. The real problem with ?...? is that it complicates the hell out of the parser. So long as the special magic is retained for m?...?, I would suggest that raw ?...? could beneficially disappear. Damian
Re: RFC 23 Higher order functions
> It strikes me that this is very fragile and limited (unless I > misunderstand, which is quite possible). We've thrashed out a much more comprehensive proposal, which I'll post this morning. Damian
Re: Overloading && ||
> Damian Conway <[EMAIL PROTECTED]> writes: > >Operator overloading is scheduled to be revamped. > > While I remember - it would be good if overload mechansim > could be extended to cover && and || as well as & and | > with the class deciding if short-circuit happens. Oh, definitely. I need lazily evaluated args for that, but (of course) there's an RFC in the pipeline to cover that too :-) Damian
Re: RFC 76 (v1) Builtin: reduce
> Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL.
>
> Assuming a "use tristate", undef + number = undef
>
> This might require that the reduce function be able to ignore undefs.
> Either always under the tristate pragma. Or on a case by case basis.
I'm not sure how this would affect the proposal. If an item in the list being
reduced is undef, it appears in the reduction subroutines arg list as undef.
The reduction subroutine can then handle it (or not) as it chooses.
For example, to short-circuit if the reduction ever becomes undef:
$sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;
> Also you haven't specified if the arguments to reduce are evaluated
> lazily.
Good point. They should definitely be Virtuous. :-)
Damian
Re: Overloading && ||
> No. I don't want to see && or || and not know whether it short-circuits > without looking in the class interface. My brain is conditioned through > years of C and Perl to expect that they always short-circuit. This is too > venerable a semantic to change. Please. What if I want to overload && and || so that they help built an expression tree, rather than immediately evaluating? Damian
Re: Overloading && ||
> >What if I want to overload && and || so that they help built an expression > >tree, rather than immediately evaluating? > > Is it worth the damage it will cause to fragile brains like mine? "Pain is the weakness leaving your body!" ;-) > I have often wondered whether a language could allow user-defined > operators. The fact that none have done it should be a clue :-) I guess > it's getting too incestuous with the lexer. User-defined operators are a can of rattle-snakes that I *seriously* recommend we don't open. Damian
Re: Overloading && ||
> Of course, by the time Damian's done, perl won't actually *do* > anything--you'll need to fire off another window and do a "kill > -HEYYOUGETMOVING 23442" to actually make something happen... Actually, the plan is exactly the opposite. By the time I'm finished everything will be done...in constant time! Damian
Re: RFC 73 (v1) All Perl core functions should return ob
> I'm nervous about these different contexts. I thought scalar vs list
> was confusion enough. Now we're talking about overloading even
> further? We need to think VERY long and VERY hard about this before
> thinking it's a good thing.
Well, I have, and I do.
(Though I'm no longer sure whether that's an argument for or against! ;-)
The problem is not multiple contexts; it's inconsistent return values.
That is, there's no way of guessing what a particular "listish" function
-- such as map, each, reverse, etc. -- will return in a scalar context,
without actually *knowing* what it's defined to return).
In some senses additional contexts actually help, by improving DWIMity.
If I can say:
my $month = date->{month};
then I'm much more confident what I'm going to get back. As opposed to:
my $what = date;
which might return epoch seconds as an integer, or a date string, or a
hash- or array ref, or the number of elements in the date array :-(
With extra contexts I can be surer:
my $yesterday = date() - 86400; # reasonable to expect epoch integer
my $today = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()->{DoY} + 1; # reasonable to expect hash ref
Damian
Re: RFC 54 (v1) Operators: Polymorphic comparisons
> > I first thought that "==" and "eq" were cut from the same cloth as
> > "||" and "or" that is the difference was precedence. Then I learned.
>
>
> Mr. Scott's experience is evidence for a strong argument AGAINST operator
> overloading.
Huh???
I draw exactly the opposite conclusion: If "==" were overloaded to
automatically Do The Right Thing for numbers vs strings as operands,
there would have been no confusion in the first place!
> If we allow object types, and allow object types to overload,
> we lose the clarity we have in a language that doesn't have
> these things.
>
> Maintaining code with perl5 package-modules is difficult enough, but
> at least all the object method calls are explicitly object method
> calls and there aren't any object method calls masquerading as
> well-understood builtins!
So these:
$vec4 = $vec1->add($vec2->unit->cross_product(
$vec3->unit)->dot_product($vec1->unit);
$diff = Math::BigFloat->new((Math::BigFloat->new((
Math::BigFloat->new((Math::BigFloat->new($China{gdp}
->fmul($China{gdp_incr})))->fdiv(Math::BigFloat->
new($China{pop}->fmul($China{pop_incr})->fsub(
Math::BigFloat->new(Math::BigFloat->new($USA{gdp}->
fmul($USA{gdp_incr})))->fdiv(Math::BigFloat->new(
$USA{pop}->fmul($USA{pop_incr})))->fabs());
are better than these:
$vec4 = $vec1 + ~$vec2 x ~$vec3 . ~$vec1;
$diff = abs(
($China{gdp}*$China{gdp_incr})/($China{pop}*$China{pop_incr})
- ($USA{gdp}*$USA{gdp_incr})/($USA{pop}*$USA{pop_incr})
);
Surely not?
Operator overloading can certainly be abused (hey, I'm building a career
on that! ;-), but it can also significantly *improve* the maintainability
of code, when used correctly.
In other words: it's just like *every* other feature of Perl.
Damian
Re: RFC 76 (v1) Builtin: reduce
> Actually, it would be easier to do in reduce, the undefs should
> simply be ignored.
>
> Otherwise having the user code it, becomes
>
>{ defined $_[0] && defined $_[1] ? $_[0] + $_[1]
>: defined $[0] ? $_[0] : $_[1] }
>
> Pretty ugly.
>
> And for the N case, it gets even uglier. So reduce should be able
> to supply the next N-1 defined() values.
$def_sum = reduce { $_[0]+$_[1] } grep {defined} @numbers;
Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
> I'm looking forward to the upcoming writeup :-). I'm thinking of recanting the whole RFC! :-) Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
> > I'm thinking of recanting the whole RFC! :-) > > <*checking etymology*> hmmm . . . "recant" . . . "recant" . . . > doesn't that mean to sing the whole thing over again? Literally: "to sing a different tune". :-) > Seems to me that while putting hooks in the core to allow this sort > of thing might be worthwhile, infinite lists are not likely to be > commonly used and so probably should go into a module. Agreed. I hereby bequeath the rewrite to someone else. Damian
Re: RFC 73 (v1) All Perl core functions should return ob
> DC> Urgh. If you want lazy eval, say so explicitly:
>
> DC> sub somesub (?@) {
> DC> my @foo = @_;
> DC> }
>
> Where do you want the lazy specified -- on the caller or the callee?
> Or should it be available to both? (and of course the opposite
> eval{}, to make it evaluate the arguments immediately.)
The RFC I'm writing specifies that if the subroutine being called has
a lazy context specifier on a given argument, that argument is only
evaluated when the value of the corresponding element of @_ is fetched,
stored, or eval'd.
So the subroutine that's being called is the one that decides.
But, of course, lvalue subroutines give you the ability to impose the
choice externally as well. If you need to pass a lazy argument to a
normally non-lazy subroutine, you could just write:
sub enervate (?$) : lvalue { $_[0] }
And then:
non_lazy( a(), enervate(b()), c() );
Damian
Re: RFC 67 (v1) Deep Copying, aka, cloning around.
> > > Why would it be necessary to deep copy a CODE reference? > > > > It might not be necessary. I'm still learning how to write kosher Perl... > > elegance is a long way off for me. > > Imagine storing your code along with your data in a database for use > later (persistent objects) See also: the Class::Classless module. Damian
Re: RFC 73 (v1) All Perl core functions should return ob
> >> An object that has many different -ify methods: > >> stringify > >> numify > >> hashify > >> listify > >> objectify (!) > > > > Possible, but blech. > > Why is that more blech? Because it's "heavy". However, if Dan assures me that objects will have lower overheads in Perl 6, I will happily withdraw my "blech". :-) Damian
Re: Overloading && ||
> We may be able to fake it with source filters and parser abuse, though. I'm intending to write RFCs on revamping source filters, and also on run-time access to the parse tree. Just as soon as I grow those two extra hands so I can run that second keyboard in parallel. Damian
Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t
> Instead of calling the right thing or actually doing the right thing, > AUTOLOAD subroutines should return a coderef which will be run as if > it were the method called. If an AUTOLOAD subroutine does not wish to > cope with a method call, it should return undef. Perl would then walk > the OO hierarchy and find the next AUTOLOAD to call, eventually failing > with an error if no AUTOLOAD method is found which will accept the call. A more general solution is to allow the AUTOLOAD to resume the dispatch process. My forthcoming RFC on revamped subroutine dispatch will cover this. I don't *dislike* your proposal, except that it interposes another layer of indirection on a process that is already too slow. > =head2 $AUTOLOAD > > While we're at it, it *may* be a good idea to remove the global > $AUTOLOAD variable and instead pass it as the first parameter of the > AUTOLOAD subroutine call. For: general global drought, the fact that > perlsub's argument "because, er, well, just because, that's why..." is > a bit weak. Against: makes AUTOLOAD more complicated, breaking the > "subroutine parameters end up as @_" paradigm (apparently). This, I really like. > =head2 UNIVERSAL->can > > This proposal has the added bonus that the UNIVERSAL->can method (or > whatever replaces it) will now work with AUTOLOAD-ed methods, whereas > in Perl 5 it used to fail. But how would it know whether a particular AUTOLOAD can handle the requested method without calling that AUTOLOAD and seeing what it returns? Oh, I get it: it *would* call every AUTOLOAD it found until one of them returned something? If so, the RFC ought to explain this explicitly. Damian
Re: RFC 73 (v1) All Perl core functions should return ob
> Why push it through a user subroutine. Might as well make it part of the
> core language.
Why exacerbate the core, when I one-line user sub can do it?
> Why add another keyword non_lazy. though it isn't an antonym, eval{}
> has the right meaning and effect.
No, "non-lazy" was just some ordinary subroutine that I was enervating an
argument for. It certainly isn't part of the proposal.
> I can see the utility of having the callee specify the alacrity of the
> parameter. But this would put quite a burden on the parser/runtime engine.
>
> Package A and B both define a function foo. A->foo has non-lazy arguments
> B->foo has lazy arguments. Then
>
>$fooA = new A;
>$fooB = new B;
>
>$fooA->foo
>$fooB->foo
>
> What is a poor perl parser to do?
Ignore the prototype unless $fooA and $fooB are typed lexicals.
I.e. act just like it does now.
Damian
Re: RFC 76 (v1) Builtin: reduce
> I don't see it.
>
>1 == f((reduce +, undef), 1) == reduce +, undef, 1
undef isn't an empty list, it's a one element list.
Consider the other "common" reduction:
sub f { $_[0] * $_[1] }
Now:
f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0
But
reduce \&f, (), 1 == 1 # list flattens to (1),
# single element immediately returned
> I really would like to be able to pass around an empty list and get
> a _reasonable_ answer. Having to check the list for emptyness before
> passing it in just seems dirty. One doesn't have to do this for anyother
> looping operator in the language.
>
>for (@empty) {}
>grep {} @empty
>map {} @empty
None of which *combines* its (possibly non-existent) values together.
> AS> Also, the RFC should specify that the function is always evaluated in
> AS> a scalar context (for things to make sense).
>
> Why? reduce should be able to reduce a set of matrices to a matrix. Or
> actually any aggregate (plural whatzit).
>
> I think this is too limiting.
>
> Depending upon the context reduce should return undef, an empty list,
> or other empty plural whatzit.
H. I need to see more debate on this before I decide what to propose
in the next version of the RFC.
Damian
Re: RFC 76 (v1) Builtin: reduce
> By writing @sum = reduce __+__ 0, @numbers > you deal elegantly with both cases. > > NOTE: I find this trick very elegant. I wish it were my trick, > instead of Damian's... Damian wishes it were Damian's, but is sure it's at least a few hundred years old :-) Damian
Re: RFC 76 (v1) Builtin: reduce
> Couldn't reduce return a list just through concatenating its elements? For
> instance:
>
> @a = (1,3,2,4,3,6,4,8);
> @sum = reduce( (^total, ^x+^y ), @a ); # (4,6,9,12)
Currying placeholders are scalars, so you want:
@sum = @{reduce (@^total, ^x+^y ), [], @a };
More and more I lean towards a scalar-only reduce.
Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
multidimensionals.
Damian
Re: RFC 73 (v1) All Perl core functions should return ob
> Hmm, would it be too nasty for perl to recognize that all foo's have the > same prototype? (Consider the singular foo case.) Probably. Remember that the programmer can always C or C and completely change inheritance hierarchies. Anyway, the overloading functionality you want will be available via multimethods, when I get around to writing that RFC. Damian
