Hacker News Reader

Comment by jliechti1 | Hacker News Reader

Guido himself has said no multiline lambdas is an explicit design choice, and it's not really a technical issue:

"But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption."

source: http://www.artima.com/weblogs/viewpost.jsp?thread=147358

EDIT: This was from an earlier proposal in 2006.

View on HN

It definitely is a technical issue: Python simply doesn't support multiline expressions.

Anything utilizing an indent block must be a statement by the nature of the Python grammar, and since lambdas pretty much require returning a value (the new lambda) to be useful (and are thus expressions), they cannot be modeled as statements in Python, and therefore can't utilize indent blocks.

This is definitely an oddity of the Python grammar, where statements vs. expressions are entangled into how Python models indent blocks. Statements can contain expressions but expressions cannot contain statements.

Compare to Haskell, an everything-is-an-expression language which still supports indent sensitivity and multiline lambdas.

Guido just chose a wacky way to implement an indent-sensitive grammar.

This is the only case where I think that using whitespace indentation for delimiting blocks of code is not a good idea. It makes this particular problem very difficult to solve elegantly. In languages where blocks are delimited by brackets is easer.

...perhaps this is a hint that significant whitespace is a bad idea?

It's an argument to weigh in the balance, yes. Given that Python is more readable than languages without significant whitespace (even when those languages have the advantage of easy multiline lambdas), I don't find it convincing.

... like $[ in Perl?

Fortunately $[ was disabled from v5.16.0 (released in 2012).

ref: http://perldoc.perl.org/perl5160delta.html

Doesn't make it any less annoying to not have them.

Language design, especially syntax design, is always a series of trade-offs. Aside from relatively rare outright mistakes (bitwise precedence in C, associativity of ?: in PHP), most syntax choices that people don't like are done to make something else easier.

I really like blocks, but Python deliberately makes it harder to support those in return for not needing scope delimiters in the majority of code that isn't using blocks. It seems like a reasonable choice to me.

Blocks could be allowed in one liners. That would make Python a credible solution in that use case.

(And yes, not all one liners need it. I know.)

And list comprehensions seems like a kludge from a lack of real lambdas (map). So that is an extra concept.

Edit: Ruby doesn't have closures?!

Edit 2: 2nd paragraph of the linked article: "In Ruby, Objective-C, and C, functions are not first-class objects, they don't capture closures, and they can't be defined inline." For Ruby, that don't claim there are no closures at all. Got it.

Ruby definitely does have closures.

Methods aren't closures in Ruby (though we have procs and lambdas for that), but you certainly can pass methods around. Methods are objects, as are unbound methods. Both of them can be passed as arguments or returned as values. That's the definition of a first-class object.

You don't see the pattern often, as it's far less idiomatic than passing procs as a block, but you can do it.

Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.

> Also, def is an expression in recent versions of Ruby. I don't remember exactly which version introduced it, but def returns the method that it created.

They added that in 2.1 Well, it was always an expression... in Ruby, every statement is an expression. But it always used to return nil. Now it returns the symbol of the method name. Still not as good as returning a method object, but since you can easily get the method object from the symbol, in practice there's no difference.

Honestly, if I had to choose between things I'd like to have in Python that exist in other languages, I'd choose improving the protocol supporting comprehension syntax improved to be more general (like Scala's) over blocks.

While blocks are nice to have, I've yet to see a good proposed syntax for them in Python.

>Language design, especially syntax design, is always a series of trade-offs.

Sure, but then again not all trade-offs make the right trade, err, off.

Even saying "right trade-off" goes against what I'm trying to say. It may be the right trade-off for some users and the wrong trade-off for others. Most of the time, when people say, "this programming language is doing this thing wrong," all it really means is "this isn't the right language for me for this problem."

That means any set of tradeoffs is valid. It's not. Tradeoffs are only OK if what you get back in each option is balanced. In some cases you're trading something very valuable for diminishing returns.

>It may be the right trade-off for some users and the wrong trade-off for others.

Well, then it matters how big are those groups relative to each other, and perhaps which one does something that's more important with the language and more tied to its core principles.

associativity of ?: in PHP

TIL that PHP is even scarier than I thought.

The proposed solution in the original post doesn't require an indent-insensitive mode.

Reply on news.ycombinator.com