Re: Accumulator

[Paul Prescod <address@hidden>]

"A.Schmolck" wrote:
> 
>...
> 
> I really have troubles understanding the continual moans about lambda -- I
> don't think it's buggy (it was, before nested scopes) and I don't think adding
> lambda to the language was a mistake to start with either (whatever Guido's
> thoughts on the matter may be). In fact, I find python's lambda just about
> perfect -- maybe I'm missing something.

Okay, you make some good points. It's just a question of whether it
meets the 80/20 point. It may be that I overreact to the fact that it
doesn't seem "complete". But you're right that it can serve a purpose.

At the very least, the name of the operator is brain-dead. We might as
well add give functions meaningless names like "cdr" and "creat". ;)

>...
> However if you want a function that contains more than one simple expression
> you can always (and presumably should) use def instead -- IMHO allowing
> lambdas that are are fully equivalent to defs would just lead to more
> spaghetti code, without adding any expressiveness to the language. 

Agreed.

> .... Moreover
> overly complicated functions for which you can't come up with a name more
> likely than not are a sign of poor structure and potential code redundancy.

Agreed again.

>...
> Yes, I agree that for many cases comprehensions can be clearer, but I also
> think for many they aren't, notably when you've got more than one sequence:
> 
>       map(add, xs, ys)
> 
> is, to me, better than:
> 
>     [x + y for (x,y) in zip(xs,ys)]

I think it's just a matter of which you learned first. zip is useful to
know for other contexts anyhow.

> ...
> in fact, as long I have a ready-made function, I'd prefer map:
> 
>    map(str, args)

Given that it exists, maybe. If we were creating the language from
scratch? I don't think so.

> Also, this style of programming naturally extends to lazy sequences (if you
> define things like, say xzipWith etc.), dictionaries and other scenarios that
> you can't accommodate with comprehensions or that are awkward and ugly with
> loops (e.g. reduce'ing). 

Python will probably grow dictionary comprehensions and lazy
comprehensions when there is enough demand.

>...
> clearer. Of course 'clear' also depends how used one is to a certain style of
> coding (e.g. do you find ``reduce(operator.getitem, pos, tree)`` clear? I
> certainly do).

I never use reduce, so no.

node = tree
for curpos in pos:
	node = node[pos]

When I write code I always have in the back of my mind whether an
occasional Python programmer could follow it. I will use an advanced
feature if it dramatically simplifies the code. Otherwise, I will avoid
it. Few people would agree with me that that is worth spending effort
on. I happen to consider both "reduce" and "operator.getitem" advanced
features.

 Paul Prescod