Alan Burlison <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons wrote:
>
>> The tricky bit i.e. the _design_ - is to separate the op-ness from the
>> var-ness. I assume that there is something akin to hv_fetch_ent() which
>> takes a flag to say - by the way this is going to be stored ...
>
>I'm not en
On Thu, Sep 07, 2000 at 11:55:17PM -0600, Nathan Torkington wrote:
> Any more? I'm keen to learn from mistakes (preferably those of
> others, but my own will do in a pinch :-).
How about: If you make an earthshaking decision on day three of a
conference, do not announce it on day five. Wait unt
On Thu, Sep 07, 2000 at 11:14:34PM -0600, Nathan Torkington wrote:
> I view branches in this initial version as highly unlikely to be
> useful. We need to have a trunk before we can have branches.
I was actually speaking of both the initial development and on from
there. You don't need a trunk
So we're three weeks away from the end of this. I've been thinking
about where we went right and where we went wrong (and in particular,
what I would do differently if I had it to do again).
The biggest thing is that I underestimated the volume of traffic. I
never thought there'd be so many RFC
[I'll take off my black hat for a moment...]
Okay, this is the FIRST TIME I've ever seen indirect object syntax
used for anything useful. (That's praise, BTW)
I was going to suggest that KEYS and VALUES methods be added to tied
hashes, but this RFC makes it all moot. Well done.
[Black hat bac
Michael G Schwern writes:
> In effect, instead of having one development track, we could have many
> development tracks, each focused on a single feature, or small group
> of features. This should make work easier, because on each track only
> one thing is changing, so its easier to track down ne
Michael G Schwern writes:
> Could we split this off into a working group and mailing list seperate
> from perl6-meta?
Sure. I'm going to set an aggressive schedule for the decision,
though, because this has all the hallmarks of a religious war. Let's
work through the problems now and be forced
On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > There's one solution, now that we have a nifty source control stuff.
> > Branch like mad! Feature creep should be discouraged, but if a group
> > wants to go off and work on something which isn't go
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> my $a :shared;
>> $a += $b;
AB> If you read my suggestion carefully, you would see that I explicitly
AB> covered this case and said that the internal consistency of $a would
AB> always be maintained (it would have to be otherwise the int
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hash slicing
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 7 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 201
Version: 1
Status: Developing
=head1 ABSTRACT
a more
On Thu, Sep 07, 2000 at 10:52:18PM -0600, Nathan Torkington wrote:
> Then we can hear informed criticism and perhaps modify the plan if a
> better system is suggested.
Could we split this off into a working group and mailing list seperate
from perl6-meta?
--
Michael G Schwern http://www.p
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 07 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Num
Adam Turoff writes:
> 3) Those developers prefer Perforce and should not be forced
> to use CVS because non-committers prefer it.
>
> Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
sk
(We are not (quite) discussing what to do for Perl6 any longer. I'm
going though a learning phase here. I.e. where are my thoughts
miswired.)
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> Actually, I wasn't. I was considering the locking/deadlock handling part
>> of database engines
Michael G Schwern writes:
> There's one solution, now that we have a nifty source control stuff.
> Branch like mad! Feature creep should be discouraged, but if a group
> wants to go off and work on something which isn't going to make it
> into the next release they can branch and play.
That divi
(or "Allowing built-in functions to use loop blocks")
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting C, C, and C with C
(or "Allowing built-in functions to use loop blocks")
=head1 VERSION
Maintainer: Garr
Michael G Schwern writes:
> Okay, the example says on thing and the text of the proposal says
> another.
Sorry, I thought you were talking about a different section of code.
I'll resubmit tomorrow.
> So you're proposing that C act like C
> $hash{$_} } sort keys %hash>? I can live with that. Ju
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lightweight Threads
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Last Modified: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 178
Version: 3
Status: D
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Everything in Perl becomes an object.
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Updated: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
On Thu, Sep 07, 2000 at 10:22:17PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> I was expecting those two crufty features to be removed. If they
> aren't, a third won't hurt.
Might want to add this assumption to the RFC. Or perhaps another RFC
to junk reset()'s current meaning.
On Thu, Sep 07, 2000 at 10:15:38PM -0600, Nathan Torkington wrote:
> The hard part is probably going to be resisting the urge to add
> features just because they're possible: once we come up with a design,
> we must code the design, and leave new features for later 6.x
> releases. Feature creep c
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Predefined POD Streams are C, C, and C
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 9 Aug 2000
Last Modified: 7 Sep 2000
Number: 79
Versio
Michael G Schwern writes:
> > C should reset the hash iterator, instead of calling
> > C or C as is currently the case.
>
> Sounds good, except the name. reset() already does something.
> Currently, reset() is for clearing large swaths of global variables (a
> dubious feature) and for reseting ?
Michael G Schwern writes:
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
Well, yes, but a
> Shoot chop. and chomp. Unless you add unchop and unchomp.
C *has* an inverse.
Surely you know about the unary postfix C<.$/> operator?
Of course, you have to be careful. There's a known bug that
the C<.$/> doesn't properly "unchomp" if you've ever used the
C<$/&=``> operator.
;-)
Damian
On Fri, Sep 08, 2000 at 02:50:37AM +, Ed Mills wrote:
> Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
> a language with YES and no NO.
>
> Just kill then both.
Although I'm rather fond of symmetry, it's not inherently good.
Rather boring if overused.
I admit
>Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
>a language with YES and no NO.
By that criterion, you have zillions of other things to kill.
>Just kill then both.
I don't think this will win us friends.
--tom
> Ok, I'm not super familiar with threads so bear with me, and smack me upside
> the head when need be. But if we want threads written in Perl6 to be able
> to take advantage of mulitple processors, won't we inherently have to make
> perl6 multithreaded itself (and thus multiple instances of t
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
Just kill then both.
>From: Bryan C. Warnock <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Michael G Schwern <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: RFC 195 (v1) Ret
Does this discussion pertain to a particular RFC? If so, could the RFC
number please be quoted in the subject?
If it's not already RFC'd, who will volunteer to do it?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level
-Original Message-
From: Nick Ing-Simmons <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Jarkko Hietaniemi <[EMAIL PROTECTED]>; Dan Sugalski <[EMAIL PROTECTED]>;
Perl6-Internals <[EMAIL PROTECTED]>; Nick Ing-Simmons
<[EMAIL PROTECTED]>
Date: Thursday, September 07, 2000
On Thu, 07 Sep 2000, Michael G Schwern wrote:
> Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
Someone, (and I've lost who, exactly) was interested in taking those
off my hands for a String::Utils module.
I believe it was quite clear, however, that my root-and-measure-deri
Damian Conway wrote:
>
>> Both are pretty much the same. Combining them, I'd say that exceptions
>> should remain exceptional.
>
> I'd say short-circuiting a vector operation was exceptional enough. :-)
I'd say it's exceptional sometimes, and very ordinary other times, and
I'd prefer to
On Thu, 07 Sep 2000, Steven W McDougall wrote:
> RFC 1 proposes this model, and there was some discussion of it on
> perl6-language-flow.
Which is strange, since it was released for this group. Hmmm. But yes,
we did seem to hash out at least some of this before, which, to
Steven's credit, was
> Both are pretty much the same. Combining them, I'd say that exceptions
> should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
> Counterproposal: grep, map, etc. define two implicit magic labels
> 'ACCEPT' and 'REJECT' that behave in th
>Counterproposal: grep, map, etc. define two implicit magic labels
>'ACCEPT' and 'REJECT' that behave in the expected way, so you use
>($first_small) = grep { ($_ < 2) and last ACCEPT } @list.
Reminds me of "next LINE" in perl -p or perl -n.
--tom
Damian Conway wrote:
>
>> > I would propose that the C operation should short-circuit if the
>> > block throws an exception, with the value of the expection determining
>> > whether the final invocation of the block should accept the element it
>> > was filtering:
>>
>> Ot
> > 'Pends on whether you modulate them.
>
> KCHP 1570 on your AM dial!
Aw, not *another* one of those easy-listening Californian motor cop stations!
Damian
On Wed, Sep 06, 2000 at 06:40:10PM -, Perl6 RFC Librarian wrote:
> C should return what C currently
> returns.
Good.
> C should reset the hash iterator, instead of calling
> C or C as is currently the case.
Sounds good, except the name. reset() already does something.
Currently, reset() i
On Thu, Sep 07, 2000 at 06:48:35PM -0600, Tom Christiansen wrote:
> >Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
>
> 'Pends on whether you modulate them.
KCHP 1570 on your AM dial!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just A
>I found the following reference in the p5p archives to a paper
>discussing open source development. I think this should be mandatory
>reading for anyone contemplating a contribution to the RFC mountain.
Amongst other things, amongst other things
>http://www.firstmonday.dk/issues/issue4_10/
>On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
>> =head1 TITLE
>>
>> Retire chop().
>Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
--tom
> I don't think C should be able to eat unintentional exceptions.
> Perhaps it could short-circuit if the exception is 1 or false, as
> opposed to true or false?
No objection here.
Damian
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant
> Exactly the sort of chicanery grep/last is meant to avoid. So the question
> becomes, how do we crowbar "last" in without altering the returned value in
> C blocks. I'm for putting it after a comma. Which matches the syntax of
> John Porter's proposal about internally converting the block to a
On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote:
> I would propose that the C operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
I do
> I think there may be a necessity for more than just a work area to be
> non-shared. There has been no meaningful discussion so far related to
> the fact that the vast majority of perl6 modules will *NOT* be threaded,
> but that people will want to use them in threaded programs. That is a
> non
At 03:55 PM 9/7/00 -0700, Nathan Wiger wrote:
> > Merge all these variables into one. Say for the sake of argument that it
> > is C<$!> (for the mnemonic value of "something went bang").
>
>First off, nice RFC. :-) I've liked this for a while now but haven't
>commented on it.
>
>Though you don't
Damian Conway wrote:
> A C such as:
>
> @array = grep BLOCK LIST
>
> is equivalent to:
>
> @tmp = ();
> foreach (LIST) { push @tmp, $_ if do BLOCK }
> @array = @tmp;
>
> That similarity would not change in any way under the proposal
> (except to be made stronge
John Porter wrote:
> heh. for a normal sub,
>
> sub foo {
> return( 42 );
> }
>
> finds OMWTDI as
>
> sub foo {
> 42;
> last;
> }
>
> Somehow, this seems like very natural perl to me.
>
> --
> John Porter
I'd
On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> They have a catchy slogan for it. They call it the
>
>test --> code --> design
>
> development cycle.
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for swe
On Thu, Sep 07, 2000 at 05:31:37PM -0400, Bennett Todd wrote:
> 2000-09-07-17:11:50 Dan Sugalski:
> That's certainly possible, but since the reason we're gathered here
> together working on trying to launch perl6 is a collective belief
> that perl5 has become unmaintainable for further development
The "assignment from a lazy list" section of RFC 123 suggests a system
for requesting the first however many items out of a map or grep by
making it lazy and then assigning it to an array of that size.
"last" is more flexible, if you are looking for a condition more
complex than the first one,
Chaim Frenkel wrote:
> AB> I'm sorry, but you are wrong. You are confusing transactions with
> AB> threading, and the two are fundamentally different. Transactions are
> AB> just a way of saying 'I want to see all of these changes, or none of
> AB> them'. You can do this even in a non-threaded
Chaim Frenkel wrote:
> I don't see where you are differing from me.
>
> And different interpreters doesn't completely isolate threads from each
> other. You are simply giving each thread its own work/scratch area.
> With the internals rewrite it may not need to be a full interpreter.
I think th
Chaim Frenkel wrote:
> I'd like to make the easy things easy. By making _all_ shared variables
> require a user level lock makes the code cluttered. In some (I think)
> large percentage of cases, a single variable or queue will be use to
> communicate between threads. Why not make it easy for the
> Merge all these variables into one. Say for the sake of argument that it
> is C<$!> (for the mnemonic value of "something went bang").
First off, nice RFC. :-) I've liked this for a while now but haven't
commented on it.
Though you don't say so (or maybe I missed it), I'm assuming that $!
wil
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>
> TH> Well if we allow value changes in the middle of iterating either
> TH> keys or values then that is a user visible behaviour change which
> TH> potential
> > I would propose that the C operation should short-circuit if the
> > block throws an exception, with the value of the expection determining
> > whether the final invocation of the block should accept the element it
> > was filtering:
>
> Otherwise nice but until now die() ha
> I would propose that the C operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
Otherwise nice but until now die() has been a serious thing, now it
> If one were looking for the first matching item, last would work:
>
>grep { /pat/ and last } @foo
># return()s the value of $_=~/pat/, which will be true
Huh? I can't see how that could work unless you change the existing
semantics of C and C.
Let's take a step back and an
Bennett Todd wrote:
> So I ask again: do any _other_ projects,
> preferably ones that aren't regarded as procedural failures that
> need re-inventing from scratch, used perforce? Or is perl5, whose
> failure has brought us out today, its one poster project?
I think reports of perl5's death have
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> The problem with saying that perl should ensure that the operation "$a =
AB> $a + $b" is atomic is that it is an unbounded problem. When should $a
AB> be automatically locked and unlocked? At the beginning and end of the
AB> += op? at
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> Perl will have to do atomic operations, if for no other reason than to
>> keep from core dumping and maintaining sane states.
AB> I don't see that this is necessarily true. The best suggestion I have
AB> seen so far is to have each thre
Johan Vromans wrote:
> my $file_format = qf(
> @<: @
> $name, $ssn
> );
>
> Now, $file_format would be a Format object (compare this with qr//,
> that produces a Regex object).
or the proposed qs// which would produce a packed structure definition
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Chaim Frenkel wrote:
>> The problem I have with this plan, is reconciling the fact that a
>> database update does all of this and more. And how to do it is a known
>> problem, its been developed over and over again.
AB> I'm sorry, but y
Bennett,
Perforce is a better source code control system than the source
alternatives, and certainly better for the task we face than CVS.
You're certainly not forced to use it. You can, if you rather, grab
snapshot archives, rsync from the repository directory, or even grab a copy
of the sou
Damian Conway wrote:
>
> The expression C<1 and last> does *not* evaluate to true -- it does not
> evaluate to *anything*. So the C is terminated by the C
> without the block having ever evaluated true. So no element of LIST is
> ever "passed through". So the C evaluates to zero.
Right. Well, pe
Jarkko Hietaniemi wrote:
>
> How about using 'return', then? That could, ahem, return both true and
> false values.
Hmm. I think it boils down to the fact that we'd like a grep block
to have characteristics of both a subroutine and a true loop block.
Here's a proposal which would mostly elim
2000-09-07-17:11:50 Dan Sugalski:
> Perl 5's development issues have nothing to do with the code
> repository -- [...]
That's certainly possible, but since the reason we're gathered here
together working on trying to launch perl6 is a collective belief
that perl5 has become unmaintainable for fu
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>> The only real issue is if the change effects the iterator order. Changes
>> to values should be allowed without out any adverse effects.
TH> Well if we allow value changes in the middle of iterating either
TH> keys or values then that is a
At 11:49 AM 9/7/00 -0400, Bennett Todd wrote:
>2000-09-06-10:51:35 Dan Sugalski:
> > >Finally, most free software and open source projects have
> > >standardized on CVS. Do we really have a compelling reason to go
> > >against the standard?
> >
> > Perl 5 uses perforce, [...]
>
>I thought one of t
Bart Lateur wrote:
>
> On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote:
>
> >I think the -1 indexing for "end of array" came from there. Or at
> >least, it was in Perl long before it was in Python, and it was in Icon
> >before it was in Perl, so I had always presumed Larry had seen Icon
John Porter wrote:
>
> David L. Nicol wrote:
> >
> > A bareword inside doublequotes is not interpreted, in Perl or C.
>
> No; a "bareword" in quotes (any kind) is not a bareword.
>
> --
> John Porter
huh?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
I found the following reference in the p5p archives to a paper
discussing open source development. I think this should be mandatory
reading for anyone contemplating a contribution to the RFC mountain.
http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
Alan Burlison
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))
> How about qy() for Quote Yacc :-) This stuff is starting to look
> more and more like we're trying to fold lex and yacc int
> I think what is needed is something along the line of :
Joe McMahon and I are working on something along these lines.
On Thu, Sep 07, 2000 at 10:05:58PM +0200, Bart Lateur wrote:
> On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>
> >But it makes "short-circuit as soon as C
> >lets through a specific value" ugly:
> >
> >my $seen;
> >$has_odd_elem = grep { $seen && last; $_%2 && ++$s
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>But it makes "short-circuit as soon as C
>lets through a specific value" ugly:
>
>my $seen;
>$has_odd_elem = grep { $seen && last; $_%2 && ++$seen } @numbers;
Not just ugly. Useless.
--
Bart.
On Thu, Sep 07, 2000 at 03:42:01PM -0400, Eric Roode wrote:
> Richard Proctor wrote:
> >
> >I think what is needed is something along the line of :
> >
> > $re = qz{ '(' \$re ')'
> >| \$re \$re
> >| [^()]+
> > };
> >
> >Where qz is
> What would be useful, would be to leave REs the hell alone; they're
> great as-is, and are only getting hairier and hairier.
Amen!
> What would be useful, would be to create a new non-regular
> pattern-matching/parsing "language" within Perl, that combines
> the best of Perl
On Thu, Sep 07, 2000 at 08:20:42PM +0100, Richard Proctor wrote:
> I think what is needed is something along the line of :
>
>$re = qz{ '(' \$re ')'
> | \$re \$re
> | [^()]+
>};
>
> Where qz is some hypothetical new quoting s
Richard Proctor wrote:
>
>I think what is needed is something along the line of :
>
> $re = qz{ '(' \$re ')'
>| \$re \$re
>| [^()]+
> };
>
>Where qz is some hypothetical new quoting syntax
Well, we currently have qr{}, and ??{} do
On Wed 06 Sep, Mark-Jason Dominus wrote:
>
> I've been thinking the same thing. It seems to me that the attempts to
> shoehorn parsers into regex syntax have either been unsuccessful
> (yielding an underpowered extension) or illegible or both.
>
>SNOBOL:
> parenstring = '(' *parenstrin
John wrote:
> > I don't know how grep works internally. I don't know if grep pushes
> > elements into @a one at a time, or if it returns a finished list of
> > elements which pass the conditional block. If it is the latter as I
> > assume, a short-circuited grep would return a list o
Garrett wrote:
> It almost feels like grep could have been written like this (in
> another life): @a = grep (@b) { $_ > 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
> While I'm at it, I'm curious as to why:
>
> $a = 2;
> @b = (1,
At 09:17 PM 9/6/00 -0400, Steven W McDougall wrote:
> > leave the locking to the coder and keep perl clean.
>
>If we don't provide this level of locking internally, then
>
> async { $a = $b }
>
>is liable to crash the interpreter.
Nope.
ilock($b);
fetch($b);
iunlock($b);
iloc
At 03:02 PM 9/7/00 +0100, Nick Ing-Simmons wrote:
>Alan Burlison <[EMAIL PROTECTED]> writes:
> >Jarkko Hietaniemi wrote:
> >
> >> Multithreaded programming is hard and for a given program the only
> >> person truly knowing how to keep the data consistent and threads not
> >> strangling each other
Bart wrote:
> >The last operator doesn't return anything does it? It immediately
> >exits the loop/block in question.
This is correct.
> But then, what is the value that would be returned to grep()? If you use
> 0 as the last value evaluated inside the block, grep() would return an
Michael G Schwern wrote:
>
> On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> > I also think this may well be a good place to apply one of the ideas of XP
> > (Extreme Programming, a fairly flexible small-group software design
> > methodology), namely to write test cases *first* in
Garrett Goebel wrote:
>
> Let's see if I've got this straight. To paraphrase Damian's
> RFC 77 for reduce:
>
> If a C's block were terminated by a call to C,
> grep immediately returns the last block value (i.e. C
> on the first block call, $_[0] otherwise). Or maybe that's @_
> otherwise...
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
> >> > grep { $a > $_ and last } @b)
> >>
> >> So "last" should return true, or what?
> >
> >The last operator doesn't return anything does it? It
> >immediately exits the loop/block
"Myers, Dirk" wrote:
> $mode = 0755 ;
> $file = "Foobar" ;
>
> #include
> #include
>
> chmod($mode, $file) ;
>
> Which chmod gets called, perl or C? What are the rules for figuring this
> out?
>
> Dirk
Following the documentation at
http://www.pe
On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
>> > grep { $a > $_ and last } @b)
>>
>> So "last" should return true, or what?
>
>The last operator doesn't return anything does it? It immediately exits the
>loop/block in question.
But then, what is the value that would be retur
2000-09-05-10:53:25 Dan Sugalski:
> >I don't think it's a good idea to build Perl6 development
> >infrastructure around non-free software.
>
> I don't think we should make decisions about the software we use
> for development based on political views. The decisions should be
> based on technical
The phrase "die a horrible death" clearly reads that something was
a bletcherous botch--a terribly brain-damaged mistake, if you
would--and so must necessarily be expurgated from the language.
For example, when Larry said, "...this does not mean that some of
us should not want, in a rather dispas
Nick Ing-Simmons wrote:
> The tricky bit i.e. the _design_ - is to separate the op-ness from the
> var-ness. I assume that there is something akin to hv_fetch_ent() which
> takes a flag to say - by the way this is going to be stored ...
I'm not entirely clear on what you mean here - is it someth
Mark-Jason Dominus wrote:
>
> Larry said:
>
> # Well, the fact is, I've been thinking about possible ways to get rid
> # of =~ for some time now, so I certainly don't mind brainstorming in
> # this direction.
>
> That is in
> <[EMAIL PROTECTED]>
>
> which is archived at
>
> ht
> > 2. Many people - including Larry - have voiced their desire
> > to see =~ die a horrible death
>
> Please provide a look-up-able reference to Larry's saying that he
> wanted to =~ to die horrible death.
Larry said:
# Well, the fact is, I've been thinking about possible ways to get
From: Tom Christiansen <[EMAIL PROTECTED]>
Sent: Thursday, September 07, 2000 11:20 AM
> Which can of course be written in an immeasuably more legible fashion
> using current Perl, a little-known language:
>
> ($name) = split /\s+/, $name;
> $string = quotemeta($string);
> @array =
1 - 100 of 126 matches
Mail list logo
