[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dumping weird objects to compiled files
- To: email@example.com, firstname.lastname@example.org
- Subject: dumping weird objects to compiled files
- From: Don Cohen <email@example.com>
- Date: Thu, 15 Dec 88 18:52:28 PST
- Cc: firstname.lastname@example.org
- Posted-date: Thu, 15 Dec 88 18:52:28 PST
The commonlisp spec is quite vague on what exactly the compiler
should do and provides no control over how or whether strange
objects can be dumped at all. However, in the case of structures
it does provide for a print function. Suppose I have a function
F that uses a macro M which expands into some structure of type S.
1. If I give S a print function, can I expect that when I compile F
to a file, that print function will be used to write something to
the compiled file that will be read to return the "corresponding"
object when the file is loaded? (I'm interested in justifications
for either answer.) The other possibility is that the compiler
would ignore the print function and dump something that would,
when loaded, create a structure of type S and fill its slots with
objects that were recursively dumped. If I could count on my print
function being used, I could arrange for it to print something that
would "do the right thing".
2. If you don't think that my expectation is justified, do you
think the commonlisp spec ought to say that it is (thereby making
This "trick" would allow us to write a macro that allows macros
to generate the analog of #, which I think is a feature sorely
missed in commonlisp. This in turn would go a long way toward
solving what I regard as a problem with the spec - that EQUAL
values may be identified. This is a solution just because it
returns control over what things are EQ to the user, who knows
which things he wants to be EQ, which things he does NOT want EQ
and which don't matter.