Re: Return

[MON KEY]

On Sun, Dec 5, 2010 at 8:48 PM, Stephen J. Turnbull <address@hidden> wrote:
 >
 > Pshaw... Doesn't GVR eschew ++Lambda++ in p3k? Heresy!

,----
| No, YAGNI.  Even more so in Emacs Lisp:
`----

Indeed, one often doesn't miss what one never knew wasn't there to be missed.
GVM has no doubt leveraged this against future Python initiates.

Fortunately a good many lispers are too accustomed w/ lambda by virtue of
defmacro and Lisp's terse parenthetical syntax to not miss it.

,----
| (defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms))
|
| or something like that. ;-)
`----

Perhaps, but quite a bit more happens at compile time around lambda and will do
more so if/when the lexbind is merged. :)

 > ,----
 > | Speaking of Common Lisp, since it has a package scheme, you might be
 > | able to implement the elisp interpreter by using the elisp
 > | interpreter, and put in in a package that uses elisp eval instead of
 > | Common Lisp's eval.
 > `----
 >
 > Sam Steingold has explored [...]

,----
| I'll take a look.  But ...
`----

FWIW I've found the old LispM sources to be the most enlightening.

 > Also, there are any number of legacy "Emacs like" editors

,----
| Indeed.  For unacceptably small values of "like", though.
|
| AFAIK the people you would expect to actually be working on those things (eg,
| you mention Bruno Haible as well as Sam Steingold) use "real" Emacs
| instead for production work.  I wonder why? ;-)
`----

I've no idea why either of those individuals might do what they do.

What would be interesting to learn is whether there is any will for a formal
incorporation of the C in Clisp w/ the E in elisp?

I imagine there are still a good many Common Lisp hacks that would contribute
their valuable skills to such an effort were it not for the closed/proprietary
control maintained on the FSF Emacs source tree.

Regardless, the "real" Emacsen we are using today are not fundamentally so far
removed from the legacy CLTL based systems they were once built upon that we can
describe the contemporary Emacsen as somehow more "real" than its ancestor.

Indeed, as you have framed it, mine was a comparison of Emacs to TECO. I would
offer that the situation may be inverted, and that in many ways todays Emacsen
are the TECOs to a certain breed of ancestral Emacsen.  No doubt you're well
aware of the lineage ;-)

Indeed, when browsing through the LispM sources it is quite surprising to learn
how much of the underlying Emacs VM (now C based) was once CLTL based. In some
cases one can still catch glimpes of entire blocks of text which nearly
superimpose one another (syntax differences aside)...

 > why on earth should a switch to either a Scheme/Python VM warrant
 > consideration.

,----
| I'm not suggesting switching to the Python VM, I'm proposing Python as
| an example of a language with several implementations targeting
| multiple VMs.
`----

Great! I misunderstood.

,----
| The reason for using a Scheme is that it's much lighter
| weight than a Common Lisp implementation.
`----

This is an awfully general assertion.
Which Scheme implementation?
Which Scheme with which R[456]RS?
And for any given implementation, which shared/linked libraries are required?
Which CL implementation?

,----
| That may not butter your bread, but it matters to Richard, I believe, and to
| the people who work on those implementations.
`----

Butter aside, it isn't at all clear what the matter that matters is and to and
for whom.

 > FWIW I find it quite odd that discussions of moving the Emacs VM to
 > Guile are bandied about

,----
| "Bandied about" is quite the odd term to use for a decision that AIUI
| was made more than a decade ago.
`----

Which decision, the decision to fork Emacs' CLTL code base from the LispM or the
decision that Guile might eventually grow into its shoes enough to become a
worthy consideration as the Emacs scripting engine?

,----
| Emacs just has a long gestation period for features. :-)
`----

And enough hubris to squelch many such features which should never have been
removed during the initial LispM fork 25+ yrs ago.

--
/s_P\