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
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
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
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
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
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
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, 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
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
--- 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
--- 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
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
34 matches
Mail list logo
