bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Futile bug reports?


From: Bill Richter
Subject: Re: Futile bug reports?
Date: 20 Aug 2001 20:58:00 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104

>>>>> Raymond Zeitler <address@hidden> replies to me:

  >> >> If someone gets interested in Emacs Lisp, I'll tell them they
  >> >> should read a Scheme book like SICP by Abelson or `How to
  >> >> Design Programs' by Felleisen [HTDP], and then the Emacs Lisp
  >> >> reference manual will make sense to them.  I can't see how
  >> >> anyone could understand the Emacs Lisp reference manual
  >> >> without having prior knowledge of Scheme/Lisp.
  >> 
  Ray> That why there's Introduction to Programming in Emacs Lisp, by
  Ray> Robert J. Chassell.  Even I can understand it.  :-)
  >> 
  >> Thanks, Ray, I just re-read the parts on pointers.  I don't think
  >> it's a very good description, and I think the users will need
  >> SICP or HTDP.  Punchline [snipped]

  Ray> In defense of the Chassell book, I should point out that the
  Ray> portions I did read helped me understand the general
  Ray> contruction of Lisp functions, and I'm motivated to write some
  Ray> useful snippets.  As well, the Emacs Lisp Reference Manual no
  Ray> longer appears to me as jibberish.

Hey great!  I like that:  Let's not think of Chassell's book as an 
                      introduction to Emacs Lisp
                          but instead, as an
           introduction to the Emacs Lisp Reference Manual, 
                               or as an
  introduction to the writing useful snippets for your .emacs file.

I bet Chassell's book serves these purpose admirably, as you say.
You're not addressing my point, which I'll restate:

What if someone asks a technical Lisp/Scheme type question on g.e.h.,
on some topic (such as pointer-ology), one which is not well treated
by either Chassell or the Emacs Lisp Reference Manual.  How do we help
them *really* learn Lisp/Scheme?  I recommend a rigorous 1st year
course on Scheme, out of a good book like SICP or HTDP.

  Ray> I do have the background to understand pointers and linked
  Ray> lists.  [...] After all, it is possible to program in C without
  Ray> using pointers (unless you need to pass a variable by
  Ray> reference....)

or pass a function as an argument, or deal with strings, or ...  :)

  Ray> Finally, I'd like to thank you for pointing out areas where I'm
  Ray> bound to become confused, once I decide to study the subject in
  Ray> greater detail.  Your followup can serve as a bridge to those
  Ray> who've graduated from Chassell but might still be struggling.

Hmm, you're making my post sound hard...  I went on about a
"theological" issue, whether we should say that

(setq x foo)

binds x to the value of `foo', or instead, to a pointer that points to
the value of `foo'.  There isn't any "right" answer.  Chassell gives
the 2nd answer, SICP Ch 3 pushes the 1st.  I guess you know about the
read/eval/print loop?  What's important to know is how to get from
`read' to `print'.  There's stuff that happens in `eval' that doesn't
get printed, and we can come up with various models to explain it.

So, the extra pointer between `x' and the value of `foo' that Chassell
and others like doesn't ever get printed, and you don't have to
believe in it, I think.  I could be wrong.  But if I'm wrong, it's
because my more naive model incorrectly predicts what Emacs prints.

So let's skip the "extra pointer theology", which is abstruse and not
well explained anywhere, including SICP.  

Did you understand the "pointers and linked lists" part of my post?
That's really important.  To quote myself:

(setq x '(1))
(setq y x)
(setcar x 6)
(car y)
=> 6

That's the whole point of pointers in Scheme/Lisp, AFAIK.  And apart
from pointer theology, this point is well explained in the Emacs Lisp
reference manual node "Setcar".  Go read it, if you haven't already!

-- 
Bill <http://www.math.nwu.edu/~richter>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]