Save to file/restore from file - Lisp structures
Bruce Lester
macro that saves and restores hash tables from files.
The hash table is defined by:
(defvar *payees* (make-hash-table :test #'equal)
"Payees with checks paid to each.")
After entries are created, the tutorial says that the state of the hash
table can be written to a file by using print.
(print *payees* file-stream)
When I try to print a hash table from Franz Lisp, I get a summary line
instead of the
contents of the hash table. Is this because the tutorial I am reviewing is
old or that Franz did something differrent than the standard.
Is there a general way (other than Lisp image) to save and restore the
contents of Lisp structures?
Thanks.
Daniel Lakeland
<bruce....@digi.com> wrote:
I don't think there is any portable way to write hash tables to files
without writing the code to do it yourself.
There is a discussion of this that you can find in the CL FAQ at the AI
repository at CMU. There they create a way to write arbitrary objects
into a file, but it's basically by compiling a file and producing a
compiled representation of the objects.
There is also some code to write hash tables to files in CLOCC
(clocc.sourceforge.net) This is probably your best bet provided what's in
the hash tables is all easily writable (ie. no structs or clocc objects etc)
The problems of writing things to files is basically identical to the
problems of a generalized "copy" operator which periodically erupts as a
flame war :-) Check groups.google.com for threads on a "copy" operator.
Barry Margolin
>macro that saves and restores hash tables from files.
>
>The hash table is defined by:
>
>(defvar *payees* (make-hash-table :test #'equal)
> "Payees with checks paid to each.")
>
>After entries are created, the tutorial says that the state of the hash
>table can be written to a file by using print.
>
>(print *payees* file-stream)
>
>When I try to print a hash table from Franz Lisp, I get a summary line
>instead of the
>contents of the hash table. Is this because the tutorial I am reviewing is
>old or that Franz did something differrent than the standard.
The standard does not specify that hash tables must have a readable printed
representation. That Lisp tutorial was presumably written by someone who
used an implementation that has an extension to do this, and assumed it was
a standard feature. It's never been required, and I don't think it will
work in most Common Lisp implementations.
>Is there a general way (other than Lisp image) to save and restore the
>contents of Lisp structures?
Some data types are required to have readable printed representations, and
*PRINT-CIRCLE* can be used to ensure that sharing relationships among the
objects that are printed are retained. The I/O chapters of CLTL2 and the
CL standard have details about which types are supported for this.
There's a function SAVE-OBJECT in the Lisp source archive that attempts to
save objects of a wide variety of types beyond what the standard requires.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum
| After entries are created, the tutorial says that the state of the hash
| table can be written to a file by using print.
| Is this because the tutorial I am reviewing is old or that Franz did
| something differrent than the standard.
Your tutorial is lying to you. If you want the truth about the standard,
consult the standard and only the standard.
The first problem is that there is no (standard) reader macro that builds
and returns a hash table. And since each of the hash-tables are of type
hash-table, not of type structure-object, #S shall _not_ be used to build
one. You could easily write a print-object method for hash-tables, but
that is not quite kosher, either. (See ANSI X3.226 11.1.2.1.2 item 19.)
If you create your own streams class sub-type, you can get around this,
and since you can create classes at run-time, you can conceivably write a
class that does only hash-table printing and use it as a mixin with the
class of the stream in a particular instance. This gets to be a little
bit more work than you probably expected, and is thus a typical case for
vendor initiative, but the standard is restrictive on what a conforming
implementation can do in this case. I think this is unfortunate, but if
the vendors agree on how to do this, the standard will be extended in
letter but maintained in spirit, just as it would be if this were added
with the appropriate standards committee blessing.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Thomas F. Burdick
> * Bruce Lester
> | After entries are created, the tutorial says that the state of the hash
> | table can be written to a file by using print.
> :
> | Is this because the tutorial I am reviewing is old or that Franz did
> | something differrent than the standard.
[...]
> (See ANSI X3.226 11.1.2.1.2 item 19.)
I'm guessing "the tutorial I am reviewing" implies unfamiliarity with
CL. Section 11.1.2.1.2 of the spec can be found here:
<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_11-1-2-1-2.html>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman
> You could easily write a print-object method for hash-tables, but
> that is not quite kosher, either. (See ANSI X3.226 11.1.2.1.2 item 19.)
In HyperMeta's libraries, I have a type TABLE that has a single slot that's
a hash table and methods for passing referencing table elements (passthrough
to GETHASH, etc.) and for PRINT-OBJECT that prints in a way that is rereadable.
Kind of a long way to go, but at least it's one way to get things printed
and be within the standard.
I don't think an implementation is forbidden from using #S to print hash
tables re-readably. I do think it's unsafe for portable code to rely on
it, though...