From: Stephan BRUNESSAUX
Subject: Re: Common Lisp Problems with Hash-table in Macros
Date:
Message-ID: <701@crin.crin.fr>
In article <···@aipna.ed.ac.uk> you write:
>In article <···@crin.crin.fr> ·······@crin.crin.fr (Stephan BRUNESSAUX) writes:
>>Is there anybody out there who can explain me what is wrong with this
>>example which correctly runs in both interpreted and compiled mode on
>>Symbolics 3620 (Genera 7.2) and correctly ONLY in interpreted mode on
>>TI Explorer II and on VAX running KCL (June 3, 1987) but not in compiled
>>mode !?...
>
>> >(defmacro test (a b)
>> (let ((table (make-hash-table :size 1)))
>> (setf (gethash a table) b)
>> `(defun aux ()
>> (maphash #'(lambda (key val)
>> (format t "key: ~a - val: ~a~%" key val))
>> ',table))))
>
>The problem is that you're trying to compile some code that contains
>aquoted hash table. So, the compiler has to put a representation of
>that hash table into the ".o" file. In KCL, the hash table just gets
>PRINTed and so looks like this:
>
> #<hash-table 0017a310>
>
>When LOAD tries to read this, it calls READ which sees the # and calls
>the reader for the # dispatching character macro. It then sees the <
>and signals an error.
>
>I don't know what happens on the Explorer.
My first question is : why the compiler does not DUMP the hash table ?
The above example correctly runs if you supersede the hash table by a vector
(with some changes to display the contents).
On Symbolics, the hash table is DUMPed; so, you can read or modify the hash
table after loading the compiled file.
On KCL, it is impossible since it is a PRINTed representation which is
compiled.
On Explorer, the hash table seems to be dumped but no longer works since you
cannot add or remove any entries.
My second question is : Am I right to write that kind of macro ?
My third question is : As far as I developped on Symbolics (in Common Lisp
package) a big software using that kind of macros, is it normal to encounter
such problems on others Common Lisps ?
Thanks for all suggestions.
STEPHAN.
--
Stephan Brunessaux
CRIN-INRIA Lorraine
BP 239 - 54506 VANDOEUVRE CEDEX - FRANCE
E-MAIL: ·······@crin.crin.fr
From: Paul Fuqua
Subject: Re: Common Lisp Problems with Hash-table in Macros
Date:
Message-ID: <65699@ti-csl.CSNET>
Date: Tuesday, December 13, 1988 1:15pm (CST)
From: stephan at crin.crin.fr (Stephan BRUNESSAUX)
Subject: Re: Common Lisp Problems with Hash-table in Macros
Newsgroups: comp.lang.lisp
On Explorer, the hash table seems to be dumped but no longer works since you
cannot add or remove any entries.
The problem is that the quoted-constant hash-table is being compiled
into a read-only area, and MAPHASH errors when it tries to write to the
hash-table-lock. Our compiler guy entered a bug-report on the problem,
since MAPHASH is not a destructive operation, so hash-tables ought to be
special-cased. His further comments:
"This is interesting because the ANSI Common Lisp compiler subcommittee
is currently discussing rules for how constants are to be dumped and
loaded and one of the stickiest problems has been deciding which
attributes of a hash table need to be preserved. I had thought the
issue was rather academic since I hadn't ever seen anyone try to use a
hash table as a constant before."
My second question is : Am I right to write that kind of macro ?
I would not write such a macro because any quoted constant is likely to
be write-protected -- you shouldn't be modifying a quoted constant in
your program, it's "constant." I have a distaste for dumping complex
structures as constants in any case, preferring to write macros that
expand into construction forms that are evaluated at load time.
Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet: ··@csc.ti.com (ARPA too, sometimes)
UUCP: {smu, texsun, cs.utexas.edu, rice}!ti-csl!pf
From: Jeff Dalton
Subject: Re: Common Lisp Problems with Hash-table in Macros
Date:
Message-ID: <403@aipna.ed.ac.uk>
In article <···@crin.crin.fr> ·······@crin.crin.fr (Stephan BRUNESSAUX) writes:
>In article <···@aipna.ed.ac.uk> you write:
>>In KCL, the hash table just gets PRINTed and so looks like this:
>>
>> #<hash-table 0017a310>
>My first question is : why the compiler does not DUMP the hash table ?
I guess it's because someone would have to write DUMP, whatever it is.
CLtL doesn't say much about what should happen to quoted constants in
code that gets compiled. There are some cleanup items about this
being discussed by the X3J13 Compiler subcommittee, so it should be
clarified in the standard; but right now different implementations
do quite different things. There has also been a proposal to give
hash tables a printed representation, by the way.
>The above example correctly runs if you supersede the hash table by a vector
>(with some changes to display the contents).
True.
>On Symbolics, the hash table is DUMPed; so, you can read or modify the hash
>table after loading the compiled file.
Some implementations might put it in a read-only area.
>On Explorer, the hash table seems to be dumped but no longer works since you
>cannot add or remove any entries.
Not surprising.
>My second question is : Am I right to write that kind of macro ?
That will depend on what X3J13 finally says. I think it is probably
safe to use something like "#," (or a LOAD-TIME-EVAL special form, if
it gets added to Common Lisp) to include an expression that builds the
hash table at load time.
>My third question is : As far as I developped on Symbolics (in Common Lisp
>package) a big software using that kind of macros, is it normal to encounter
>such problems on others Common Lisps ?
Probably, because it isn't well-defined by Common Lisp: the Language,
and because people don't completely agree on what should be done.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton