Functional Programming and python

[rusi]

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)