Dear all,
In my application users may supply library definitions of the form
(FOO-TYPE-DEF
`(baz
(param-a . 34.567)
(param-b . (a b c d))
(param-c . (boo))))
Where the macro FOO-TYPE-DEF does some reformatting as necessary on
the parameters associated with BAZ before adding the entry to the
library of FOO types. The dotted list notation is used, of course,
because further down the line variations of ASSOC are used to pick out
parameter values. Importantly, it is assumed that each parameter is
associated with either a single atom or form.
Nevertheless, from the user's point of view it would seem that the dot
notation is superfluous. I would like to eliminate this requirement,
allowing:
(FOO-TYPE-DEF
`(baz
(param-a 34.567)
(param-b (a b c d))
(param-c (boo))))
but without changing a lot of code that expects the dotted lists. In
other words, I want to change, for example, the definition of
FOO-TYPE-DEF so that it treats the parameter sublists as dotted lists,
and is also backward compatible.
So, the parser should somehow map
Example Input Desired Output
-------------------------------------------------------
1 '(param-a . 34.567) (PARAM-A . 34.567)
2 '(param-a 34.567) (PARAM-A . 34.567)
3 '(param-b . (a b c d)) (PARAM-B A B C D)
4 '(param-b (a b c d)) (PARAM-B A B C D)
5 '(param-c . (34.567)) (PARAM-C 34.567)
6 '(param-c (34.567)) (PARAM-C 34.567)
I can determine example 1 with a function like PROPER-LIST?
given by Graham (p49).
Example 3 can be determined by the fact that it is a proper list and
its length is greater than 2.
Examples 4 and 6 can be determined by the fact that they are proper
lists,
and have length equal to 2 with the 2nd element a cons.
I am stuck on distinguishing examples 2 and 5, since I can't find
anyway to detect the "." in the original form (and both are proper,
and EQUAL, lists). Is this a readtable issue?
Thanks for any ideas,
Lyle
--
............................................................
Lyle Borg-Graham
Equipe Cognisciences, Institut Alfred Fessard, CNRS
91198 Gif-sur-Yvette
FRANCE
tel: (33 1) 69 82 34 13 fax: (33 1) 69 82 34 27
_ o
/ /
. . . . . . _ _/|
From: Kent M Pitman
Subject: Re: Hiding dotted list notation from the user
Date:
Message-ID: <sfwemkd5ism.fsf@world.std.com>
Lyle Borg-Graham <····@spam*cogni.iaf.cnrs-gif.fr*spam> writes:
> ... from the user's point of view it would seem that the dot
> notation is superfluous. I would like to eliminate this requirement,
Many people use cadr-style instead of cdr-style [or list-style instead
of cons-style, depending on how you look at it] alists. Common Lisp's
ASSOC is quite neutral about this choice, though RASSOC is not. [You
can use FIND with a :KEY #'CADR argument to make up for it.]
You should know, of course, that cadr-style alists are more storage
intensive, requiring two conses per entry instead of one. And they
are more expensive to access, requiring two memory-reads to get the
cadr instead of one to get the cdr. But for many applications neither
of these is a big deal. Using lists instead of conses has the virtue
that if you ever need another element in the same entry, there is a
place to put it. In (a . b) there is no room for a c, but in
(a b) you can always make (a b c) without perturbing most other uses
[other than punning on the whole tail].
> So, the parser should somehow map
>
> Example Input Desired Output
> -------------------------------------------------------
> 1 '(param-a . 34.567) (PARAM-A . 34.567)
> 2 '(param-a 34.567) (PARAM-A . 34.567)
> 3 '(param-b . (a b c d)) (PARAM-B A B C D)
> 4 '(param-b (a b c d)) (PARAM-B A B C D)
> 5 '(param-c . (34.567)) (PARAM-C 34.567)
> 6 '(param-c (34.567)) (PARAM-C 34.567)
>
>
> I can determine example 1 with a function like PROPER-LIST?
> given by Graham (p49).
>
> Example 3 can be determined by the fact that it is a proper list and
> its length is greater than 2.
>
> Examples 4 and 6 can be determined by the fact that they are proper
> lists,
> and have length equal to 2 with the 2nd element a cons.
These are all domain issues in your proram. 1 and 2 are only usefully
distinguished because you know that, in application data, lists of
numbers do not occur. Item 2 could mean (parama-a . (34.567)) on input,
in which case it is not correctly reduced to the indicated output style,
but must be reduced per example 3.
> I am stuck on distinguishing examples 2 and 5, since I can't find
> anyway to detect the "." in the original form (and both are proper,
> and EQUAL, lists). Is this a readtable issue?
You have to write your own reader if you want to distinguish these
cases. The post-READ distinction between 2 and 5 is non-existent.
They are identical in meaning. Further, "." has magic properties
that you will have trouble simulating in readtables. if this is your
only use of "." in your application, you could consider making "." a
constituent character and then just recognizing lists that have
"." as the second element of a list and translating those to be dotted
pairs. But I don't recommend that.
> Thanks for any ideas,
I recommend you come to grips with the fact that (a . (b c)) and (a b
c) are just textually the same object, just as (a b c) is the same as
(a b c). The reader takes care of collapsing whitespace and of
collapsing cascaded dotted pairs. You don't get in there in time for
that. You should make your alists either be cdr-style or cadr-style,
but it is not a good use of your precious time on earth fighting this
problem, in my opinion. When you get all done with it, you will be no
closer to solving any of the problems you set out in life to solve.
To paraphrase a well-worn piece of advice, no one has ever been heard
on their deathbed saying "I wish I'd spent more time trying to get rid
of those stupid looking dots in the dotted pairs of my lisp code's
alists." If getting rid of the the dots matter to you a lot, just use
lists and take the speed hit. Or write a special readmacro on "["
that lets you say [x y] and have it turn into (x . y). But don't try
to make lisp dotted pairs be what they are not. I have spent more
time doing this than I should have, and trust me, it's not something I
regret having gotten out of.
From: Lyle Borg-Graham
Subject: Re: Hiding dotted list notation from the user
Date:
Message-ID: <7huj5b$n06$1@upsn21.u-psud.fr>
Kent M Pitman wrote:
>
> Many people use cadr-style instead of cdr-style [or list-style instead
> of cons-style, depending on how you look at it] alists. Common Lisp's
> ASSOC is quite neutral about this choice, though RASSOC is not. [You
> can use FIND with a :KEY #'CADR argument to make up for it.]
In my application the cdr-style alist decision was made early on,
without thinking too carefully about it, unfortunately (for this
particular part of the application database, the storage/efficiency wins
for cdr-style are not important).
> You have to write your own reader if you want to distinguish these
> cases. The post-READ distinction between 2 and 5 is non-existent.
> They are identical in meaning. Further, "." has magic properties
> that you will have trouble simulating in readtables. if this is your
> only use of "." in your application, you could consider making "." a
> constituent character and then just recognizing lists that have
> "." as the second element of a list and translating those to be dotted
> pairs. But I don't recommend that.
This is more or less what I was afraid of, given that one half of my
brain had indeed come to grips with the EQUALness of (a . (b c)) and (a
b c), but the other half thought there might be an elegant way to
subvert it for this particular aspect of the user interface.
> but it is not a good use of your precious time on earth fighting this
> problem, in my opinion. When you get all done with it, you will be no
> closer to solving any of the problems you set out in life to solve.
> To paraphrase a well-worn piece of advice, no one has ever been heard
> on their deathbed saying "I wish I'd spent more time trying to get rid
> of those stupid looking dots in the dotted pairs of my lisp code's
> alists."
Indeed, my app will survive with this, as you say.
Thanks for the clarification!
............................................................
Lyle Borg-Graham
Equipe Cognisciences, Institut Alfred Fessard, CNRS
91198 Gif-sur-Yvette
FRANCE
tel: (33 1) 69 82 34 13 fax: (33 1) 69 82 34 27
_ o
/ /
. . . . . . _ _/|
···@sevak.isi.edu (Thomas A. Russ) writes:
> Lyle Borg-Graham <····@spam*cogni.iaf.cnrs-gif.fr*spam> writes:
>
> > So, the parser should somehow map
> >
> > Example Input Desired Output
> > -------------------------------------------------------
> > 2 '(param-a 34.567) (PARAM-A . 34.567)
> > 5 '(param-c . (34.567)) (PARAM-C 34.567)
> >
> > I am stuck on distinguishing examples 2 and 5, since I can't find
> > anyway to detect the "." in the original form (and both are proper,
> > and EQUAL, lists). Is this a readtable issue?
>
> As you note, the problem is that examples 2 and 5 are just alternative
> ways of writing the same list structure. That means that there is no
> way of determining the difference between the two structures once they
> have passed through the reader.
>
> I suppose it may be possible to modify the readtable in such a way that
> the "." isn't interpreted as being a consing operator. You could then
> search the input for an occurence of the symbol |.| in the second
> position of the list.
>
> But since this is a read-time issue, you would have to modify the
> readtable in the environment in which the data files are being read in.
> If this modification is made to the global readtable (in other words if
> users are supposed to be able to type this in at top level), then you
> would potentially break any other code that uses dotted pairs in its
> input.
I have not followed the beginning of this discussion, but I believe
that this is a case where poor Lisp teaching (i.e. old-fashioned) plus
poor Elisp programming are the real cause.
What you really want to to is
(defstruct param name data)
(make-param :name 'param-a :data 34.567)
(make-param :name 'param-b :data '(34.567))
and so on... DEFSTRUCT options can be used to limit the amount of
typing. Note that the above works in Elisp as well, but a lot of,
even fairly new, Elisp packages insist on using alists of list coded
data structures when DEFSTRUCT would fit the bill.
The morale of this story is to put
(require 'cl)
in your .emacs file.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa