> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
AS> 2. Error codes as digit strings with decimal point. So "123.4567"
AS>(_not_ 123.4567) represents error 4567. People will still try
AS>stupid floating-point math tricks to get at the suberror code, but
AS>at least
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
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,@lis
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes, for Chaim Frenkel
<[EMAIL PROTECTED]>:
[...]
> =item As a floating point number
>
> The integer part would be the actual identifier. The fractional
> part could encode some classification scheme.
Floating point numbers don't work this way. Supp
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for error
I'm several days behind on -language due to dodgy home dialups and the
noise and insanity I suffer at the office.
I'm making a valiant attempt to catch up on 700 posts right now, but
would appreciate it if people could email me privately if there's
anything they particularly want to bring to my a
Peter Scott wrote:
> Have you used strict lately? :-)
No, but the documentation for strict is some of what I reread before making a
fool of myself arguing with Damian, and it says nothing about barewords, as far
as I could read.
Having used it on occasion, I am aware it _does_ have some effect
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 complex types?
- Constant refs vs refs to constants?
- Types o
On Thu, 10 Aug 2000, Decklin Foster wrote:
> Syloke Soong <[EMAIL PROTECTED]> writes:
>
> > my $varname type;
>
> The syntax
>
> my $varname : constant; # pun not intended :)
>
> Was brought up earlier (but probably not before this RFC was written).
> Perhaps something similar could
Bart Lateur <[EMAIL PROTECTED]> writes:
> What's so hard? Subtracting 2 hours and 30 minutes from the official
> referential time (GMT)? Or the Daylight Savings Time rules?
It's not a problem of implementation. It's a problem of semantics due to
the way Perl parses the language.
Suppose you ca
Chaim Frenkel wrote:
>
> [stuff about exception numbering]
>
> Hmm, I thought I saw another exception RFC pass by.
> Yup, RFC 88, Tony Olekshy <[EMAIL PROTECTED]>
>
> Could you two folks get together and hash this out.
RFC 88 goes to some trouble to seperate exception handling from
exception obje
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 context, how does one
end up with the invariant restored
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
=>. You
> could just as well say
>
>
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 call stack
> } continue {
>... # Executed
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> =head1 TITLE
>>
>> All perl generated errors should have a unique identifier
PS> This looks awfully similar to RFC 80. Certainly the exception objects RFC
PS> 80 is thinking about can well have unique numeric attributes.
>> All perl ge
At 07:29 PM 8/10/00 -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
>=>. You
As a casual VMS user, I've always liked the way that VMS coded its error
messages. Perhaps a similar technique could be adopted for perl.
Each message has 4 parts:
Facility:
This is the thing that is reporting the error
Severity:
This is a severit
At 10:33 PM 8/10/00 +0100, Graham Barr wrote:
>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 but. How does the 'else' clause indicate that the exception
> > was handled?
>
>By not
Peter Scott wrote:
>
> try {
> } catch Exception::IO with {
> } catch Exception::Socket with {
> } otherwise {
> };
Jonathan Scott Duff wrote:
>
> try {
> } catch {
> switch ($EXCEPTION->name) {
> case IO { ... }
> case Socket { ... }
>
Damian Conway 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 "," (see
>
> > Currying placeholders are scalars
>
> Is that a general truth?
Yes. It proceeds from the fact that $_[0], $_[1], ect are scalars.
> It wasn't obvious from RFC 23... If you
> rev it, perhaps you could make that clearer.
Will do.
> Looking back, the defining exampl
At 07:53 PM 8/10/00 +0200, Bart Lateur wrote:
>p.s. I've always disliked the word "throwing" for errors, just to be a
>complement to "catch". An error to me is something like a trapdoor,
>where you unexpectedly fall through.
The only difference is the direction of travel :-) In both cases you do
At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>Well what is the difference between try and eval ?
There isn't any. I could have sworn I once read that the block eval was so
different from the string eval that Larry wanted to use 'try', but didn't
want to add another keyword, but later wished h
Syloke Soong <[EMAIL PROTECTED]> writes:
> my $varname type;
The syntax
my $varname : constant; # pun not intended :)
Was brought up earlier (but probably not before this RFC was written).
Perhaps something similar could be used for the sake of consistency.
> if ($somecond
At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>In fact the syntax could be
>
> eval {
> }
> continue {
> }
>
> switch ($@) {
> } if $@;
>
>I just don't see the need to make perl look like other languages just for
>the sake of makeing it look like other languages.
No, I wasn't thinking
Damian Conway wrote:
> Currying placeholders are scalars
Is that a general truth? It wasn't obvious from RFC 23... If you rev it, perhaps
you could make that clearer.
Looking back, the defining example did give a list of (;) in the prototype. I
suppose it would be pretty complex to infer
Perhaps a pair is a degenerate pseudo-hash (but then a pseudo-hash is
degenerate period.)
So the correct access should be
print keys %$array[0]
During the give and take of Topaz, having arrays and hashes have similar
access functions was bandied about. So that one could possibly have
a
At 12:59 PM 8/10/00 -0400, John Porter wrote:
>I'd like to recommend just "catch" instead of "otherwise",
>because sometimes you'll do this:
>
> try {
> # fragile code
> }
> catch {
> # handle other exceptions
> };
>
>And it would loo
At 02:39 PM 8/10/00 -0500, Jarkko Hietaniemi wrote:
>There are quarter-hour time zones...
And then there's Damian, who lives in a non-linear time zone...
--
Peter Scott
Pacific Systems Design Technologies
>=head1 TITLE
>
>All perl generated errors should have a unique identifier
This looks awfully similar to RFC 80. Certainly the exception objects RFC
80 is thinking about can well have unique numeric attributes.
>All perl generated errors should have a unique identity. So that
>changes in the
> 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 "," (see
> perldata).
The Perl documen
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 "first-argument-stringifying comma
operator". In fact, the doc
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> All perl generated errors should have a unique identity. So that
> changes in the text should not cause breakage in code.
>
Good idea. A lot of programs do this. It could make it easier to
handle error callbacks. (If you ever get a 'no space l
> @array = ( a=>1, b=>2, 'c', 3 );
Isn't this just an array of hashrefs in in disguise? Or am I missing
something?
I don't see a problem for adding more ways to do something, my only
problem would be if the "key" and "value" builtins were the only ways to
get to the data. You should be a
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
Version: 1
Number: 89
=head1 ABSTRACT
Provide a choice for
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> This method of creating constants has three serious drawbacks:
They're also quite heavy, although I think that CONSTSUB was to take
care of that.
What I never understood, although I'm sure there's a very simple
reason, is why it wasn't simply mad
> 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.
> What about a plural whatzit or a reference to a plural
> whatzit?
References ar
Shades of LISP, batman.
I can see it now, the '=>' operator will be called cons-ing.
And the new keword for accessing a pair will be CAR and CDR.
Are the two values of a pair restricted in anyway? All your examples
were scalar. What about a plural whatzit or a reference to a plural
whatzit?
Damian Conway wrote:
>> > When a pair reference is assigned (in)to an array, it remains a
>> > single scalar (referential) value. So:
>> >
>> > @array = ( a=>1, b=>2, 'c', 3 );
>> >
>> > assigns four elements (not six) to @array.
> The proposed C and C built-ins (o
On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote:
> On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:
Did not.
> > people in Newfoundland are going to expect to be
> >> able to pass in -0230 and have that work, and that's interestingly hard.
>
> What's so hard? Subtracting
On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:
> people in Newfoundland are going to expect to be
>> able to pass in -0230 and have that work, and that's interestingly hard.
What's so hard? Subtracting 2 hours and 30 minutes from the official
referential time (GMT)? Or the Daylight
A semantic definition of "constant" would be nice.
I'd like to propose the following definition:
A constant value cannot be assigned to, deleted, or used as the argument to
a mutating function/operator.
Doing any of these would be a catchable error. (However, it can be deleted
by the GC, and th
> > When a pair reference is assigned (in)to an array, it remains a
> > single scalar (referential) value. So:
> >
> > @array = ( a=>1, b=>2, 'c', 3 );
> >
> > assigns four elements (not six) to @array.
>
> How do we get keys and values out?
The proposed C and C
Chaim Frenkel wrote:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
>
What's wrong with:
$average = reduce (^last+^this, @^list) / scalar @^list;
print $average->([1,3,5]); # Prints '3'
You don't need to explicitly add a '0' to the front of the summed list.
Okay, then for
reduce &avg $identity, @list
What should $identity be?
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
AS> Think of the first element of the list as different from the rest --
AS> it is the initial value to reduce from (for + and *, you'll usually
AS> pick an
Perl6 RFC Librarian wrote:
[...]
> This RFC proposes the introduction of a new data type -- the I
[...]
I hereby propose that all current Perl 6 Project Plan deadlines
be extended 3 months so that Damian has more time to come up
with gems like this. I have no idea if it ultimately makes sense
or
Volume on perl6-language is so high, I didn't notice the thread on
RFC 64 until today. That's really the kind of discussion I'm looking
for over (t)here, so I hereby declare RFC 64 as open game for more
focused discussion on perl6-language-strict and request people discuss
it over here in the
Perl6 RFC Librarian wrote:
> The first component of a pair would be called its C, and the second, it's
> C. It is proposed to either extend the semantics of C and
> C to allow them to operate of pair references, or else introduce
> two new built-ins -- C and C -- to access the components of a pair
> Hmm, would it be too nasty for perl to recognize that all foo's have the
> same prototype? (Consider the singular foo case.)
Probably. Remember that the programmer can always
C or C and completely change
inheritance hierarchies.
Anyway, the overloading functionality you want will be avai
Michael Fowler wrote:
> > > Which then raises a few more problems (whew): how do you coax user input
> > > (which is an SV) into a value $foo can accept with very-strict on?
> >
> > You run it through an explicit conversion process, like using C in
> > a C program
>
> Unfortunately, this involv
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> $fooA->foo
>> $fooB->foo
>>
>> What is a poor perl parser to do?
DC> Ignore the prototype unless $fooA and $fooB are typed lexicals.
DC> I.e. act just like it does now.
Hmm, would it be too nasty for perl to recognize that al
> Couldn't reduce return a list just through concatenating its elements? For
> instance:
>
> @a = (1,3,2,4,3,6,4,8);
> @sum = reduce( (^total, ^x+^y ), @a ); # (4,6,9,12)
Currying placeholders are scalars, so you want:
@sum = @{reduce (@^total, ^x+^y ), [], @a };
More
> "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 but. How does the 'else' clause indicate that the exception
>> was handled?
G
John Porter wrote:
> Jeremy Howard wrote:
> > The reason that having (1..) implies having (..-1) is that if you allow
> > (1..), then this is a valid construct:
> >
> > @dot_dot_neg_one = reverse (map {-$_} (1..));
> >
> > which is identical to (..-1)!
>
> No, NOT identical. The same set of num
Damian Conway wrote:
>> AS> Also, the RFC should specify that the function is always
evaluated in
>> AS> a scalar context (for things to make sense).
>>
>> Why? reduce should be able to reduce a set of matrices to a matrix.
Or
>> actually any aggregate (plural whatzit).
>>
On 10 Aug 2000, Perl6 RFC Librarian wrote:
> %hash = ( a=>1, b=>2, 'c', 3 );
>
> does what it does in Perl 5, but works slightly differently. The list being
> assigned consists of four elements (not six): a pair reference, another pair
> reference, a string, and an integer.
Well, I supp
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All perl generated errors should have a unique identifier
=head1 VERSION
Maintainer: Chaim Frenkel <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
85
All
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=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
2000-08-10-17:36:41 Graham Barr:
> And the difference is ?
>
> $ perl -e 'warn \$main::fred::x," ",\$fred::x'
> SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.
Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
names
On Thu, Aug 10, 2000 at 10:43:02AM -0400, Bennett Todd wrote:
> If the only real problem that can be found with making module use
> package-local is in these few option-flag type variables, perhaps
> they could be handled differently. E.g. suppose normal package
> variables end up being local to t
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 but. How does the 'else' clause indicate that the exception
> was handled?
By not rethrowing it. ie if it does not want to handle the
error
On Fri, Aug 11, 2000 at 06:22:46AM +1000, Damian Conway wrote:
> I don't *dislike* your proposal, except that it interposes another layer of
> indirection on a process that is already too slow.
>
>
>> =head2 $AUTOLOAD
>>
>> While w
> By writing @sum = reduce __+__ 0, @numbers
> you deal elegantly with both cases.
>
> NOTE: I find this trick very elegant. I wish it were my trick,
> instead of Damian's...
Damian wishes it were Damian's, but is sure it's at least a few hundred
years old :-)
Damian
I'd put it into
Perl::Option{__Package__}
There was some talk about making Perl:: special. So that might be the one
and only truely global space.
Hmm, that wouldn't work with multiple versions without cooperation.
Alternatively, we could treat a set
Perl::Option{FTP::Net}->
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
>
> >> If the original list has no elements, C immediately returns C.
>
> AS> I like everything except this part. Reducing an empty list should be
> AS> an error.
>
> AS> Returning undef (or
> I don't see it.
>
>1 == f((reduce +, undef), 1) == reduce +, undef, 1
undef isn't an empty list, it's a one element list.
Consider the other "common" reduction:
sub f { $_[0] * $_[1] }
Now:
f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0
But
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
A couple of possiblities
1. Undef $@. But that's a bit of extra work in each leg.
2. switch is 'slightly' special in an eval/else block.
> Why push it through a user subroutine. Might as well make it part of the
> core language.
Why exacerbate the core, when I one-line user sub can do it?
> Why add another keyword non_lazy. though it isn't an antonym, eval{}
> has the right meaning and effect.
No, "non-lazy" was jus
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
>> If the original list has no elements, C immediately returns C.
AS> I like everything except this part. Reducing an empty list should be
AS> an error.
AS> Returning undef (or anything else, really) breaks the algebraic
AS> equivalence
> Instead of calling the right thing or actually doing the right thing,
> AUTOLOAD subroutines should return a coderef which will be run as if
> it were the method called. If an AUTOLOAD subroutine does not wish to
> cope with a method call, it should return undef. Perl would then wal
> my %STRUCT : constant = (
> Name =>str 'Jane',
Isn't this ambiguous, considering that the => operator quotes the
left side?
-Hao
(I'm not quite in favour. But assuming this flys...)
Why not use Damien's switch syntax. Much more powerful and the flow
is better controlled.
And why add another keyword. Just extend eval{} to accept two blocks.
eval {
}
catch {
}
finally {
}
Wi
On Thu, 10 Aug 2000, Larry Wall wrote:
> Can't put a modifier like "constant" in the type slot. The syntax for
> variable attributes will look more like this:
>
> my num $PI : constant = 3.1415926;
> my int @FIB : constant = (1,1,2,3,5,8,13,21);
> my str %ENG_ERRORS : constant = (E_
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>Why - the 1/10 of second is not exact anyway (unless you happen to
>>have an atomic clock in an appropriate physical enviroment attached to
>>your machine). A double's mantissa is better than your typical oscillator.
>
>While it may not be correct, at lea
Perl6 RFC Librarian wrote:
> It is proposed that a new syntax for declaring constants be introduced:
>
> my constant $PI = 3.1415926;
> my constant @FIB = (1,1,2,3,5,8,13,21);
> my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed');
I like this. Implementation wise, it coul
Why push it through a user subroutine. Might as well make it part of the
core language.
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
I can see the utility of having the callee specify the alacrity of the
parameter. But this would put quit
> We may be able to fake it with source filters and parser abuse, though.
I'm intending to write RFCs on revamping source filters, and also on
run-time access to the parse tree. Just as soon as I grow those two
extra hands so I can run that second keyboard in parallel.
Damian
On Thu, Aug 10, 2000 at 09:30:05AM -0700, Russ Allbery wrote:
> Bart Lateur <[EMAIL PROTECTED]> writes:
>
> > As for the parameter's format: GMT is easy, you can pass "GMT" (or
> > "+"). For localtime(), you often don't explicitely know the time
> > zone and Daylight savings Time rule, so thi
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Instead of calling the right thing or actually doing the right thing,
PRL> AUTOLOAD subroutines should return a coderef which will be run as if
PRL> it were the method called. If an AUTOLOAD subroutine does not wish to
PR
perl parser compiles perl language into perl op-code tree.
Larry ("the" Larry) has said that a new parser might parse
other languages into perl op-code trees too.
If the parts of the language are well organized, a LanguageSwitch
(the computer equivalent of a "context switch" in a conversation
[EMAIL PROTECTED] writes:
: =head1 IMPLEMENTATION
:
: This strikes me as being a fairly easy thing to do, but then again
: internals ain't my thing, baby.
The problem I see here isn't the internals--it's how do you translate
Perl 5 to Perl 6?
Larry
On Thu, 10 Aug 2000 09:34:43 -0700, Peter Scott wrote:
>Do you propose this solely to conserve keywords, or is there another
>advantage? I find
>
> try {
> #
> } catch Exception::Thingy with {
> #
> } catch Exception::Whatsit with {
> #
>
Jeremy Howard wrote:
> The reason that having (1..) implies having (..-1) is that if you allow
> (1..), then this is a valid construct:
>
> @dot_dot_neg_one = reverse (map {-$_} (1..));
>
> which is identical to (..-1)!
No, NOT identical. The same set of numbers, yes, but generated in
the o
> Perhaps Damian's want() (RFC 21) can be used to allow allow either return
> type?
Yes indeed.
> Assuming that's adopted, of course.
Sure looks to me like a good idea; I hope it does.
2000-08-10-12:19:49 Peter Scott:
> Ah, got it. Now we have actually two types of error from builtins:
>
> Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc).
> RFC 70 wants all these to be turned into optional exceptions if Fatal is used.
Ultimately, yes, that's my goal
On Thu, Aug 10, 2000 at 04:47:33PM -, Perl6 RFC Librarian wrote:
> cope with a method call, it should return undef. Perl would then walk
> the OO hierarchy and find the next AUTOLOAD to call, eventually failing
> with an error if no AUTOLOAD method is found which will accept the
> call.
Why n
[EMAIL PROTECTED] writes:
: It is proposed that a new syntax for declaring constants be introduced:
:
: my constant $PI = 3.1415926;
: my constant @FIB = (1,1,2,3,5,8,13,21);
: my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed');
Can't put a modifier like "constant" in the
At 05:46 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> > No, it wouldn't, really. We could make "use fatal;" scoped, so that the
> > quit op (or whatever it is) only jumps through all its hoops if the
> > pragma's in effect. If its not, then
Peter Scott <[EMAIL PROTECTED]>:
>
> try {
> # fragile code
> } catch Exception::IO with {
> # handle IO exceptions
> } catch Exception::Socket with {
> # handle network exceptions
> } otherwise {
> # handle other exceptions
> };
I'd l
Graham Barr wrote:
>
> The catch syntax is less flexable, if you wanted to catch two
> different types with the same code you are forced to either
> * duplicate code
> * put it in a sub, which is away from the statement.
> * put a switch statement in the otherwise
Could catch lists of type
Overloading an existing operator such that it changes the performance
in prior situation is evil, evil, evil. Yes, I know it can have some
wins, and I agree they're big ones. But no win is worth having to
debug this (admittedly contrived for the example) situation:
if ( ( $ares = A() ) && (
On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> No, it wouldn't, really. We could make "use fatal;" scoped, so that the
> quit op (or whatever it is) only jumps through all its hoops if the
> pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return
> and that'
On Thu, Aug 10, 2000 at 09:34:43AM -0700, Peter Scott wrote:
> At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
> >I was more thinking of
> >
> > eval {
> > # fragile code
> > }
> > else { # catch ALL exceptions
> > switch ($@) {
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The AUTOLOAD subroutine should be able to decline a request
=head1 VERSION
Maintainer: Leon Brocard <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 8
=hea
At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
>I was more thinking of
>
> eval {
> # fragile code
> }
> else { # catch ALL exceptions
> switch ($@) {
> case __->isa('IO') { ... }
> case __->isa
Bart Lateur <[EMAIL PROTECTED]> writes:
> As for the parameter's format: GMT is easy, you can pass "GMT" (or
> "+"). For localtime(), you often don't explicitely know the time
> zone and Daylight savings Time rule, so this looks like a good candidate
> for undef.
The string "GMT" is technica
At 12:11 PM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-11:52:31 Dan Sugalski:
> > Why not, then, introduce non-fatal errors and a new keyword to
> > throw them?
>
>Arranging for all the builtins to throw a non-fatal exception would
>impose a cost on the rest of the folks, who prefer to have mo
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> By "local timezone" do you mean that some sort of inspection happens to
> determine the local timezone and the date() intrinsically knows about
> it? What about daylight savings time?
This all should be handled by the operating system. If you c
At 09:44 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-02:40:41 Perl6 RFC Librarian:
> > RFC 70 proposes that all builtins throw trappable exceptions on
> > error.
>
>Not quite. RFC 70 acknowleges that perl's current behavior is
>preferred by some very focal participants in the language's
>dev
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make constants look like variables
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 83
=head1 ABSTRACT
This RF
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make operators behave consistently in a list context
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 82
=he
1 - 100 of 138 matches
Mail list logo
