Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation

Bart Lateur <[EMAIL PROTECTED]> writes: > OK, how about this idea then. && and || still work as they did, but you > provide a callback method (say, TRUTH or BOOLEAN) that says whether this > particular object is true or false. So: You don't take into account using && and || to build trees for la

Does Perl need true constants? (was Re: RFC 83 (v1) Make constants look like variables)

> How about any variable created in UPPER case is a constant? Well, Perl does something similar now, just that they're not readonly. But as everyone knows messing with @ISA, %ENV, BEGIN, FETCH, etc, etc, etc will definitely alter your program. Do we really need constants in Perl? I've always won

Re: RFC 94 (v1) Rename @ARGV to @ARGS

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: [...] > =head1 TITLE > > Rename @ARGV to @ARGS Renaming is a good idea. But @ARGS has one disadvantage: it's a plural form. Arrays usually have the singular name of their contents (yes, "ARGument Vector" manages to break that too); the plural

Re: RFC 90 (v1) Builtins: zip() and unzip()

Dave Storrs <[EMAIL PROTECTED]> writes: > On Fri, 11 Aug 2000, Damien Neil wrote: > > > On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > > > I think I like plow() or maybe just weave() > > > > weave() and ravel()? > > > > - Damien [...] > The word "r

Re: RFC 74 (v1) Proposal to rename C and C

> point: the convention of the upper case name indicates that they > probably will be called automatically. "import" does not adhere to that > convention. Don't get me wrong, I'm all for it. I just thought the RFC glossed over some important details so was trying to clarify some facts. They shoul

Re: RFC 83 (v1) Make constants look like variables

At 11:07 AM 8/12/00 +1000, Jeremy Howard wrote: >My current thinking is that a ref to a constant should only be possible >through creating a constant first, and then creating a reference to that >separately. What, like: $foo = \5' which you can do in perl 5 right now. (Basically a scalar's c

Re: Suggested meaning for (0..), (..0), and (..)

Buddha Buck wrote: > There has been some discussion recently about lazy-evaluated semi-infinite > lists. The biggest point of disagreement is over lists of the form (..n) > and (..), i.e., semi-infinite lists bounded from above and semi-infinite > lists which are unbounded. > > I believe there ar

Re: RFC 91 (v1) Builtin: partition

Nathan Wiger wrote: > Let me make an observation, having done tons of matrix stuff: We're > going to wind up with 200 functions, all of which essentially are doing > special types of matrix operations. > > How about a matrix-like set of functions that interleaves and > un-interleaves stuff however

Re: RFC 91 (v1) Builtin: partition

> Buddha Buck wrote: > > Or... Let's say you had a 3x3 array implemented as follows: > > > > @array = ( a1, a2, a3, > > b1, b2, b3, > > c1, c2, c3 ); > > > > unzip(3,@array) would return the columns. > > partition(3,@array) would return the rows. > > > Nice example!

Re: RFC 91 (v1) Builtin: partition

Buddha Buck wrote: > Or... Let's say you had a 3x3 array implemented as follows: > > @array = ( a1, a2, a3, > b1, b2, b3, > c1, c2, c3 ); > > unzip(3,@array) would return the columns. > partition(3,@array) would return the rows. > Nice example! I think this better go

Re: RFC 90 (v1) Builtins: zip() and unzip()

Philip Newton wrote: > Would it not be more natural to pass the *number* of lists to unzip, > rather than the desired length? This way, unzip() would know to pick off > elements two-at-a-time, three-at-a-time, etc., rather than having to go > through the zipped list, count the elements, divide by

Re: RFC 83 (v1) Make constants look like variables

Steve Simmons wrote: > I really like the idea of constants in perl, but think the RFC should > go a lot further. C/C++ has solved this problem; we should follow in > their footsteps. > <...> I desparately _don't_ want to follow the horrible mess that is const in C++. The enormous hassle in trying

hash to hash reduction operator

I now you all will kill me for this but here goes.. this is slow: foreach (keys %h) {if (/some regex/) {$h2{$_}=$h{$_}} } In other words, extract a new hash from an existing one by searching for primary keys matching a regex. (Please don't get off on your solutions to this or syntax c

Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)

