Re: list changes: perl6-language-objects added, perl6-language-unlink closed

On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote: >LIST: perl6-language-objects >CHAIR: Nathan Wiger <[EMAIL PROTECTED]> >MISSION:Develop RFCs related to objects and OO programming in >Perl, possibly rationalising existing RFCs where they

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

Please take this discussion to perl6-language-datetime. Thanks! K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664

Array notation (was Re: RFC 104 (v1) Backtracking)

Mark Cogan wrote: > At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote: > >You are missing the beauty of vector/matrix operations. > > No, I'm not; I'm opining that the vast majority of Perl users don't need to > do vector/matrix ops, and that they don't belong in the core. > The vast majority of Perl

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

Damien Neil <[EMAIL PROTECTED]> writes: > Arrays are ordered. Hashes are not. Sure, you can iterate over a hash, > but add an element to one and you can change the order of everything in > it. Formally, I believe it's permissable for a hash implementation to return a different order the second

Re: RFC 82 (listops in list context)

On Tue, Aug 15, 2000 at 11:15:03PM -0700, Peter Scott wrote: > No, || is half-consistent at the moment: the left hand side is forced into > scalar context but the result context propagates down the right hand > side. I challenge anyone to come up with a rationalization for this that > does not

Re: RFC 82 (listops in list context)

