Re: Return

[Stephen J. Turnbull]

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.

 > In any event, AIUI much of GvR's objection w/re Python's lambda was
 > that it won't parse cleanly given the syntactic reliance on
 > whitespace.

Not at all.  That's an excuse that some lambda supporters will buy,
but he just doesn't think that the scope for appropriate use of
lambdas is that great, and especially not in Python.  He'd rather add
new specialized syntax for major use cases.  He's almost certainly
right for Python, and he doesn't claim any more generality than that.

 > No doubt this is obvious to most here but it is all too easily
 > forgotten when discussion of alternative non-lispy languages are
 > brought to bare on the efficacy of lispy languages.

Proposing a non-Lispy language wasn't my intention at all.

 > However, as you suggest with your caveat "in a typical interpreted
 > Lisp" this may not apply to compiled code... Which is to say, doesn't
 > your example dance around what happens around defun/defmacro/lambda at
 > compile time in any lexically scoped implementation of
 > <substitute your non-interpreted lexically scoped modern lispy
 > dialect of choice here>?

I'm not sure what you think happens there.  All that defun ever does
(that matters to this discussion) is create a function object and
assign a name (a symbol) to it.  In a Lispy language when that symbol
is encountered as the car of a list to be evalled it is dereferenced
(the function cell in Lisp-2s and the value cell in Lisp-1s), and the
resulting function object applied to the arguments.  Otherwise the car
must be a function object.  And what is a function object?  Either a
lambda or equivalent compiled code (yes, Virginia, a list starting
with a subr can be eval'ed).

So all the interesting questions of lexical scope vs. compilation have
to do with argument passing (including the special semantics of the
environment "variable", however that is defined and implemented).
However, AFAICS this doesn't (and mustn't, otherwise you'd be able to
tell the difference between eval'ing interpreted code and eval'ing
compiled code, which is verboten) change depending on whether the
compiled code object was defined directly as a lambda expression, or
via defun.  If you know differently, I'd rather learn than teach. :-)

 > > But [the CL advocates] all long since left the [Emacs]
 > > development community.
 > 
 > The slime users/developers are _actively_ incorporating Common Lisp
 > (of various implementations) with Emacs/Emacs lisp (unfortunately they
 > have to resort to a different RPC per implementation to do
 > so). Regardless, the Slime user/devel community is hardly an
 > insignificant group.

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 grant
that could be a huge investment of time, effort, code, and persuasive
engineering.  I'm not criticizing them, I'm telling you that my view
is Emacs Lisp will turn into an implementation of Common Lisp sometime
later than Real Soon Now.

 > >  If they choose not, you can always do it yourself, as we do.
 > 
 > 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.

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.

 > persistent inability to engage in reasoned/meaningful/intentioned
 > discussion w/re incorporating of a particular set of Lisp features
 > by either ignoring and/or dismissing the utility these features do
 > otherwise provide both Emacs user community and the greater
 > community of Lisp dialect users despite a general acknowledgment by
 > both of these communities that the particular set of features are
 > wanted/needed and FTMP can be reasonably implemented.

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.

Take lexbind, for example.  It's been on the agenda for a long time,
and AFAIK RMS *never* objected to it in principle (at least once it
was made clear that dynamic scope would continue to be supported).
However, he does like dynamic scope, and insists that features like
lexbind be added in a way that doesn't get in the way of ordinary
users of existing Emacs features or cause the whole program to become
unstable.

 > [1] The long term evidence of this inability IMO suggests that the Emacs
 > project(s) are closed and proprietary project (whether their source be
 > free or not). That [SX]Emacs does remain reasonably compatible with
 > GNU Emacs suggest that it too abides this inability (whether tacitly
 > or otherwise).

All it proves is that we're lazy, and want to take advantage of the
improvements to *Emacs* technology more than we want to take advantage
of improvements to *Lisp* technology.  When all is said and done,
\(S?X\)?Emacs is as much an application as it is a language, and most
of our developers have far more interest in the application than the
language.

Eg, Aidan Kehoe has been busily improving our Common Lisp support,
even down to rewriting some of the docs (will wonders never cease?!) 
and using some standard set of tests for the features he's
adding/upgrading/conformancing.  Has he released any code that
*depends* on these features?  Not yet, and I bet not soon.  Does he
release (non-CL-implementation) code?  Sure, an' he does.  But it's
all bug fixes and conventional features.  You may think that's
unfortunate, but that's the way the world works.