Re: Return

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> MON KEY writes:
>
>  > > [GvR] just doesn't think such [lambda or anon blocks] belong in
>  > > Python, and I have to admit I don't miss them.
>  > >
>  > 
>  > I'e no clue whether this is good or bad for Python(istas) my
>  > concern is simply that this viewpoint not encroach upon the Emacs Lisp
>  > VM without qualification. :)
>
> No, it won't.  However, I must say (as a maintainer) that use of
> lambdas often imposes extra work on debuggers.  I almost always give
> lambdas a nickname when I'm reading code that uses them, unless
> they're simply implementing partial evaluation.

A nickname doesn't really apply well with closures.  For debugging
purposes, a "named lambda" might be helpful.  Conceivably one could
supply something like that using a DOC string.

> Nobody says they are.  But unless they hang out here, which they only
> seem to do when they've got a bug report, they're not going to have
> much influence on the future of the language.  Given that RMS is
> generally not in favor of incorporating Common Lisp features,

I don't think anybody minds the features.  The problem is the cost in
syntactic complexity and language intransparency.  cl is a large and
invasive hack that is not particularly nice during debugging,
decompiling and code design and optization.  lexbind is a first step in
a direction where some Common Lisp features become less costly.

>  > Yes but there is an accord to maintain some mutual consensus. AIUI
>  > your presence on this list is indicative of such an effort no?  To
>  > paraphrase JWZ, "Now you have two problems."
>
> One of my problems is an addiction to email.  The other is an
> affection for David Kastrup.  That is what my presence here indicates.

Doing all the right things for ostensibly awfully bad reasons sounds
like a form of compassionate nihilism designed to get out of the line of
appreciation.  After all, it could get you into serious trouble at
/home/xemacs if somebody were as foolish as to, say, nominate you for
the Free Software Award for minimizing, for whatever reason, the
consequences of the great schism without losing face or focus.  And it
would look decidedly fishy if I were to do such a thing after this
announcement.

> More to the point, I long ago gave up on effecting a mutual consensus.
> We either do it Emacs's way, or we don't.  That's just the way it has
> to be.  I advocate things here that I think would be good for Emacs on
> Emacs's own terms.  I don't always get that right, but I'm definitely
> not here to advocate the XEmacs way of thinking.

You are advocating the Turnbull way of thinking, here and "there".  At
least here, mixed success is nothing to be worried about.

> Frankly, I don't see any such general acknowledgement in the general
> Emacs community.  There is a significant subset of developers who
> would like that, yes.  But the non-developer users could care less,
> and many developers either prefer a different style of language or
> fear that incorporation of more features would lead to a deterioration
> of performance for typical use-cases or instability in use, which
> really isn't acceptable.

I see much more the danger in bit rot.  I've been considering helping
with a dedicated lilypond-mode building on lyqi.el (there is a git repo
for that).  The code is an exercise in cl use and makes my eyes glaze
over.  I can't sensibly contribute, because it is utterly beyond me.
Many times in Emacs programming, I give up on the documentation and just
dig through the sources to see what something does deep down.

cl does not lend itself to that approach.  Its code is highly complex
and utterly underdocumented.  You have to trust it to do the right
thing.  I hate doing that.

-- 
David Kastrup