At 04:02 PM 8/16/00 +1000, Jeremy Howard wrote: >Nathan Torkington wrote: > > Your [Jeremy's] RFC says: > > > Currently, operators applied to lists in a list context behave > > > counter-intuitively: > > > > Counter-intuitively is different from consistently. Your title is > > misleading. Perl's

Uses for array notation (was Re: RFC 104 (v1) Backtracking)

Mark Cogan wrote: > At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote: > >It seems obvious that @a should be the whole array @a, not the size of the > >array. If I want to check the size of @a, I should have to do so explicitly, > >with scalar or $#. > > > >This is non-obvious if you think that || is

Re: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote: > I like the idea of adding the context-aware operators, but I don't > think I'd use them as often as I use "the number of things in the > array". I think most Perl programmers would be in the same camp. > Unless you can show a co

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

On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote: > Why is it silly? Hashes and arrays are *conceptually* very similar (even > if they are extremely different implementation-wise). One of them has > implicit key, the other has an explicit key. They both provide some sort > of o

Re: RFC 82 (listops in list context)

Nathan Torkington wrote: > Your [Jeremy's] RFC says: > > Currently, operators applied to lists in a list context behave > > counter-intuitively: > > Counter-intuitively is different from consistently. Your title is > misleading. Perl's ops *are* applied consistently: they consistently > give the

Re: "Try? There is no try." -- Yoda's Exception handling syntax

Jonathan Scott Duff wrote: > > Tony Olekshy wrote: > > > > The "try" is not necessarily for Perl's sake. It's for the > > programmer's sake. It says, watch out, some sort of non-local > > flow control may be going on here. It signals intent to deal > > with action at a distance (unwinding sema

Re: Exceptions and Objects

I have moved this to [EMAIL PROTECTED] Jonathan Scott Duff wrote: > > Okay, imagine something for me: > > # some code here that may cause an exception > exceptions {# when thrown, we end up here > switch ($@->^_) { > case canFoo { ... }

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

I have moved this to [EMAIL PROTECTED] Chaim Frenkel wrote: > > Sorry, I keep reading [except], even with your explanation, as > "ignore this [catch]". A more positive word would be better. I take your point. Patches are welcome ;-) > I haven't seen a good reason that it should be any more co

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

Jonathan Scott Duff wrote: > > On Tue, Aug 15, 2000 at 05:14:56PM -0700, Peter Scott wrote: > > > > I want: exceptions to contain 'file' and 'line' attributes which > > are arrays that get a location pushed on every time an exception > > bubbles up through a scoping level. > > Why not have a spe

Re: RFC 63 (v3) Exception handling syntax

Chaim Frenkel wrote: > > > [stuff about exceptions being self-ignorable] > > I am adamant against increasing the number of methods of creating > action at a distance. (Look at the planed removal of all the $/, etc > variables. Don't keep adding this type of problem. I agree completely. Not to p

Re: English language basis for "throw"

"Stephen P. Potter" wrote: > > I think fail() and handle() are good. Something fail()ed and > it was handle()d by an exception. Fail is no good, because exceptions can be used to indicate success. Just because you don't isn't a counter-argument. Exceptions are *not* the same as errors, that's

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

Dan Sugalski wrote: > At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote: > > > > > No, neither proposal makes sense. Arrays can be stored compactly and > > > > > > > > $a[1_000_000_000] = 'oh, really?' # :-) > > > > > > > my int @a: sparse; > > > >I see: you have a time machine and I don't. So

Re: RFC 65 (v1) Add change bar functionality to pod

[EMAIL PROTECTED] writes: > I don't think this is a language issue. However, I don't believe > there's a -doc working group yet, either. > > Is it time for a -doc group to form? Not unless there's a significant interest in doc issues, as reflected in RFCs. Nat

Re: "Try? There is no try." -- Yoda's Exception handling syntax

On Tue, Aug 15, 2000 at 04:12:17PM -0700, Peter Scott wrote: > >Would someone please enlighten me as to the purpose of an explicit "try." > > Well, for one, it makes it easier to see that a block is subject to > exception handling if all you have to do is look at the beginning for 'try' > rathe

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

On Tue, Aug 15, 2000 at 10:52:02PM -0400, Chaim Frenkel wrote: > Why does all the unwinding stuff have to be there? Let $@ exist in > the always block the iff $@ is defined then you are unwinding and > do your wishes. Otherwise you are just falling out of the BLOCK. > > Why all the extra syntax?

Re: Toward an omnibus Perl 6 Exceptions RFC, v0.1.

On Tue, Aug 15, 2000 at 05:14:56PM -0700, Peter Scott wrote: > You want: while handling an exception, throwing another exception pushes > the first one onto a stack which could be reported en masse when the coup > de gras arrives. Like VMS error cascading. You do this with a _link > attribute

list changes: perl6-language-objects added, perl6-language-unlinkclosed

Subscribe by sending mail to [EMAIL PROTECTED] More details at http://dev.perl.org/lists.shtml LIST: perl6-language-objects CHAIR: Nathan Wiger <[EMAIL PROTECTED]> MISSION:Develop RFCs related to objects and OO programming in Perl, possibly rationalisi

Re: Exceptions and Objects

On Tue, Aug 15, 2000 at 06:23:57PM -0600, Tony Olekshy wrote: > Jonathan Scott Duff wrote: > > > > What's wrong with just using the switch statement? It seems > > like except and catch are becoming special-purpose switches > > to me. Is it really necessary? > > It's not necessary, but it is th

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

At 22:07 -0600 2000.08.15, Nathan Torkington wrote: >NOTICE: reply-to set to the -language-datetime list. > >Ted Ashton writes: >> Well then, why 1970? If we're defining our own, why buy into one >> which is scheduled to blow up in 2038? Why not at the very least >> start with Jan 1, 2K? > >This

Re: command line option: $|++

> "s" == skud <[EMAIL PROTECTED]> writes: s> Command line options aren't really a language issue, however I'm not s> sure that there is a better list for them. Anyone on bootstrap got any s> good ideas? shove it over onto -internals. They will have to implement it anyway. The only other

Re: command line option: $|++

Command line options aren't really a language issue, however I'm not sure that there is a better list for them. Anyone on bootstrap got any good ideas? K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, 15 Aug 2000, Nathan Wiger wrote: > Jarkko Hietaniemi wrote: > > > > > Is Perl currently using different epochs on different platforms? If so, I > > > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > > just to be portable.) MacOS' epoch zero is 1900 (or was i

Re: RFC 109 (v1) Less line noise - let's get rid of @%

On Tue, 15 Aug 2000, Karl Glazebrook wrote: > or one could just *use* english plurals... > I tried this once with filters. It sort of worked. (With the obvious bombs, of course.) > my $speaker = 'Jim'; > my $speakers = ('Fred','Bill','Sally','Betty'); > > my $male_speakers = $speakers[0:1]; #

Re: English language basis for "throw"

John Porter wrote: > So, instead of "throw": "throwup". That leads me down the path of "puke" and "scrub" instead of "throw" and "catch". Actually, I rather liked the "oops" Scott suggested, but used in place of "throw" instead of a rename of "exception". So how about "oops" and "recover" inst

Re: RFC 109 (v1) Less line noise - let's get rid of @%

On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote: > I hope people will actually read the RFC before coming back with these > canned responses which I (and presumably everyone else on this list) > am completely familiar with. I used to believe that too! Honest... I think you do a si

Re: new -language sublists. perl6-language-datetime and perl6-language-errors

At 03:55 PM 8/15/00 -0700, you wrote: >LIST: perl6-language-errors >CHAIR: Steve Simmons <[EMAIL PROTECTED]> >MISSION:To develop RFCs related to error handling and exceptions > in Perl 6, possibly combining existing RFCs into a more > cohe

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jonathan wrote: > >On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: >> I don't know about this. Sounds cool, but I think we should stick to >> something that somebody somewhere uses already. Of course, something >> standard like 0 AD isn't bad. > >Standard for whom? I bet there are

Re: Internal Filename Representations (was Re: Summary of I/O related

[EMAIL PROTECTED] (Jarkko Hietaniemi) wrote on 13.08.00 in <[EMAIL PROTECTED]>: > On Sun, Aug 13, 2000 at 02:14:24PM -0400, Chaim Frenkel wrote: > > Why do all those acts have to be performed to do an open? > > I must not be explaining myself very well... To do an open() from > Perl the user

Unify the Exception and Error Message RFCs?

On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote: > At 03:30 PM 8/13/00 -0500, David L. Nicol wrote: > >Whose RFC deals with this? > 63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-) Well yes, but they represent three authors with (as best I can tell) pr

Re: RFC 99 (v1) Maintain internal time in Modified Julian (notepoch)

Proposal for 64 bit time. Just can't help but put in a little more A bit of speculative physics and religion here. To keep historians, geologists, cosmologists, theologians, ufologists and aliens happy, Perl needs neutral time base, which has the most far fetched possibility. Imagine a kid

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

>> Is Perl currently using different epochs on different platforms? If so, I > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), > VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical > rea

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> On 14 Aug 2000, Russ Allbery wrote: > >> Day resolution is insufficient for most purposes in all the Perl scripts >> I've worked on. I practically never need sub-second precision; I almost >> always need precision better than one day. >> > > MJD allows fractional days (otherwise it would of co

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

