map/filter/reduce/lambda opinions and background unscientificmini-survey

Scott David Daniels Scott.Daniels at Acm.Org
Sun Jul 3 17:14:28 CEST 2005

egbert wrote:
> On Sat, Jul 02, 2005 at 08:26:31PM -0700, Devan L wrote:
>>Also, map is easily replaced.
>>map(f1, sequence) == [f1(element) for element in sequence]
> How do you replace
> map(f1,sequence1, sequence2)
> especially if the sequences are of unequal length ?
> I didn't see it mentioned yet as a candidate for limbo,
> but the same question goes for:
> zip(sequence1,sequence2)

OK, you guys are picking on what reduce "cannot" do.
The first is [f1(*args) for args in itertools.izip(iter1, iter2)]
How to _you_ use map to avoid making all the intermediate structures?

I never saw anything about making zip go away.  It is easy to explain.

Now reduce maps to what I was taught to call "foldl."
How do you express "foldr?"  How do you express:

      _accum = initial()
      for elem in iterable:
          _accum = func(elem, _accum, expr)


If you want functional programming in python, you have at least three
big problems:

1) Python has side effect like mad, so order of evaluation matters.
    I'd claim any useful language is like that (I/O to a printer is
    kind of hard to do out-of-order), but I'd get sliced to death
    by a bunch of bullies wielding Occam's razors.

2) Python's essential function call is not a single-argument
    function which might be a tuple, it is a multi-argument
    function which is not evaluated in the same way.  The natural
    duality of a function taking pairs to a function taking an arg
    and returning a function taking an arg and returning a result
    breaks down in the face of keyword args, and functions that
    take an indeterminate number of arguments.  Also, because of (1),
    there is a big difference between a function taking no args and
    its result.

3) Python doesn't have a full set of functional primitives.
    Fold-right is one example, K-combinator is another, ....
    Why pick on reduce as-is to keep?  There is another slippery
    slope argument going up the slope adding functional primitives.

--Scott David Daniels
Scott.Daniels at Acm.Org

More information about the Python-list mailing list