B
Bruno Desthuilliers
Grant Edwards a écrit :
And also for some implementations of some purely procedural languages IIRC.
L
Lorenzo Stella
Hi all,
I haven't experienced functional programming very much, but now I'm
trying to learn Haskell and I've learned that: 1) in functional
programming LISTS are fundmental; 2) any "cycle" in FP become
recursion.
I also know that Python got some useful tool such as map, filter,
reduce... so I told: "let's try some FP-style programming with
Python!". I took a little example of Haskell:
listprimes :: Integer -> [Integer]
listprimes n = if n == 0 then sieve [2..] else sieve [2..(n-1)]
where
sieve [] = []
sieve (p:xs) = p : sieve (filter (\x -> mod x p > 0) xs)
and I tried to "translate" it in Python:
def sieve(s):
if s == []:
return []
else:
return [s[0]] + sieve(filter((lambda x: x % s[0] > 0),
s[1:]))
def listprimes(n):
return sieve(range(2,n))
These should be almost the same: listprimes actually lists prime
integers up to n-1. The result is: Haskell implementation works well,
maybe it's not the better way to do it, but it does what I wanted.
Python implementation gives me
RuntimeError: maximum recursion depth exceeded in cmp
My question is: how can we call a language "functional" if it's major
implementation has a limited stack? Or is my code wrong?
LS
I haven't experienced functional programming very much, but now I'm
trying to learn Haskell and I've learned that: 1) in functional
programming LISTS are fundmental; 2) any "cycle" in FP become
recursion.
I also know that Python got some useful tool such as map, filter,
reduce... so I told: "let's try some FP-style programming with
Python!". I took a little example of Haskell:
listprimes :: Integer -> [Integer]
listprimes n = if n == 0 then sieve [2..] else sieve [2..(n-1)]
where
sieve [] = []
sieve (p:xs) = p : sieve (filter (\x -> mod x p > 0) xs)
and I tried to "translate" it in Python:
def sieve(s):
if s == []:
return []
else:
return [s[0]] + sieve(filter((lambda x: x % s[0] > 0),
s[1:]))
def listprimes(n):
return sieve(range(2,n))
These should be almost the same: listprimes actually lists prime
integers up to n-1. The result is: Haskell implementation works well,
maybe it's not the better way to do it, but it does what I wanted.
Python implementation gives me
RuntimeError: maximum recursion depth exceeded in cmp
My question is: how can we call a language "functional" if it's major
implementation has a limited stack? Or is my code wrong?
LS
E
Evan Klitzke
Python does not optimize tail recursion. You can increase the maximum
recursion limit with sys.setrecursionlimit, but the code will still be
slow.
I am a fan of functional programming languages (including Haskell!),
but I wouldn't try to write functional code in Python -- the language
isn't optimized for this type of code, and the syntax it provides
isn't very elegant, compared to other functional languages. If you
want to write functional code, use a real functional language!
R
Rustom Mody
The following defines the infinite list of primes as a generator [chap
6.5 of the library]
def sieve(l):
p = l.next()
yield p
for x in sieve(l):
if x % p != 0:
yield x
After that
from itertools import *
I tried to write a shorter generator expression based sieve but cant
get it right.
Can someone help? Heres the non-working code
def si(l):
p = l.next()
yield p
(x for x in si(l) if x % p != 0)
There should be an yield or return somewhere but cant figure it out
6.5 of the library]
def sieve(l):
p = l.next()
yield p
for x in sieve(l):
if x % p != 0:
yield x
After that
from itertools import *
I tried to write a shorter generator expression based sieve but cant
get it right.
Can someone help? Heres the non-working code
def si(l):
p = l.next()
yield p
(x for x in si(l) if x % p != 0)
There should be an yield or return somewhere but cant figure it out
A
Alex Martelli
Rustom Mody said:
Change last line to
for x in (x for x in si(l) if x % p != 0): yield x
if you wish.
Alex
R
Rustom Mody
Thanks but why does
(yield(x) for x in si(l) if x % p != 0)
not work? I would have expected generator expression to play better
with generators.
More generally, if one wants to 'splice in' a generator into the body
of a generator, is there no standard pythonic idiom?
K
Kay Schluehr
Never mind. In the provided example the call to sieve() is not in tail
position anyway
[...]
It's hard to disagree. As a Python programmer I'd rather care for
smooth integration with code written in Haskell or OCaml than adopting
their particular programming idioms. For instance the Python - OCaml
bridge is aged and I'm not aware that one between Python and Haskell
even exists.
D
Duncan Booth
Rustom Mody said:
Why should it? It evaluates the expression which returns an object that
just happens to be a generator and then as with any other expression
that isn't assigned or returned it throws away the result.
Yes there is, as Alex showed you the standard python idiom for a
generator to yield all elements of an iteratable (whether it is a
generator or any other iterable) is:
for somevar in iterable: yield somevar
There have been various proposals in the past such as 'yield from
iterable', but there doesn't seem any compelling case to introduce a new
confusing syntax: the existing syntax works, and adding a special syntax
wouldn't open the door to any performance benefits since the
implementation would have to be pretty much the same (at most you would
save a couple of local variable accesses).
B
Bruno Desthuilliers
Lorenzo Stella a écrit :
Not exactly. They are used quite a lot, yes, but that's also the case in
other paradigms. What's important in functional programming is *functions*.
FP idioms tends to use recursion instead of iteration, yes. But that's
only viable with implementations doing tail-recursion optimisation -
which is not the case with CPython (not that it couldn't FWIW - it's a
design choice, and one of the few I don't necessarily agree with).
And all there itertools versions...
Most of the functional constructs that makes sens in Python are already
idiomatic. And some common functional stuff are better reimplemented the
pythonic way - as an example, while partial application is usually
implemented with closures, and *can* indeed be implemented that way in
Python, the class-based implementation is IMHO much better.
Strictly speaking, a language is functional if it has functions as first
class objects. Period. According to this definition, Python is a
functional language. Now that doesn't mean you should try to write
Haskell in Python... IOW, your code is not "wrong", but it's certainly
not the best way to implement such an algorithm in Python.
Not exactly. They are used quite a lot, yes, but that's also the case in
other paradigms. What's important in functional programming is *functions*.
FP idioms tends to use recursion instead of iteration, yes. But that's
only viable with implementations doing tail-recursion optimisation -
which is not the case with CPython (not that it couldn't FWIW - it's a
design choice, and one of the few I don't necessarily agree with).
And all there itertools versions...
Most of the functional constructs that makes sens in Python are already
idiomatic. And some common functional stuff are better reimplemented the
pythonic way - as an example, while partial application is usually
implemented with closures, and *can* indeed be implemented that way in
Python, the class-based implementation is IMHO much better.
Strictly speaking, a language is functional if it has functions as first
class objects. Period. According to this definition, Python is a
functional language. Now that doesn't mean you should try to write
Haskell in Python... IOW, your code is not "wrong", but it's certainly
not the best way to implement such an algorithm in Python.
P
Paul Rudin
Lorenzo Stella said:
It's no tthat it's "wrong", but doing recursion in python can be
problematic because there's no tail recursion optimisation and the
size of the stack is limited (so eventually you'll run out of stack if
you recurse deep enough).
One way to capture the spirit of that Haskell program in Python is to
use things from itertools; something like this (modified from
<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117119>):
import itertools
def listprimes(n):
def sieve(nums):
seq = nums
while True:
prime = seq.next()
seq = itertools.ifilter(prime.__rmod__, seq)
yield prime
if n == 0:
return sieve(itertools.count(2))
else:
return sieve(itertools.islice(itertools.count(2), n-1))
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97]
K
Kay Schluehr
Functional lists are not quite the same. They are actually recursive
datastructes. In Python you would model them as nested tuples:
t = (a, (b, (c, ...(d, None)))))
These are essentially pairs build from the bottom up using a list
constructor and they have little in common with those mutable list
objects ( arrays, vectors ) being used in Python. You can easily
extend them into n-ary trees and implement mutations on them as forks
where the original strucure is almost preserved. This leads to all
kinds of "functional data structures".
In order to access an element you already need a recursive function
defintion ( unless you just want to examine the head or the tail
only ) and this makes functional programming and "consed" lists a
perfect match.
[...]
No, not period and not strictly speaking. A language is functional
when its semantics is based on lambda calculus where everything is a
function or a variable bound to a function which can be substituted by
a function. Each functional language, to be usefull, must be augmented
with programming language constructs used from other paradigms or
support unsafe operations to enable proper side effects. This is not a
humpty-dumpty issue where everyone can name his language a functional
programming language just because one can pass functions as first
class citizens around and he says so. Otherwise those languages can
support a few functional programming language idioms such as map,
reduce and filter or comprehensions as in Pythons case.
N
Neil Cerutti
Tuples won't work for cyclic data, though.
B
Bruno Desthuilliers
Kay Schluehr a écrit :
Linked lists, most of the time, yes.
(snip)
Indeed. And that's also why some FP idioms don't translate directly in
Python.
Ok, even on c.l.functional - where the above definition comes from BTW
-, nobody really agree on the "correct" definition of functional !-)
Linked lists, most of the time, yes.
(snip)
Indeed. And that's also why some FP idioms don't translate directly in
Python.
Ok, even on c.l.functional - where the above definition comes from BTW
-, nobody really agree on the "correct" definition of functional !-)
S
Steve Holden
Lorenzo Stella wrote:
[...]
stack?
You remind me of the conversation between the philosopher and an
attractive lady whom he was seated next to at dinner. He asked her if
she would sleep with him for a million dollars, to which she readily
agreed. So he followed this by asking her if she'd sleep with him for a
dollar. She replied: "No. Do you take me for a prostitutte?", to which
his riposte was "We have already established that fact, and are now
merely haggling about the price".
You just don't like the specific limit that Python imposes. So increase
it with sys.setrecursionlimit().
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Sorry, the dog ate my .sigline
[...]
So, which environment do you habitually use that provides an *unlimited*
stack?
You remind me of the conversation between the philosopher and an
attractive lady whom he was seated next to at dinner. He asked her if
she would sleep with him for a million dollars, to which she readily
agreed. So he followed this by asking her if she'd sleep with him for a
dollar. She replied: "No. Do you take me for a prostitutte?", to which
his riposte was "We have already established that fact, and are now
merely haggling about the price".
You just don't like the specific limit that Python imposes. So increase
it with sys.setrecursionlimit().
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Sorry, the dog ate my .sigline
G
Grant Edwards
Perhaps Lorenzo Stella is referring to Python's lack of
tail-recursion optimization? There are languages that
guarantee unlimited tail-recursion with a limited stack.
That's a typical feature for a function language, right?
R
Robin Becker
Steve said:
allegedly G B Shaw
(http://findarticles.com/p/articles/mi_qn4158/is_19980925/ai_n14182408)
P
Paul Rudin
Robin Becker said:
Also allegedly Winston Churchill, although wikiquote says:
"This is a very old joke where the participants vary dramatically
from each telling. It's very unlikely though not impossible that
the joke originated from Churchill."
S
Steve Holden
Paul said:
Also allegedly Bertrand Russell, who was going to be the subject of my
version until I realized that I would get many corrections to any
asserted identity of the originator. I should have know to expect just
as many corrections to the absence of any such assertion, this being
c.l.py
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Sorry, the dog ate my .sigline
J
Jonathan Fine
Steve said:
I've seen this before, and it is witty.
However, it is perhaps unfair towards the woman. The man, after all, is
someone who has offered a woman money in return for sex.
The whole story reads differently if we replace 'philosopher' by 'man'
and 'attractive lady' by 'woman'.
L
Lorenzo Stella
That's it.
Rustom Mody: your implementation lacks exactly where mine does. Try
listing the first 2000 primes... That's what I meant: I cannot in
general (with Python) get such list just by defining *what* it is, I
have to express *how* to get it (describing an algorithm).
"What" or "How": that is the question.
Steve said:
That is obviously not the answer to my question.