There is already precedent (-M, et alia) for a "perl epoch" which is time since the start of execution of the script. Negative numbers are used to represent times prior to the start of execution, and positive numbers are used to represent times after the start of execution. The "perl epoch" does

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Jon Ericson wrote: > > Perl6 RFC Librarian wrote: > > [snip reconstructionist history and newer-is-better fallacy] > > > I argue in this Brave New World the distinction between C<$x>, C<@x> and > > C<%x> are no longer useful and should be abolished. We might want > > to use all kinds of array o

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Perl6 RFC Librarian wrote: [snip reconstructionist history and newer-is-better fallacy] > I argue in this Brave New World the distinction between C<$x>, C<@x> and > C<%x> are no longer useful and should be abolished. We might want > to use all kinds of array objects, why should @x be special? Ra

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: > Midnight, Jan 1, 2000, Greenwich time > > seems like a good candidate. have found 2000-03-01 to be a good epoch. It makes -mm-dd decoding and leap year calculations cheaper/simpler as it is the closest start of a new 400 yea

RFC 109 (v1) Less line noise - let's get rid of @%

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Less line noise - let's get rid of @% =head1 VERSION Maintainer: Karl Glazebrook <[EMAIL PROTECTED]> Date: 15 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 109 =head1 ABSTRACT T

RFC 108 (v1) Scope of Polymorphic References and Objects

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Scope of Polymorphic References and Objects =head1 VERSION Maintainer: Syloke Soong <[EMAIL PROTECTED]> Mailing List: [EMAIL PROTECTED] Date: 15 Aug 2000 Version: 1 Number: 108 =head1 A

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote: >Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00 >UTC. >(somebody threw that date out, It appears to be purely >arbitrary rather than based on some celestial event) Not arbitrary at all. From: http://www.kgb.com/calend.

RFC 107 (v1) lvalue subs should receive the rvalue as an argument

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE lvalue subs should receive the rvalue as an argument =head1 VERSION Maintainer: Andy Wardley <[EMAIL PROTECTED]> Date: 15 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 107

RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Standardize ALL Perl platforms on UNIX epoch =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 14 Aug 2000 Last-Modified: 15 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] N

RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Downgrade or remove "In string @ must be \@" error =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 15 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 105 Stat

Re: command line option: $|++

Peter Scott wrote: > > Can someone knowledgeable on this issue speak to it? > > Will $| $/ $\ et al be retired, or be valid for some default filehandle? > > Will there still be default filehandles? There's been a big debate on the -io list about this. No clear decisions yet, but looks like the

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

