I V <[EMAIL PROTECTED]> wrote:
...
> >> higher level languages. There are useful programming techniques, like
> >> monadic programming, that are infeasible without anonymous functions.
> >> Anonymous functions really add some power to the language.
> >
> > Can you give me one example that would be feasible with anonymous
> > functions, but is made infeasible by the need to give names to
> > functions? In Python, specifically, extended with whatever fake syntax
> > you favour for producing unnamed functions?
>
> Monads are one of those parts of functional programming I've never really
> got my head around, but as I understand them, they're a way of
> transforming what looks like a sequence of imperative programming
> statements that operate on a global state into a sequence of function
> calls that pass the state between them.
Looks like a fair enough summary to me (but, I'm also shaky on monads,
so we might want confirmation from somebody who isn't;-).
> So, what would be a statement in an imperative language is an anonymous
> function that gets added to the monad, and then, when the monad is run,
> these functions get executed. The point being, that you have a lot of
> small functions (one for each statement) which are likely not to be used
> anywhere else, so defining them as named functions would be a bit of a
> pain in the arse.
It seems to me that the difference between, say, a hypothetical:
monad.add( lambda state:
temp = zipper(state.widget, state.zrup)
return state.alteredcopy(widget=temp)
)
and the you-can-use-it-right now alternative:
def zipperize_widget(state):
temp = zipper(state.widget, state.zrup)
return state.alteredcopy(widget=temp)
monad.add(zipperize_widget)
is trivial to the point of evanescence. Worst case, you name all your
functions Beverly so you don't have to think about the naming; but you
also have a chance to use meaningful names (such as, presumably,
zipperize_widget is supposed to be here) to help the reader.
IOW, monads appear to me to behave just about like any other kind of
HOFs (for a suitably lax interpretation of that "F") regarding the issue
of named vs unnamed functions -- i.e., just about like the difference
between:
def double(f):
return lambda *a: 2 * f(*a)
and
def double(f):
def doubled(*a): return 2 * f(*a)
return doubled
I have no real problem using the second form (with a name), and just
don't see it as important enough to warrant adding to the language (a
language that's designed to be *small*, and *simple*, so each addition
is to be seen as a *cost*) a whole new syntaxform 'lambda'.
((The "but you really want macros" debate is a separate one, which has
been held many times [mostly on comp.lang.python] and I'd rather not
repeat at this time, focusing instead on named vs unnamed...))
Alex
--
http://mail.python.org/mailman/listinfo/python-list
