Re: [Sbcl-help] Cannot defvar a symbol?

> You're relying heavily on global variables here which is not a good
> thing to do.
>
> Try using LET or a hash table.
>
Yes, that's cleaner, but...
Some time ago I had an application that needed a lot of configuration
parameters shared by many functions. Speed was an important issue for
this app, so I did some quick benchmarks. Turned out that using global
variables was the fastest solution.
All the solutions which involved passing around some kind of
"environment" (an object containing all those configuration parameters)
were slower:
A structure had more or less the same speed of globals, but you cannot
redefine it (e.g. for adding a parameter).
Classes were about twice slower.
Hash tables were about four times slower.
So I ended with a lot of globals inside a package. Not elegant, but
faster (it seems).
gg

Thread view

I need help in understanding the seeming inconsistency in the following
sequence of commands:
CL-USER>(type-of (intern "ABC"))
SYMBOL
CL-USER>(defvar (intern "ABC"))
The value (INTERN "ABC") is not of type SYMBOL
[Condition of type TYPE-ERROR]
Or, is there a better way to do what I'm trying: convert a string to a
defvar'd variable?
SBCL 1.0.18.debian
Thanks,
- Arindam
--
http://www.fastmail.fm - mmm... Fastmail...

> I need help in understanding the seeming inconsistency in the following
> sequence of commands:
>
> CL-USER>(type-of (intern "ABC"))
> SYMBOL
> CL-USER>(defvar (intern "ABC"))
>
> The value (INTERN "ABC") is not of type SYMBOL
> [Condition of type TYPE-ERROR]
>
> Or, is there a better way to do what I'm trying: convert a string to a
> defvar'd variable?
>
(defvar ...) is a macro, which expects the first parameter to be a symbol.
A possible workaround is to do something like
(defvar #.(intern "ABC"))
Alternatively, you could try macroexpanding a call to defvar, and build a
solution based on what defvar does. It looks like it should be trivial to
come up with something that works in SBCL, but portability may be
difficult :-)

Thanks to everyone who responded.
I should have realized that defvar doesn't evaluate it's argument. But
I'm glad I asked anyway, learned something. I didn't know about the #.
reader macro, or progv.
I was trying to do something like the following (why I was doing it is
too complex to explain :-) :
Create a function/macro which takes a symbol and an expression, creates
a variable by prefixing the symbol with NFA and assigns the value of the
expression to it. So for example:
(setnfa 'test 10)
should create a variable NFA-TEST and assign 10 as its value.
Based on the replies I got, I'm now doing this:
(defun setnfa (sym val)
(setf (symbol-value (intern (concatenate 'string "NFA-" (symbol-name
sym))))
val))
Not pretty, but it seems to work. Is this a reasonable/reliable way to
accomplish it?
Thanks again,
Arindam
--
http://www.fastmail.fm - Email service worth paying for. Try it for free

On Thu, Jun 18, 2009 at 04:10:32AM -0700, Arindam Roy wrote:
> I need help in understanding the seeming inconsistency in the following
> sequence of commands:
>
> CL-USER>(type-of (intern "ABC"))
> SYMBOL
> CL-USER>(defvar (intern "ABC"))
>
> The value (INTERN "ABC") is not of type SYMBOL
> [Condition of type TYPE-ERROR]
DEFVAR is a macro. It does not evaluate its arguments,
so you're trying to define a variable named (INTERN "ABC")
which is not a valid value for a variable name.
TYPE-OF in contrast is a function so it does evaluate its
arguments which explains the apparent inconsistency.
> Or, is there a better way to do what I'm trying: convert a string to a
> defvar'd variable?
Try PROGV. But you probably don't want to do anything like that;
what are you trying to achieve?
Leslie

"Arindam Roy" <arind_roy@...> writes:
> I need help in understanding the seeming inconsistency in the following
> sequence of commands:
>
> CL-USER>(type-of (intern "ABC"))
> SYMBOL
> CL-USER>(defvar (intern "ABC"))
>
> The value (INTERN "ABC") is not of type SYMBOL
> [Condition of type TYPE-ERROR]
DEFVAR does not evaluate its first argument. So it sees the literal list
(INTERN "ABC"), not the result of evaluating that form.
> Or, is there a better way to do what I'm trying: convert a string to a
> defvar'd variable?
Could you elaborate on your intended use case? It's likely that there's
a better way than what you're trying to do. :-)
-T.

"Arindam Roy" <arind_roy@...> writes:
> I need help in understanding the seeming inconsistency in the following
> sequence of commands:
>
> CL-USER>(type-of (intern "ABC"))
> SYMBOL
> CL-USER>(defvar (intern "ABC"))
>
> The value (INTERN "ABC") is not of type SYMBOL
> [Condition of type TYPE-ERROR]
>
defvar is a macro and it doesn't evaluate the first argument.
One way is (proclaim `(special ,(intern "ABC" :package)))
And if you want to set its value: (setf (symbol-value symbol) value)
--
With best regards, Stas.

> You're relying heavily on global variables here which is not a good
> thing to do.
>
> Try using LET or a hash table.
>
Yes, that's cleaner, but...
Some time ago I had an application that needed a lot of configuration
parameters shared by many functions. Speed was an important issue for
this app, so I did some quick benchmarks. Turned out that using global
variables was the fastest solution.
All the solutions which involved passing around some kind of
"environment" (an object containing all those configuration parameters)
were slower:
A structure had more or less the same speed of globals, but you cannot
redefine it (e.g. for adding a parameter).
Classes were about twice slower.
Hash tables were about four times slower.
So I ended with a lot of globals inside a package. Not elegant, but
faster (it seems).
gg

Giovanni Gigante wrote:
> Yes, that's cleaner, but...
> Some time ago I had an application that needed a lot of configuration
> parameters shared by many functions. Speed was an important issue for
> this app, so I did some quick benchmarks. Turned out that using global
> variables was the fastest solution.
But surely that's an optimization that should be reserved for
special cases, and then only in a late stage of development.
Leslie
--
http://www.linkedin.com/in/polzer