A critic of Guido's blog on Python's lambda

[Joe Marshall]

Alex Martelli wrote:
>
> I think it's reasonable to make a name a part of functions, classes and
> modules because they may often be involved in tracebacks (in case of
> uncaught errors): to me, it makes sense to let an error-diagnosing
> tracebacks display packages, modules, classes and functions/methods
> involved in the chain of calls leading to the point of error _by name_.
>
> I think it's reasonable to make a name a part of types for a different
> reason: new types are rarely meant to be used "just once"; but also, if
> during debugging any object is displayed, it's nice to be able to show,
> as part of the display, "this object is of type X and ...", with X shown
> as a name rather than as a complete (thus lengthy) description. (any
> decent interactive shell/debugger will let you drill down into the
> details as and when you need to, of course, but a well-chosen name can
> be often sufficient during such interactive exploration/debugging
> sessions, and therefore save time and effort).

I agree that symbolic debugging info is a good thing.

> Indeed, "given an object, how do I get its NAME" (for inspection and
> debugging purposes) is the most frequently asked question on
> comp.lang.python, and I've grown a bit tired of answering "you can't, an
> object in general intrinsically ``has no name'', it might have many or
> none at all, blah blah" -- yeah, this is technically true (in today's
> Python), but there's no real reason why it should stay that way forever
> (IMHO).  If we at least ALLOWED named objects everywhere, this would
> further promote the use of names as against mysterious "magic numbers",
> since the programmer would KNOW that after
>     VAT_MULTIPLIER = 1.19
> then displaying in a debugger or other interactive session that
> PARTICULAR instance of the value 1.19 would show the name string
> 'VAT_MULTIPLIER' as well (or no doubt a more structured name constructed
> on the fly, identifying package and module-within-package too).

The problem is that a `name' is a mapping from a symbolic identifier to
an object and that this mapping must either be global (with the
attendant name collision issues) or within a context (with the
attendant question of `in which context').

> Mandating names for _everything_ would complicate the language by
> forcing it to provide builtin names for a lot of elementary building
> blocks: so for most types of objects it's best to "gently nudge".  For
> functions, classes, modules, and packages, I think the naming is
> important enough (as explained above) to warrant a syntax including the
> name; better, therefore, not to complicate the language by providing
> another different syntax in each case just to allow the name to be
> omitted -- why encourage a pratice that's best discouraged, at the price
> of language simplicity?

I agree.  This is why I write
(defun foo (x) ...)

rather than
(setf (symbol-function 'foo) (lambda (x) ...))

However, there are places where names are cumbersome.  They are
certainly cumbersome for most literal objects like numbers and strings.
 There are circumstances where they are cumbersome for function
objects.  The function (lambda (x) (+ x 3)) doesn't really need a name.
 It isn't any big deal if you give it a name, but it's a trivial
annoyance to be forced to give it a name.  It becomes a major annoyance
when you write code in continuation-passing-style or monadic style.

It is an annoyance when refactoring code, too.  Suppose you had written
(mapcar #'sin list-of-numbers)

and you realize that the numbers are in degrees.  With an unnamed
function, this is an easy fix:
(mapcar (lambda (x) (sin (deg->rad x))) list-of-numbers)

With a named function, you have to do one of these:
(flet ((sin-d (x) (sin (deg->rad x))))
  (mapcar #'sin-d list-of-numbers))

or
(mapcar (flet ((sin-d (x) (sin (deg->rad x)))) #'sin-d)
list-of-numbers)


Matthias Felleisen once suggested that *every* internal function should
be named.  I just said `continuations'.  He immediately amended his
statement with `except those'.