Chaim Frenkel wrote: > A nice way of making a value read-only is lovely. And let it be a > runtime error to modify it. > > The caller can easily do a &foo eval{$const_item} to remove the > read-only attribute. > > Hmm, perhaps we should rename the attribute > :read-only > Can't we make a value 'tr

Re: RFC 80 (v1): Exception objects and classes for builtins

Chaim Frenkel wrote: > > [ ... ] for me polymorphism is action-at-distance of the worst > stripe. Its the cheap and dirty way of doing OO. [...] I see > very little reason to have two methods with different signatures. Method signatures and polymorphism are orthogonal. The latter refers to diff

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

I guess I shouldn't use printed docs for anything in these discussions. I looked that up on paper, and it really does (did) say "synonym". But things change. I'd tell you what version of paper I looked it up on, but the paper doesn't seem to have recorded its version number. Perl 5.something.

Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation

On Sat, 12 Aug 2000 05:44:54 +1000 (EST), Damian Conway wrote: >And people, seeing every other operator overloaded for a particular >module, will assume that || and && do the right thing too. > >But they won't :-( OK, how about this idea then. && and || still work as they did, but you provide a

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

On Fri, 11 Aug 2000 15:27:03 +0200, Bart Lateur wrote: >I kinda like it. I'm not sure any more if I still like it as much. As proposed, it seems very unperlish (as we know Perl today). It would virtually turn Perl into a whole different language. Well, half a different language. ;-) I, too, ha

Re: RFC 85 (v1) All perl generated errors should have a

Chaim Frenkel wrote: > > > "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: > > NW> Also, how about just $@->id? Shorter and I would argue the "unique_" is > NW> really redundant (id's are usually unique, hence the name > NW> "identifiers"). > > Not really. > > Consider: Chaim is an identi

Re: RFC 83 (v1) Make constants look like variables

From: "Nathan Wiger" <[EMAIL PROTECTED]> Sent: Friday, August 11, 2000 1:58 AM > How would this take into account stuff like this: > >sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644); This is completely the problem of the module that exports O_RDWR. O_RDWR could still be defined as a sub tha

Re: RFC 74 (v1) Proposal to rename C and C

On Fri, 11 Aug 2000 02:38:24 -0700, Nathan Wiger wrote: >The problem with this is that they rely on the indirect object notation, >same as new(). So: > > import Module; # calls Module->import > new Module;# calls Module->new > bob Module;# calls Module->bob > >So impor

Re: RFC 85 (v1) All perl generated errors should have a

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Also, how about just $@->id? Shorter and I would argue the "unique_" is NW> really redundant (id's are usually unique, hence the name NW> "identifiers"). Not really. Consider: Chaim is an identifier. But not unique. -- Chaim Frenkel

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Sat, Aug 12, 2000 at 07:22:01AM +1000, Damian Conway wrote: > dwim @results, dwim $stuff, @args, %hey; > > Can you say 'Lisp'? Lithp Michael (who couldn't resist) -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --

Re: we might as well give up now: CobolScript(R)

On Fri, Aug 11, 2000 at 04:48:12PM -0500, David L. Nicol wrote: > It's a vast and contrived joke, right? If it is, someone has really gone into some trouble: http://www.cobolscript.com/samples.htm > Jarkko Hietaniemi wrote: > > > > We will never conquer the world with Perl 6: > > CobolScript(

Re: we might as well give up now: CobolScript(R)

It's a vast and contrived joke, right? I like the way the "check out the (xx) page" links tend to link to exactly the page you are looking at Jarkko Hietaniemi wrote: > > We will never conquer the world with Perl 6: > CobolScript(R) got there before us. > > http://www.cobolscript.com/

Suggested meaning for (0..), (..0), and (..)

There has been some discussion recently about lazy-evaluated semi-infinite lists. The biggest point of disagreement is over lists of the form (..n) and (..), i.e., semi-infinite lists bounded from above and semi-infinite lists which are unbounded. I believe there are some reasonable semantics

Re: RFC 80 (v1): Exception objects and classes for builtins

Chaim Frenkel wrote: > > Let the object determine the calling convention for the method. > I see very little reason to have two methods with different signatures. Yes! That's the Perl philosophy! Right on! -- John Porter

Re: RFC 94 (v1) Rename @ARGV to @ARGS

This one is off-base. Too much history with @ARGV. I'll be constantly having a typo. This one is anti-"current community". > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> This and other RFCs are available on the web at PRL> http://dev.perl.org/rfc/ PRL> =head1 TITLE PR

Re: Self-Sorting Containers

> > tie %thehashinquestion, 'Sorted', flubber(^a,^b); > > > > ??? > > > > Damian > > > Compiler will know to pass flubber as ref-to-code instead of > intant eval because (^a,^b) instead of ($a,$b), or is more, > like \&flubber needed here? I was using the HOF

Re: Self-Sorting Containers

On Fri, 11 Aug 2000, David L. Nicol wrote: > I've started talking about "containers" instead of arrays and hashes > since those both tie directly to implementation details, and containers > are abstractions. [...] > > If hashes normally had a sort method of null, they would work normally, > bu

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

Damian Conway <[EMAIL PROTECTED]>: > > This RFC proposes the introduction of a new data type -- the I -- and > the co-opting of the => operator to act as a pair constructor. Most existing > uses of => would be preserved. >[etc.] > %hash = ( a=>1, b=>2, 'c', 3 ); > > does what it does in

Re: Self-Sorting Containers

Damian Conway wrote: > >> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b}) >> >> What is a better syntax for this? > > tie %thehashinquestion, 'Sorted', flubber(^a,^b); > > ??? > > Damian Compiler will know to pass flubber as ref-to-code instead of intant eval

Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)

