Re: untaintby property
I think that if a package deliberately tries to untaint data, and then
the data isn't untainted, there will be an error shortly.
Perhaps you could be more specific about what you mean by untainting
things which shouldn't be untainted? Did you mean globals?
Otherwise, I'd think that if a package author untainted data, you
should let him have it untainted. If the data wasn't untainted
CORRECTLY, that's a bug. But otherwise?
=Austin
--- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
SUMMARY
The 'untaintby' property restricts which modules may untaint the data
or
data derived from that data.
DETAILS
I was recently using a module I downloaded from CPAN and looking
through
the code I discovered that it untainted certain data that it had no
business untainting (IMHO). The untainting was an unintended
byproduct of
some otherwise useful work. (See my earlier concern about untainting
at
http://makeashorterlink.com/?Y28261A12)
Now, tainting is a funny thing: it's an admission that maybe your
program
doesn't work quite the way you want it to. I submit that if it's
healthy to
doubt the perfection of your own code (even though you run it), it's
also
healthy to doubt other people's code (even though you use it). I
would feel
a little more comfortable if I could say I'll hold back the
untainting to
just my own code.
Here's my little brainstorm. Objects can be marked with a property
called
'untaintby'. The value of the property is a list of modules that are
allowed to untaint the data. Example:
my $command is untaintby('MyApp::Commands', 'Util::IdCheck')
= CGI.param('command');
Any module that isn't authorized by that list cannot untaint the
data, and
cannot derive untainted data from it. No error results from a class
trying
to do an unauthorized untaint: the data just isn't untainted.
So, for example, if the data were copied into $privatecmd in
Foo::Bar, that
copied value would inherit the untaintby property. If a regex were
run
against $privatecmd...
# bad untainting, bad!
$mycmd =~ m|([^!-`])+|;
$newcmd = $1;
... $newcmd would also inherit the untaintby property, and would
still be
tainted. Modules may further restrict the untaintby property (i.e,
shorten
the list) but they may not add to it.
The module that initially sets the untaintby property is by default
included in the list, so to restrict to just the current class you
could
say
my $command is untaintby() = CGI.param('command');
(Hmm, I'm not sure about that, though. It isn't clear just reading
it that
the current module can untaint. What do you think?)
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos More
http://faith.yahoo.com
RE: perl6 operator precedence table
On Sun, 13 Oct 2002, fearcadi wrote: : in : http://archive.develooper.com/perl6-language%40perl.org/msg11440.html : Larry Wall wrote: : I'm wondering whether the single ones could indicate parallel streams. : We had the difficulty of specifying whether the Cfor loop should : terminate on the shorter or the longer stream. We could say that | : terminates on the longer, and on the shorter. Possibly there's : some relationship with any() and all() in there as well. The | could : generally be construed as a comma that doesn't guarantee ordering. : So cases could be written : : but then in the for loop a | b should result in *ordered* : any(a,b) because we need to distinguish the first and second stream when : attaching to the arguments of - ... closure. : : While inside when a|b results in unordered any(...). : How this lives together? The | or doesn't really indicate a superposition in the Cfor. All I meant by unordered was that it was not guaranteed that a is evaluated before b, so they could in theory be evaluated in separate subthreads. The Cfor loop would just be stealing the |/ notation because it's convenient to be able to distinguish whether both values have to be there or only one for the loop to continue. The streams would stay discrete, however. And the $a | $b in the declaration would likewise not be producing an any(). It's just a funny kind of anchor to pattern match the formal args against the actual args. But we haven't thought through all the ramifications yet, so it may yet turn out to be a bad idea. Larry
Re: perl6 operator precedence table
On Sun, 13 Oct 2002, Aaron Crane wrote:
: Luke Palmer writes:
: Some of my students want to go:
:
: if ($x == 1 || 2) { ... }
:
: Now they can:
:
: if $x == 1 | 2 { ... }
:
: I like that a lot. (Some of my students also want to do that.)
:
: You can write an equivalent thing in Icon:
:
: if x = (0 | 1)
:
: though (if memory serves) the parens are required. And in Icon it's done
: with backtracking, not superpositions.
The optimizer could certainly choose to implement it with backtracking
if that was deemed to be more efficient and just as correct. The big
value of superpositions is that they're a declarative syntax for
something that would otherwise have to be specified procedurally.
But everything ends up procedural underneath, at least with our
current computers.
I think that any() really needs to avoid making any guarantees
about whether (and in what order) its arguments are evaluated.
(Use || if you want to be sure.) In a sense, that's the way
QM-based nanomachinery works anyway--progress is never guaranteed
unless an external constraint is met. In other words, you just
run probabistically on Brownian motion until something latches.
Proteins just happen to be very good at latching.
Larry
Re: Draft Proposal: Declaring Classwide Attributes
On Sun, 13 Oct 2002, Piers Cawley wrote:
: I like that idea:
:
:class SomeClass {
: method class_method ( Class $class: ... ) { ... }
: method instance_method ( SomeClass $self : ... ) { ... }
: method dont_care_method ( $self : ... ) { ... }
:}
:
: Or will 'Class' actually be CLASS by analogy with HASH, ARRAY etc?
I'm not sure we're sticking with the all-uppercase built-in types.
They're kind of ugly, and we keep running into boundary cases.
So I think the built-in class types will start with an initial cap,
and the built-in primitive types will be all lowercase. So a general
polymorphic integer object is Int, while a low-level, C-like integer
is int. (An array of int is guaranteed to be stored compactly,
for instance.)
And I suspect it would make some people happy to turn class UNIVERSAL
into class Object.
Larry
Re: Draft Proposal: Declaring Classwide Attributes
On Sun, 13 Oct 2002, Trey Harris wrote: : I was going to say the same thing, but then I remembered that Perl 6 : methods, unlike the sub 'methods' in Perl 5, won't get the invocant as the : first real argument--it will be the topic instead. And I don't think you : can do multiple-dispatch on topic, can you? The topic *is* the first real argument. It's just that you aren't required to name the first argument. Whether an argument has a name or not is somewhat independent of whether it can participate in multiple dispatch. It might be convenient for the argument to have a type, however. The use of an implicit invocant should not be confused with out-of-band topicalization. That's a mechanism for binding the outer topic to a formal parameter that is not necessarily the inner topic. Larry
Re: your mail
On Sun, 13 Oct 2002, fearcadi wrote:
: in
: http://archive.develooper.com/perl6-language%40perl.org/msg11451.html
: Larry Wall wrote:
: for cases ^| newcases - $x is rw | $y {...}
:
: do I understand correctly that what happens is (more or less) --
: any($a,$b) := any($x,$y)
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.
Larry
Re: untaintby property
If properties aren't entirely passive, then it may be possible to register a callback on the tainted property itself that defeats any misguided attempt to untaint it. It's unlikely to protect against malicious attempts, however. Larry
Re: Draft Proposal: Declaring Classwide Attributes
On Sun, 13 Oct 2002, Michael Lazzaro wrote:
: My temporary hack while writing the proto-recipes was that we'd have a
: property that would simply declare a method to be a class method, but
: I'm having a hard time coming up with an acceptable name to suggest for it:
:
: method foo is class_method { ... } # ???
:
: It feels, conceptually, like something that should be a property. The
: other possibility is to use a keyword other than method for class
: methods, but that would also require us to think of a word (and would
: probably just be shorthand for a named property anyway). So, I haven't
: been able to come up with a single decent noun or adjective that means
: class method, so far. (classwide? static? blind? classmeth? cmethod? classorific?)
Doesn't feel like a property to me. Feels to me like a type-coercion on
the invocant. Or if not a coercion exactly, a view of the desired type
of the invocant.
: Regardless of how we declared it, my operating theory was that any
: method declared as a class method would automatically be able to take
: either a class or a class instance as it's invocant, and do the right
: thing (i.e. when using an instance to invoke a class method, it would
: automatically convert it to a class before assigning it as the topic, so
: the implementing method wouldn't even notice, unless it went out of it's
: way to look.)
If every Object happens to implement the Class interface, merely
declaring the invocant as a Class would presumably have this effect,
whether or not MD was in effect. I don't know whether that's a good
idea or a bad idea. I'm sure there are people out there with opinions
on the subject, though.
: This would DWIM, would mean we don't need multiple dispatch for it (at
: least not in visible form) and would be in line with the common perl5 strategy:
: $class = ref $class if ref $class;
:
: If you *did* want a method that treated invoke-by-classname and
: invoke-by-instance differently (i.e. a constructor), you simply wouldn't
: declare it as a class method, and have the method check the topic itself.
We haven't solved the problem of instance methods that want to
reject class invocants at compile time. Though I suppose explicitly
declaring the type of the invocant would have that effect. I'm sure
there are some who would argue (and I might be one of them) that an
implicit invocant should default to only accepting an instance, and
you have to declare an untyped invocant to get class-or-instance.
(Or declare it with a class superposition like (Class|Dog), which
presumably lets you pass either a Class instance or a Dog instance).
Larry
Re: Draft Proposal: Declaring Classwide Attributes
--- Larry Wall [EMAIL PROTECTED] wrote:
On Sun, 13 Oct 2002, Michael Lazzaro wrote:
: My temporary hack while writing the proto-recipes was that we'd
have a
: property that would simply declare a method to be a class method,
but
: I'm having a hard time coming up with an acceptable name to suggest
for it:
:
: method foo is class_method { ... } # ???
:
: It feels, conceptually, like something that should be a property.
The
: other possibility is to use a keyword other than method for class
: methods, but that would also require us to think of a word (and
would
: probably just be shorthand for a named property anyway). So, I
haven't
: been able to come up with a single decent noun or adjective that
means
: class method, so far. (classwide? static? blind? classmeth?
cmethod? classorific?)
Doesn't feel like a property to me. Feels to me like a type-coercion
on
the invocant. Or if not a coercion exactly, a view of the desired
type
of the invocant.
An instance of class Class is wierd, because it defines two different
sets of things: internal bits, usually called static, and
interitable/delegatable bits (both data and methods) which will be
present in all the instances of the type.
Javascript makes for a good thinking-about language here because the
constructors must explicitly attach each function and each member of
the new class.
Perl5 had some of this with bless'ing an anonymous, initialized hash --
the act of creating the data members was overt.
C++/Java, OTOH, fall into the trap of treating the class as a structure
definition -- once they've gone this route, there's the question of
what secret word do we use to escape from the structure model --
answer static.
According to Java, there's four sets of permissions available for
members: private, package (no keyword), protected, public.
Package means anything in the same package, Protected is package
plus subclasses.
I wonder if there's actually another aspect here: That which is
accessible to instances. (Particular?)
Static members are usually considered class-global, but uniformly
visible to the instances. Is it useful to talk about variables which
belong in the class object but which may or may not be visible to the
instances?
This may be more meaningful in the context of a tainted object, or in
conjunction with inheritance (we allow direct instances to access this
variable, but not instances of subclesses).
: Regardless of how we declared it, my operating theory was that any
: method declared as a class method would automatically be able to
take
: either a class or a class instance as it's invocant, and do the
right
: thing (i.e. when using an instance to invoke a class method, it
would
: automatically convert it to a class before assigning it as the
topic, so
: the implementing method wouldn't even notice, unless it went out of
it's
: way to look.)
If every Object happens to implement the Class interface, merely
declaring the invocant as a Class would presumably have this effect,
whether or not MD was in effect. I don't know whether that's a good
idea or a bad idea. I'm sure there are people out there with
opinions
on the subject, though.
That paragraph is a little counterintuitive? Wouldn't Class implement
the Object interface?
=Austin
__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos More
http://faith.yahoo.com
Re: Draft Proposal: Declaring Classwide Attributes
On Mon, 14 Oct 2002, Larry Wall wrote: : We haven't solved the problem of instance methods that want to : reject class invocants at compile time. Though I suppose explicitly : declaring the type of the invocant would have that effect. I'm sure : there are some who would argue (and I might be one of them) that an : implicit invocant should default to only accepting an instance, and : you have to declare an untyped invocant to get class-or-instance. : (Or declare it with a class superposition like (Class|Dog), which : presumably lets you pass either a Class instance or a Dog instance). And I should point out that this approach would be good not just for type purity, but because it optimizes for the common case. Class methods are much rarer than instance methods. And the class-or-instance approach seems to be even rarer than ordinary class methods, in practice. Larry
Re: untaintby property
Larry said: If properties aren't entirely passive, then it may be possible to register a callback on the tainted property itself that defeats any misguided attempt to untaint it. Callbacks on properties? That's too cool. By doing callbacks on tainted and on taintby, a module could be written to implement my ideas without having to fiddle with the language itself. Too groovy. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: untaintby property
I'd say the correct solution isn't to control which modules can accidentally untaint data (it seems pretty likely that no matter what we do, maliciously coded modules will be able to screw you over if they try to do so intentionally) but rather fix those aspects of tainting that allow any module to accidentally untaint data. Personally, I think untainting data should only be the result of an explicit untaint function, but maybe that's going too far. -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Her hair glistened in the rain like nose hair after a sneeze. (Chuck Smith, Woodbridge)
Re: Draft Proposal: Declaring Classwide Attributes
On Monday, October 14, 2002, at 10:28 AM, Larry Wall wrote:
On Mon, 14 Oct 2002, Larry Wall wrote:
And I should point out that this approach would be good not just for
type purity, but because it optimizes for the common case. Class
methods
are much rarer than instance methods. And the class-or-instance
approach
seems to be even rarer than ordinary class methods, in practice.
Of course, in hindsight. So we have three cases to deal with:
- a method that can only take an instance (80% of the time?)
- a method that can take only a Class (15% of the time?)
- a method that can deal with both ( 5% of the time?)
The first two are well-understood and common behaviors, and probably
shouldn't force you to declare the invocant at all. The third form is
almost never what you mean (except in constructors and a few other
places) and should be discouraged compared to the other two.
In a message dated Sun, 13 Oct 2002, Piers Cawley writes:
I like that idea:
class SomeClass {
method class_method ( Class $class: ... ) { ... }
method instance_method ( SomeClass $self : ... ) { ... }
method dont_care_method ( $self : ... ) { ... }
}
So if the first two should be shorter than the third, one way to do
that would be something like:
class SomeClass {
cmethod class_method {...} # via a keyword
method instance_method {...} # via another keyword
sub dont_care_method {...} # check it yourself, as 1st arg
}
Except for the fact that the word 'cmethod' is not a terribly intuitive
choice.
In general, I'd vote for making the distinction through a keyword
rather than through more subtle hints: it seems the shortest way to say
what you mean, and the first two cases are certainly common enough to
justify them. Trying to put the distinction in the method name itself
makes me worry that other things are going on, like implicit
typecasting or something:
method SomeClass.class_method {...}
And putting it in the argument list makes me think at first glance that
it's an argument, but not necessarily an invocant:
method class_method ( Class $class : ... ) { ... }
(looks a lot like) ...
method class_method ( Class $class, ... ) { ... }
which, I assume, does something completely different.
MikeL
Re: Draft Proposal: Declaring Classwide Attributes
In a message dated Mon, 14 Oct 2002, Michael Lazzaro writes:
So if the first two should be shorter than the third, one way to do
that would be something like:
class SomeClass {
cmethod class_method {...} # via a keyword
method instance_method {...} # via another keyword
sub dont_care_method {...} # check it yourself, as 1st arg
}
Except for the fact that the word 'cmethod' is not a terribly intuitive
choice.
I don't know about this precisely, but I will say that I have a strong
intuition that Csub within a class block Ishould mean something, and
be neither a syntax error nor a synonym for Cmethod.
Trey
Re: Draft Proposal: Declaring Classwide Attributes
Austin Hastings [EMAIL PROTECTED] writes: --- Larry Wall [EMAIL PROTECTED] wrote: If every Object happens to implement the Class interface, merely declaring the invocant as a Class would presumably have this effect, whether or not MD was in effect. I don't know whether that's a good idea or a bad idea. I'm sure there are people out there with opinions on the subject, though. That paragraph is a little counterintuitive? Wouldn't Class implement the Object interface? I would expect Class to inherit from Object (along with everything else). It might be worth looking at a Smalltalk image or two at this point... -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Draft Proposal: Declaring Classwide Attributes
On Monday, October 14, 2002, at 11:57 AM, Trey Harris wrote:
class SomeClass {
cmethod class_method {...} # via a keyword
method instance_method {...} # via another keyword
sub dont_care_method {...} # check it yourself, as 1st arg
}
Except for the fact that the word 'cmethod' is not a terribly
intuitive
choice.
I don't know about this precisely, but I will say that I have a strong
intuition that Csub within a class block Ishould mean something,
and
be neither a syntax error nor a synonym for Cmethod.
Sorry, what I meant was that you would just use 'sub' when you don't
want the enforcement of invocant that either of the first two imply,
i.e. you'd use sub in the perl5 way:
sub dont_care_method {
my $self = shift;
if (ref $self) {
...
} else {
...
}
}
So sub is still just a perl5 sub, where the invocant is passed as the
first arg.
MikeL
Re: Draft Proposal: Declaring Classwide Attributes
On 2002-10-14 at 19:58:50, Piers Cawley wrote: I would expect Class to inherit from Object (along with everything else). It might be worth looking at a Smalltalk image or two at this point... You might want to look at _Putting_Metaclasses_To_Work_ by Danforth and Forman - or at Ruby, which follows the same model (with one extra class introduced into the hierarchy). In this model, classes are objects, but they are not instances of their superclass. The subclass relation is separate from the instance of relation. The minimal environment is this: Object is an instance of Class. Class is also an instance of Class - that is, an instance of itself. Class is a subclass of Object. Ruby's small variation consists of a class called Module between Class and Object: Module (also an instance of Class) is a subclass of Object and the direct superclass of Class. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
RE: Draft Proposal: Declaring Classwide Attributes
On Mon, 14 Oct 2002, Larry Wall wrote: : We haven't solved the problem of instance methods that want to : reject class invocants at compile time. Though I suppose explicitly : declaring the type of the invocant would have that effect. I'm sure : there are some who would argue (and I might be one of them) that an : implicit invocant should default to only accepting an instance, and : you have to declare an untyped invocant to get class-or-instance. : (Or declare it with a class superposition like (Class|Dog), which : presumably lets you pass either a Class instance or a Dog instance). In your superposition example (Class|Dog), am I'm assuming correctly that you could invoke that method with an instance of any object that IS-A Dog? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Indeterminate math
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
Re: Indeterminate math
Michael G Schwern sent the following bits through the ether: 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?) This is probably the mathematician in me escaping, but I also remember a discussion at Y::E about number systems. What if you didn't want Perl to use the normal number system, but instead only have, say, positive integers, or integers modulo prime P. This is possible with Perl 5, but with lots of scary overloading. Will it be any different in Perl 6? [Or are we not quite there yet?] Cheers, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ Any wire cut to length will be too short
RE: Indeterminate math
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. It would make more sense if either 1/0 returned NaN, if Perl6 has NaN, or throw an error, which Larry has indicated will be a concept in Perl6. There once was a man from NaNtucket Who kept all his bits in a bucket He said I'm a hero! I divided by zero! and the bits in the bucket, they tuckit! -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: untaintby property
On Mon, Oct 14, 2002 at 10:09:41AM -0400, [EMAIL PROTECTED] wrote: SUMMARY The 'untaintby' property restricts which modules may untaint the data or data derived from that data. DETAILS I was recently using a module I downloaded from CPAN and looking through the code I discovered that it untainted certain data that it had no business untainting (IMHO). The untainting was an unintended byproduct of some otherwise useful work. (See my earlier concern about untainting at http://makeashorterlink.com/?Y28261A12) The concern here seems to be more about unintentional untainting rather than deliberate untainting by unauthorized parties. Rather than add an additional, explicit security system on top of an implicit security system, the causes of unintentional untainting in the language should be reduced. Something in the family of your original /T regex proposal would make more sense. Attack the problem at its source. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do you have a map? Because I keep getting lost in your armpits.
Re: Indeterminate math
At 10:38 PM +0100 10/14/02, Leon Brocard wrote: Michael G Schwern sent the following bits through the ether: 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?) This is probably the mathematician in me escaping, but I also remember a discussion at Y::E about number systems. What if you didn't want Perl to use the normal number system, but instead only have, say, positive integers, or integers modulo prime P. This is possible with Perl 5, but with lots of scary overloading. Will it be any different in Perl 6? [Or are we not quite there yet?] I expect the overloading will be just as pervasive, though perhaps not as scary as in perl 5. (I suppose you could just go override the vtable methods for all the core data types... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Indeterminate math
On Mon, Oct 14, 2002 at 05:45:23PM -0400, [EMAIL PROTECTED] wrote: The problem with returning undef is that undef numifies to zero. Yes, but it does produce a warning. It would make more sense if either 1/0 returned NaN, if Perl6 has NaN, or throw an error, which Larry has indicated will be a concept in Perl6. What happens when NaN is used in an expression? Is NaN + 0 == NaN? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One 11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. -- RFC 1925
Re: Indeterminate math
On Mon, Oct 14, 2002 at 07:06:57PM -0400, Michael G Schwern wrote: What happens when NaN is used in an expression? Is NaN + 0 == NaN? Actually, NaN is never equal to anything at all, even NaN. Many languages have an isNaN() function for that. -- David cogent Hand http://davidhand.com/ mailto:[EMAIL PROTECTED] icq:4321282
Re: Indeterminate math
Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of dividing by 0 if the numerator is either infinite or also 0. The reason most implementations throw an error on division by 0 is that they either don't have a representation for infinity (not a problem in IEEE floating point) or the rest of the arithmetic operations don't behave sensibly when handed an infinite value. I would argue that Perl's arithmetic operations should behave sensibly on infinite values and that 1/0 should therefore just return +Infinity. No exception, no error, no undefined value. Summary of values: 1/0+Inf -1/0-Inf 0/0NaN Inf/0 NaN (Sign doesn't matter for these two; Inf/Inf NaN +Inf and -Inf may be interchanged) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On 2002-10-14 at 19:48:23, Mark J. Reed wrote: Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of dividing by 0 if the numerator is either infinite or also 0. The reason most implementations throw an error on division by 0 is that they either don't have a representation for infinity (not a problem in IEEE floating point) or the rest of the arithmetic operations don't behave sensibly when handed an infinite value. Well, let me backpedal a bit, here. I realize the above is mathematically simplistic. The real reason y = x/0 returns an error is because no matter what value you assign to y, you aren't going to get x back via multiplying y by 0. Certainly 0 times infinity is not going to give you back your original numerator; the infinity value of x/0 is just a convention, inspired by the fact that the *limit* of x/z as z approaches 0 is infinity. So it's probably a good idea when doing $y = $x/$z to notice that $z is 0 before later trying to get $x back by multiplying $y * $z. I suspect the erroneousness of division by 0 should be pragmatically controlled. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On Mon, Oct 14, 2002 at 07:48:23PM -0400, Mark J. Reed wrote: Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of dividing by 0 if the numerator is either infinite or also 0. There are several verbal proofs why 1/0 is not +Infinity here: http://mathforum.org/dr.math/faq/faq.divideby0.html -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: Indeterminate math
From: Mark J. Reed [EMAIL PROTECTED] Summary of values: 1/0 +Inf -1/0 -Inf 0/0 NaN Inf/0NaN Inf/Inf NaN Are Inf and NaN going to be standard in Perl 6? As long as we're traveling down that road, how about i (the square root of -1), or Lukasiwiscean Null? (Sorry if I sound sarcastic, I'm actually honestly curious.) My inner Larry Wall is right now saying that there needs to be a more generalized solution to all this. OK, here's one. By default, anything/0 throws an exception. However, you can load modules to handle those exceptions, substituting Inf, NaN, or whatever as the evaluation of the expression. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Indeterminate math
On 2002-10-14 at 20:15:33, Michael G Schwern wrote: There are several verbal proofs why 1/0 is not +Infinity here: http://mathforum.org/dr.math/faq/faq.divideby0.html Yeah, that would be why I sent my followup. I did not mean to imply that 1/0 is positive infinity in real world math. However, returning Infinity when asked to divide a finite number by 0 is conformant behavior according to the IEEE spec. An implementation is *allowed* to indicate an error on division by 0, but is not *required* to - returning infinity is legal. It is also, as an example, the behavior required by the ECMAScript specification. In any case, my point was simply that 1/0 is not NaN. If you're going to return a defined value as the result of 1/0, you should return +Infinity instead. NaN is used for other purposes, such as square roots of negative numbers when complex numbers are not available, or as the return value of failed numeric coercions, or of operations where even as a limit the result is indeterminate, such as 0/0. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Indeterminate math
On Monday 14 October 2002 20:20, [EMAIL PROTECTED] wrote: Are Inf and NaN going to be standard in Perl 6? As long as we're traveling down that road, how about i (the square root of -1), or Lukasiwiscean Null? (Sorry if I sound sarcastic, I'm actually honestly curious.) After much fighting with google to find the right spelling, 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. Miko, did I get the right thing out of that? --hobbs P.S. Delurk.
Re: Indeterminate math
On Mon, Oct 14, 2002 at 08:25:43PM -0400, Mark J. Reed wrote: On 2002-10-14 at 20:15:33, Michael G Schwern wrote: There are several verbal proofs why 1/0 is not +Infinity here: http://mathforum.org/dr.math/faq/faq.divideby0.html Yeah, that would be why I sent my followup. I did not mean to imply that 1/0 is positive infinity in real world math. Sorry, I was a little too fast on the reply gun. However, returning Infinity when asked to divide a finite number by 0 is conformant behavior according to the IEEE spec. An implementation is *allowed* to indicate an error on division by 0, but is not *required* to - returning infinity is legal. snip It is also, as an example, the behavior required by the ECMAScript specification. Heh. Because Javascript does it is supposed to be an argument for? ;) In any case, my point was simply that 1/0 is not NaN. If you're going to return a defined value as the result of 1/0, you should return +Infinity instead. Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate in the set of rational numbers. The IEEE may say otherwise. So here's a big question. Should Perl's core maths conform to IEEE or mathematics? (Not something I expect an answer to.) NaN is used for other purposes, such as square roots of negative numbers when complex numbers are not available, or as the return value of failed numeric coercions, or of operations where even as a limit the result is indeterminate, such as 0/0. So NaN means this equation might have an answer, just not in your current set of numbers and it means a coercion failed and it means the limit is indeterminate? A lot of meanings. But it doesn't mean 1/0? This gets into questions of how Perl's math systems are extended/overridden. Something better suited to guys like Tels I guess. While I'd personally like built-in support for automatic bignum conversion, I suppose the best answer I could expect right now would be Perl 6's support for additional maths will be greater than or equal to Perl 5. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm a man, but I can change... if I have to. -- Red Green
Lukasiewiczian logic (was Indeterminate math)
From: Andrew Rodland [EMAIL PROTECTED] After much fighting with google to find the right spelling, Sorry bout that. Your searching was probably as difficult as my attempts to pronounce it. 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. Miko, did I get the right thing out of that? Yup. It would be cool to be able to overload , ||, and ! to implement Lukasiewiczian logic within a given scope. I'm no expert, but I wrote a short essay explaining Lukasiewiczian logic. See http://ars.userfriendly.org/cartoons/read.cgi?id=20020904tid=389032 Trivia: Jan Lukasiewicz is the Polish in Reverse Polish Notation. Trivia 2: my mom, Carole O'Sullivan nee Lucas, says Lukasiewicz is probably my second cousin fifteen times removed, or something like that. It's probably my best credentials in the math world. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
RE: Indeterminate math
Mark J. Reed wrote:
I realize the above is mathematically simplistic. The
real reason y = x/0 returns an error is because no matter what
value you assign to y, you aren't going to get x back via multiplying
y by 0.
Well, that may be true in math; but there's no reason why it has to be
true in Perl6 (using the Math::Perverse module?)
Imagine
$b = 7 / 0
$b = undef but DivZero(7) but Overload('*' = sub ($rhs) { $rhs==0 ? 7 :
})
print $b * 0
7
print $b * 2 * 0
14
I.e. you can use a runtime property to remember the value that was
divided by zero. I'm not sure what the correct syntax is to make that
really clean: hopefully the DivZero property could do the Overload.
Dave.
RE: Lukasiewiczian logic (was Indeterminate math)
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 use Perl to do ASIC testbenches and stuff: so I'll probably be constructing something similar (and hopefully I'll have some nice bitwise and/or operators available: I use bitwise and | frequently; though I can accept that the majority of Perl users don't). Maybe I'll implement Verilog as a Parrot language. Dave.
Re: Indeterminate math
On 2002-10-14 at 20:49:52, Michael G Schwern wrote: It is also, as an example, the behavior required by the ECMAScript specification. Heh. Because Javascript does it is supposed to be an argument for? ;) Heh, indeed. :) But seriously, you could do worse. JavaScript receives a lot of (IMHO) undeserved criticism. The name is a blatant marketing ploy, and abuses abound in web pages, but there's really not much wrong with the core language, and there are even a couple things I wouldn't mind seeing Perl6 borrow from it. I'm going to continue my train of thought as it wanders directly off the rails of Perl6, so feel free to stop reading this now. :) JavaScript is a fine object-oriented scripting language with prototype-based inheritance. (I think that term is a misnomer, btw - if you create an object using a prototype, then change the prototype, that later change is visible through the earlier-created object. That doesn't sound like the behavior of what we normally mean by the word prototype in English. But it's the standard term.) Since it is prototype-based, the syntax for defining (or faking) classes, and subclasses thereof, is a little clunky; and it has no data hiding - everything is effectively a public associative array, But both of those things could be said about Perl5, as well, although Perl5's syntax is less clunky. On the single axis of O-O purity - which I am by no means advocating as a general measure of language utility - JavaScript ranks somewhere above Python (which is itself above Perl5) and below Ruby. It has the usual stuff - inheritance (albeit prototype-based); automatic type coercion among strings and numbers and Objects; regular expressions (syntax stolen from Perl5, of course); dynamic arrays (with a variety of manipulation methods that were also stolen from Perl5: splice, slice, shift, unshift, push, pop); and associative arrays (every object is one, really). It also has some a couple nice features regarding functions: They have prototypes, but they're not enforced by the language. A function definition may specify a set of named parameters, but any function may be called with fewer (in which case the unspecified ones have the undefined value), or more (which may be accessed via an array analogous to @_). An anonymous function/closure may call itself recursively despite not having a name by which to do so. This in particular is something I would like to see in Perl6. There are some oddly confusing things. We were talking about what to return for failure in the context of 1/0. Well, as I said, JavaScript actually returns +Inf for 1/0, but for other cases it has *three* different nil values: 1. undefined (like Perl undef; true of variables that have been declared but not yet assigned any other value) 2. null (for use when an Object reference is expected) 3. NaN (for use when a number is expected) Additionally, an attempt to access a variable that hasn't even been declared yet throws an exception, so that could be considered a fourth case, although it pertains to variables rather than their values. The biggest problem with JavaScript is the fact that the environment in which it runs - the interface to the outside world - is not defined by the language spec. You can't even write Hello, world! without specifying more information. (Running in a web browser? Use document.write(). Running under the Windows Script Host? Use WScript.stdOut.writeLine(). Running under the Mozilla project's rhino interpreter? Use print().) Anyway, I don't think JavaScript is going to make any inroads in the sysadmin scripting language market. For Windows administrators, it has some advantages: it's already there on modern versions of the OS, and it's a huge improvement over the previous scripting language for which that was true, namely DOS batch files. But Windows administrators who were brought up in the Windows world will probably use VBScript instead of JScript to access the WSH, and those who were brought up in the UNIX world will just download ActiveState Perl. :) Anyway, I'll shut up now. Just don't knock it 'til you've really tried it. :) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
