in reply to Lisp vs. Perl Round 3: Operator Associativity and Manipulation

This is all only true if you decide to go out of your way to make it obscure and convoluted. Of course I am probably only taking the bait, but here goes.... 
#!/usr/bin/perl -w

use strict;

my $pat = '"%d %s %d is %d" if (%d %s %d == %d)'; 

matchIf($pat, 3, '+', 4, 7);
matchIf($pat, 5, '*', 4, 20);
matchIf($pat, 5, '%', 4, 20);
matchIf($pat, 5, '-', 4, 20);

sub matchIf {
    my ($pat, $x, $op, $y, $z) = @_;
    my $foo =  sprintf($pat, $x, $op, $y, $z, $x, $op, $y, $z);
    print eval ($foo),"\n";
}

[download]
Not even golfed.

Not nearly as wacky as you made it out to be. BTW, I spent 3 semesters doing Artificial intelligence work with Lisp in college and I actually love working with it; But your arguement here just shows that either you didn't bother to learn the tool (Perl) well enough to do the job right, or you intentionally misrepresented things to serve your point.

And as a note: Most people do not consider the Lisp method of using Reverse Polish notation for conditionals and mathmatics particularly simple. Most people would understand "x op y = z" but only a programmer (or maybe a mathematician) could love "op op x y z".

Update Figured I would add that the development time on this was ~5 minutes.

Update And just a couple more showed that we can do this.... 


#!/usr/bin/perl -w

use strict;

my $pat = '"%d %s %d is %d" if (%d %s %d == %d)'; 
my $order = '[$_[0], $_[1], $_[2], $_[3]]';

matchIf($pat, $order, 3, '+', 4, 7);
matchIf($pat, $order, 5, '*', 4, 20);
matchIf($pat, $order, 5, '%', 4, 20);
matchIf($pat, $order, 5, '-', 4, 20);

sub matchIf {
    my ($pat, $order) = (shift, shift);
        print eval sprintf($pat, @{eval $order}, @{eval $order}), "\n"
+;

}

[download]
To make the ordering configurable as well.
Update Got rid of the maps, because well.... they were complete useless.

Replies are listed 'Best First'.
Re: Re: Lisp vs. Perl Round 3: Operator Associativity and Manipulation
by hding (Chaplain) on Jun 08, 2001 at 22:45 UTC

    Just a nit: the Lisp notation for math would be described as Polish (function before arguments) rather than Reverse Polish (function after arguments).

[reply]
Re: Re: Lisp vs. Perl Round 3: Operator Associativity and Manipulation
by princepawn (Parson) on Jun 08, 2001 at 23:33 UTC
    Thank you for taking the bait. First of all, your example does not support unification. I assume you know what this is and why your example does not support it. If not, read Norvig for details.

    Most people do not consider the Lisp method of using Reverse Polish notation for conditionals and mathmatics particularly simple.
    But would you agree that it is consistent and that one does not have to refer to a manual to know whether an operator associates to the left, to the right or not at all?

    But your arguement here just shows that either you didn't bother to learn the tool (Perl) well enough to do the job right, or you intentionally misrepresented things to serve your point.
    How does your example "do the job right?" Please read the title of the post. You created a telegraphed example which only supports binary infix operators. It won't work for unary ops and it will fail on more complex ops where you must know Perl prcedences rules.

    And finally, the use of strings is very slow.

[reply]
      But would you agree that it is consistent and that one does not have to refer to a manual to know whether an operator associates to the left, to the right or not at all?

      Consistency is not the be-all end-all goal. I personally am very comfortable sacrificing some consistency for greater flexibility to write easier to read and maintain code. You however, as evident from several posts, have a bit of a fetish for it. However, as before, your claim of inconsistency wrong.
      Perl is consistent, just on a more granular level; There is an order of precedence, and it is always followed. I extremely rarely find myself refering to a manual to figure out how to put together an expression ( I say rarely, because I never say never. ).

      How does your example "do the job right?" Please read the title of the post. You created a telegraphed example which only supports binary infix operators. It won't work for unary ops and it will fail on more complex ops where you must know Perl prcedences rules.

      You example only used '+' and 'eql' so I followed suit. I only invested 5 minutes in putting it together. You show me yours and I will show you mine.

      And finally, the use of strings is very slow

      And when did Lisp become blindingly fast?

[reply]
        And when did Lisp become blindingly fast?

        Well, I'd say that Lisp, being merely a language, and thus somewhat of an abstract thing, is neither slow nor fast. For individual implementations of Lisp, one might give the rather tautalogical but nonetheless true answer that they became fast when implementers figured out how to make them fast (which incidentally doesn't relieve the programmer of his responsibility to help out, but that's another story entirely). Modern Lisp implementers have done a pretty good job of holding up their end of the bargain; good examples are CMUCL and ACL. (I myself am a user of Lispworks which isn't too shabby either.)

[reply]

In Section Meditations