On Sat, Sep 13, 2008 at 10:02 AM, Cliff Wells <cliff@develix.com> wrote:
On Fri, 2008-09-12 at 21:56 -0600, Adam Olsen wrote:
At most, it's a *small* benefit to the language. It comes a tradeoff, just like a+b rather than add(a, b), or len(x) rather than x.len().
Okay, you kept providing this example and I kept brushing it off because I didn't see where you were leading. Now I do and now I realize that I've utterly failed to get the problem across.
Let's use your example from above: a+b vs add(a, b)
a + b is the *exact* semantical equivalent of add(a, b). They do the same thing, they can be used in the same contexts. The + operator is pure semantic sugar (and well-used sugar too).
Now let's imagine things aren't quite so equivalent. a+b has the same result as add(a, b), except you can only use the + operator in one particular context: assignment. It cannot be used say, with a comparison operator.
So in my imaginary Python, this is legal
x = 1 + 2
but this is not
if x < y + 1: pass
and must instead be written
if x < add(y, 1): pass
Now lets make it even more of an exact comparison.
Let's say the add(x,y) function didn't even exist. You have to write it yourself. Worse, writing it requires fairly deep knowledge of Python, and worse yet, you sometimes must write a different add(x,y) function depending on what context you want to use it in.
At this point we've now made your example much closer in spirit to the problem I'm attempting to present.
Your explanation would be true, except custom functions can be used as either statements or expressions! It is only the existing statements which are limited to being used as statements, and they're syntactic sugar.
You're claiming we don't have to make that tradeoff.. but you've done *nothing* to substantiate that. Even logix only adds more complexity, rather than removing and unifying existing syntax.
And you've provided nothing to substantiate this (aside from this assertion).
Also, if we combine statements into expressions, how does this not unify existing syntax? Combining two into one is practically the definition of "unify".
Merging generator expressions, list comprehensions, and the for-loop would be unifying. Making the for-loop also usable as an expression is generalizing a specific feature. I've given many examples of why that doesn't work, so I'll assuming not seeing them was due to the terminology confusion. -- Adam Olsen, aka Rhamphoryncus