Re: Is DEFCONSTANT broken?

On Jun 23, 5:09 pm, Scott Burson <FSet....@xxxxxxxxx> wrote:
On Jun 23, 3:20 pm, Duane Rettig <du...@xxxxxxxxx> wrote:

On Jun 23, 2:40 pm, Scott Burson <FSet....@xxxxxxxxx> wrote:
I have long thought DEFCONSTANT is
not as useful as its inventor(s) probably hoped.

That's because you're thinking of defconstant as providing some sort
of "protection", which it does not.

There's that, but there's also the issue raised on the SBCL page
someone in this thread linked to, which is that it arguably would be
better if it didn't assign a new value on repeated evaluation (i.e. it
should be more like DEFVAR).

Perhaps. But then your program would be write-only. What do you do
when you realize that yopu made a mistake? Lisp is good at allowing
you to redefine things, and so the concept of a truly immutable object
is foreign to Lisp. Instead, what seems to be meant by some level of
immutability (as is described in the glossary definition of immutable)
is that the means to modify the object is taken away (and this could
be on a graduated basis).

Back to your point, no, I'm not into bondage either, but I do
appreciate helpfulness.

As do we all; that's why warnings are given by most implementations
when a constant is redefined.

 For example, I could imagine an
implementation noting cases where the compiler has integrated a
declared constant into a compiled routine, in such a way that it could
e.g. warn you, when loading a fasl file, if the current value of the
declared constant differs from the one the function was compiled
with.  I don't know if the spec should have mandated such helpfulness,
but I think DEFCONSTANT would be more useful if at least the high-end
implementations did stuff like that.

Well, there's nothing to prevent an implementation from doing this,
but I certainly wouldn't - how much memory and code overhead do you
think might be involved in remembering that this value 23 compiled
inline into this function's code came from the particular constant you
compiled long ago?

And thirdly, I'm inclined to agree with Ron that the sentence of the
spec he quoted is unfortunate: "An implementation may choose to
evaluate the value-form at compile time, load time, OR BOTH [emphasis
added]."  I think it should have to be evaluated at compile time,
period, and Ron has given a good argument as to why.

This is part of the whole environments issue. Environments are not
well-defined, but they are strongly indicated, and defining forms (as
is defconstant) are free to choose where they place their definitions
(see 3.2.3.1.1). We've had lengthy conversations about this issue,
and I'd prefer not to rehash it; perhaps someone can point to the
relevant thread.

All this is off the cuff, though, and I could be persuaded otherwise.
I just know that over the years I have made little use of DEFCONSTANT.

I probably should have mentioned this to Ron, but I can't spare the
time to do this right now; instead I'll just show it here. This is
what we do when we need something that acts like a constant; we don't
bother hiding it, but it provides very efficient access. In our hash-
table implementation, the "empty" and "deleted" values are provided by
this style:


(eval-when (:compile-toplevel :execute)
(define-symbol-macro .empty-entry-marker. (load-time-value *empty-
entry-marker*))
)

(defvar *empty-entry-marker* (list :empty))

Then in our code we reference .empty-entry-marker. Mutatis mutandis
for the deleted marker. This not only gives us markers that are
accessed quickly, but their values are valid across lisp invocations.
Perhaps if necessary I can go into more detail when I have more
time...

Duane
.

Relevant Pages

  • Re: Is DEFCONSTANT broken?
    ... thought the only way I coyld get immutability in CL is with DEFCONSTANT, ... and that at least potentially gives me a compile time value whether I ...
    (comp.lang.lisp)
  • Re: Blowfish, and a question about DEFCONSTANT
    ... > of DEFCONSTANT, or that of SBCL. ... compile time, load time, or both. ... So SBCL is complaining here about 'uninterned ...
    (comp.lang.lisp)
  • Re: Is DEFCONSTANT broken?
    ... That's because you're thinking of defconstant as providing some sort ... I'm inclined to agree with Ron that the sentence of the ... I think it should have to be evaluated at compile time, ...
    (comp.lang.lisp)
  • Re: creaping coupling......
    ... In C++ it would be trivial to break that source code dependency, ... When you compile a .java module, ... In Java and C# it's asserted at compile time. ...
    (comp.object)
  • Re: VB Compiler Warnings & other woes ...
    ... you will get this warning in vs 2005. ... > have a direct legacy language path of evolution to consider. ... >> compile time errors rather than runtime. ...
    (microsoft.public.dotnet.languages.vb)