Jonathan Scott Duff wrote:
On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
An error has text associated with it, but also a bunch of other
attributes.
So it's a structured data type... where does OOP come into play?
1. It allows you to *extend* the base type with new
Piers Cawley wrote:
Tony Olekshy writes:
Peter Scott wrote:
An exception is an 'error'. That's already a vague concept.
I'll say it's vague. There are certainly uses for an exception to
trigger non-local success, not an error at all. In fact, there are
whole programming
From: "Peter Scott" [EMAIL PROTECTED]
Sent: Sunday, August 13, 2000 10:35 PM
try {
# fragile code which doesn't call any subroutines that might die
# and doesn't include any other try blocks
} catch {
# No code at all
}
Well, I don't really like that solution. It's exactly the
I think folks are forgetting that there are more than one client for
any class. Global settings should be restricted to a single setter.
The only logical single setter is main. All other clients should
be using something local.
Another reason to avoid globals, is we are designing perl6 to be
Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Ah,
Evan Howarth wrote:
Tony Olekshy wrote:
Just be sure to arrange to handle exceptions while handling
exceptions.
Are you saying that the try-catch proposal automatically
handles exceptions thrown in catch and finally blocks?
Yes.
That's an interesting idea. Java, C++, and Delphi
Peter Scott wrote:
Tony Olekshy wrote:
When you want the first one, use try + catch.
When you want the second one, use eval, then manipulate $@.
Just be sure to arrange to handle exceptions while handling
exceptions.
Erk, people shouldn't have to use such radically different
Peter Scott wrote:
If anyone suggests that
try { }
catch Exception::Foo, Exception::Bar { ... }
catch { exception thrown here causes it to
start going through catch blocks again }
then I'm afraid I'm going to have to turn to drink.
Agreed. However,
This seems like a good idea, to me.
-Corwin
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
IMHO trading six RFCs for two will greatly improve the chance of passing.
What does that mean? When the handler is invoked, what does it see?
$fh = open myhttp "http://www.perl.com", "fred", "barney";
Does that result in a call like this?
myhttp::open("http://www.perl.com", "fred", "barney");
Exactly. Or to be "more correct"
Here's a radical thought:
In most languages, dynamic scoping of variables offers no advantages
over lexical scoping, other than dynamic assignment. Dynamic
assignment can be accomplished with the local() operator (soon to be
renamed, I hope). The local() operator can be extended to operate
Nathan Wiger wrote:
However, make lexicals the default so that MyPackage would have to look
like this:
package MyPackage;
# my is redundant since lexicals are default
my($internal1, $internal2) = ('value1', 'value2');
# have to use your to give this variable to other
=head1 TITLE
Yet another lexical variable proposal: lexical variables made default
without requiring strict 'vars'
=head1 VERSION
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: perl6-language-strict
Number:
=head1 ABSTRACT
Perl was
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
prototype-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 97
=head1 ABSTRACT
When I read
On 14 Aug 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
prototype-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List:
yOn 14 Aug 2000, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
context-based method overloading
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL
"ABH" == Ask Bjoern Hansen [EMAIL PROTECTED] writes:
=head1 ABSTRACT
When I read the chapter on OO in the second edition camel book I
was saddened that C++ style method overloading was not explicitly
described. Ever hopeful, I wrote some quick code that I hoped would
do what I meant and
It will run faster, because it doesn't have to evaluate
the want(). (97,98) doesn't invalidate the current way of doing
things, it just gives a new way. And in syntax that is currently
erroneous.
Nathan Wiger wrote:
And what will aSub decide is it's context?
@foo = (1, 2,
In message [EMAIL PROTECTED]
Graham Barr [EMAIL PROTECTED] wrote:
On Fri, Aug 11, 2000 at 03:30:28PM -, Perl6 RFC Librarian wrote:
In order to reverse this operation we need an Cunzip function:
@zipped_list = zip(\@a,\@b); # (1,2,3,4,5,6)
@unzipped_list = unzip(3,
Damian Conway [EMAIL PROTECTED] writes:
Just to point out that the standard CS term is "merge".
`merge' produces a list of items from 2 (or more) lists of items;
`zip' produces a list of pairs (or tuples) of items from 2 (or more)
lists of items. So in a language like Haskell which uses
Ariel Scolnicov wrote:
Damian Conway [EMAIL PROTECTED] writes:
Just to point out that the standard CS term is "merge".
`merge' produces a list of items from 2 (or more) lists of items;
`zip' produces a list of pairs (or tuples) of items from 2 (or more)
lists of items. So in a language
The multiline comments sublist was due to expire on the 10th (a few days
ago). It's now time to perform the wrapup and close the sublist.
The chair was Michael Mathews, who I'd now like to ask to present a
summary of the sublist's discussion to us, and tell us about the status
of the multiline
The unlink sublist was due to expire on the 12th (a few days
ago). It's now time to perform the wrapup and close the sublist.
The chair was Nathan Wiger, who I'd now like to ask to present a
summary of the sublist's discussion to us, and tell us about the status
of the unlink RFC (RFC 29).
On Tue, Aug 08, 2000 at 07:44:11PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Add change bar functionality to pod
=head1 VERSION
Maintainer: Dan Sugalski [EMAIL PROTECTED]
Date: August 08, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 65
I don't think this is a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow exception-based error-reporting.
=head1 VERSION
Maintainer: Bennett Todd [EMAIL PROTECTED]
Date: 8 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Controllable Data Typing
=head1 VERSION
Maintainer: Syloke Soong [EMAIL PROTECTED]
Mailing List: [EMAIL PROTECTED]
Date: 10 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Number: 89
=head1
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy --
I agree that constants deserve a prominent place in Perl, as they offer
constaint which can be beneficial to programmers. Sometimes its nice to know
that I mistakenly tried to treat a static variable as dynamic.
I disagree with "const" as it's verbose; I'd rather see something like
Steve Simmons writes:
: On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
:
: Please, please, please, PLEASE, let us not replicate the debacle that is
: C++'s const modifier!
:
: It doesn't feel like a debacle to me, it feels like it put the control
: in the programmers hands.
Dan Sugalski wrote:
perl cribs from english as much as
any other language, spending some time to get names that fit well makes
perfect sense, especially since most of the perl programmers that start
using this won't be coming with huge gobs of experience from languages that
already do it.
On Mon, Aug 14, 2000 at 01:46:55PM -0400, Lipscomb, Al wrote:
While the implicit change works on most (if not all) situations it would be
nice to have a way to control the conversion.
Sounds like an RFC to me :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
tie %h A_DATABASE_RETURNING_OBJECTS, yadda, yadda, yadda;
for (grep {$h{$_}-STATE eq 'NY'} keys %h){
$h{$_}-send_advertisement();
};
We want "keys" to return an RFC24 "lazy list" when it is
compiler-obvious that it is safe to do so, meaning:
---
At 11:15 AM 8/14/00 -0700, Nathan Wiger wrote:
I'm going to actually ask for a new mailing sublist, probably called
-object, on which this should be discussed. There's lots and lots and
lots and lots of details to work out.
It might be best to wait a bit and see how the proposed internal
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
How would this be stored? As a floating point number? What about
sub-second accuracy? To get seconds you'd need about 5.15 decimal
places (let's just
How 'bout 100ns ticks from base date, stored in a 64-bit number? That
We are going to have quads supported on all platforms, then? With
software emulation of our own if nothing else is available? I wouldn't
object, mind...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special
On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote:
At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
How would this be stored? As a
At 01:48 PM 8/14/00 -0500, Jarkko Hietaniemi wrote:
How 'bout 100ns ticks from base date, stored in a 64-bit number? That
We are going to have quads supported on all platforms, then? With
software emulation of our own if nothing else is available? I wouldn't
object, mind...
I'd like to
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote:
I'm not sure anyone does that much in the way of time/date work that it'd
make a difference. Besides, we're talking internal here--time() may still
return Unix epoch seconds for compatibility reasons.
Blah! I saw the prosal for
Nick Ing-Simmons wrote:
Ed Mills [EMAIL PROTECTED] writes:
There are many logical reasons for and against the RFC's here, but saying
"it looks like c so it doesn't make it for me" is a weak argument at best.
I don't think anyone made that argument - they have all been
"I hate that in
On Mon, 14 Aug 2000, Nick Ing-Simmons wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
There has to be _an_ epoch - even Caesar started
John Porter [EMAIL PROTECTED] writes:
Nick Ing-Simmons wrote:
Ed Mills [EMAIL PROTECTED] writes:
There are many logical reasons for and against the RFC's here, but saying
"it looks like c so it doesn't make it for me" is a weak argument at best.
I don't think anyone made that argument -
Nathan Wiger wrote:
"David L. Nicol" wrote:
These things sound like perfectly reasonable CPAN modules.
What's the block prevenenting their implementation w/in the
perl5 framework?
Jeremy and I are working on a general purpose matrix/unmatrix function
that may well be core-worthy. This
=head1 TITLE
Controllable Data Typing
=head1 VERSION
Maintainer: Syloke Soong [EMAIL PROTECTED]
Mailing List: [EMAIL PROTECTED]
...
Retain current flexibility of Perl liberal variables.
Provide a new form of declaring variables:
scope cast-type $varname:constraint;
...
=head2
RFC 89 forms the basis of another RFC I'm forwarding very soon. Though I realise this
broadens the scope of the RFC, I needed the constant thing defined in the manner of a
constraint for my next one coming.
Both of us are in agreement. It's a constraint through the use of attributes. By
No posts we recorded on the mailing list perl6-language-unlink, which
was setup to discuss RFC 29.
As such, the issue is assumed closed per the existing RFC 29. It will be
frozen as-is.
-Nate
On Mon, Aug 14, 2000 at 02:28:29PM -0500, Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 03:01:48PM -0400, Dan Sugalski wrote:
I'm not sure anyone does that much in the way of time/date work that it'd
make a difference. Besides, we're talking internal here--time() may still
return Unix
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Handlers and Pseudo-classes
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 101
Status: Developing
=head1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 102
=head1 ABSTRACT
Unlike many
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix print "$r-func" and $pkg::$var precedence
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 103
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Maintain internal time in Modified Julian (not epoch)
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 99
Status:
skud [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?
[EMAIL PROTECTED] already exists; maybe it should be blessed as a Perl 6
working group as well?
--
Russ Allbery
I'm not sure anyone does that much in the way of time/date work that it'd
make a difference. Besides, we're talking internal here--time() may still
return Unix epoch seconds for compatibility reasons.
Blah! I saw the prosal for an mjdate() routine and thought it was at
the language
This seems like a good idea, to me.
-Corwin
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
IMHO trading six RFCs for two will greatly improve the chance of passing.
On 14 Aug 2000, Russ Allbery wrote:
Nathan Wiger [EMAIL PROTECTED] writes:
The idea would be twofold:
1. time() would still return UNIX epoch time. However, it
would not be in core, and would not be the primary
timekeeping method. It would be in Time::Local for
Anyway, it doesn't matter; it's a lot more widely used than any other
epoch, and epochs are completely arbitrary anyway. What's wrong with it?
I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX
(thank
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
reason
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
reason IIRC.
On Mon, 14 Aug 2000, Nathan Wiger wrote:
1. time() would still return UNIX epoch time. However, it
would not be in core, and would not be the primary
timekeeping method. It would be in Time::Local for
compatibility (along with localtime and gmtime).
2. mjdate()
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 course be
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
On Sun, Aug 13, 2000 at 09:36:48PM -0400, Ronald J Kimball wrote:
On Sun, Aug 13, 2000 at 09:04:41PM +0100, Paul Marquess wrote:
I'm cc-ing this to p6 because there doesn't seem to be anyone left on
p5p.
Then who is generating all this
Tim Jenness [EMAIL PROTECTED] writes:
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
61 matches
Mail list logo
