hi there,
I am still learning some basic syntax of lisp and happy to learn from
others here. Also sorry for later some elementary problems put forward
here.
Here is some others' codes written in ACL I recently can't understand:
(defstruct sort-info . #.sort-slots)
what's the meaning of " . " behind the sort-info.
Thanks.
--
peng
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------
The syntax '(foo . bar) creates a cons cell containing the symbols 'foo
and 'bar. The #.some-form thing is a reader macro which means "replace
me with the value of whatever comes after the #. at read time".
For example, try evaluating this:
'(1 2 #.(1+ 2) 4 5)
The quote would normally cause just that to be printed, but since the
(1+ 2) form was evaluated at read time, you get (1 2 3 4 5) as the
result.
-Peter Scott
+ ·········@gmail.com:
| The syntax '(foo . bar) creates a cons cell containing the symbols
| 'foo and 'bar.
Uh, no. First, 'foo and 'bar aren't symbols, they are lists - 'foo is
the list (quote foo), and 'bar is (quote bar).
This may seem like nitpicking, and maybe it is. But I think the
distinction is important. The Lisp newbie needs to understand that
anything entered at the prompt is first read, then evaluated. Your
explanation conflates the two, thereby confusing more than it
illuminates.
So: More correct is to say that the reader reads the text (foo . bar)
as a cons cell containing the symbols foo and bar. It reads the
syntax '(foo . bar) as if it were (quote (foo . bar)), and
/evaluating/ this results in the cons cell which we write (foo . bar)
- not evaluated further.
| The #.some-form thing is a reader macro which means "replace
| me with the value of whatever comes after the #. at read time".
Almost good enough, but I prefer "read whatever comes after #., then
evaluate it and insert the result into the form currently being
read".
| For example, try evaluating this:
|
| '(1 2 #.(1+ 2) 4 5)
Even more educational: Evaluate the form (read), then type in
(1 2 #.(1+ 2) 4 5) with or without a quote to see what the reader does
to the form.
Or one could run a simplified, verbose read-eval-print loop like this
(loop for form = (progn (format t "~&Huh> ") (force-output) (read)) do
(format t "~&Input form: ~S" form)
(format t "~{~&=> ~S~}" (multiple-value-list (eval form))))
try some different inputs to it, and see the boundary between reader
and evaluator in action. This REPL is easy to get out of: Anything
which provokes an error will get you, via the debugger, back to the
usual top-level.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + ·········@gmail.com:
>
> | The syntax '(foo . bar) creates a cons cell containing the symbols
> | 'foo and 'bar.
>
> Uh, no. First, 'foo and 'bar aren't symbols, they are lists - 'foo is
> the list (quote foo), and 'bar is (quote bar).
I disagree. Sometimes explanations are given with respect to
internal lisp constructs, and sometimes they are given as
instructions for forms to be evaluated for their effect. So
consider discussions about 'foo which represents the symbol,
as opposed to foo which represents the global value of a symbol.
Another time this contrast is used is in distinguishing #'foo
(a function object, after the function form is evaluated) from
the 'foo form which represents the symbol when evaluated.
The phrase "the symbol 'foo" as used above is unambiguous and
should present no problem to readers, since the form (quote foo)
is obviously not a symbol unless evaluated.
> This may seem like nitpicking, and maybe it is. But I think the
> distinction is important. The Lisp newbie needs to understand that
> anything entered at the prompt is first read, then evaluated. Your
> explanation conflates the two, thereby confusing more than it
> illuminates.
Evaluation times are always confusing. My belief is that it is
better to be exposed to as many of these styles as possible, for
practice, in order to understand the power of eval and quote -
it also allows gurus to maintain proper humility for the complexity
and to be glad that they don't have to deal with it every day ...
If you give a newbie the straightjacket of only one way to look
at things, then he'll certainly act out the part of living in
an assylum, just as users of other languages often do.
> So: More correct is to say that the reader reads the text (foo . bar)
> as a cons cell containing the symbols foo and bar. It reads the
> syntax '(foo . bar) as if it were (quote (foo . bar)), and
> /evaluating/ this results in the cons cell which we write (foo . bar)
> - not evaluated further.
I agree that this is correct, but disagree with the assertion that
it is _more_ correct.
> | The #.some-form thing is a reader macro which means "replace
> | me with the value of whatever comes after the #. at read time".
>
> Almost good enough, but I prefer "read whatever comes after #., then
> evaluate it and insert the result into the form currently being
> read".
Preferences are fine, but again, why force people to think that way?
> | For example, try evaluating this:
> |
> | '(1 2 #.(1+ 2) 4 5)
>
> Even more educational: Evaluate the form (read), then type in
> (1 2 #.(1+ 2) 4 5) with or without a quote to see what the reader does
> to the form.
>
> Or one could run a simplified, verbose read-eval-print loop like this
>
> (loop for form = (progn (format t "~&Huh> ") (force-output) (read)) do
> (format t "~&Input form: ~S" form)
> (format t "~{~&=> ~S~}" (multiple-value-list (eval form))))
>
> try some different inputs to it, and see the boundary between reader
> and evaluator in action. This REPL is easy to get out of: Anything
> which provokes an error will get you, via the debugger, back to the
> usual top-level.
Why not just use the Common Lisp toplevel, which already gives you
all of this information?
CL-USER(1): '(1 2 #.(1+ 2) 4 5)
(1 2 3 4 5)
CL-USER(2): (values + *)
'(1 2 3 4 5)
(1 2 3 4 5)
CL-USER(3):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
+ Duane Rettig <·····@franz.com>:
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
|
| > + ·········@gmail.com:
| >
| > | The syntax '(foo . bar) creates [...]
| >
| > Uh, no. [...]
|
| I disagree.
As well you might. Everything you say is correct at some level. My
only problem is that the level we're talking about is fairly newbie
(that was my assumption anyway, otherwise this discussion is moot),
and at that level I think my point is valid. I guess sketerpot's
choice of words just rubbed the teacher in me the wrong way. I
believe there is a need to limit one's vocabulary, and the ways it is
being used, when explaining something for the newbie. Later, when the
basics have been internalized, is the time to relax these restrictions
and speak more freely, relying on context to resolve any ambiguities.
Now, I teach mathematics, not computer science - so it may well be
that my intuitions about what will confuse newbies are off the mark.
| Sometimes explanations are given with respect to internal lisp
| constructs, and sometimes they are given as instructions for forms
| to be evaluated for their effect.
| [...]
| The phrase "the symbol 'foo" as used above is unambiguous and
| should present no problem to readers, since the form (quote foo)
| is obviously not a symbol unless evaluated.
Absolutely. At least, among experienced Lisp users, it is so.
| Evaluation times are always confusing. My belief is that it is
| better to be exposed to as many of these styles as possible, for
| practice, in order to understand the power of eval and quote -
All in good time, yes. But surely not at the very beginning of the
learning process?
| > Or one could run a simplified, verbose read-eval-print loop like
| > [...]
| Why not just use the Common Lisp toplevel, which already gives you
| all of this information?
|
| CL-USER(1): '(1 2 #.(1+ 2) 4 5)
| (1 2 3 4 5)
| CL-USER(2): (values + *)
| '(1 2 3 4 5)
| (1 2 3 4 5)
Heh. I had forgotten about the + variable. Never found a use for it,
but this is an obvious case where it is handy.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Duane Rettig <·····@franz.com>:
>
> | Harald Hanche-Olsen <······@math.ntnu.no> writes:
> |
> | > + ·········@gmail.com:
> | >
> | > | The syntax '(foo . bar) creates [...]
> | >
> | > Uh, no. [...]
> |
> | I disagree.
>
> As well you might. Everything you say is correct at some level. My
> only problem is that the level we're talking about is fairly newbie
> (that was my assumption anyway, otherwise this discussion is moot),
> and at that level I think my point is valid. I guess sketerpot's
> choice of words just rubbed the teacher in me the wrong way. I
> believe there is a need to limit one's vocabulary, and the ways it is
> being used, when explaining something for the newbie. Later, when the
> basics have been internalized, is the time to relax these restrictions
> and speak more freely, relying on context to resolve any ambiguities.
Yes, but one needs to be able to assign notation without necessarily
insistng on it being a particular way while you're teaching.
> Now, I teach mathematics, not computer science - so it may well be
> that my intuitions about what will confuse newbies are off the mark.
As a mathematics teacher, how much Greek do you teach your students
before you dive into concepts using their letters? It's not necessary
to explain perfectly the potentially conflicting uses of a symbology
in order to use them. The initial learning tends to be by rote, and
then students can dive deeper into meanings and discriminations
between various patterns they have learned.
> | Sometimes explanations are given with respect to internal lisp
> | constructs, and sometimes they are given as instructions for forms
> | to be evaluated for their effect.
> | [...]
> | The phrase "the symbol 'foo" as used above is unambiguous and
> | should present no problem to readers, since the form (quote foo)
> | is obviously not a symbol unless evaluated.
>
> Absolutely. At least, among experienced Lisp users, it is so.
It was not a problem to me when I was an inexperienced Lisp user,
either.
> | Evaluation times are always confusing. My belief is that it is
> | better to be exposed to as many of these styles as possible, for
> | practice, in order to understand the power of eval and quote -
>
> All in good time, yes. But surely not at the very beginning of the
> learning process?
Not necessarily how to distinguish, but at least the (correct)
terminology shouldn't be called to question - that is definitely
a way to confuse a newbie with detail he is not ready to handle.
And as I recall, you didn't just call it into question; you labelled
it as wrong.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
+ Duane Rettig <·····@franz.com>:
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
|
| > + Duane Rettig <·····@franz.com>:
| >
| > | Harald Hanche-Olsen <······@math.ntnu.no> writes:
| > |
| > Now, I teach mathematics, not computer science - so it may well be
| > that my intuitions about what will confuse newbies are off the mark.
|
| As a mathematics teacher, how much Greek do you teach your students
| before you dive into concepts using their letters?
None at all.
| > | The phrase "the symbol 'foo" as used above is unambiguous and
| > | should present no problem to readers, since the form (quote foo)
| > | is obviously not a symbol unless evaluated.
| >
| > Absolutely. At least, among experienced Lisp users, it is so.
|
| It was not a problem to me when I was an inexperienced Lisp user,
| either.
Lucky you. Actually, I cannot remember if this was a problem to me.
What I do remember is that I suffered lots of confusion and
misconceptions in the beginning. In particular, I used to worry a lot
(needlessly, as I later found out) about whether or not stuff got
evaluated when I wanted it to.
| > | Evaluation times are always confusing. My belief is that it is
| > | better to be exposed to as many of these styles as possible, for
| > | practice, in order to understand the power of eval and quote -
| >
| > All in good time, yes. But surely not at the very beginning of the
| > learning process?
|
| Not necessarily how to distinguish, but at least the (correct)
| terminology shouldn't be called to question - that is definitely
| a way to confuse a newbie with detail he is not ready to handle.
On the one hand, I still don't see "the symbol 'foo" as /correct/. To
me, it is the sort of (strictly speaking) incorrect language which
experienced people use for the sake of brevity, but can be confusing
to beginners. (But still it grates on my nerves in the same way
incorrect grammar does - it distracts from the real content of the
text, and so is better avoided.)
On the other hand, it is true that we probably confuse the newbie with
this sort of discussion. But that's usenet for you - there is no
private room where we can withdraw and discuss the finer points of
pedagogy without confusing the students.
(And on the gripping hand, it is probably pointless to go on and on
discussing this point, so I'll stop here.)
| And as I recall, you didn't just call it into question; you labelled
| it as wrong.
Maybe I came on too strong, but I think it is better to state opinions
clearly than to be wishy-washy. This way, the issues get out where
they can be examined and viewpoints revised. I have learned something
from our discussion, not about Lisp but about how to talk about Lisp,
which is also important.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Duane Rettig <·····@franz.com>:
>
> | Harald Hanche-Olsen <······@math.ntnu.no> writes:
> |
> | > + Duane Rettig <·····@franz.com>:
> | >
> | > | Harald Hanche-Olsen <······@math.ntnu.no> writes:
> | > |
> | > Now, I teach mathematics, not computer science - so it may well be
> | > that my intuitions about what will confuse newbies are off the mark.
> |
> | As a mathematics teacher, how much Greek do you teach your students
> | before you dive into concepts using their letters?
>
> None at all.
Good approach. The rote comes first, then the explanations of rules
and exceptions. This order is best, because a student is more likely
to remember rules and exceptions if he understands why they are there.
> | > | The phrase "the symbol 'foo" as used above is unambiguous and
> | > | should present no problem to readers, since the form (quote foo)
> | > | is obviously not a symbol unless evaluated.
> | >
> | > Absolutely. At least, among experienced Lisp users, it is so.
> |
> | It was not a problem to me when I was an inexperienced Lisp user,
> | either.
>
> Lucky you. Actually, I cannot remember if this was a problem to me.
> What I do remember is that I suffered lots of confusion and
> misconceptions in the beginning. In particular, I used to worry a lot
> (needlessly, as I later found out) about whether or not stuff got
> evaluated when I wanted it to.
Yes, I did as well. That part is a complexity that should be eventually
taught, just as in natural language one first learns how to speak by
copying, and then one learns what the rules, notations, and exceptions
are.
> | > | Evaluation times are always confusing. My belief is that it is
> | > | better to be exposed to as many of these styles as possible, for
> | > | practice, in order to understand the power of eval and quote -
> | >
> | > All in good time, yes. But surely not at the very beginning of the
> | > learning process?
> |
> | Not necessarily how to distinguish, but at least the (correct)
> | terminology shouldn't be called to question - that is definitely
> | a way to confuse a newbie with detail he is not ready to handle.
>
> On the one hand, I still don't see "the symbol 'foo" as /correct/.
I thought as much.
> To
> me, it is the sort of (strictly speaking) incorrect language which
> experienced people use for the sake of brevity, but can be confusing
> to beginners. (But still it grates on my nerves in the same way
> incorrect grammar does - it distracts from the real content of the
> text, and so is better avoided.)
But the 'foo notation is entirely correct, because it is exactly what
is written in the source! It's the same concept as talking in meta-terms
about parts of speech. Consider, if you will, the three admonitions
'Consider the huddled masses', 'Consider "the huddled masses"', and
'Consider the phrase "the huddled masses"'. The first is unambiguous,
obviously; it is talking about a group of people. The third is likewise
unambiguous; becasue it is clear that a part of speech is being
considered. But the second; what are we talking about here; a part
of speech, or a group of people (emphasized as a group identified
prevously, in this case on the US Statue of Liberty)? I consider
the third style the only way to disambiguate, if that is what is
desired (understanding, of course, that ambiguity might be precisely
what is called for in poetry or in double-entendre).
> On the other hand, it is true that we probably confuse the newbie with
> this sort of discussion. But that's usenet for you - there is no
> private room where we can withdraw and discuss the finer points of
> pedagogy without confusing the students.
I suspect that every lisper has had this same kind of experience of
confusion, and so I consider it important fro them to know that they
are not the only ones.
> (And on the gripping hand, it is probably pointless to go on and on
> discussing this point, so I'll stop here.)
No problem.
> | And as I recall, you didn't just call it into question; you labelled
> | it as wrong.
>
> Maybe I came on too strong, but I think it is better to state opinions
> clearly than to be wishy-washy. This way, the issues get out where
> they can be examined and viewpoints revised. I have learned something
> from our discussion, not about Lisp but about how to talk about Lisp,
> which is also important.
All agreed.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> On the one hand, I still don't see "the symbol 'foo" as /correct/.
Look at the other thread where _a_ symbol 4 is discussed. At first I
wanted to write the symbol '4, but it is not. (quote 4) is a list and
its evaluation produces the fixnum 4.
The evaluation of the following lists all produces _a_ symbol foo:
(quote foo)
(make-symbol "FOO")
(intern "FOO")
(intern "FOO" "SOME-PACKAGE")
(intern "FOO" "KEYWORD") ; while in this case you'd speak of the
; _keyword_ :foo
(quote |Foo|)
(intern "foo")
; etc
So when you speak of the symbol foo, whether you write foo or 'foo,
you're just waving your hand in the general direction of some symbol
and let the reader/listener resolve the ambiguity and infer what
symbol you exactly mean. In conclusion, it doesn't matter.
> To me, it is the sort of (strictly speaking) incorrect language which
> experienced people use for the sake of brevity, but can be confusing
> to beginners.
For beginners, tutorial usually give the exact keying to use and the
expected kind of answer; at the beginning:
Type at the REPL:
( q u o t e space f o o ) return
and get:
FOO
and later in more advanced tutorials:
Type at the REPL:
(quote foo)
and get:
FOO
> (But still it grates on my nerves in the same way
> incorrect grammar does - it distracts from the real content of the
> text, and so is better avoided.)
Grammar is a figment of your imagination. The percentage of
gramatically correct oral phrases is nul or close. And that of
usenet written material is not far either.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
+ Pascal Bourguignon <····@mouse-potato.com>:
| Grammar is a figment of your imagination.
8) Yeah, but I have a vivid imagination.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Pascal Bourguignon schrieb:
> Grammar is a figment of your imagination. The percentage of
> gramatically correct oral phrases is nul or close. And that of
> usenet written material is not far either.
Researchers found that newborn humans had a fundamental knowledge about
grammer. So it may be a good idia to make this oriented at natural
speech. Just to keep things easy.
stefan
In article <·················@freenet.de>, lin8080 <·······@freenet.de>
wrote:
> Pascal Bourguignon schrieb:
>
> > Grammar is a figment of your imagination. The percentage of
> > gramatically correct oral phrases is nul or close. And that of
> > usenet written material is not far either.
>
> Researchers found that newborn humans had a fundamental knowledge about
> grammer.
Sounds a Chomskian prophecy got self-fulfilled. :)
kenny
peng <···········@mail.codecomments.com> wrote in message news:<·································@tng>...
> hi there,
> I am still learning some basic syntax of lisp and happy to learn from
> others here. Also sorry for later some elementary problems put forward
> here.
>
> Here is some others' codes written in ACL I recently can't understand:
>
> (defstruct sort-info . #.sort-slots)
>
> what's the meaning of " . " behind the sort-info.
A token consisting of all dots normally requires that an error be
signaled. There is one exception: a token consisting of exactly one
dot is permitted in the so-called dot notation.
In the dot notation, the dot token precedes the last element of a
parenthesized list. What that means is that the list will be
terminated by the object which follows the dot, rather than by the NIL
symbol.
E.g.
(a b) # list terminated by NIL, equivalent to (a b . nil)
(a b . 3) # list terminated by the atom 3.
A list terminated by an atom other than NIL is called ``improper''.
The dot is sometimes called a consing dot because originally it was a
binary operator which indicated the construction of a cell out of two
elements. That is, the notation (a . b) stands for one cons cell whose
CAR and CDR fields are the atoms A and B, respectively. You can use
the dot notation to represent the conses of a list explicitly, like
this:
(((a . b) . c) . nil)
which represents the same thing as
(a b c)
Note that if you use the dot to terminate a list using another cons,
then effectively, it specifies the spliced list. That is to say
(a b c d e f g)
is the same as
(a . (b c d e f g))
or
(a b . (c d e f g))
and so on: we can continue that all the way to:
(a b c d e f g . ())
and of course () is equivalent to NIL.
This splicing is the key to understanding the DEFSTRUCT you have
encountered:
(defstruct sort-info . #.sort-slots)
Here, there is one more notation, #. or ``hash dot'' which means,
``read the following expression and evaluate it a read time, then
substitute its return value''. So here the Lisp reader will take the
value of the SORT-SLOTS variable and, with the help of the consing
dot, splice it in order to produce a variable DEFSTRUCT form at
read-time. For instance, if SORT-SLOTS holds the list (A B C) then
effectively what ends up being read is:
(defstruct sort-info . (a b c))
which is the same as
(defstruct sort-info a b c)
I.e. the contents of SORT-SLOTS are spliced to form the trailing
portion of the DEFSTRUCT.
Effectively, the Lisp program is dynamically computing a portion of
its own source code at read time.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Effectively, the Lisp program is dynamically computing a portion of
> its own source code at read time.
Very nice explanation. So how do you get Lisp code to be evaluated at
read time? This seems like even more voodoo than having code
evaluated at compile time (macro expansion).
Also, when do you want to do such a thing? The code example from
above:
(defstruct sort-info . #.sort-slots)
seems like code obfuscation unless sort-slots is computed at read time
from some sort of platform dependent information. That computation
would have to occur prior to reading in the above form.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Also, when do you want to do such a thing? [read-time evaluation]
Imagine something like this:
(defconstant +object-db-script+ #.(read-file-contents "XOS:ADMIN;object-db.sql"))
Where the application, when it starts up the very first time,
might go and create its DB schema from the contents of +object-db-script+.
We prefer to not ship the file object-db.sql with the application,
for reasons both technical and non-technical.
Would this count as a good use, do you think?
Alain Picard <············@memetrics.com> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Also, when do you want to do such a thing? [read-time evaluation]
>
> Imagine something like this:
>
> (defconstant +object-db-script+ #.(read-file-contents
> "XOS:ADMIN;object-db.sql"))
>
> Where the application, when it starts up the very first time,
> might go and create its DB schema from the contents of +object-db-script+.
> We prefer to not ship the file object-db.sql with the application,
> for reasons both technical and non-technical.
>
> Would this count as a good use, do you think?
Yes, I think it probably would given good reasons not to ship
object-db.sql. Presumably the end user can still see the contents of
that file by evaluating +object-db-script+ in the REPL. It looks like
a way to merge files.
Is +object-db-script+ then available at macro-expansion time in the
case where you would speed startup by off-loading some work to compile
time?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Is +object-db-script+ then available at macro-expansion time in the
> case where you would speed startup by off-loading some work to compile
> time?
Yes, AFAIK, all forms defined by DEFCONSTANT are immediately
available, in the same compilation environment, for use by
later macro definitions. And there is no reason why #.
could not itself appear in a macro definition function.
Alain Picard <············@memetrics.com> writes:
> David Steuber <·····@david-steuber.com> writes:
>
>> Is +object-db-script+ then available at macro-expansion time in the
>> case where you would speed startup by off-loading some work to compile
>> time?
>
> Yes, AFAIK, all forms defined by DEFCONSTANT are immediately
> available, in the same compilation environment, for use by
> later macro definitions.
Not so, as I understand it, in CMUCL. And, also as I understand it,
the consensus is that there's nothing in the spec that makes CMUCL's
behavior non-conforming.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Not so, as I understand it, in CMUCL. And, also as I understand it,
> the consensus is that there's nothing in the spec that makes CMUCL's
> behavior non-conforming.
Ugh. I've been writing non-conformant code then. :-(
···@ashi.footprints.net (Kaz Kylheku) writes:
> peng <···········@mail.codecomments.com> wrote in message news:<·································@tng>...
> > hi there,
> > I am still learning some basic syntax of lisp and happy to learn from
> > others here. Also sorry for later some elementary problems put forward
> > here.
> >
> > Here is some others' codes written in ACL I recently can't understand:
> >
> > (defstruct sort-info . #.sort-slots)
> >
> > what's the meaning of " . " behind the sort-info.
The " . " is the representation of the wall that separates the CAR
from the CDR.
A cons cell:
+---+---+
|CAR|CDR|
+---+---+
^
|
+--- The dot between CAR and CDR.
> (a b) # list terminated by NIL, equivalent to (a b . nil)
>
> (a b . 3) # list terminated by the atom 3.
+-------------------+ +-------------------------------+
| (a . b) | | (a b . 3) |
| | | |
| +---+---+ +---+ | | +---+---+ +---+---+ +---+ |
| | * | * |-->| B | | | | * | * |-->| * | * |-->| 3 | |
| +---+---+ +---+ | | +---+---+ +---+---+ +---+ |
| | | | | | |
| v | | v v |
| +---+ | | +---+ +---+ |
| | A | | | | A | | B | |
| +---+ | | +---+ +---+ |
+-------------------+ +-------------------------------+
> You can use
> the dot notation to represent the conses of a list explicitly, like
> this:
>
> (((a . b) . c) . nil)
>
> which represents the same thing as
>
> (a b c)
Not exactly:
+-----------------------+ +-----------------------------------+
| (((a . b) . c) . nil) | | (a b c) |
| +---+ | |
| +---+---+ | | +---+---+ +---+---+ +---+---+ |
| | * |NIL| | | | * | * |-->| * | * |-->| * |NIL| |
| +---+---+ | | +---+---+ +---+---+ +---+---+ |
| | | | | | | |
| v | | v v v |
| +---+---+ +---+ | | +---+ +---+ +---+ |
| | * | * |-->| C | | | | A | | B | | C | |
| +---+---+ +---+ | | +---+ +---+ +---+ |
| | | +-----------------------------------+
| v |
| +---+---+ +---+ |
| | * | * |-->| B | |
| +---+---+ +---+ |
| | |
| v |
| +---+ |
| | A | |
| +---+ |
+-------------------+
( A B C ) == ( A . ( B . ( C . NIL ) ) )
But there's no reason why you could not reprensent lists using CAR as
REST instead of CDR:
(defun carlist (&rest args)
(cond ((null args) args)
(t (cons (apply (function carlist) (cdr args)) (car args)))))
(defun carfirst (carcons) (cdr carcons))
(defun carrest (carcons) (car carcons))
(carlist 'a 'b :k :l 1 2)
==> ((((((NIL . 2) . 1) . :L) . :K) . B) . A)
(carfirst (carlist 'a 'b :k :l 1 2))
==> A
(carrest (carlist 'a 'b :k :l 1 2))
==> (((((NIL . 2) . 1) . :L) . :K) . B)
(carfirst (carrest (carlist 'a 'b :k :l 1 2)))
==> B
Of course, it's better to take advantage of the simplified notation
( A B C ) for lists using CDR as REST: ( A . ( B . ( C . NIL ) ) )
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
peng wrote:
> hi there,
> I am still learning some basic syntax of lisp and happy to learn from
> others here. Also sorry for later some elementary problems put forward
> here.
>
> Here is some others' codes written in ACL I recently can't understand:
>
> (defstruct sort-info . #.sort-slots)
>
> what's the meaning of " . " behind the sort-info.
There are two dots in the example, and it's not really clear which one
you mean.
The first is just the "consing dot". List syntax in Lisp is just
shorthand for a longer notation that uses dots. That's because a list is
actually just a number of pairs, called "conses", whose first elements
are the elements of a list and whose second elements are the links to
the next elements of a list.
This means that if you see, say, (1 2 3), you actually have (1 . (2 . (3
. nil))) internally. (1 . <something>) is a pair, (1 . (2 .
<something>)) is a pair whose second element is another pair, and (1 .
(2 . (3 . nil))) has (3 . nil) as its last pair, and nil means the empty
list.
So: (defstruct sort-info . <something>) means that <something> must be a
list (possibly the empty list). In a concrete case, say (defstruct
sort-info a b c), this would be equivalent to (defstruct sort-info . (a
b c)).
Now the #.: This is a notation that evaluates an expression at readtime
and puts the result into the source code. So sort-slots should be a
variable that's already initialized at readtime and supposedly contains
the slot names that make up a sort-info structure.
Essentially, #. allows you to put any object into source code. This is
not so unusual: You can already put for example numbers and strings into
your source code without the need to bind them to variables first. So
for example, (print "Hello, World"), treated as source code, is just a
list with two elements, the symbol 'print and the string "Hello, World".
It's handy that you can put the string object into the source code like
that. Sometimes, it's also handy to put other arbitrary objects into the
source code, and that's what #. is there for.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> [.....]
> Essentially, #. allows you to put any object into source code.
> [.....]
Btw, I cannot compile this file (in cmucl)
$ echo "(defparameter first #.(symbol-function (quote first)))" > example-dot.lisp
(compile-file "example-dot.lisp")
; Python version 1.1, VM version Intel x86 on 02 DEC 04 01:08:35 am.
; Compiling: /home/ssb/jogger.lisp/example-dot.lisp 02 DEC 04 01:08:27 am
; File: /home/ssb/jogger.lisp/example-dot.lisp
; In: DEFPARAMETER FIRST
; (DEFPARAMETER FIRST #<Function FIRST {1037EF79}>)
; --> PROGN SETQ SETQ
; ==>
; #<Function FIRST {1037EF79}>
; Error: Cannot dump objects of type FUNCTION into fasl files.
; Compilation unit finished.
; 1 error
;; --------------------------------------------------------
In CLISP it's ok:
[2]> (compile-file "example-dot.lisp")
Compiling file /home/ssb/jogger.lisp/example-dot.lisp ...
0 errors, 0 warnings
[3]> (load *)
[4]> (funcall first '(1))
1
Regards, Szymon.
Pascal Costanza schrieb:
> peng wrote:
> > what's the meaning of " . " behind the sort-info.
> The first is just the "consing dot".
(setq a (cons 2 22))
> (2.22)
(setq c (cons 3 33))
> (3.33)
(reverse c)
> a true list must not end with 33
(setq xx (cons c nil))
>((3.33))
(reverse xx)
> ((3.33))
(setq yy (cons a nil))
>((2.22))
(setq zz (cons (car xx) yy))
>((3.33) (2.22))
(reverse zz)
>((2.22) (3.33))
(list (nth 0 xx))
>((3.33))
xx
>((3.33))
(nth 0 (nth 0 xx)) --> 3
(nth 0 (nth 1 xx)) --> NIL
(nth 1 (nth 0 xx)) --> NTH 33 is not a list
(nth 1 (nth 1 xx)) --> NIL
more: nthcar, nthcdr, first vs last, ...
lin
who needs cddr and consorts?
lin8080 wrote:
> who needs cddr and consorts?
I do. ;)
Pascal
--
Pascal Costanza University of Bonn
·········@p-cos.net Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
peng <···········@mail.codecomments.com> writes:
> Here is some others' codes written in ACL I recently can't understand:
>
> (defstruct sort-info . #.sort-slots)
Would it be better to write that as:
#.`(defstruct sort-info ,@sort-slots)
I think ,@ shows the intent better than . but I don't like having
to move the #. to the beginning of the form.
Kalle Olavi Niemitalo wrote:
> peng <···········@mail.codecomments.com> writes:
>
>>Here is some others' codes written in ACL I recently can't understand:
>>
>>(defstruct sort-info . #.sort-slots)
>
> Would it be better to write that as:
>
> #.`(defstruct sort-info ,@sort-slots)
>
> I think ,@ shows the intent better than . but I don't like having
> to move the #. to the beginning of the form.
It depends. Peter Norvig uses the (... . list) variant instead of (...
,@list) throughout his book. I guess this is just a matter of style.
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon