untaintby property

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 unt

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 packag

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 C loop should : >terminate on the shor

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 equivale

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

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 topi

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

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_

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

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

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 wri

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 t

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

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 {

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 goo

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

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 f

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

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 o

Re: Indeterminate math

On Mon, Oct 14, 2002 at 05:05:14PM -0400, 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

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

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 simpl

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 discovere

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 proba

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

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

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 t

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

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.div

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 (

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". How

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

Re: Indeterminate math

On Mon, 14 Oct 2002, [EMAIL PROTECTED] wrote: : 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 i

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 no

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

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 tr

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

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