Re: Is DEFCONSTANT broken?
- From: Ron Garret <rNOSPAMon@xxxxxxxxxxx>
- Date: Tue, 23 Jun 2009 17:01:08 -0700
In article
<b75fdb8a-6682-4954-b91e-8a087b81069c@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Thomas F. Bur***" <tbur***@xxxxxxxxx> wrote:
On Jun 23, 7:14 pm, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
In article
<9af29dff-e5a1-4b13-9359-459ef1c90...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Lars Rune Nøstdal <larsnost...@xxxxxxxxx> wrote:
On Jun 23, 3:37 am, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
In article <20090704075344....@xxxxxxxxx>,
Kaz Kylheku <kkylh...@xxxxxxxxx> wrote:
On 2009-06-22, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
In article
<2e409792-6696-45b5-9474-636a45da8...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Scott Burson <FSet....@xxxxxxxxx> wrote:
On Jun 21, 6:12 pm, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
Actually, DEFVAR comes closest to doing what I want. But I also
want to
insure that the value doesn't change or get bound.
Well, there's always DEFINE-SYMBOL-MACRO...
Doesn't work, because it doesn't insure the value won't change:
[ron@mickey:~/Desktop]$ cat test.lisp
(eval-when (:compile-toplevel :load-toplevel :execute)
(define-symbol-macro c7 '#.(gensym))
(defun c7 () c7)
Right; you get a different instance of the c7 macro when compiling
and
loading.
It's evaluated again, just like the initializing value of
defconstant.
How about this:
;; macro only at compile time
(eval-when (:compile-toplevel)
(define-symbol-macro c7 '#.(gensym)))
;; function only available in compiled form
(eval-when (:load-toplevel)
(defun c7 () c7))
Now the problem goes away: there is /no/ C7 symbol macro when you
load
the object file. And if you load the source file, there is no c7
function.
Just like in C, there are no more #define constants when you're
loading
.o
files. And you can't run source without compiling it. (That's not
real
programming; you're supposed to edit, compile, then run, right?)
So, everything is cool.
That won't work for me. My actual use case is that I want to define a
guardian value to use as an indication of an exceptional situation.
Specifically, I want to use it in code that implements something like
Python iterators to indicate end-of-iteration. I also want users to be
able to define their own iterators. So the actual code looks something
like this:
(defconstant +iterend+ (gensym-or-something-similar))
(defmacro iterloop (iterator)
... (if (eq (funcall iterator) +iterend+) (return)) ...)
(defmethod iterator ((thing class)) ... (when ... (return +iterend+)))
or something like that. (If you want to see the actual code it's
inhttp://www.flownet.com/ron/lisp/rg-utils.lisp). But the point is
that I
need +iterend+ to maintain a single value in any given Lisp session.
rg
Isn't this what symbols are for? Symbols..
..can't be bound: *check*
..can't be set: *check*
..or..
(let (('answer 42))
"No way.")
(setf 'answer 42) ;; No way.
If you can't use NIL since the container might store NIL and you can't
or don't want to use two values; VALUE & FOUND-P or so, then an
unexported symbol works great, no?
Normally yes. However, the application here is special: this value is
being used to indicate an exceptional situation (the motivating example
is the end of an iteration) and so it's important that this value be
available *only* through the facility that generates the exceptional
situation and not any other way. So yes, you can use a symbol, but it
can't be an interned symbol or you might accidentally generate it
through a call to READ or INTERN. So it has to be an uninterned symbol.
But then to use it you have to bind it to something precisely because
you can't generate it any other way. And then you want to make sure
that that binding never changes.
Of course, you can still accidentally generate it with a call to
INTERN and another to SYMBOL-VALUE. Less likely, of course, but I'm
not so sure that something like my-package::|| private do not use this
symbol name -- magical iterator stop value -- seriously, DON'T USE
THIS AS A VARIABLE OR VALUE !!!1!|| would be qualitatively worse.
A good point. I think Kaz's suggestion of using multiple values is
probably the Right Answer.
rg
.
- References:
- 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: 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: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Lars Rune Nøstdal
- Re: Is DEFCONSTANT broken?
- From: Ron Garret
- Re: Is DEFCONSTANT broken?
- From: Thomas F. Bur***
- Is DEFCONSTANT broken?
- Prev by Date: Re: Is DEFCONSTANT broken?
- Next by Date: Re: Is DEFCONSTANT broken?
- Previous by thread: Re: Is DEFCONSTANT broken?
- Next by thread: Re: Is DEFCONSTANT broken?
- Index(es):