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
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 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
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
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
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
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
Dave Whipp asks: Does it do short-circuit evaluation, too? I would certainly expect it to, yes. Damian
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
