Suppose I have
(defstruct mark
a
b)
And few functions that use MAKE-MARK, MARK-A, MAKR-B.
Should I recompile them (functions) after changing MARK to
for example
(defstruct mark
(a 0)
(b 1))
?
In general: is it true to say 'After any change of DEFSTRUCT
form all code that uses it must be recompiled' ?
--
Vladimir Zolotykh
In an attempt to throw the authorities off his trail, Vladimir Zolotykh <······@eurocom.od.ua> transmitted:
> Suppose I have
>
> (defstruct mark
> a
> b)
>
> And few functions that use MAKE-MARK, MARK-A, MAKR-B.
> Should I recompile them (functions) after changing MARK to
> for example
>
> (defstruct mark
> (a 0)
> (b 1))
>
> ?
>
> In general: is it true to say 'After any change of DEFSTRUCT
> form all code that uses it must be recompiled' ?
No, it is not true, in general.
It _is_ true, in general, to say that:
The consequences of redefining a defstruct structure are
undefined.
(That is, after all, what the standard says.)
The consequences could conceivably include Kent Pitman and Erik Naggum
being sent to your office to beat up your boss. (Not that that's a
terribly _likely_ consequence :-).) Specific implementations probably
have more specific consequences, but the standard certainly doesn't
define anything you might use as guidance.
If you are expecting to need to change the structure, then you
probably should use DEFCLASS instead, as it has rather more clearly
defined semantics as to what happens if you modify slots.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/lisp.html
Would-be National Mottos:
Canada: "We're nicer than you, and we've got national health insurance."
(Message on billboards all over the US-Canada border, sponsored by the
National Council of Smug Canadians)
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> In general: is it true to say 'After any change of DEFSTRUCT
> form all code that uses it must be recompiled' ?
In general, it is true that "The consequences of redefining a
defstruct structure are undefined." See
<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/m_defstr.htm>
So it may not even be enough to recompile code that uses the structure
in question. Your implementation may allow you to get away with this,
of course, but it's not generally valid. (CMUCL 18c issues a warning
and some useful continuations.)
I find that it's usually easier to develop with CLOS classes, because
in the early stages of development, it is not uncommon to need to
redefine/extend my data structures.
...Peder...
--
Cogito ergo panta rei.
> In general, it is true that "The consequences of redefining a
> defstruct structure are undefined."
OK, Safe enough would be to behave as the structure defined the
first time, I suppose.
--
Vladimir Zolotykh