Python syntax in Lisp and Scheme

[Bengt Richter]

On Thu, 16 Oct 2003 05:01:44 -0400, mertz at gnosis.cx (David Mertz) wrote:

>|> But the underlying issue was the spurious claim that lambda forms
>|> were somehow required for HOFs, which is totally bogus.  Python
>|> could get by with only 'def', Lisp with only 'defun', and Haskell
>|> only '=' and 'where'... and all of them would be just as capable at
>|> using combinatorial and other HOFs.
>
>Jacek Generowicz <jacek.generowicz at cern.ch> wrote previously:
>|Yes, but arguments such as these are the first step down the slippery
>|slope to Turing Equivalence. For just about any feature in just about
>|any language, you could argue that the langugage could get by without
>|it ... and taking this to its logical conclusion, you end up with
>|assembler.
>
>There is no such slope.  OF COURSE everything is *computable* in every
>language.  That's obvious and trivial.  Well, so are lots of things, but
>it's not the point I've made.
>
>What I am talking about is HIGHER ORDER FUNCTIONS.  I.e. things
>(abstractions) that don't exist in assembly language or in Turing
>machines.  You don't need that abstraction to do any computation, but
>obviously, HOFs have a certain utility and beauty.
>
>And you DO NOT NEED lambdas for HOFs!  Categorically so--it's not that
>you can use only a subset of HOFs if you only have def/defun/=.  A
>language that doesn't have lambda, but treats functions as first class,
>can express EVERY HOF that one that adds lambda can.

ISTM there could be ways that you need BOTH named and un-named functions.
I.e., a function NEEDS a name in order to call itself recursively
(unless you create some specialized syntax for a recursive call).

OTOH, if you evaluate a def in a namespace where you don't know what
all the names are, you have a collision risk when you choose a name.
An un-named function eliminates that risk.

I.e., even if the function-definition part is identical in syntax and
capability, ISTM the name-binding side effect could be an issue.
Practically, it is probably rare that you can't use a named function,
but really def is a convenience construct that does name binding after
doing (what would be) a full-fledged lambda thing IMO.

Why should the following kind of thing be arbitrarily restricted?
(currently for two reasons -- a name is useless here and def
is a statement, not allowed in this contex):

 >>> funlist = [
 ...     (lambda value:
 ...         lambda:'My value is %s'%value
 ...             # imagine freedom to have full suites here
 ...     )(y) for y in range(5)
 ... ]
 >>> for fun in funlist: print fun()
 ...
 My value is 0
 My value is 1
 My value is 2
 My value is 3
 My value is 4

(Not that a bound method (aka callable object if bound method is __call__) might
not be as good or better in many cases, but that might lead to asking whether
you NEED to be able to define functions outside of classes ;-)

ISTM there are uses for lists (and dicts for that matter) of functions
where the def names would at best be ignored side effects. E.g., perhaps
key or macro-key-sequence bindings for an editor, or event bindings for a GUI, etc.

>
>This point is quite neutral as to whether lambda forms are otherwise
>worthwhile.  It's just a basic fact that a bunch of posters oddly want
>to deny.
>
ISTM you are focusing on the defined function to the exclusion of
the name-binding-as-side-effect, and saying you don't need lambdas
because def's can generate the same functions, but ISTM that's not the whole story ;-)

Regards,
Bengt Richter