Re: Is DEFCONSTANT broken?

On Jun 23, 9:23 pm, Scott Burson <FSet....@xxxxxxxxx> wrote:
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.

But in this "new and improved" CL where defconstant really defines
something that can't be changed, would makunbound then have an effect?

 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.

This argument has been given since the beginning of computing, long
before Bill Gates made his famous "nobody will ever need 840K memory"
quip. We're giving people those terabytes, and it's not enough. when
more becomes available, it will not be enough. Besides, it's usually
not available memory that limits the economics of memory usage.

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 :)

Agreement that defconstant is not the right tool for this situation.
It is a situation similar to what Ron is wanting to do (except for
immutability guarantees), and it works well in Allegro CL, but I don't
know how well it would work in other CLs. But it was meant to be a
helpful idea for Ron, and thus a non-sequitur, so no, it's not
necessarily agreement in general.

Duane
.

Relevant Pages

  • Re: Is DEFCONSTANT broken?
    ... that's why warnings are given by most implementations ... implementation noting cases where the compiler has integrated a ... declared constant into a compiled routine, in such a way that it could ... So you don't try to use DEFCONSTANT for this either. ...
    (comp.lang.lisp)
  • Re: WWDC -- MacBook Pro?
    ... ....but once the program has loaded it into its program memory, ... boundaries, int16 are aligned on 2 byte boundaries, int32 are ... people are always able to come up with the compiler ... Case B, same glass, same ice code water.  ...
    (comp.sys.mac.system)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)
  • Re: Compiler and How It Handles Scope
    ... VB's compiler isn't really "state of the art" David. ... memory, no matter how many processes map the code into their virtual address ... words, no real distinction is made between Public/Private variables, or even ... > Modules can contain Public and Private variables, ...
    (microsoft.public.vb.winapi)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... that later locks the same mutex. ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)