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
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
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
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
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
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
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
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
--- 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
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
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
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
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
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 {...}
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
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
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
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
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
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
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
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
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
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
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/
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
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
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:
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
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.
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
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
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
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
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
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
36 matches
Mail list logo