At 05:09 PM 8/11/00 -0400, Chaim Frenkel wrote: >Hmm, perhaps we should rename the attribute > :read-only Works, though I like "constant" (or const, that's OK) just as much. Might be worth having a way to set things to read-only temporarily, too. Won't help the optimizer, but it could k

Re: Self-Sorting Containers

At 03:44 PM 8/11/00 -0500, David L. Nicol wrote: >If hashes normally had a sort method of null, they would work normally, >but you could overload the sort method of any hash with > >methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b}) > >What is a better syntax for this? Overload t

Re: RFC 80 (v1): Exception objects and classes for builtins

> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes: PC> Good OO programming practice. Use polymorphism to replace switches. Then PC> when you subclass one of your classes you don't have to go 'round PC> rejigging the switch statements. I haven't used OO in anger. But for me polymorphism is ac

Re: RFC 90 (v1) Builtins: zip() and unzip()

> In fact, perl really only needs one OP: > >@results = dwim $stuff, @args, %hey; > > (Well, I guess that's two: the assignment is an op also.) dwim @results, dwim $stuff, @args, %hey; Can you say 'Lisp'? Damian

Re: Self-Sorting Containers

> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b}) > > What is a better syntax for this? tie %thehashinquestion, 'Sorted', flubber(^a,^b); ??? Damian

Re: RFC 90 (v1) Builtins: zip() and unzip()

At 04:36 PM 8/11/00 -0400, John Porter wrote: >Damian Conway wrote: > >> Note that cleave is its own antonym! :-) > > > > I can see it now: > > > > @interspersed = cleave(@list1, @list2, @list3) > > @separated= cleave(3,@interspersed); > > > > Now *that's* DWIM! ;-) > >In fact

Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote: >> Someone on this list (TomC?) has supplied a major diatribe against const. DS> Maybe, but I don't see what's wrong with: DS> my $foo :const = 12; DS> A nice, named, lexically scoped con

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

Nathan Wiger wrote: > ...if the "key" and "value" builtins were the only ways to > get to the data. You should be able to get to the data directly. How about: $array[0].k $array[0].v -- John Porter

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

