[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions from M. Hagiya
- To: Wholey@CMU-CS-C.ARPA
- Subject: Questions from M. Hagiya
- From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
- Date: Mon, 27 Aug 84 09:40 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <WHOLEY.12042666619.BABYL@CMU-CS-C.ARPA>
Date: Sun, 26 Aug 1984 23:03 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
The manual explicitly states (on page 90) that is is an error to invoke the
thing that symbol-function returns if macro-p or special-form-p of that symbol
is true. That seems lucid enough.
No, I don't think that has anything to do with it. The thing returned
is not a function, but that doesn't mean that you can't stick it back
into a symbol and use that symbol as the name of a special form.
I don't know if that's a legal complex number (the components are of different
types), but I believe it's just as easy (perhaps easier) to make a reader
accept #c(0.0l0 #.pi) instead of scream about it.
Whether it's easy to make the reader do it wasn't the question, though.
The question is one of language definition. I strongly suspect that all
of the existing Common Lisp readers will accept that definition, since
they probably use READ to parse after #c.
I don't think anything should happen to *Standard-Input*. Consider a program
(i.e. a file of Lisp code) that wants to query the user when it is loaded. In
that case, leaving *Standard-Input* as is is useful. I can't think of any
useful thing one could do with having *Standard-Input* be bound to the file.
In Maclisp, it was quite standard to put (read) into a file in order to
get the next form and manipulate it. The main motivation for doing that
has been eliminated by the introduction of eval-when, but Maclisp
programmers certainly expect (read) in a file to read from the file. I
don't feel strongly either way, but it really should be specified.
Would you please mail me, under separate cover, the Spice Lisp
definition of "rationalize", if that's OK? Thanks. By the way, Gosper
hasn't been working for PARC for some time; he works for Symbolics
He was confused by the term "alphadigit" in Table 22-3, apparently not
having read the fine print at the bottom. I presume that the function
alpha-char-p needs to reference *read-base* in order to function properly?
No. The definition of Alpha-Char-P is straightforward enough. At the end:
"Of the standard characters, the letters A through Z and
a though z are alphabetic."
I don't see at all how frobbing *Read-Base* can change this.
Aha, now I remember. The real problem Hagiya was having is that
alpha-char-p uses the term "alphabetic" one way, and Table 22-3 uses it
a completely different way. This really needs to be fixed.