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
--- Karthik Kumar <[EMAIL PROTECTED]> wrote:
> Hi Leon,
>
> --- Leon Brocard <[EMAIL PROTECTED]> wrote:
> > Karthik Kumar sent the following bits through the
> ether:
> >
> > > Can you please let me know if any work going on
> relative to this or
> > > any src code tree that you would me to loo
--- Bala Karthik <[EMAIL PROTECTED]> wrote:
>
> Hi Ramesh,
>
> That sounds exciting. Just wanted to clarify on your
> suggestion. Are you saying that the parrot compiler
> should be able to decipher the asm generated by any
> C code.
Well... EIther we just compile C down to Parrot. Or
work at a
[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
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
On Mon, 14 Oct 2002, Leon Brocard wrote:
> Jonathan Sillito sent the following bits through the ether:
>
> > I have been playing with classes and instances for parrot. In
> > the process I found I needed a way to pass more information when
> > creating new pmcs. So the attached patch adds th
>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
>
>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
> 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
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 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
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;
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 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
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
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
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
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
Leopold Toetsch (via RT) wrote:
> # New Ticket Created by Leopold Toetsch
> # Please include the string: [perl #17931]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17931 >
>
>
> I send this to the list first, becaus
> 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
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
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
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
> 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
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
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 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
> 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 {
>
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
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
On Mon, Oct 14, 2002 at 10:06:54AM +0200, Leopold Toetsch wrote:
> Steve Fink wrote:
>
>
> >The problem is that the JIT doesn't support tracing.
>
>
> No, the problem is, that restarting JIT is broken. So it's truely a bug
> and should not be marked with SKIP or TODO.
>
> >... I could imagi
Well I hope there are some interested parties out there for this. The
new and improved "getting started" guide should be ready in pod by
Thursday. I have added more content and tried to incorporate the
suggestions that everyone gave to me. The document is growing as I
learn more. I have t
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
Steve Fink wrote:
> On Mon, Oct 14, 2002 at 10:06:54AM +0200, Leopold Toetsch wrote:
>>This is, what restart NEXT() does.
>>
>
> That's what I originally thought, but there seemed to be no attempt at
> implementing this in the code, so I though it must not have been
> attempted yet -- hence the
34 matches
Mail list logo
