At 2:33 PM -0400 10/15/02, [EMAIL PROTECTED] wrote:
>
>The constructor returns one of three values: an exception object, the
>DO_OVER constant, or the EXPRESSION constant.
>
>If an exception object is returned, that means that the interpretor should
>immediately exit the block, throwing the except
From: Luke Palmer [EMAIL PROTECTED]
> I like the idea of this. The finer details, like returning
> what to do, could be more elegant. But the extensibility
> idea is golden.
Thanks Luke. Your email made me think of another way of explaining the
concept. Basically, what I'm suggesting is that
long time reader, first time writer...
On Tue, Oct 15, 2002 at 10:06:37PM +0200, Angel Faus wrote:
> >
> > > Mathematically, 1/0 is whatever you define it to be.
> >
> > Well, sure. That's as axiomatic as saying, "mathematically, the
> > number one is whatever you define it to be." But a mathe
> Put another way, is there a significant difference between:
>
> eval {
> $foo = 1/0;
> print "Bar";
> }
> if( $@ =~ /^Illegal division by zero/ ) {
> ... oops ...
> }
>
> and
>
> try {
> $foo = 1/0;
> print "Bar";
> }
> catch {
>
On Tuesday, October 15, 2002, at 01:07 PM, Luke Palmer wrote:
>> Any value may be forced, however, into being an explicit type: this is
>> commonly known as casting or typecasting. Typecasting is the act of
>> transforming a value of one type into a value of another type. The
>> typecasting ope
In a message dated Tue, 15 Oct 2002, Michael G Schwern writes:
> On Tue, Oct 15, 2002 at 01:44:50PM -0500, Jonathan Scott Duff wrote:
> > People have used the terms "error" and "exception" interchangably in
> > this disucssion. To me, an "error" is something that stops program
> > execution whil
On Tue, Oct 15, 2002 at 01:44:50PM -0500, Jonathan Scott Duff wrote:
> People have used the terms "error" and "exception" interchangably in
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what the u
> Date: Tue, 15 Oct 2002 12:24:56 -0700
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> In Perl, variable names always begin with a special character called
> a sigil,
Ahem, "funny character." The Camel glossary has no entry for "sigil"
(though I realize it's common terminology).
>
> Any value
I was writing up a quick beginner-level summary on variables &
assignment yesterday evening, mostly to get my head around the syntax
as it currently stands. You can see it at
http://cog.cognitivity.com/perl6/var.html
if desired. The 3 or 4 parts in red are things that I'm making up
In a message dated Tue, 15 Oct 2002, Jonathan Scott Duff writes:
> People have used the terms "error" and "exception" interchangably in
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what the user
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Tue, 15 Oct 2002 14:33:28 -0400
I like the idea of this. The finer details, like returning what to
do, could be more elegant. But the extensibility idea is golden.
> To change how certain exceptions behave, a block simply changes the meth
Perl 6 summary for week beginning 2002-10-07
This is yet another Perl 6 summary, documenting what has happened over
on the perl6-internals (where Parrot, the virtual machine that will run
Perl 6 is discussed) and perl6-language (where Perl 6 language design is
discussed) mailing li
On Wednesday, October 16, 2002, at 04:44 AM, Jonathan Scott Duff wrote:
> People have used the terms "error" and "exception" interchangably in
> this disucssion. To me, an "error" is something that stops program
> execution while an "exception" may or may not stop execution depending
> on what
On Wed, Oct 16, 2002 at 02:54:37AM +1000, Ken Williams wrote:
>
> On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote:
> > This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> > produce a divide by zero error in Perl 6, or if it would return a value
> > represe
Would it make sense for the syntax to be more like
my $obj3 = $obj.new;
Of course, that would kill my ".= new" idea for instantiation (since it would
call an instance-based new instead of class-based), but I'm getting less fond
of that syntax anyway (though I think .= should definitely be suppo
A brainstorm for your enjoyment, perusal, and general discussion...
SUMMARY
A proposal for an extension to the usual exception handling concept. The
concept detailed here provides a mechanism for handling exceptions in one
of three ways: changing the values being evaluated, setting the result
On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
> Heh, indeed. :) But seriously, you could do worse. JavaScript
> receives
> a lot of (IMHO) undeserved criticism. The name is a blatant marketing
No, I've had to use it off-and-on for the past year... it deserves it.
:-) But
On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote:
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> produce a divide by zero error in Perl 6, or if it would return a value
> representing an indeterminate result (undef?) It would make more sense
> for
On Fri, 11 Oct 2002 14:05:30 -0700, Michael Lazzaro wrote:
> Maybe postfix ! on a class name means to autoinstantiate an object of
> the named class only if/when first accessed:
>
> our FancyCache $cache; # declare, but leave undef
> our FancyCache! $cache;
>
> > Mathematically, 1/0 is whatever you define it to be.
>
> Well, sure. That's as axiomatic as saying, "mathematically, the
> number one is whatever you define it to be." But a mathematical
> system that has a definition which is inconsistent with the rest of
> the system is a flawed one. If
In a message dated Tue, 15 Oct 2002, Angel Faus writes:
>
> > Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> > in the set of rational numbers. The IEEE may say otherwise.
>
> Mathematically, 1/0 is whatever you define it to be.
Well, sure. That's as axiomatic as saying,
> Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> in the set of rational numbers. The IEEE may say otherwise.
Mathematically, 1/0 is whatever you define it to be.
And it is perfectly correct to assume that operations happen in the
extended real line, and thus that 1/0 i
>
>And I really do like | for any(). And I can see using it like this:
>
>@cases ^|= @newcases;
>
>to mean
>
>for @cases | @newcases -> $x is rw | $y {
> $x = any($x, $y);
>}
>
but then probably we should also have
@cases = @cases ^| @newcases; is same as ( @cases ^|= @newcas
>I don't think the C construct would be dealing with real
>superpositions at the top level. I was just thinking about stealing
>the | and & notation.
so, "|", "&", are special "meta-comma" operators that create a (meta:-) "list"
with additional relation between entries. this (meta)list expands
On Mon, Oct 14, 2002 at 06:27:48PM -0700, David Whipp wrote:
> > it looks like "Lukasiewiczian NULL" is just the nifty NULL
> > that SQL has, and the nifty ways that it affects logical
> > and aggregate operations. Actually, something I wouldn't mind
> > seeing in other languages -- I can't say if
[EMAIL PROTECTED] wrote:
>From: Michael G Schwern [EMAIL PROTECTED]
>
>
>>This came up at YAPC::Europe. Someone [1] wanted to know if 1/0
>>would produce a divide by zero error in Perl 6, or if it would
>>return a value representing an indeterminate result (undef?)
>>It would make more sense f
Sounds like a good place for "fail", as described in Exegesis 4, so that it
could be taken as undef or an exception depending on pragmata.
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would
> produce a divide by zero error in Perl 6, or if it would return a value
> represent
27 matches
Mail list logo