Damian Conway wrote: > > The proposed C and C built-ins (or the extended C and > C) would be used on a pair reference: > > print key $array[0];# or perhaps: print keys $array[0]; > print value $array[0]; # or perhaps: print value $array[0]; What's the point?

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[EMAIL PROTECTED] writes: : p52p6 would handle it (by translating all Perl 5 C"y">'s to Perl 6 : C<'x',"y">'s. : : I *must* put this in the RFC! I think most of the RFCs could use a MIGRATION POLICY section, or some such. Larry

Re: Portable upper/lower case regexp matches

Peter Scott wrote: > >Perl 5.6.0 has [[:lower:]] and [[:upper:]]. > > Yes, but this one is worth a digraph. Question is, which one? Currently > the free ones are: > > \F \h \H \i \I \j \J \k \K \m \M \o \O \q \R \T \v \V \y \Y > > \v \V are being debated on p5p currently. > > I s

Re: RFC 79 (v2) Perl Compiler is Just Another Pod Proces

Glenn Linderman wrote: > But you need to discuss the initial condition: I'd guess you need >. > =end all begin perl I like it! > This would restrict data from containing lines beginning with =, or at > least lines > beginning with =end, =begin, =handle, or =for. Could "escape" with \= >

Re: RFC 95 (v1) Object Classes

Andy- Wow, this is a huge RFC. I read it, but could you please explain briefly how this is different from a special type of package syntax? It seems to me the . Java notation is the biggest salient feature of the RFC. Looks like the rest is just a modification/reinvention of Perl's current packa

Self-Sorting Containers

I've started talking about "containers" instead of arrays and hashes since those both tie directly to implementation details, and containers are abstractions. A self-sorting container would be easy enough to tie to, most methods would inherit from an underlying numbered array, except the ins

Re: the currying operator

> I like the idea of currying, it seems powerful and Perlish in many > ways. However, I don't like the currying operator chosen, because > of it's ugliness (IMHO), and its potential for ambiguity (human, > not necessarily parser). It's not an operator, it's a placeholder. > So,

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

> But... would it be possible to exten this proposal so that, if the right > hand operand is an array or hash variable, it will create a reference to > this variable? > > That would allow subroutine calls like: > foo('names' => @names, 'size' => 'A4', 'labels' => %labels)

Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation

> Then, we could simply write our own versions of shortcutting AND and OR. > The difference would be that it would look like a function, not like an > operator. Compare: > >expr1 && expr2 > vs. >AND(expr1, expr2) > > but at least, there would be no confusion WR

Re: RFC 76 (v1) Builtin: reduce

> A better example might be trying to perform join, with reduce eg > > reduce __.','.__ $identity, @list > > Which would not work for any value of $identity unless you did > > reduce __.','.__ shift @list, @list > > which is probably a good example why not to req

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

> > @array = ( a=>1, b=>2, 'c', 3 ); > > > > assigns four elements (not six) to @array. > > But won't this cause breakage to existing scripts No. p52p6 will simply translate: x => 'y' to 'x', 'y' > > Note that these semantics still support the popul

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

> but in the case of > > sub demo ($name, %options) {...} > > what does > > demo($var, name => $value); > > do ? Named parameters are processed first, and any remaining parameters then assigned. So $name gets $value and %options gets $var (which generates an "Od

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

> I kinda like it. It's... intuitive. It makes named sub arguments rather > straightforward, apart from that prefix thing. > > Should (name => 'Bart') really stuff 'Bart' into a lexical variable > $name? That's... odd. Not really. If (name=>'Bart') is an arg list, it probably stuf

Re: RFC 90 (v1) Builtins: zip() and unzip()

> Note that cleave is its own antonym! :-) I can see it now: @interspersed = cleave(@list1, @list2, @list3) @separated= cleave(3,@interspersed); Now *that's* DWIM! ;-) Damian

Re: RFC 90 (v1) Builtins: zip() and unzip()

Damian Conway wrote: >> Note that cleave is its own antonym! :-) > > I can see it now: > > @interspersed = cleave(@list1, @list2, @list3) > @separated= cleave(3,@interspersed); > > Now *that's* DWIM! ;-) In fact, perl really only needs one OP: @results = dwim $stu

Re: RFC 83 (v1) Make constants look like variables

Please, please, please, PLEASE, let us not replicate the debacle that is C++'s const modifier! Damian

Re: RFC 79 (v2) Perl Compiler is Just Another Pod Proces

Nice. But you need to discuss the initial condition: I'd guess you need an implicit =begin perl before line 1 of each script file, so that scripts that don't pod still work. How about some extensions, which integrate another old perl5 feature? Instead of __END__, how about =begin data Now t

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

