On Tuesday, October 1, 2013 6:11:18 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 30 Sep 2013 19:04:32 +0200, Franck Ditter wrote: > > 2. Lambda-expression body is limited to one expression. Why ? > > Nobody has come up with syntax that is unambiguous, would allow multiple > statements in an expression, doesn't break backwards compatibility, and > isn't ugly. > > Since lambda is just a convenience, not a necessity -- it almost got > dropped from Python 3 -- it is not worth compromising on those design > requirements just for multiple-statement lambdas. It simply isn't > important enough.
Agreed. λ-expressions are fundamental to functional programming theory; they are not strictly necessary to practical functional programming. [Miranda one of the predecessors to haskell and a seminal FP language had no λ-expressions ] I find serious limitations in python from the pov of effectively doing FP; λ-expression limitations not the most crucial. eg - scope leakage in comprehensions - no comprehensions for tuples - need to use assignments to simulate let - mutable default parameters leak scope On Monday, September 30, 2013 10:47:45 PM UTC+5:30, Chris Angelico wrote: > On Tue, Oct 1, 2013 at 3:04 AM, Franck Ditter wrote: > > > 1. Tail recursion is not optimized. We are in 2013, why ? This is known > > technology (since 1960). > > And don't answer with "good programmers don't use recursion", this is > > bullshit. > > I've yet to see any value in having the compiler/interpreter optimize > tail recursion that can't be achieved just as well, and usually more > clearly, with simple iteration. Recursion's important; tail > recursion's important; tail recursion optimization isn't. Yeah -- since register allocation is isomorphic to graph-coloring[1] and graph-coloring is computationally hard[2], lets all go back to machine language! [1] http://en.wikipedia.org/wiki/Register_allocation#Isomorphism_to_graph_colorability [2] http://en.wikipedia.org/wiki/Graph_coloring#Algorithms > (But I do sometimes yearn for a goto.) Ha! In Scheme, a tail call IS a goto with parameter re-assignment The real advantage to mandatory tail-call optimized language like scheme is pedagogical. Students brought up on a scheme-like philosophy are liable to see recursion and iteration as synonymous [Certain common forms of recursion are more easily expressed as loops] and be more easy switching between them. Recursion is just too central to the business of programming to afford having it pushed to one side in beginner's heads. http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html The irony is that most non-FP programmers imagine that FP consists of using recursion for any and everything. See the progression and specially the last entry here http://www.willamette.edu/~fruehr/haskell/evolution.html - no loops - no recursion - if possible no variables (the 'pointless' version) -- https://mail.python.org/mailman/listinfo/python-list