Today's disgusted moment

rafael on 2006-01-13T18:09:35

Sometimes, language programming constructs are just objectively ugly. (Or do I do too much C programming ? No. I don't want to believe that.)

---

ternary operators are inherently ugly

jmm on 2006-01-13T19:54:08

Ternary operators are inherently ugly, the only thing a language designer can do is choose amongst the flavours of ugliness.

Having to create a syntax that lets three units (condition, true selection, false selection) be associated easily by a reader requires at least 2 operators and is an order of magnitude more awkward than binary operators. While C and Perl5 go for huffman encoding with ? : (which Perl6 is changing to ?? :: IIRC), there is history for using a more verbose mechanism, requiring more verbosity from the writer in exchange for greater clarity for the reader which is reasonable for a relatively rare construct. Algol 68 had all statements allowed as an expression, so you just coded "if cond then true_expr else false_expr fi" in the middle of an expression.

Using 4 operators instead of 2 provided complete bracketing of the operands so there was no need to assign and remember precedence to the operators - that is useful for an operator that is not used often, and the ternary nature requires that the middle term is completly bracketed anyhow and only permits precedence to affect the parsing of the first and last terms.

Guido has taken a middle ground with "true_exp if cond else false_exp" which keeps the longer keyword operators for clarity, but only 2 operators for shorter encoding (than using 4). Switching the order so that the condition is in the middle may have some odd effects on precedence. (It makes the conditional portion unambiguous, but now both result portions need operator precedence rules to determine which parts of the surrounding context is part of one of the two condition result expressions and which is to be applied to whichever result emerges. I don't know whether this is better or worse than the C/perl syntax, offhand.)

Historical huffman encodeing of ternary operator

n1vux on 2006-01-15T03:24:32

While C and Perl5 go for huffman encoding with ? : (which Perl6 is changing to ?? :: IIRC), there is history for using a more verbose mechanism,

The oldest is the quatenary operator or ternary if in Fortran -

if (expr) line_lt, line_eq, line_gt

which predates if..then by several years; but neary as old is the ternary operator if in Lisp

(if pred-expr, true-val, false-val)

which with is pretty well Huffman encoded.

The beautiful thing of Perl is TIMTOWTDI ... if you won't want ternary operators, don't use one. Once Switch.pm is built-into Perl 6, I'll probably use it less.

Backward compatibility in Python?

speters on 2006-01-27T02:33:19

We will adjust the syntax of what goes inside an 'if' to disallow lambda; currently

if lambda: x:

is accepted but quite useless (it's always true) so this will be disallowed.

I guess backward compatibility is an issue when working with Python. That's something rather important advocacy note to remember.