|
Re: Why not support this syntax?
by merlyn (Sage) on Apr 24, 2001 at 03:34 UTC
|
| [reply] |
Re: Why not support this syntax?
by clemburg (Curate) on Apr 24, 2001 at 16:09 UTC
|
sub in_open_range {
my ($x, $min, $max) = @_;
return ($min < $x && $x < $max);
}
Why do they all want to modify the Perl parser?
Is it not complicated enough?
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com | [reply]
[d/l] |
|
|
Well, I know why I'd like to see it.
One of the reasons I like Perl is its 'humanness', e.g. when I speak to
humans (well, some of them anyway) I can say 'it' or 'those' and they
usually know what I mean and in Perl, of course, we've got $_ and @_.
In short, I like my programming language to be as much like my
speaking language as possible. Us humans have no trouble understanding
what 1 < x < y <= z < 12 means without writing it as a conjunction of
independent order tests: ( 1 < x ) && ( x < y ) ...
Therefore, I wish Perl was such that perl could understand the human
form as well.
Alternately, yes you could write a subroutine but ... then you'd have
to write a subroutine!
I prefer to have the tools I use do as much of my work for me as
possible -- well, all of it actually but that hasn't ever happened yet
and I'm not optimistic. :)
Penultimately, I say it's definitely not complicated enough. When I
can talk to it in English and have it do what I want, then it'll be
complicated enough. In a less tongue-in-cheek mode, the complexity of
the parser shouldn't, IMHO, drive the development of the language. The
first sentence of the Preface of the Camel book is 'Perl is a language
for getting your job done'. It's not 'Perl is a language with a
reasonably, but not unreasonably, complicated parser'.
Ultimately, since I don't have to write the parser
... :)
Scott
| [reply]
[d/l]
[select] |
|
|
Penultimately, I say it's definitely not complicated enough. When I can talk to it in English and have it do what I want, then it'll be complicated enough.
Well OK then, how does the proposal generalize to things
like this:
$mystery = $a < $b < $c < $d < $f;
Quick - say: which one is the ternary operator?
Why cause such problems when a little subroutine
is enough?
In a less tongue-in-cheek mode, the complexity of the parser shouldn't, IMHO, drive the development of the language. The first sentence of the Preface of the Camel book is 'Perl is a language for getting your job done'. It's not 'Perl is a language with a reasonably, but not unreasonably, complicated parser'.
Perl is a language for getting your job done - right.
After writing this little subroutine, the job is done.
Why wait for other people to do jobs for you that you
can do for yourself in 30 seconds.
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com | [reply]
[d/l] |
|
|
I could only guess that it would be:
$mystery = ($a < $b) && ($b < $c) && ($c < $d) && ($d < $f);
As in, for any:
A x B y C
Where 'x' and 'y' are one of ('>','>=','<','<='),
then the equivalent would be:
(A x B) && (B y C)
Which would also hold true for:
A < B >= C -> (A < B) && (B >= C)
A > B < C -> (A > B) && (B < C)
And so forth. | [reply]
[d/l]
[select] |
|
|
|
|
|
|
Re: Why not support this syntax?
by Masem (Monsignor) on Apr 24, 2001 at 07:41 UTC
|
Personally, I'd like to see something like
if ( $x in [$min, $max] ) { ... } #inclusive container,
# $x==$min would be true
# OR
if ( $x in ($min, $max) ) { ... } #exclusive container,
# $x==$min would be false
# OR
if ( $x in ($min, $max] ) { ... } #mixed ends
since, IMO, reads better than having consecutive '<'s or '>'s, but this also has similar parsing problems particularly in the mixed variety with balancing parans.
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply]
[d/l] |
|
|
That would be nice as well, though it lacks the ability to succinctly express the following condition:
if ($min < $x < $y <$max) { ... }
The unbalanced braces would absolutely wreak havok on syntax highlighters, too.
MeowChow
s aamecha.s a..a\u$&owag.print | [reply]
[d/l] |
(tye)Re: Why not support this syntax?
by tye (Sage) on Apr 24, 2001 at 19:17 UTC
|
The other common case you
want is that $x is outside some range. So will
people try to write this:
if( $min > $x < $max ) {
which would always be false (provided $min < $max).
Or would you only allow inequalities of the same "direction"
to be clustered together like that? Personally I never use
> nor >= because I find the code
easier to understand when the values are sort left-to-right,
smallest-to-largest. (:
-
tye
(but my friends call me "Tye")
| [reply]
[d/l]
[select] |
|
|
if ($min > $x > $max) { ... }
What you're implicitly suggesting is that Perl would change symantics from && between inequalities to ||, but how could perl possibly know when to do this and when not to? Eg. in my original expression, what would Perl do if $x was greater than $max? I think your example can more sensibly be expressed as:
unless ($min < $x < $max) { ... }
MeowChow
s aamecha.s a..a\u$&owag.print | [reply]
[d/l]
[select] |
|
|
See, I told you I can't understand code that uses >. (:
But you just illustrated more problems with this. For
example, your last line should have been:
unless( $min <= $x <= $max )
But I don't find those compelling reasons to not
implement it. If someone actually managed to produce a
patch for this I wouldn't be opposed to it.
-
tye
(but my friends call me "Tye")
| [reply]
[d/l] |
Re: Why not support this syntax?
by r.joseph (Hermit) on Apr 24, 2001 at 07:27 UTC
|
Sounds like a very good idea, especially for those of us who, in our study of complex math, tend to like to use Perl to help us and would be allowed - with this syntax - to easily test certain intervals and such. Good idea!
r.
j
o
s
e
p
h
"Violence is a last resort of the incompetent" - Salvor Hardin, Foundation by Issac Asimov | [reply] |