Buddha Buck <[EMAIL PROTECTED]> writes: > UT and UTC are different scales, ref: > http://tycho.usno.navy.mil/systime.html I believe, as reflected on that page, that UT isn't a time scale in and of itself, but a system of them (including UT0, UT1, and UTC as a weird step-child based on TAI with c

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

On Fri, 11 Aug 2000, Nathan Wiger wrote: > > Adding support for (modified) Julian Date will be much more > > generic and remove dependency on unix epoch with little > > extra code. > > To me, the real question is which date() should we use: > >$date = date $seconds_since_epoch; # uses tim

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

> Adding support for (modified) Julian Date will be much more > generic and remove dependency on unix epoch with little > extra code. To me, the real question is which date() should we use: $date = date $seconds_since_epoch; # uses time() $date = date $modified_julian_date; # non-Unix

Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation

Bart Lateur <[EMAIL PROTECTED]> writes: > Actually, we don't need it. All we need, is lazy evaluation. > > The idea comes from Lisp, where you have a possibility to create > ordinary looking functions (in Lisp, there's no difference between a > function and an operator; the less polite name is "

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

At 05:59 PM 8/10/00 -0700, Glenn Linderman wrote: >Perl6 RFC Librarian wrote: > > > The => operator would cease to be a > > first-argument-stringifying comma operator > >I find nothing in the documentation that suggests that => is anything >other than a >plain comma operator, yet you call it a "f

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

At 11:52 AM 8/11/00 -0700, Russ Allbery wrote: >Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > > s/gmt/ut/ > > > IIRC GMT got obsoleted in the 70s by UT (Universal Time). > >Officially called UTC, so utcdate would be a better name I think. UT and UTC are different scales, ref: http://tycho.usn

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

> =head2 Date Arithmetic > > Date arithmetic has been axed from this proposal. Before you get too > upset, I had discussions with several people and became convinced that > this is something too difficult and bloated to stick in core. An > external module would be much better suited to this. We

Re: RFC 83 (v1) Make constants look like variables

On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote: > How about any variable created in UPPER case is a constant? This involves Perl dictating style to the user. Very un-Perllike, IMHO. Michael -- Administrator www.shoebox.net Programmer, System Administrator

Re: RFC 91 (v1) Builtin: partition

On Fri, 11 Aug 2000, Nathan Wiger wrote: > Let me make an observation, having done tons of matrix stuff: We're > going to wind up with 200 functions, all of which essentially are doing > special types of matrix operations. > > How about a matrix-like set of functions that interleaves and > un-in

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

On 11 Aug 2000, Russ Allbery wrote: > Nathan Wiger <[EMAIL PROTECTED]> writes: > > > The problem is, many people on this list claimed that GMT != UTC, > > Correct. > > > and that machine time is only in GMT, making UTC dicey to derive. > > Nope. Other way around. Machine time is only UTC; G

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

Nathan Wiger <[EMAIL PROTECTED]> writes: > The problem is, many people on this list claimed that GMT != UTC, Correct. > and that machine time is only in GMT, making UTC dicey to derive. Nope. Other way around. Machine time is only UTC; GMT has fractional skew instead of leap seconds, making

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > s/gmt/ut/ > IIRC GMT got obsoleted in the 70s by UT (Universal Time). Officially called UTC, so utcdate would be a better name I think. -- Russ Allbery ([EMAIL PROTECTED])

Re: RFC 91 (v1) Builtin: partition

> The difference is how they group: > > @unzipped_list= unzip(3, (1,2,3,4,5,6)); # ([1,3,5],[2,4,6]) > @partitioned_list = partition(3,(1,2,3,4,5,6)); # ([1,2,3],[4,5,6]) Let me make an observation, having done tons of matrix stuff: We're going to wind up with 200 functions, all of wh

Re: Portable upper/lower case regexp matchesre and procedures

