Re: Why not support this syntax?

[clemburg]

I will never understand what is wrong with writing a simple subroutine like:

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

[scott]

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

[clemburg]

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

[tadman]

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.

[clemburg]

Good idea, and we can even cover that one ourselves, too:

sub is_ordered_according_to {
    my ($binary_predicate, @values) = @_;
    if (@values < 3) {
        return $binary_predicate->(@values);
    } else {
        return $binary_predicate->($values[0], $values[1])
            && is_ordered_according_to($binary_predicate, 
                                       @values[1..$#values]);
    }
}

sub less_than {
    return shift() < shift();
}

print is_ordered_according_to(\&less_than, 
1, 2, 3, 4, 5, 6) ? "yes" : "no", "\n" ;
print is_ordered_according_to(\&less_than, 
3, 2, 1, 4, 5, 6) ? "yes" : "no", "\n" ;
print is_ordered_according_to(\&less_than, 
1, 2, 3, 4, 6, 5) ? "yes" : "no", "\n" ;

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com