Re: suggested properties of operator results
From: "Dave Storrs" <[EMAIL PROTECTED]>
To: "Chris Hostetter" <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 9:07 PM
Subject: Re: suggested properties of operator results
> On Fri, 8 Jun 2001, Chris Hostetter wrote:
> > $v2 = VALUE2;
> > $v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
> > return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
> >
> > which ... would cause the following code to mean ... think it
> > should mean:
> > if ($foo < $bar < $baz) { ... }
I'm assuming that you're correct (I see no reason that you wouldn't be; I
just havn't checked it out myself, and am not clear on where "valueR" is
defined.)
...
> 1) The "do this because it will be more intuitive for beginners"
> argument comes up a lot, and is pretty appealing at first. However, as
> someone (was it tchrist?) pointed out, beginners don't stay beginners for
> long, so writing a language for beginners may cost you people when they
> "grow out of" your language.
Which it is indeed. (The feature is a good idea, and tchrist is right.)
It's a lot easier to read, and a lot easyer to write ($a < $b < $c) then
($a<$b) && ($b<$c). Moreover, when the varables have names longer then a,
b, and c, then it gets rather easy to change only one of several instances
of a varable. (That is, $a<$b && $b<$c into $a<$d && $b<$c).
> 2) This feature would be very prone to abuse (makes it easier to
> obfuscate code), but that isn't a reason to disqualify something either.
Certianly not in perl. Hell, I think sometimes it's a reason /to/ put a
feature in perl.
> 3) Used for what it is intended for, it seems like a very concise,
> expressive way to do multiple relationship tests without needing all those
> "&&"s and such.
Indeed. (Though, as defined above, this won't work on the string
operations, only the numerics.)
-=- James Mastros
RE: suggested properties of operator results
At 09:15 AM 6/12/2001 +1000, Damian Conway wrote: >Dave Whipp asks: > > > Does it do short-circuit evaluation, too? > >I would certainly expect it to, yes. It will, unless Larry specs it out otherwise. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: suggested properties of operator results
Dave Whipp asks: > Does it do short-circuit evaluation, too? I would certainly expect it to, yes. Damian
RE: suggested properties of operator results
> From: Damian Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 4:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: suggested properties of operator results
> I think we will see n-ary comparisons allowed in Perl 6:
>
> if ($x < $y <$z < $foo) {...
>
> but as special case syntactic sugar for the expANDed version:
>
> if ($x < $y && $y < $z && $z < $foo) {...
>
> Oh, and with only single evaluation of each operand.
>
Does it do short-circuit evaluation, too?
Dave.
Re: suggested properties of operator results
Larry and I recently discussed chaining inequality operators.
He's in favour of it, but not of complex semantics involving
properties and implicit state (as I originally proposed in the
RFC)
I think we will see n-ary comparisons allowed in Perl 6:
if ($x < $y <$z < $foo) {...
but as special case syntactic sugar for the expANDed version:
if ($x < $y && $y < $z && $z < $foo) {...
Oh, and with only single evaluation of each operand.
Damian
Re: suggested properties of operator results
Dave Storrs wrote: > 2) This feature would be very prone to abuse (makes it easier to > obfuscate code), Whoa! Never thought I'd hear that! And computed function calls/adding things to the namespace at runtime/rearranging the inheritance tree at runtime aren't "very prone to abuse" !? :-) > but that isn't a reason to disqualify something either. Clearly hasn't been so far anyway. Why stop now? :-) Chris's proposed feature seems much less prone to abuse than many others. I myself have wanted this feature, but never thought to ask for it. Thanks Chris. Not clear on how it should be actually implemented though. Daniel
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:42:53PM +0100, Simon Cozens wrote: > On Mon, Jun 11, 2001 at 01:31:36PM +0100, Graham Barr wrote: > > On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: > > >$input = 4; > > >$bool = $input < 22;# $bool = 1 is valueR(22) > > >print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR > > > > Well perhaps $input < 22 should yield 22 is true > > Or perhaps you should have said "my bit $bool;" :) Um, perhaps I was no clear. I meant $bool to get 22, which now I read goes against the previous message :) But if < returns RHS is true when the LHS is less than the RHS you can do 6 < $var < 10 as long as precedence means that is (6 < $var) < 10 and perl uses the truth to determine when to stop as this would expand to (6 < $var) and ($var < 10) And of course if it actually returned LHS is false when the LHS is greater, then $c = max($a,$b) is simply $c = $a < $b Graham.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:31:36PM +0100, Graham Barr wrote: > On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: > >$input = 4; > >$bool = $input < 22;# $bool = 1 is valueR(22) > >print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR > > Well perhaps $input < 22 should yield 22 is true Or perhaps you should have said "my bit $bool;" :) -- When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, comp.lang.c++
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: > > For the record, bwarnock pointed out to me that damian allready proposed > this behavior in RFC 25... > > http://dev.perl.org/rfc/25.html > > That RFC doesn't suggest having the comparison operators set properties > on their result -- instead it recomends that "multiple chained comparisons > should be automagically expanded to the equivalent binary conjunction." > ... I think I like his way better. Mainly because I didn't consider the > ramifications of scenerios like this... > >$input = 4; >$bool = $input < 22;# $bool = 1 is valueR(22) >print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR Well perhaps $input < 22 should yield 22 is true Graham.
Re: suggested properties of operator results
For the record, bwarnock pointed out to me that damian allready proposed
this behavior in RFC 25...
http://dev.perl.org/rfc/25.html
That RFC doesn't suggest having the comparison operators set properties
on their result -- instead it recomends that "multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction."
... I think I like his way better. Mainly because I didn't consider the
ramifications of scenerios like this...
$input = 4;
$bool = $input < 22;# $bool = 1 is valueR(22)
print "ok!" if $bool == 1; # whoops, '==' is looking at $bool.valueR
But as long as we're on the subject, dstorrs raises some good issues on
"should we do it at all"...
: someone (was it tchrist?) pointed out, beginners don't stay beginners for
: long, so writing a language for beginners may cost you people when they
: "grow out of" your language. I don't this we should do this just because
I agree with that sentiment, but I don't think it applies in this case.
We're not talking about a feature that will be usefull for beginers, and
a hinderence to experienced users who move on to to another language
because being able to write "1 < $val <10" is making more work for them.
: 2) This feature would be very prone to abuse (makes it easier to
: obfuscate code), but that isn't a reason to disqualify something either.
I disagree, I think that this...
if (1 <= $x <= 10 and 1 <= $y <= 10) { # inside grid?
is much less obfuscated then this...
if (1 <= $x and $x <= 10 and 1 <= $y and $y <= 10) { # inside grid?
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Re: suggested properties of operator results
On Fri, 8 Jun 2001, Chris Hostetter wrote:
> After reading the Apocalypse & Exegesis articles, and seeing some examples
> of properties and the "is" operator, I'd like to suggest that the
> less-then operator be changed, so it is functionally equivalent to:
>
> $v2 = VALUE2;
> $v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
> return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
>
> which (assuming the operator's association was changed to "left") would
> cause the following code to mean what beginning programmers always think it
> should mean:
>
> if ($foo < $bar < $baz) { ... }
>
> It should be obvious how "> <= >= lt gt le ge" can similarly
> be modified. Then even this would make sense...
>
> if ($foo <= $bar > $yak lt $wak) { ... }
For certain definitions of "sense." :>
Seriously, I have several thoughts on this:
1) The "do this because it will be more intuitive for beginners"
argument comes up a lot, and is pretty appealing at first. However, as
someone (was it tchrist?) pointed out, beginners don't stay beginners for
long, so writing a language for beginners may cost you people when they
"grow out of" your language. I don't this we should do this just because
it would be better for beginners; if we're going to do it, let's do it
because it is a good feature.
2) This feature would be very prone to abuse (makes it easier to
obfuscate code), but that isn't a reason to disqualify something either.
3) Used for what it is intended for, it seems like a very concise,
expressive way to do multiple relationship tests without needing all those
"&&"s and such. If we assume that these expressions read from left to
right by overlapped pairs, so that these are equivalent:
($foo < $bar < $baz < $jaz)
(($foo < $bar) && ($bar < $baz) && ($baz < $jaz))
...then I don't think we're giving up any comprehensibility, and
we are gaining conciseness. I vote 'yes' (fwiw).
Dave
suggested properties of operator results
Currently, this expression:
VALUE1 < VALUE2
is functionally equivalent to this:
$v2 = VALUE2;
$v1 = VALUE1;
return ($v2-$v1 == abs($v2-$v1));
After reading the Apocalypse & Exegesis articles, and seeing some examples
of properties and the "is" operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to "left") would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo < $bar < $baz) { ... }
It should be obvious how "> <= >= lt gt le ge" can similarly
be modified. Then even this would make sense...
if ($foo <= $bar > $yak lt $wak) { ... }
"== != eq ne" could be similarly modified (with the addition of a valueL
property to deal with precedence) but I haven't convinced myself it's a
good idea -- too many people like using == in place of xor...
if (($foo < $bar) == ($yak < wak)) { ... }
(I haven't even begun to consider <=> and cmp, but I'm sure there's
someone smarter then me out there with an idea on how/why they could
be modified as well (if for no other reason then to make obfuscated perl
contests even more interesting))
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
