[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment on Emacs Lisp Introduction
From: |
Fren Zeee |
Subject: |
Re: Comment on Emacs Lisp Introduction |
Date: |
Tue, 3 Aug 2010 20:19:39 -0700 |
On Mon, Aug 2, 2010 at 8:26 PM, Stephen J. Turnbull <address@hidden> wrote:
> Fren Zeee writes:
>
> > I am not complaining. Its just that I dont have it, and need to find
> > source matching this old executable, which means that it will take
> > some time to search for the particular freeze or tar file if it is
> > still on the web.
>
> Huh. Why are you so focused on "old"? If you are an historian, you'd
> better enjoy such searches because that's what historians do. If
> you're a programmer, though, old versions are of no particular
> interest unless you already know them well enough for forward
> differences to have meaning to you.
It appears that software is developed both outside-in and inside-out
at various times and the oldest most primitive version has the
simplest structure, and least features. IMHO it would be for
educational purposes, not just historical.
For a professor like you, who knows a lot more, perhaps, can start
anywhere in the field, but not for a newbie like myself.
> If you're interested in a particular function, M-x disassemble.
Show me an example where disassemble would help in understanding the
code. I think it gives VM code, not lisp code.
Give a walk-thru concrete example of several functions that illustrate
how disassemble would help understanding the code.
> Otherwise, why do you refuse to take the advice to use a modern
> version? The basic architecture hasn't changed since the GNU rewrite.
OK, so give me a diagram which shows the scanner of LISP interpreter,
and in addition some comments for writing the primitives.
> Functions that are more complex now have become that way for a reason;
> those reasons are worth studying. Many functions are *not* more
> complex in themselves than they were then, but have become simpler
> because they delegate subtasks that have increased in complexity to
> other functions. It's easier to work backward from modern versions which
> are well-developed based on better abstractions (cf. Michael Stokes'
> comment about Green's Theorem: "It is trivial. It is trivial because
> the concepts have been well-defined. That definition took decades."
> -- or something like that, I don't have _Calculus on Manifolds_ handy).
I know what you mean but you cant stuff that into the mouth of a
newbie before knowing something of vector calculus.
Franz Xe
It would certainly help if I can get some debug sessions from you and
the other gentleman who gave me the initial advice on playing with
emacs using its own debug and gdb, a typescript file.
- Re: Comment on Emacs Lisp Introduction, David Kastrup, 2010/08/01
- Re: Comment on Emacs Lisp Introduction, Óscar Fuentes, 2010/08/01
- Re: Comment on Emacs Lisp Introduction, Harald Hanche-Olsen, 2010/08/01
- Re: Comment on Emacs Lisp Introduction, Stephen J. Turnbull, 2010/08/02
- Re: Comment on Emacs Lisp Introduction, Fren Zeee, 2010/08/02
- Re: Comment on Emacs Lisp Introduction, Stephen J. Turnbull, 2010/08/02
- Re: Comment on Emacs Lisp Introduction,
Fren Zeee <=
- Re: Comment on Emacs Lisp Introduction, Stephen J. Turnbull, 2010/08/04
- Re: Comment on Emacs Lisp Introduction, David Kastrup, 2010/08/04
- Re: Comment on Emacs Lisp Introduction, Fren Zeee, 2010/08/05
- Re: Comment on Emacs Lisp Introduction, Fren Zeee, 2010/08/05