Dave Storrs writes: : Here's my question of procedure: plenty of times on these lists, : I see something that I think is a really good idea. I don't want to waste : bandwidth by posting just a "me too!", but I also don't want the idea to : die because no one weighed in in support of it. I

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Fri, 11 Aug 2000, Damien Neil wrote: > On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > > I think I like plow() or maybe just weave() > > weave() and ravel()? > > - Damien > Unfortunately, ravel has two opposite meanings (according to www.m-w.c

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

> So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan', > 'Feb') or qw(dummy Jan Feb)... oh well. Far better, use the new builtin object methods: $d = date; print "today is ", $d->date('%A'); # Friday > Apparently, neither is hour. And why not, pray? I'd like to see t

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

On 11 Aug 2000, Perl6 RFC Librarian wrote: >=head1 TITLE > >Replace localtime() and gmtime() with date() and gmtdate() Since GMT is specific to the UK and UTC (Universal Time, Coordinated) is the global equivalent, shouldn't the names be date() and utcdate()? >=head1 VERSION > > Maintainer: N

Re: RFC 85 (v1) All perl generated errors should have a

On 10 Aug 2000 22:26:47 -, Chaim Frenkel <[EMAIL PROTECTED]> wrote: > =head2 Encodings > > I have listed some possiblities. But none of these are ideal. > > =head3 A unique number > =item As an integer > =item As a floating point number > =head3 Unique String > =head3 Prefixes for all error

Re: Portable upper/lower case regexp matchesre and procedures

>From the Perl6-language list: On Thu, 10 Aug 2000, Bart Lateur wrote: > On Thu, 10 Aug 2000 17:21:44 +0300, Jason Elbaum wrote: > > > \x match lowercase alpha char > >\X match uppercase alpha char > > You've got my vote, apart from one tiny detail: \x is already in use.

RE: RFC 90 (v1) Builtins: zip() and unzip()

Graham Barr: > I know other languages call it zip, but personally I dislike that name > as zip() is commonly used with reference to compression. Although > I do not have a good alternative. Personally, I'd like join() to do this: @a = (1,3,5) ;

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

* Philip Newton ([EMAIL PROTECTED]) [12 Aug 2000 03:47]: [...] > So if we're now on 1-indexing, we'll see lots of @months = (undef, > 'Jan', 'Feb') or qw(dummy Jan Feb)... oh well. Perhaps a method should be added: $t->monthstr() which would return the month as a shortened form (qw/Jan Feb .../)

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote: > I think I like plow() or maybe just weave() weave() and ravel()? - Damien

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Fri, 11 Aug 2000, Brad Hughes wrote: > Andy Wardley wrote: > > > fold() and unfold()? > > > > merge() and cleave()? > > collate() and ...? > Sure, and if it throws an exception you get a papercut().

Re: RFC 90 (v1) Builtins: zip() and unzip()

Andy Wardley wrote: > > > I know other languages call it zip, but personally I dislike that name > > as zip() is commonly used with reference to compression. Although > > I do not have a good alternative. > > fold() and unfold()? > > merge() and cleave()? > > A collate() and ...?

Re: RFC 83 (v1) Make constants look like variables

On Fri, 11 Aug 2000, Andy Wardley wrote: > > Spinning off from Larrys syntactic comment and Mike > > Pastores example, how about some of the following: > > How about any variable created in UPPER case is a constant? > > Quite restrictive, and likely to screw many things up, admittedly, > but

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

On 11 Aug 2000, Perl6 RFC Librarian wrote: > In the past, Perl has provided access to date and time information > through the C library C and C functions. > Unfortunately, these functions have several "really bad things" about > them: > >1. some values are 0-indexed while others are 1-indexe

RFC 95 (v1) Object Classes

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Object Classes =head1 VERSION Maintainer: Andy Wardley <[EMAIL PROTECTED]> Date: 11 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 95 =head1 ABSTRACT This RFC proposes a s

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Fri, Aug 11, 2000 at 06:25:07PM +0100, Andy Wardley wrote: > > I know other languages call it zip, but personally I dislike that name > > as zip() is commonly used with reference to compression. Although > > I do not have a good alternative. > > fold() and unfold()? People would confude that

Re: RFC 83 (v1) Make constants look like variables

> Spinning off from Larrys syntactic comment and Mike > Pastores example, how about some of the following: How about any variable created in UPPER case is a constant? Quite restrictive, and likely to screw many things up, admittedly, but it's an easy rule to remember and one which is generally

Re: RFC 80 (v1): Exception objects and classes for builtins

On Fri, Aug 11, 2000 at 10:26:25AM -0700, Peter Scott wrote: > At 10:34 AM 8/11/00 -0400, John Porter wrote: > >But I'm against the idea of implicit rethrowing in any case. > > > >Sure, other languages do it, but perl doesn't, and personally I think > >it's a better paradigm. > > We may have to d

Re: RFC 76 (v1) Builtin: reduce

On Fri, Aug 11, 2000 at 10:51:45AM -0400, John Porter wrote: > Damian Conway wrote: > > > > More and more I lean towards a scalar-only reduce. > > Yep! Have you stollen my brain :) Graham.