In message <[EMAIL PROTECTED]> Dan Sugalski <[EMAIL PROTECTED]> wrote: > I think I'd snag a date after the last western country went Julian, just to > avoid some of the less fun time conversion issues. (How long ago Jan 1, > 1690 was depends on what country you're in) I think you mean

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jonathan Scott Duff wrote: > >> standard like 0 AD isn't bad. > > Standard for whom? I bet there are *millions* of Jews for whom "0 AD" > is meaningless. s/Jews/ calendar that predates christianity>/ Good point. Unix epoch it is! :-) -Nate

Re: Exceptions and Objects

On Tue, Aug 15, 2000 at 11:47:03AM -0500, Jonathan Scott Duff wrote: > On Tue, Aug 15, 2000 at 11:47:32AM +0100, Graham Barr wrote: > > On Mon, Aug 14, 2000 at 10:56:36AM -0500, Jonathan Scott Duff wrote: > > > try { } > > > catch SomeException { } > > > catch SomeOtherException { } > > >

Re: command line option: $|++

Jonathan Scott Duff wrote: > > Well, now it's my turn to suggest something ;-> How about we give > perl the ability to look for a .perlrc file? (Yes, I know the reasons > against, but everything is up for grabs now right? :-) If we do this, it should be off by default. csk/ksh make you turn i

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 09:25 AM 8/15/00 -0700, Larry Wall wrote: >[EMAIL PROTECTED] writes: >: Yep. Or more generally "Standardize Perl on all platforms to one >: common time epoch" and reccommend the Unix epoch since it's so >: widespread. :-) > >Oh, gee, where's your sense of history? (As in creating our own. :-

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: > I don't know about this. Sounds cool, but I think we should stick to > something that somebody somewhere uses already. Of course, something > standard like 0 AD isn't bad. Standard for whom? I bet there are *millions* of Jews for wh

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > : Yep. Or more generally "Standardize Perl on all platforms to one > : common time epoch" and reccommend the Unix epoch since it's so > : widespread. :-) > > Oh, gee, where's your sense of history? (As in

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Larry Wall wrote: > > Oh, gee, where's your sense of history? (As in creating our own. :-) > Maybe we should invent our own epoch, like the year 2000. Or use a > really standard one, like the year 0 AD (aka 1 BC). I don't know about this. Sounds cool, but I think we should stick to something t

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the ye

RFC 63 (v3) Exception handling syntax

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Exception handling syntax =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 8 Aug 2000 Last-Modified: 14 Aug 2000 Version: 3 Mailing List: [EMAIL PROTECTED]

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote: > There seems to be a groundswell against this idea, which is fine by me > (heck, just because it's my idea doesn't me it's a GOOD one!). > > Here's a different proposal, same vein: "Standardize all Perl platforms > on the UNIX epoch".

RFC 29 (v2) unlink() should be left alone

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE unlink() should be left alone =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Last-Modified: 14 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 29 Sta

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jarkko Hietaniemi wrote: > > > Is Perl currently using different epochs on different platforms? If so, I > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), > VMS' epoch zero is 17-NOV-1858 00:00:00.0

RFC 104 (v1) Backtracking

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Backtracking =head1 VERSION Maintainer: iVAN Georgiev <[EMAIL PROTECTED]> Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 104 =head1 ABSTRACT Backtraking mechanism is core f

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote: > No, but currently Perl IS forcing Windows, Mac, and BeOS users to > understand what the UNIX epoch is. So you're proposing that rather than give one platform (unix) an advantage, we force all platforms to use some other completely a

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 10:56 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: > > Is Perl currently using different epochs on different platforms? If so, I > >Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, >just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), >VMS' epoch zero is 17

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes: RA> Is Perl currently using different epochs on different platforms? If so, I RA> can definitely see the wisdom in doing something about *that* and RA> off-loading the system-local time processing into modules (although I can RA> also see th

Implementing array notation (was Re: Threaded In-Line Code (was Re: Typed Intermediate Language))

Graham Barr wrote: > On Tue, Aug 15, 2000 at 02:03:12PM +1000, Jeremy Howard wrote: > > The PDL team are now examining how to incorporate these kinds of features > > into perl 6. I'm also interested in seeing how to implement things like > > (from RFC 82) > > > > > > @b = (1,2,3); > > @c = (2

Re: RFC 97 (v1) prototype-based method overloading

Chaim Frenkel <[EMAIL PROTECTED]> writes: > Why would anyone want to select a different method based upon the > arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may b

Re: Exceptions and Objects

Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote: > > Could be. I'd be interested in seeing non-OOP proposals that do what I > > want exceptions to do, I have a hard time imagining one. > > Well, what is it that you want exceptions t