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

Chaim Frenkel <[EMAIL PROTECTED]> writes: > One thing that isn't addressed in any of the exception RFC's (and it > may not be appropriate) is how to actually use it. Not in the syntactical > or semantic meaning. But in how to use it practically. > > Given six lines of code within a trapping cont

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

Graham Barr <[EMAIL PROTECTED]> writes: > Damian Conway <[EMAIL PROTECTED]> writes: > >Leon Brocard writes: > >> =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 > >> paramet

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

> =head1 TITLE > > Replace => (stringifying comma) with => (pair constructor) > > =head1 VERSION > > Maintainer: Damian Conway <[EMAIL PROTECTED]> > Date: 10 August 2000 > Version: 1 > Mailing List: [EMAIL PROTECTED] > Number: 84 I like this a lot, especially the way it deals with s

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

Damian Conway <[EMAIL PROTECTED]> writes: >> Are the two values of a pair restricted in anyway? All your examples >> were scalar. > > Yes. The two components must be scalars. > The key is stringified iff it's a bareword. > Otherwise no restrictions. So assuming pairs are scalars...

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

I think the whole idea of overloading the '&&' and '||' operators is too farfetched. It's and incredibly dangerous can of worms, precedence rules changing, shortcircits not working, etc. Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, where you have a possi

Re: RFC 76 (v1) Builtin: reduce

On 11 Aug 2000 09:30:03 +0300, Ariel Scolnicov wrote (and quoted): >> reduce &avg $identity, @list >This was my first point regarding C -- not all functions have >an identity element. One should note that in general > >(reduce &avg $x,@list) != (reduce &sum 0,@list)/@list > >for I valu

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

On Thu, Aug 10, 2000 at 06:43:30PM -0400, Chaim Frenkel wrote: > > "GB" == Graham Barr <[EMAIL PROTECTED]> writes: > > GB> On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote: > >> Nice. > >> > >> The continue clause, I assume would re-raise an uncaught exception. > >> But, a big b

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

On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote: > So I'm thinking: > > eval { ... > } catch Exception::Foo { >... > } catch Exception::Bar, Exception::Baz { >... > } catch { >... # everything else, but if this block is absent, uncaught exceptions ># head up the ca

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

