Re: Is DEFCONSTANT broken?

On Jun 23, 6:17 pm, Duane Rettig <du...@xxxxxxxxx> wrote:
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 you made a mistake?

Perhaps MAKUNBOUND would do for this. It's rarely enough used that
one is unlikely to call it without thinking.

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.

Right.

 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?

This seems a very strange question in an era when a terabyte disc
drive costs under $100.

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.

So you don't try to use DEFCONSTANT for this either. Sounds like
agreement to me :)

-- Scott
.

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... > Microsoft compiler, or do you draw the line at C89? ... in the same sense that the implementors of the Lua language considered C to be ... Now why would they bother if portable mutex implementations ... C doesn't have strings. ...
    (comp.lang.c)
  • Re: Is DEFCONSTANT broken?
    ... But in this "new and improved" CL where defconstant really defines ... implementation noting cases where the compiler has integrated a ... declared constant into a compiled routine, in such a way that it could ... before Bill Gates made his famous "nobody will ever need 840K memory" ...
    (comp.lang.lisp)
  • Re: "Sorting" assignment
    ... place depending on implementations, including implementations in which ... issue on some ancient compiler doesn't make a lot of sense. ... I think we better forget about XOR. ... to his on a few commonly used platforms and compilers, ...
    (comp.programming)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... > a compliant C99 targetting them? ... With programmers like you having built that assumption ... I've used implementations of C on systems that would ... good C compiler and optimizing assembler that can ...
    (sci.crypt)
  • Re: Symbol macros dont capture their lexical environments?
    ... And yet you posted a transcript of running that code in CLisp without ... and instead "leaking" internal compiler information. ... and the very reason why I had brought up ... especially when all other implementations ...
    (comp.lang.lisp)