Re: Is DEFCONSTANT broken?
- From: Scott Burson <FSet.SLB@xxxxxxxxx>
- Date: Wed, 24 Jun 2009 19:51:11 -0700 (PDT)
On Jun 23, 10:32 pm, Duane Rettig <du...@xxxxxxxxx> wrote:
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?
I think it could, but again this is off the cuff. I don't have a
fully thought out proposal and I probably won't bother to produce one.
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.
??? I proposed that for each compiled function the implementation
would remember all values of constants integrated into the compiled
code. Even constant-heavy code is going to have what, on average --
two or three of these per routine? How much space do you think we're
talking about here?
I'm not saying this is a very important feature, but I think the
reason not to do it is that it's more trouble to implement than it's
worth, not that the fasl file space requirement would be prohibitive.
-- Scott
.
- Follow-Ups:
- Re: Is DEFCONSTANT broken?
- From: Duane Rettig
- Re: Is DEFCONSTANT broken?
- References:
- Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Pascal J. Bourguignon
- Re: Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Scott Burson
- Re: Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Kaz Kylheku
- Re: Is DEFCONSTANT broken?
- From: Kaz Kylheku
- Re: Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Scott Burson
- Re: Is DEFCONSTANT broken?
- From: Duane Rettig
- Re: Is DEFCONSTANT broken?
- From: Scott Burson
- Re: Is DEFCONSTANT broken?
- From: Duane Rettig
- Re: Is DEFCONSTANT broken?
- From: Scott Burson
- Re: Is DEFCONSTANT broken?
- From: Duane Rettig
- Is DEFCONSTANT broken?
- Prev by Date: Re: read-from-string t nil :start
- Next by Date: Softwear and Games
- Previous by thread: Re: Is DEFCONSTANT broken?
- Next by thread: Re: Is DEFCONSTANT broken?
- Index(es):
Relevant Pages
|