On Thu, Aug 10, 2000 at 07:47:47PM -0600, Tony Olekshy wrote: > With the approach proposed in RFC 88 (Structured Exception > Handling Mechanism), you could write that as: > > try { > } catch { > switch ($_[0]->name) { > case IO { ... } > case Sock

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

On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote: >I find nothing in the documentation that suggests that => is anything other than a >plain comma operator, yet you call it a "first-argument-stringifying comma >operator". In fact, the documentation explicitly claims "=>" is a synonym of

Re: RFC 76 (v1) Builtin: reduce

On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote: > Okay, then for > > reduce &avg $identity, @list > > What should $identity be? I would like to see what &avg would be, given that each time it would be passed the previous result (or the first element) and the next element.

Re: RFC 76 (v1) Builtin: reduce

On Fri, Aug 11, 2000 at 01:20:36PM +0200, Bart Lateur wrote: > I think we don't really need reduce(). There are well working, > relatively simple, and *far more transparent* alternatives, at least, > for Perl. We do have OP= operators, after all. For example: > > $total = 0; > map { $

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

On Thu, Aug 10, 2000 at 10:21:37PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Replace => (stringifying comma) with => (pair constructor) > > =head2 Pairs and arrays > > When a pair reference is assigned

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

On Fri, Aug 11, 2000 at 11:24:48AM +1000, Damian Conway wrote: > This can be correctly handled. The named parameter's context specifier > would be propagated to the right operand of the =>. So: > > sub demo ( $name, \%options ) {...} > > will accept: > > demo(options=>%myopts, name

Re: the currying operator

On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote: > Mike- > > Jeremy's got a great explanation of this, which I'll paraphrase, but the > discussion went through lots of iterations. Think of the ^ as a carat or > thumbtack, holding the place for later variables. Then, consider the > pa

Re: the currying operator

Graham Barr <[EMAIL PROTECTED]> writes: > On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote: > > Mike- > > > > Jeremy's got a great explanation of this, which I'll paraphrase, but the > > discussion went through lots of iterations. Think of the ^ as a carat or > > thumbtack, holding t

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

> "Glenn" == Glenn Linderman <[EMAIL PROTECTED]> writes: Glenn> No, but the documentation for strict is some of what I reread Glenn> before making a fool of myself arguing with Damian, and it says Glenn> nothing about barewords, as far as I could read. Even this part? ... strict subs

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

At 02:29 PM 8/11/00 +1000, Jeremy Howard wrote: >Dan Sugalski wrote: > > The syntax is actually: > > > >my type $varname; > > > > This is in perl 5.6.0. Modifiers go as attributes after the colon: > > > > my Dog $spot : constant = new Dog; > > >Yes. But what about types and attributes within

Re: the currying operator

On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote: > > /^_/ > > > > What is that matching ? > > We've done this. It's matching a string that begins with '_'. Which is > why, if you want to disambiguate you do /^{_}/ just like you do with > variables. No that won't work either. Tha

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

On 10 Aug 2000 22:21:37 -, Perl6 RFC Librarian wrote: >Replace => (stringifying comma) with => (pair constructor) >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 preserve

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

On Thu, 10 Aug 2000 19:29:29 -0700, Glenn Linderman wrote: >Thanks for the clarification in your intentions, but isn't _any_ bareword is >converted to a string, unless it is in some particular context where a bareword is >meaningful (such as filehandle)? So that seems to be nothing unique to =>.

Re: the currying operator

Graham Barr <[EMAIL PROTECTED]> writes: > On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote: > > > /^_/ > > > > > > What is that matching ? > > > > We've done this. It's matching a string that begins with '_'. Which is > > why, if you want to disambiguate you do /^{_}/ just like yo

Re: the currying operator

> "Graham" == Graham Barr <[EMAIL PROTECTED]> writes: Graham> No that won't work either. That matches the string {_} But that's arguably a DWIMmy thing, since {} is in the category of * + and ?, which always need to be *after* something, and there's no *something* here. I don't know how muc

Re: the currying operator

On Fri, Aug 11, 2000 at 02:03:47PM +0100, Graham Barr wrote: > On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote: > > > /^_/ > > > > > > What is that matching ? > > > > We've done this. It's matching a string that begins with '_'. Which is > > why, if you want to disambiguate you do

Re: the currying operator

On Fri, Aug 11, 2000 at 02:52:32AM -0700, Nathan Wiger wrote: > Mike- > > Jeremy's got a great explanation of this, which I'll paraphrase, but the > discussion went through lots of iterations. Think of the ^ as a carat or I only make this annoying and pedantic point because everyone I have seen

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

I'm leaning to splitting identifier from the classification. A pure monotonically increasing integer would ensure the non-reuse. And the classification scheme could evolve seperately. Using numbers for the classification scheme would require a translation table. So why not just use alphanumeric

Re: the currying operator

Piers Cawley wrote: > Graham Barr <[EMAIL PROTECTED]> writes: > > On Fri, Aug 11, 2000 at 01:47:12PM +0100, Piers Cawley wrote: > > > > /^_/ > > > > > > > > What is that matching ? > > > > > > We've done this. It's matching a string that begins with '_'. Which is > > > why, if you want to disamb

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

Graham Barr wrote: > > > If we're really talking about new keywords, we wouldn't need a ; at the end > > of the last block; it's only needed at the moment because eval is a > > function, not a keyword. I would vote for the keywords only because people > > are going to forget the ; otherwise.

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

Piers Cawley wrote: > > The (continue|always|finally|whatever) clause will *always* be > executed, even if one of the catch clauses does a die, so you can use > this to roll back the database transaction or whatever else was going > on and restore any invariants. Which makes me think that it wou

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

On Fri, Aug 11, 2000 at 10:34:00AM -0400, John Porter wrote: > I support the idea of renaming the block eval as die, and leaving eval ^^^ That would be interesting :) > for string eval. > > But I'm against the idea of implicit rethrowing in any

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

> On Fri, Aug 11, 2000 at 10:34:00AM -0400, John Porter wrote: > > I support the idea of renaming the block eval as die, and leaving eval Crimonentlies! I meant "try", of course. :-/ Freudian slip? -- John Porter

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

John Porter <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > > > > The (continue|always|finally|whatever) clause will *always* be > > executed, even if one of the catch clauses does a die, so you can use > > this to roll back the database transaction or whatever else was going > > on and rest

Re: RFC 76 (v1) Builtin: reduce

Damian Conway wrote: > > More and more I lean towards a scalar-only reduce. Yep! > Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need > multidimensionals. Combined with highlander variables, and there ceases to be a problem. -- John Porter

Re: RFC 76 (v1) Builtin: reduce

John Porter <[EMAIL PROTECTED]> writes: > > Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need > > multidimensionals. > > Combined with highlander variables, and there ceases to be a problem. Will you stop with the highlander variables? -- Piers

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

Someone on this list (TomC?) has supplied a major diatribe against const. > "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> Dan Sugalski wrote: >> The syntax is actually: >> >> my type $varname; >> >> This is in perl 5.6.0. Modifiers go as attributes after the colon: >> >> my Dog

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

>bareword => $value > > ALWAYS quotes the left hand side, even if it's a filehandle. What about with -w: read => $value -Hao

Re: RFC 76 (v1) Builtin: reduce

Bart Lateur wrote: > > I have some reservations about this reduce() thing. Plain and simple > incorporating it into the core language would introduce the chance for > lots of buggy programs, like the example Arial gave. In fact, I think > that *most* programs that use reduce() would be buggy. W

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

On Fri, 11 Aug 2000 11:01:30 -0400 (EDT), Simply Hao wrote: >What about with -w: > >read => $value What warning? Oh, you're probably using a pre-5.005 Perl. 5.004 (the latest MacPerl, for example) still had that warning. 5.005 and later, do not, any more. -- Bart.

Re: RFC 76 (v1) Builtin: reduce

> "GB" == Graham Barr <[EMAIL PROTECTED]> writes: GB> On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote: >> Okay, then for >> >> reduce &avg $identity, @list >> >> What should $identity be? GB> I would like to see what &avg would be, given that each time it GB> would be passed

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

> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes: PC> The (continue|always|finally|whatever) clause will *always* be PC> executed, even if one of the catch clauses does a die, so you can use PC> this to roll back the database transaction or whatever else was going PC> on and restore any inva

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

Bart Lateur wrote: > > Actually, we don't need it. All we need, is lazy evaluation. > The idea comes from Lisp, No, that's no good; lazy evaluation was necessitated by functional programming, which of course perl should avoid like the plague... -- John Porter

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

At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote: >Someone on this list (TomC?) has supplied a major diatribe against const. Maybe, but I don't see what's wrong with: my $foo :const = 12; A nice, named, lexically scoped constant. The optimizer should be able to make reasonably good use of that.

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

At 11:13 AM 8/11/00 -0400, John Porter wrote: >Bart Lateur wrote: > > > > Actually, we don't need it. All we need, is lazy evaluation. > > The idea comes from Lisp, > >No, that's no good; lazy evaluation was necessitated by functional >programming, which of course perl should avoid like the plague

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

Chaim Frenkel <[EMAIL PROTECTED]> writes: > > "PC" == Piers Cawley <[EMAIL PROTECTED]> writes: > > PC> The (continue|always|finally|whatever) clause will *always* be > PC> executed, even if one of the catch clauses does a die, so you can use > PC> this to roll back the database transaction o

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

At 10:42 PM 8/10/00 -0400, Chaim Frenkel wrote: >PS> Can this be merged with RFC 80, or do they need to live apart? > >I believe they do. This portion can independently survive without >an exception mechanism. I'm only addressing the "what error did >I get". You are addressing the error handling m

RFC 78 and shared vs unshared modules/data

On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote: > Today there's no difference. If the proposal under discussion were > to pass, and packages' namespaces were to become local to the > namespace where the "use" occurred, then perhaps main::whatever > could be a common, stable, global

Re: RFC 78 and shared vs unshared modules/data

2000-08-11-11:59:47 Steve Simmons: > There's a strong implication here that we've just made package > namespaces heirarchical. The possibility of doing so was raised during discussion of ways to handle needs for one running program to have two different versions of the same support module. Once

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

On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote: > > =head1 ABSTRACT > > It is proposed that two new functions, C, and C, be added to > Perl. C would return a list that interleaved > its arguments. C would reverse this operation. I know other languages call it zip, but perso

Re: RFC 91 (v1) Builtin: partition

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 Howard <[EMAIL PROTECTED]> > Date: 11 August 2000 > Versio

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

On Fri, Aug 11, 2000 at 04:22:33PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Replace localtime() and gmtime() with date() and gmtdate() I think to be politically acceptable to all that should be utcdate

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

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 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 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 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 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()

> 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 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()

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 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()

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

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 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 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 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 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 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

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 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 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()

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 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()

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 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: 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 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 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 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: 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 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

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 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 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 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 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 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: 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 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: 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

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 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 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 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 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 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 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 =>

> > @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 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: 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 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)

  1   2   >