> I (and many others) haven't posted here in a while, but I thought I'd
> give it a shot... :)
>
> In many languages, logic operators "and" and "or" have been overloaded
> to handle more than booleans. For example:
>
> x = x or 0 # if x is nil, 0
> x and x.foo() # if x is not nil, call foo
> x = x > 0 # if x is > 0, x, else false
>
> I'm torn between this being easier for the programmer, or just bad
> practice in general.
What the hey, I'll bite.
It's bad practice. You're conflating different ideas- for example
nil/null and false. Which becomes a problem if the programmer needs to
differentiate the idea- for example, consider a function that can return
null as an error case, or 0 as a valid response, and the caller wants to
determine whether the call succeeded or not. Anyone who has done much
perl programming knows exactly the problem I'm talking about. This
becomes even worse in maintainance when the semantics of the called
function is changed, and now the maintainer needs to divine not only what
the program used to do, but also what the originally programmer (now
raising goats in Uganda) meant for it to do.
I've come to believe in two rules a programming language should follow to
make life easier for the programmer:
1) If there is one thing, and only one thing, the programmer can mean by a
given code construct, then the programmer shouldn't have to specify it-
even if it means the compiler/runtime has to do work to figure out what
the one thing is, and
2) If there is more than one thing the programmer might mean by a given
code construct, then the compiler/runtime shouldn't guess or default, the
*compiler* should figure that out and make the programmer specify what is
meant (as a corollary, it should be easy for the programmer to resolve the
ambiguity).
The first rule is simply an application of the DRY principal- Don't Repeat
Yourself. The more often the programmer has to specify the information,
the more likely the programmer is to screw it up- and then not catch the
screw up. Humans can't pay attention to boilerplate and ceremony, they
zone out and miss minor things. The human shouldn't have to repeat
themselves, or spell things out that the compiler can figure out
unambiguously what is meant.
The second rule comes from the fact that computers are stupid. If the
computer has to guess what the programmer meant, then the computer is
going to guess wrong- and Murphy, Lord of Entropy, will gaurentee that the
computer will guess wrong in the worst possible way and at the worst
possible time. And the more complicated is the procedure for the compiler
to "guess" what the programmer meant, and the more likely it is that the
compiler "guesses" right, the more unexpected (and therefor deadly) it is
when the compiler gets it wrong. Assume that sometimes I'll want it one
way, and sometimes another, and that if the compiler isn't sure, it should
ask me, the programmer.
I (and many others) haven't posted here in a while, but I thought I'd give it a shot... :) In many languages, logic operators "and" and "or" have been...
... What the hey, I'll bite. It's bad practice. You're conflating different ideas- for example nil/null and false. Which becomes a problem if the programmer...
Replying to myself is bad etiquette, I know, but a new though just occurred to me. There is a logical fallacy a lot of people fall into that goes like this: ...
... These rules are operationally meaningless. The compiler has no access to what the programmer means or might mean, only to what he says, which always ...
... This is NOT operationally meaningless. It's just very generic. A couple of specific examples help. A classic example of violating rule #2 is the dangling...
... In one of several directory trees or ZIPfiles which mirror the package tree, is the more correct statement. The reason for that requirement is to permit...
Sorry for the short response, but the question remains... Python, Javascript, Lua, Ruby, all use "or" and "and" as: 1 or 2 => 1 1 and 2 => 2 Can there be a...
... Yes, this is called the "coalesce" operator. My language, Cobra, has this as "a ? b" which evals to "a" unless it's nil, in which case it evals to "b"....
... Lisp, too. Pretty much any language without a separate boolean type that isn't trying to be C-compatible will naturally do the same thing. -- They do not...
... foo()" which doesn't overload the logic operators? ... My language uses 'default' operator to achieve this. "x default 5" returns 5 if (and only if) the...
... There are languages beyond Python, Javascipt, Lua, and Ruby. And I should ask- what is the meaning of 1 or 2? I could make the cogent argument that the...
... Sure. It depends on how (and if) the language in question maps its values into booleans. Given that 1 is true (not the unique true value, but one of the...
Ahh, learn something every day :) What is the operator, if any, for the equivalent of "obj and obj.foo()"? One issue of introducing more operators is that you...
... For an obj that is a nilable type? You can say exactly that: def compute(t as List<of int>?) if t and t.count print t.count Notice the ? on the type which...
Questions - So why did you introduce a "default" operator vs. using "or"? And, why were you more strict about it than your coercive "+" operator? I ask only...
The '+' and 'or' operator (and most other) behave in similar way. The '+' operator tries to convert it's operands to numbers. The 'or' operator tries to...
I'm familiar with other languages also, I just mention the ones below because they have the same semantics. When you say "compiler guessing", do you mean the...
"It's not a format argument, but I thing it is valid, as language designers should apply certain amount of aesthetics when designing the language." I...
... it's the fact that without the "if", "or" is kind of kind of hanging out by itself, being indecisive, hah ... No, in this case there is not an option. The...
Another reason to avoid this type of overloading is that it breaks the operator's properties. 'Or' is normally symmetric operator (a or b == b or a). When you...
... The && and || flavors of 'or' and 'and' aren't symmetrical anyway with respect to undefined expressions. Ada neatly expresses their conditional nature by...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email