Jason Gloudon wrote:
On Mon, Oct 14, 2002 at 08:31:16PM +, Leopold Toetsch wrote:
headers.c:
- set PMCs and Buffers initially to live. This helps somwhat, that
initially created objects are not killed immediately by a DOD run e.g.
in midst of string_make
But what happens where
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
representing
--- 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 look
into.
--- 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 an asm to
[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 for Perl,
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 perl is
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 the op:
I don't think the Cfor 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 ^|= newcases; )
cases = cases
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 is
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 you let
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
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
representing
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 the user
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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17931
I send this to the list first, because
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 methods
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
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 may be
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 user decides
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 while an
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 operator
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 {
when /^Illegal
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 imagine
ways of
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
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 exception
32 matches
Mail list logo
