Re: Indeterminate math
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 an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. If nothing else it would make guarding against indeterminate math easier. Rather than the user having to trap an error, or do possibly complicated work to see if any of the denominators might be zero, you can just see if the result is undef. [1] I apologize for forgetting who. [2] Discussion of divide by zero and why it's not infinity [3] http://mathforum.org/dr.math/faq/faq.divideby0.html [3] I was always taught it's infinity. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Don't worry, baby, my wrath can be pretty groovy. http://www.goats.com/archive/980804.html -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Who are you and what have you done with reality? --Jamin Gray
Re: Indeterminate math
[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, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. The problem with returning undef is that undef numifies to zero. Why can't it return undef but +Inf, or undef but NaN for 0/0, which would then cause a warning/error/nothing, as required by pragma, following the 0 but true that has been discussed previously. Normal numification would presumably propogate the undef but +Inf value. R. -- Richard Nuttall Invisible Networks DDI: 01954 206361 Tel: 01954 22 Mob: 07798 528923 Fax: 01954 206360 Web: www.invisible.uk.net
Re: Lukasiewiczian logic (was Indeterminate math)
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 one of those, but if it can be provided by expansion, that would be neato. Looks like the X value of the 4 (or 9) state logics that ASIC designers use. I suspect that it would be possible to implement this with properties and overloading. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00124.html -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: your mail
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 differently in for(...), when(...) , bits(...), any(...), all(...) . and probably in no special context it implies enclosing any(...) or all(...). so now we will have 4 comma operators : ; | , | , ; ? arcadi.
RE: perl6 operator precedence table
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 ^, newcases; is same as ( cases ^,= newcases; )
the second creates a list of two-element arrays which may be useful.
Another question is whether using a superposition to represent parallel
streams in for is doing the any concept too much violence. Really,
it's more of a hyper-any, at least on the left:
for cases ^| newcases - $x is rw | $y {...}
But note that ^ automatically gives us the shorter of the two lists.
in analogy, may be here
for cases ^, newcases - $x is rw , $y {...}
will do the job . though not clear what happens when arrays have different
length. which proves that | is just special comma.
print arcadi =~ s/Larry/arcadi/ ;
Maybe...
Just thinking... :-)
Larry
arcadi
Re: Indeterminate math
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, 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 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. But will it really matter one way or the other? Probably not, so we should stop quibbling. Perhaps if someone could demonstrate a real-world need for either NaN or infinity in this case, or else a case for why exception-throwing should *not* go away, we'd be able to bring the discussion somewhere more fruitful. For my part: division by zero is so often a programmer error, and so rarely a useful thing to do, that it seems to me that exception-throwing should remain the behavior in Perl 6. Trey
Re: Indeterminate math
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 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. My point was that there is no stone-carved mandate of the ancient mathematicians saying whether the value of 1 / 0 is defined or not. I did not intend to say that you could assign it any value. It is general practice among mathematicians to say that is undefined, but it is also general practice among other respectable ocupations to say it is something like infinite, and both approaches can be formalized. But of course, as you said, this is largelly irrelevant to the actual discussion. My personal opinion is that a language that lets you add apples + oranges and get 0, shouldn't be too picky about 1 / 0 not being a proper number. -angel
Re: Object Instantiation
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; # undef, but new() it if/when we need it our $cache returns FancyCache!; # the same (That's just a joke. Um, I think. Hmm...) Apart from the auto bit of autoinstantiate, that's almost what it means in Eiffel, except there it's a prefix !! operator. Actually, you can specify a subclass between the two shrieks, but perl lets you do that by sticking Class:: on the method name, which means we'd only need one shriek: # ! is the new .= our FancyCache $cache; # declare but leave undef our FancyCache $cache ! new; # create new instance our FancyCache $cache ! ReallyFancyCache::new; # create subclass instance Eiffel does let you omit the name of the constructor if there is a single argumentless constructor, but Eiffel constructors are all marked as such, which (at least so far) Perl6 constructors aren't. -- Peter Haworth [EMAIL PROTECTED] The Hotmail migration is becoming the IT equivalent of painting-the-Forth- bridge, evidently. Once you've think you've finished migrating one end, more FreeBSD boxes reappear at the other. So you have to start all over again. -- http://www.theregister.co.uk/content/28/23348.html
Re: Indeterminate math
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 Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. Well, if you're an exceptions guy like me, you'd *much* rather have it produce an error than a zero, which I assume undef would still evaluate to. NaN is another option, following some standard or other. [2] Discussion of divide by zero and why it's not infinity [3] http://mathforum.org/dr.math/faq/faq.divideby0.html [3] I was always taught it's infinity. Positive or negative infinity? (it's a trap!) -Ken
Prototype-Based Inheritance (was Re: Indeterminate math)
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 enough of that.
I agree, prototype based inheritance is really useful sometimes.
(Those of you not subjected to JS may be more familiar with
Class::Classless, a quite nice perl5 implementation.)
I'd definitely like to see builtin support for instance based
inheritance. I've found many, many uses for Class::Classless, and have
made halfbreed variations of it for several special-case situations.
IMO the best situation would be to have both worlds collide; not
strictly class-based, not strictly proto-based, but a mix-and-match of
each in accordance to the particular problem you're trying to solve.
An interesting way to do this could simply be to allow object
instances, as well as normal classes, in the inheritance tree; you
could then mix a prototype-based object with, for example, several
class-based mixin behaviors, etc.
Something like:
my $obj = Something.new;# (1) obj based on a class
class MyClass is $obj {...} # (2) a class based on an obj!
my $obj2 = MyClass.new; # (3) obj based on a class based on
an obj
my $obj3 isa $obj; # (4) an obj based on another obj
my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
Note that (2) would have interesting implications if you changed $obj
runtime, but would be very uncommon. (4,5) could be quite common, tho.
And (4,5) need to use a word other than 'is', which means that
currently none of these syntaxes look anything alike. :-P
Mixing OO frameworks is quite useful in some real-world situations.
Sometimes it's more efficient to change your OO implementation than to
try to translate your problem to fit the one you're given.
MikeL
A concept for Exceptions
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 of the entire expression, or throwing an exception as usual. JUSTIFICATION Why do I want to augment how exceptions are handled? Is everything about exceptions already invented? The answer is that I hate how Java handles exceptions. In Java it seems like every time you want to do something, you have to surround it with exception handlers. I find that in Java my code becomes buried in exceptions. Yes, the current every-block-is-a-try-block greatly helps this problem, but there's still the looming prospect of having to write mountains of CATCH blocks to handle every problem. What I propose here is a system that provides a technique for actually fixing the problems on the fly, instead of having to hand code error handling every step of the way. Furthermore, the techniques described here provide a way to make certain behaviors modifiable, so that everybody gets their own favorite flavor of ice cream, so to speak. This concept was inspired by the variety of preferences about how Perl6 should handle 1/0. Please note that this is not a proposal for *changing* how exceptions are handled, it's merely an *addition* to the standard techniques. EXCEPTIONCREATOR CLASS Each block gets a reference to an ExceptionCreator object. By default, blocks inherit their parent's reference, so we won't have to be moving and creating references a lot. When the interpretor gets to an error, it calls the ExceptionCreator's standard method for handling that specific type of exception: divByZero(), stringConcatenationUsingUndef(), whatever. The method for that type of exception calls the constructor of an Exception class that is devoted to handling just that type of exception. The Exception's constructor method, described in more detail on the next section, determines how the exception is handled. To change how certain exceptions behave, a block simply changes the methods of the existing ExceptionCreator to point to other subroutines. This approach allows for an ala carte style of exception configuration. Blocks can (through a module that makes this sort of thing easy), clone the ExceptionCreator object, then change just the methods that are desired. A reference to that new object is passed down the line to child blocks. You can also set the default ExceptionCreator reference, i.e. the ExceptionCreator used by default by all blocks in the entire program. By doing so, you can set how certain exceptions are handled by modules that you use but didn't write. For example, suppose I want all string concatenations using undef to be fatal (and I do). I simply override the default ExceptionCreator's concatUndef() method to something more fatal. The following are some of the standard exceptions that the interpretor might throw. I'm sure there a more. These are just the ones that come to mind. - divide by zero - numeric operation on non-numeric value - string concatenation using undef - use of tainted data in protected operation - unsuccesful attempt to open file Modules that provide alternate exception handlers should supply static methods for making the change to a given block. For example, to have div by zero evaluate to Inf instead of a fatal exception, you could simply add this code to your block: use Math::Inf::Exception; and voila, the import routine sets your block's ExceptionCreator for handling div by zero errors. EXCEPTION CLASS Every type of standard exception has its own class. The static constructor method, new, accepts one argument and returns one of three possible values. The input is a reference to the object that caused the exception. This is an optional argument in case no specific object threw the exception. An example of an object that threw an exception would the undef object used in a string concatenation. 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 to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. For example, the undef might have been changed to an empty string. The interpretor will only call each type of exception once for each type of object. If the exception constructor just sets the value to another undef, the interpretor will make a nasty gesture are the handler, so enough of you, and throw its own UnhandledException exception. It must be noted
Re: Prototype-Based Inheritance (was Re: Indeterminate math)
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 supported in the
language, and $a .= foo; should DTRT, ie, $a = $a.foo).
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 enough of that.
I agree, prototype based inheritance is really useful sometimes.
(Those of you not subjected to JS may be more familiar with
Class::Classless, a quite nice perl5 implementation.)
I'd definitely like to see builtin support for instance based
inheritance. I've found many, many uses for Class::Classless, and have
made halfbreed variations of it for several special-case situations.
IMO the best situation would be to have both worlds collide; not
strictly class-based, not strictly proto-based, but a mix-and-match of
each in accordance to the particular problem you're trying to solve.
An interesting way to do this could simply be to allow object
instances, as well as normal classes, in the inheritance tree; you
could then mix a prototype-based object with, for example, several
class-based mixin behaviors, etc.
Something like:
my $obj = Something.new;# (1) obj based on a class
class MyClass is $obj {...} # (2) a class based on an obj!
my $obj2 = MyClass.new; # (3) obj based on a class based on
an obj
my $obj3 isa $obj; # (4) an obj based on another obj
my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
Note that (2) would have interesting implications if you changed $obj
runtime, but would be very uncommon. (4,5) could be quite common, tho.
And (4,5) need to use a word other than 'is', which means that
currently none of these syntaxes look anything alike. :-P
Mixing OO frameworks is quite useful in some real-world situations.
Sometimes it's more efficient to change your OO implementation than to
try to translate your problem to fit the one you're given.
MikeL
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
Re: Indeterminate math
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 an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. Well, if you're an exceptions guy like me, you'd *much* rather have it produce an error than a zero, which I assume undef would still evaluate to. 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 to do about exceptions. 1/0 could throw an exception, yet continue execution. Somewhere I expect we should be able to define a policy for what to do in these situations. use Policy DivideByZero = Nan; use Policy DivideByZero = Inf; use Policy DivideByZero = DivideByZeroException; I'm sure someone else can pick a better syntax than I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Indeterminate math
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 decides to do about exceptions. Agreed. I've meant exception in my comments, in the trappable sense of the term. I don't see much need for a true untrappable error - one man's error is another man's case. 1/0 could throw an exception, yet continue execution. Somewhere I expect we should be able to define a policy for what to do in these situations. use Policy DivideByZero = Nan; use Policy DivideByZero = Inf; use Policy DivideByZero = DivideByZeroException; I'm sure someone else can pick a better syntax than I. I don't think there are going to be many real situations when people would want Inf or Undef (99% of the rare cases where people think they might want it, they're probably wrong ;-), but NaN or Exception could indeed be common needs. -Ken
Re: A concept for Exceptions
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 of the existing ExceptionCreator to point to other subroutines. This approach allows for an ala carte style of exception configuration. Blocks can (through a module that makes this sort of thing easy), clone the ExceptionCreator object, then change just the methods that are desired. A reference to that new object is passed down the line to child blocks. I think a clone should be implicit (and lazy). Exception handlers should be lexically (or dynamically?) scoped. Dynamically could be useful in that if a module generated some known exception, you could tell it what to do---on it's level. I worry that this could break things too easily, though. I definitely like this idea in that it eliminates a lot of redundancy. Instead of 10 CATCH blocks doing the same thing with different names, you just have one handler that does it all. Exceptions are always something that seemed tedious to me (though I have had some fun with them), and this might possibly relieve that. Let's see if we can come up with a more elegant method than the return constant thing. Luke
Re: Indeterminate math
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 decides to do about exceptions. I'm not familiar with that dichotomy. In the OO languages I'm familiar with, errors fall into two basic classes, compile time and run time. Compile time errors are 'fatal', in the sense that they will prevent the program from ever beginning execution. Runtime errors throw exceptions, which may be caught, and if not caught at the top level of execution, will cause the program to abort (or do whatever else it is supposed to do by default when an error propagates that far). Java (and at least one of the Eiffel runtimes I've used) makes a further division in the runtime category between exceptions, which must be handled or declared, and errors, which are conditions like out of memory which are so baroque or whose potential for ocurring is so pervasive as to make required handling a ridiculous burden on the programmer. But you still *may* attempt to handle these errors, if you wish--they are still exceptions. For instance, running on a system in which programs can give previously allocated memory back to the operating system, a program might attempt to use a fast but memory-intensive algorithm, but, upon catching the OutOfMemoryError exception, return the memory to the OS and fall back to a slower but less greedy algorithm. Perl obscures things a bit by its free movement between compile- and runtimes, in some sense collapsing the two types of errors into one, or rather making it possible for either to manifest in the guise of the other. For example, a string eval could cause the ordinarily compile-time syntax error, which would generate a runtime exception, or a BEGIN block might try to perform a division by zero, in which case the ordinarily runtime DivByZero exception would be thrown at compile time (and probably cause the program to never begin execution in the sense we ordinarily think about it). So the compile-time vs. runtime error distinction goes away, so far as the programmer is concerned. Since I assume that Perl will not require that subroutines declare the exceptions they might throw (but I guess we'll find out in the next Apo!), the dichotomy Java sets up goes away, too. So, I think it is completely reasonable to use error and exception as interchangeable terms. If there is a difference, it may be merely in point of view. Errors happen, while exceptions are thrown and caught. 1/0 could throw an exception, yet continue execution. Somewhere I expect we should be able to define a policy for what to do in these situations. use Policy DivideByZero = Nan; use Policy DivideByZero = Inf; use Policy DivideByZero = DivideByZeroException; I'm sure someone else can pick a better syntax than I. I think miko just suggested one, though I'm still digesting it. Trey
Values, Variables, Assignment
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 -- they either haven't been decided yet, or they were and I can't find the answer. If people would take a look and tell me where it's incorrect or stupid, I'd be grateful. MikeL
Re: Indeterminate math
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 to do about exceptions.
Unless I've missed my mark, Perl errors have always been trappable [1]. Does
that make them exceptions? We've been calling them errors for years now.
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 division by zero/ {
... oops ...
}
}
(putting aside that exception handlers stack).
Whatever you call it, exception or error, it will halt the program if left
unhandled.
[1] Less the few odd really hard core the interpreter is having a bad trip
sort of errors.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Here's hoping you don't harbor a death wish!
Perl 6 summary for week beginning 2002-10-07
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 lists. Piers is still off on holiday (bungee jumping and motocrossing, no doubt), so I'm still your host this week. A fairly quiet week, so let's start off with the perl6-internals list as usual. The Pumpking is dead, long live the pumpking! I am happy to report that we have a new Parrot pumpking. Jeff Goff has done great work in the past, but taking over is Steve Fink who has been active in Parrot since near the beginning. He's been extremely active this week, participating in almost all of the discussions and accepting patches left, right and center. http://makeashorterlink.com/?X18F23422 Variables have three parts Dan Sugalski decreed that vtables were about to get more complicated. Variables and values used to be simple, but now we need to have three parts for each thing: an optional name, a container and the contents of the container. There wasn't any discussion, but I expect Dan will rejig vtables some more anyway. http://makeashorterlink.com/?T29F12422 Line number metadata Juergen Boemmels explained that the line number information given by the setline opcode was quite verbose in the source and suggested adding line number metadata into Parrot bytecode. He proposed using the DWARF-2 debugging format (as used by the Mono project) so as not to reinvent the wheel. Dan promised some specs for moving this information out of band. This thread quickly got out of hand, with Nicholas Clark noticing that having column number information magically built in full debugging support for Befunge (a two-dimensional language) and Sean O'Rouke wishing to make source position a vector, thus generalising to scripting languages of any dimension. http://makeashorterlink.com/?A2BF52422 New array base Leopold Toetsch continued in his attempt to confuse the summariser with thousands of patches. He had rewritten the base routines from the array PMC as a working engine for list operations. It should be fast and simple, being based on chunks with fast index get and set. He committed this as list.c, and commented that most of the other array-style PMCs will start to use it as a base, and that it may replace the intlist PMC (and other typed array PMCs). http://makeashorterlink.com/?H2CF32422 Parrot_sprintf Continuing last week's sprintf in Parrot mention, Brent Dax committed a huge patch completing the feature set of Parrot_sprintf, including width and precision for ints and strings, and modified many little bits of code to use it. Inspiration then struck him, or rather, vtables did. He's rewritten it to use vtables, and split some of code out of misc.c and into the new spf_render.c and spf_vtable.c, which managed to turn into another huge patch. Looks like there is a portability issue on PPC systems with va_copy however. http://bugs6.perl.org/rt2/Ticket/Display.html?id=17791 http://bugs6.perl.org/rt2/Ticket/Display.html?id=17817 Nuke dem opcodes Simon Glover proposed a patch to get rid of the 2-element ne opcode, which at a first glance should be optimisable at compiler time and hence should not be in Parrot, barring complicated number precision issues. After a little discussion, Nicholas Clark pointed out that maybe we should do as C99 and state that constant folding will be done at compile time and at the precision of the compiling Parrot. Some of the opcodes where nuked, but it's important to keep some opcodes just in case of overloading. http://makeashorterlink.com/?F1DF46422 Getting Started Guide Cast your minds back, dear readers, if you will, to last week, where Erik Lechak proposed writing a getting started guide. Well, he did just that, starting from the beginning with the configure system and then all the way out. There were many comments and suggestions, and it would be great to see this as POD and in the repository soon. Unfortunately, it is not in the archive. Larry explains all Perl6-language had very few new threads this week. Instead, there were mostly little updates to previous threads, which makes it somewhat tricky to summarise. However, Larry Wall was everywhere this week, giving us detailed insights into the Perl 6 language. Larry clarified that to remove ambiguity, variable properties will surrounded in brackets and have repetitions of is: # instead of this: my $foo is rw cmp ; # we would have: my ($foo is foo is bar, $bar is baz) = (1,2); Additionally, it looked like class attributes had changed
Re: Indeterminate math
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 exception may or may not stop execution depending
on what the user decides to do about exceptions.
Unless I've missed my mark, Perl errors have always been trappable [1]. Does
that make them exceptions? We've been calling them errors for years now.
The Perl trainers I've seen have been calling Perl errors exceptions for
years now, mostly, I think, to shut up the Javaphiles who think that
they're the only ones that have such a wondrous and unprecedented thing
(at least, that's why I always did it ;-)
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 division by zero/ {
... oops ...
}
}
None that I can see.
Trey
Re: Values, Variables, Assignment
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 in Perl is as: 5 as int 5 as string 5 as MyNumber Weren't we going to use constructor-style typecasting (at least as it currently stands)? int(5) # or int.new(5) Not sure -- probably so, but now I'm thinking it couldn't work that way. I don't think typecasting can be constructor-based, because if you said ($obj as MyThing), and $obj was already a MyThing, you probably shouldn't be cloning it, whereas (MyThing.new($obj)) probably should. The keyword but is provided as a synonym for is. A typical use for but is in expressions where the property is perhaps surprising in some way. Nope. Cbut is entirely different from Cis. I think the best description is that Cis is for variables, and Cbut is for values. I can't be sure this is always the case, however Indeed, many of your examples use Cis when they should use Cbut. Thanks, I'll redo. I'm trying to look it up again, but I still can't find the thread. (Apparently I am the only one confused by this, but mighty confused I still be.) MikeL
Re: Indeterminate math
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 division by zero/ {
... oops ...
}
}
(putting aside that exception handlers stack).
Yeah. The latter is not valid syntax in any version of Perl. :)
try {
$foo = 1/0;
print Bar\n;
CATCH {
when /division by [zero|0]/ {
... ooops ...
}
}
}
Luke
Re: Indeterminate math
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 mathematical system that has a definition which is inconsistent with the rest of the system is a flawed one. If you let 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. My point was that there is no stone-carved mandate of the ancient mathematicians saying whether the value of 1 / 0 is defined or not. I did not intend to say that you could assign it any value. Well, yes and no. The original progenitor of the number zero did say that he thought 0 / 0 should be 0, so mathematicians haven't always gotten it right. But it can be proven that 1 / 0 should be undefined, and once it's been proven, it doesn't need to be gone over again -- effectively setting it in stone. So for instance, 1 / 0 is not defined because the division algorithm explicitly fails to work correctly for it[1]. If you can't use the division algorithm how do you expect to divide? It cannot be done. 1 / 0 can only be construed as +Inf if we're discussing limits of functions such that the denominator approaches 0 (from the positive side). It does not appear that we are discussing such things, but the actual integers 1 and 0. Even in the case of limits i am want to be careful, for infinity is not technically a number, but a convenient concept used to describe certain behaviors... It is general practice among mathematicians to say that is undefined, but it is also general practice among other respectable ocupations to say it is something like infinite, and both approaches can be formalized. No offense, but i would love to see someone's formalization that the integer division 1 / 0 is equivalent to infinity. Mostly because i would attempt to rip it asunder :) (i might fail, but i would try...) My personal opinion is that a language that lets you add apples + oranges and get 0, shouldn't be too picky about 1 / 0 not being a proper number. i more have to agree with tilly on this one[2]. Essentially, if i ever divide by zero, it's probably an unmistakable error on my part. And it should raise a trappable error so that if i'm expecting it i can shuffle it under the rug, and if i'm not i'll be notified that something went 'splody. jynx [1]: This comes from a recent discussion on perlmonks where i attempted to formally iron things out for people, since i have yet to see anywhere thus far on the web where it was actually formalized. (formalization being markedly different from rationalization) http://www.perlmonks.org/index.pl?node_id=203698 [2]: Tilly's opinion can be found at the following: http://www.perlmonks.org/index.pl?node_id=98996 +-+ |jynx d mouse | |[EMAIL PROTECTED]| |You're just another X --Filter| +-+
Re: A concept for Exceptions
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 certain common types of exceptions could be handled in-place, instead of having to write exception handlers. Perl5 already does some things like this, e.g. undefs become empty strings and zeros when needed. I'm just suggesting formalizing the process more so that custom in-place exception handlers can be implemented. Does that make the return what to do concept a little more elegant? If not, feel free to work a Pygmalion with my Eliza Doolittle. -miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: A concept for Exceptions
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 to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. While a nifty idea, this is not going to happen, at least not in the general case. Restartable exceptions are very, very difficult to do. (And parrot, alas, isn't going to be able to do them) You still need to establish an exception handler at the spot you want to restart at (which isn't free, alas) and you run into problems when you cross some internal boundaries in the interpreter. That won't stop you from throwing a continuation when you throw your own exceptions, which your own exception handlers can invoke when they see fit, but low-level exceptions like division by zero and suchlike things won't be able to do that. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
