in reply to numbers with chainable comparisons

Overloading is an attempt to rewrite aspects of the language to make them more palatable to the program author.

I'd rather struggle with clunkier syntax than deal with subtle bugs introduced by an almost-but-not-quite perfect overloading attempt. Ideally, the language we'ld write it would *have* the syntax we wanted in the first place. I'd rather work with the language we know than spent time rewriting it and learning the abstractions, and the limitations of the abstractions in theory, and the bugs in the abstractions in practice. Enough of that ad hoc development work, and you've got your own entirely new language which no one understands, and which doesn't actually work.

So, while interesting, if I want to write the mathematical expression "x <y <=z" in perl, I'd probably just use the alternative math syntax, "x is bounded by the interval (x,z]", and write:

$x->is_bounded_by("(",$y,$z,"]" );

or more likely just the simple and obvious:

$x < $y and $y <= $z

which does force you to repeat part of the expression, but has the advantage that a grade school kid knows what the code does.

Just my $0.02
--
Ytrew

Replies are listed 'Best First'.
Re^2: numbers with chainable comparisons
by Irrelevant (Sexton) on Jan 19, 2006 at 09:44 UTC

    I accept what you're saying here -- I wouldn't use even the most polished version of this in production code.

    The modules's intent was more to be a proof of concept than anything actually useful. I thought that, if people other than me liked the idea, maybe it could go into something more "official" in the future (should I devise a programming language myself, or I could even've suggested it for perl6 if everyone loved the idea *g*).

[reply]
Re^2: numbers with chainable comparisons
by Courage (Parson) on Jan 19, 2006 at 18:19 UTC
    $x < $y and $y <= $z is good but then you'll quickly need to write very differently when instead of $y there will be complex expression with may be side effects.
    ... unfortunately...

    Best regards,
    Courage, the Cowardly Dog

[reply]
[d/l]
      I would never put a complex expression with side effects inside a comparison anyway. I prefer simple code; if I have to have a complex expression, I'd evaluate it separately, then go on to do the comparison.

      I hate those map-grep-map-fold-spindle-mutilate commands where everything is done in a single, incomprehensible line riddled with nested ternary operators and uncommented regexps. When the code breaks, there's no intermediate stages to check for correctness; there's just a mess of nested context and conditional return values that are supposed to work, but somehow don't.

      Yes, I'm bitter. My boss got fired, and I have to maintain the code he left behind, most of it undocumented, and often attempting to solve problems we don't actually have, and may never encounter. Sometimes code that is probably never hit looks buggy; but it's hard to tell because of all the state and flags flying around.

      It's done nothing to lessen my hatred for complex expressions where simple ones do the job. If you really need complexity, fine. If you don't, just do what's simple and obvious; don't waste someone else's time fixing your mistakes just because you thought it would be fun to be clever. --
      Ytrew

[reply]

In Section Meditations