Re: RFC 94 (v1) Rename @ARGV to @ARGS

On 11 Aug 2000, Perl6 RFC Librarian wrote: > @ARGS is a better choice for several reasons: > >1. It's closer to a word and so is faster to read [1] > >2. It's easier to explain and remember "Your command-line > args are contained in @ARGS" > >3. When you say "$var = $ARGS[2]"

Re: RFC 90 (v1) Builtins: zip() and unzip()

Andy Wardley wrote: > cleave()? Note that cleave is its own antonym! :-) -- John Porter

Re: RFC 90 (v1) Builtins: zip() and unzip()

> Builtins: zip() and unzip() Think of some other names, please. -- John Porter

Re: RFC 90 (v1) Builtins: zip() and unzip()

On 11 Aug 2000, Perl6 RFC Librarian wrote: > its arguments. C would reverse this operation. [...] > In order to reverse this operation we need an C function: > > @zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6) > @unzipped_list = unzip(3, \@zipped_list); # ([1,3,5], [2,4,6]) Would it not

Re: RFC 85 (v1) All perl generated errors should have a

> well, if it is only a string, why use . as the separator? use something > else like : and no one will try any fancy math tricks on it. Agreed. I like :, it's a common separator. Also, how about just $@->id? Shorter and I would argue the "unique_" is really redundant (id's are usually unique, h

Re: RFC 90 (v1) Builtins: zip() and unzip()

> I know other languages call it zip, but personally I dislike that name > as zip() is commonly used with reference to compression. Although > I do not have a good alternative. fold() and unfold()? merge() and cleave()? A

Re: RFC 80 (v1): Exception objects and classes for builtins

At 10:34 AM 8/11/00 -0400, John Porter wrote: >But I'm against the idea of implicit rethrowing in any case. > >Sure, other languages do it, but perl doesn't, and personally I think >it's a better paradigm. We may have to disagree. If you don't have a clause to catch an exception, semantically,

Re: RFC 90 (v1) Builtins: zip() and unzip()

On Fri, Aug 11, 2000 at 10:06:38AM -0700, Nathan Wiger wrote: > > I know other languages call it zip, but personally I dislike > > that name as zip() is commonly used with reference to compression. > > Ditto, I really dislike zip() and unzip(). They're PC and even UNIX > commands on several platf

Re: RFC 83 (v1) Make constants look like variables

I really like the idea of constants in perl, but think the RFC should go a lot further. C/C++ has solved this problem; we should follow in their footsteps. Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: A constant struct with constant val

Re: RFC 91 (v1) Builtin: partition

At 05:33 PM 8/11/00 +0100, Graham Barr wrote: >On Fri, Aug 11, 2000 at 03:36:21PM -, Perl6 RFC Librarian wrote: > > This and other RFCs are available on the web at > > http://dev.perl.org/rfc/ > > > > =head1 TITLE > > > > Builtin: partition > > > > =head1 VERSION > > > > Maintainer: Jeremy

Re: RFC 90 (v1) Builtins: zip() and unzip()

> I know other languages call it zip, but personally I dislike > that name as zip() is commonly used with reference to compression. Ditto, I really dislike zip() and unzip(). They're PC and even UNIX commands on several platforms now, increasing confusion. Here's two names: mix() and unmix(). It

Re: RFC 48 (v2) Replace localtime() and gmtime() with da

> > Replace localtime() and gmtime() with date() and gmtdate() > > I think to be politically acceptable to all that should be utcdate() Me too. Actually, this was my first choice, believe it or not. The problem is, many people on this list claimed that GMT != UTC, and that machine time is only

  1   2   >