From: Joe Marshall
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <zncycxtq.fsf@ccs.neu.edu>
Christophe Turle <······@nospam.fr> writes:
> Once I read there should be no "eval" in code. But here I don't see
> how to do this ...
In general you should not need to use EVAL that often, and there are
drawbacks to unnecessary use. But that doesn't mean that you should
*never* use it, just that you should be aware of why you use it.
Now as to the code:
> (defmacro def-corba-component ( &key abrev name )
> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
> `(defvar ,var-name (make-instance 'corba:component :name ,name :abrev ,abrev)) ))
>
This macro is the start of your problems.
The variable name is being auto-generated from the keyword argument.
You really ought to let the macro user specify the variable name
directly.
> (defmacro add-corba-object ( component &key name )
> (let ((corba-object-name (intern (format nil ···@(*~a-~a*~)" (corba:abrev (eval component)) name))))
> `(defvar ,corba-object-name (make-instance 'corba:object :name ,name :component ,component)) ))
This macro has numerous problems. You cannot even *expand* the macro
without having previously defined the component. This means that you
have a dependency at compile time based on a run time value.
A second problem with ADD-CORBA-OBJECT is that it does not appear to
be a defining form --- it creates a DEFVAR, but there is no indication
in the name that it is doing so.
Before going further, I'd like to ask why DEF-CORBA-COMPONENT needs to
define a variable. Is it only so that you can refer to the component
by name later on? If that is the case, you are using the package
system as a cheesy hash-table, and you would be better served by using
a real hash-table. The same question applies to ADD-CORBA-OBJECT.
I'd probably do this:
1) Toss the macros altogether. The example now becomes this:
(defvar *mon* (make-instance 'corba:component
:name "monitor"
:abbrev "MON"))
(defvar *mon-grapheh* (make-instance 'corba:object
:name "GraphEH"
:component *mon*))
Yes, this is more verbose, but it is much clearer what is going
on, and has the added benefit that you have decoupled the
variable names from the object names.
or
2) Use a hash table. Something like this (warning, untested code):
(defvar *corba-component-table* (make-hash-table))
(defun find-corba-component (abbrev)
(or (gethash abbrev *corba-component-table*)
(error "No component named ~s" abbrev)))
(defmethod :after shared-initialize ((instance corba:component) &rest initargs)
(setf (gethash (corba:abbrev instance) *corba-component-table*) instance))
(make-instance 'corba:component :name "monitor" :abbrev "MON")
(make-instance 'corba:object :name "GraphEH"
:component (find-corba-component "MON"))
From: Christophe Turle
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <btk476$be6$1@news.irisa.fr>
> Now as to the code:
>
>
>>(defmacro def-corba-component ( &key abrev name )
>> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
>> `(defvar ,var-name (make-instance 'corba:component :name ,name :abrev ,abrev)) ))
>>
>
>
> This macro is the start of your problems.
>
> The variable name is being auto-generated from the keyword argument.
> You really ought to let the macro user specify the variable name
> directly.
I don't agree there. if it can be generated automaticaly let's do it. Less work for me ( macro-user ) with less errors.
>>(defmacro add-corba-object ( component &key name )
>> (let ((corba-object-name (intern (format nil ···@(*~a-~a*~)" (corba:abrev (eval component)) name))))
>> `(defvar ,corba-object-name (make-instance 'corba:object :name ,name :component ,component)) ))
>
>
> This macro has numerous problems. You cannot even *expand* the macro
> without having previously defined the component. This means that you
> have a dependency at compile time based on a run time value.
yes, you're right.
> A second problem with ADD-CORBA-OBJECT is that it does not appear to
> be a defining form --- it creates a DEFVAR, but there is no indication
> in the name that it is doing so.
ok. DEF-CORBA-OBJECT should be better with documentation : "define a new CORBA object for the component"
> Before going further, I'd like to ask why DEF-CORBA-COMPONENT needs to
> define a variable. Is it only so that you can refer to the component
> by name later on? If that is the case, you are using the package
> system as a cheesy hash-table, and you would be better served by using
> a real hash-table. The same question applies to ADD-CORBA-OBJECT.
>
> I'd probably do this:
>
> 1) Toss the macros altogether. The example now becomes this:
>
> (defvar *mon* (make-instance 'corba:component
> :name "monitor"
> :abbrev "MON"))
>
> (defvar *mon-grapheh* (make-instance 'corba:object
> :name "GraphEH"
> :component *mon*))
>
> Yes, this is more verbose, but it is much clearer what is going
> on, and has the added benefit that you have decoupled the
> variable names from the object names.
The problem with this solution is that you don't express knowledge your represent it. My internal representation should be separated from the data. It is why i hide the "make-instance" calls. I can also add some other infered informations.
>
> or
>
> 2) Use a hash table. Something like this (warning, untested code):
>
> (defvar *corba-component-table* (make-hash-table))
>
> (defun find-corba-component (abbrev)
> (or (gethash abbrev *corba-component-table*)
> (error "No component named ~s" abbrev)))
>
> (defmethod :after shared-initialize ((instance corba:component) &rest initargs)
> (setf (gethash (corba:abbrev instance) *corba-component-table*) instance))
>
> (make-instance 'corba:component :name "monitor" :abbrev "MON")
>
> (make-instance 'corba:object :name "GraphEH"
> :component (find-corba-component "MON"))
>
>
ok for the hash tables. listening what you said but keeping the implementation hidden :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defvar *corba-component-table* (make-hash-table :test #'equalp))
(defmethod set-user-name ((corba-component corba:component) (name string))
(setf (gethash name *corba-component-table*) corba-component) ))
(defun find-corba-component ( name )
(or (gethash name *corba-component-table*)
(error "No component named ~s" name)))
(defun def-corba-component ( &key abbrev name )
(let ( (new-corba-component (make-instance 'corba:component :name name :abbrev abbrev)) )
(set-user-name new-corba-component abbrev) ))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defvar *corba-object-table* (make-hash-table :test #'equalp))
(defmethod set-user-name ((corba-object corba:object) (name string))
(setf (gethash name *corba-object-table*) corba-object) ))
(defun find-corba-object ( name )
(or (gethash name *corba-object-table*)
(error "No corba object named ~s" name) ))
(defun def-corba-object ( &key ((:component component-user-name)) name)
"define a new CORBA object for the component"
(let* ((component (find-corba-component component-user-name) )
(new-corba-object (make-instance 'corba:object :name name :component component ))
(user-name (format nil "~a-~a" (corba:abbrev component) name)) )
(set-user-name new-corba-object user-name) ))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(def-corba-component :abbrev "MON" :name "monitor")
(def-corba-object :component "MON" :name "GraphEH")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
The first 3 forms are very similar. Sure a macro should play a role this time. And the problem of defining a defvar with runtime comes once again ...
ctu.
Christophe Turle wrote:
>> Now as to the code:
>>
>>
>>> (defmacro def-corba-component ( &key abrev name )
>>> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
>>> `(defvar ,var-name (make-instance 'corba:component :name ,name
>>> :abrev ,abrev)) ))
>>>
>>
>>
>> This macro is the start of your problems.
>>
>> The variable name is being auto-generated from the keyword argument.
>> You really ought to let the macro user specify the variable name
>> directly.
>
>
> I don't agree there. if it can be generated automaticaly let's do it.
> Less work for me ( macro-user ) with less errors.
I think the larger question is your creative use of defvars. I think
your eval problem is a Message From God that you are using them in ways
they may not be able to handle gracefully. Another bad sign is the way
*mon* appears here out of the blue:
(def-corba-component :abrev "MON" :name "monitor")
(add-corba-object *MON* :name "GraphEH")
I would not call that "hiding implemenation", since you are relying in
the second form on the implementation having created the defvar of that
specific name.
I agree with Joe that users should code defvars (not macros), but that
is less important than whether you should be using defvars this way at
all. I mean, I appreciate the creativeness, but again, I think they may
not be cut out for this.
defvar does not evaluate the name of the variable being def'ed. You are
trying to get it to, because you are using what seem to be run-time
allocated instances at compile-time, during macro expansion. This is
just a mismatch, and that is why you are forced into an ugly use of EVAL.
My 2.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Christophe Turle
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <btm19k$flj$1@news.irisa.fr>
Kenny Tilton wrote:
>
>
> Christophe Turle wrote:
>
>>> Now as to the code:
>>>
>>>
>>>> (defmacro def-corba-component ( &key abrev name )
>>>> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
>>>> `(defvar ,var-name (make-instance 'corba:component :name ,name
>>>> :abrev ,abrev)) ))
>>>>
>>>
>>>
>>> This macro is the start of your problems.
>>>
>>> The variable name is being auto-generated from the keyword argument.
>>> You really ought to let the macro user specify the variable name
>>> directly.
>>
>>
>>
>> I don't agree there. if it can be generated automaticaly let's do it.
>> Less work for me ( macro-user ) with less errors.
>
>
> I think the larger question is your creative use of defvars. I think
> your eval problem is a Message From God that you are using them in ways
> they may not be able to handle gracefully.
yes.
> Another bad sign is the way *mon* appears here out of the blue:
yes.
>
> (def-corba-component :abrev "MON" :name "monitor")
> (add-corba-object *MON* :name "GraphEH")
>
> I would not call that "hiding implemenation",
i hide the "make-instance".
> since you are relying in
> the second form on the implementation having created the defvar of that
> specific name.
If the "def-corba-component" specification indicate the variable creation it is not implementation details. The spec was in my head, i should have written the corresponding documentation string.
>
> I agree with Joe that users should code defvars (not macros),
if defvar is a good programming style why deny this to computers ?
> but that
> is less important than whether you should be using defvars this way at
> all. I mean, I appreciate the creativeness, but again, I think they may
> not be cut out for this.
>
> defvar does not evaluate the name of the variable being def'ed. You are
> trying to get it to, because you are using what seem to be run-time
> allocated instances at compile-time, during macro expansion. This is
> just a mismatch, and that is why you are forced into an ugly use of EVAL.
yes.
> My 2.
>
> kt
>
>
"Christophe Turle" <······@nospam.fr> wrote in message
·················@news.irisa.fr...
Hi Christophe,
Just picking on this statement ignoring the specific context:
> > I agree with Joe that users should code defvars (not macros),
>
> if defvar is a good programming style why deny this to computers ?
Because computers have different needs than human programmers. A defvar is
really for the human need for naming things to keep track of them. It seems
to me largely a convenience for readability and maintainability. (Not that
computer generated code should not necessarily be readable, in fact I think
it is often an excellent idea to make it so, but that is a slightly
different issue.)
Now, I think there are plenty of times when generated code wants symbols,
but that is what gensym is for. If your generated code is creating
specifically named symbols all over the place what you will end up with is a
whole bag of inter-dependencies that may not be easy to ferret out when
something breaks.
You can get the best of both worlds by giving a string to gensym anyway.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
From: Joe Marshall
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <65fmdl4l.fsf@comcast.net>
Christophe Turle <······@nospam.fr> writes:
> ok for the hash tables. listening what you said but keeping the implementation hidden :
>
[code snipped]
Yes, this is how I would have done it.
I'd like to present my rationale for disagreeing with this statement:
> I don't agree there. if it can be generated automaticaly let's do
> it. Less work for me ( macro-user ) with less errors.
I was objecting *specifically* to generating the variable names from
something else. Whenever you generate a symbol, you have to deal with
the package system. You were generating the symbol name like this:
(intern (format nil ···@(*~a*~)" abrev))
This will cause a symbol to be interned in whatever package is bound
to *PACKAGE* when the macro is expanded. This will *usually* be the
package of the file being compiled, but if for some reason someone
were to EVAL a DEF-CORBA-COMPONENT form in some other package, they
may be in for a surprise. The is also a possibility of name collision:
(def-corba-component :abrev "print" :name "Printing Device")
(add-corba-object *PRINT* :name "tower")
(add-corba-object *PRINT* :name "base")
It isn't immediately obvious that the second object is going to
collide with CL:*PRINT-BASE* Additionally, it isn't possible for the
user to make an exception just for this symbol. If instead you
require the user to give the symbol name explicitly, he can do this:
(defvar *printing-device-base* (make-corba-object ....))
and avoid the name collision without having to shadow *PRINT-BASE*.
------
As to having a lot of MAKE-INSTANCE calls around. You can always wrap
those if you don't like them, but it seems to me that by doing so all
you have done is created an alias equalivalent to make-instance, but
with far less functionality. In addition, you have added a new name
to the protocol of object creation. If your wrapper around
make-instance does anything interesting, then someone calling
`MAKE-INSTANCE' directly would not get the correct behavior. It is
less suprising to the user to customize the instance creation protocol
to handle everything. As an example, if someone were to call
(make-instance 'corba:component ...), he would get a more-or-less
valid component and it would seem to work, but no one else would be
able to use FIND-CORBA-COMPONENT to find the object. If you put the
registration of the object as a method in SHARED-INITIALIZE, the
object would be `findable' no matter how the object was created.
-----
To avoid typing, rather than define a global macro, define a local one!
At top level, do something like this:
(macrolet ((define-corba-component (var)
`(defvar ,var (make-instance 'corba:component :name
(strip-stars (symbol-name var))))))
(def-corba-component *foo* ...))
This allows me to avoid typing the hairy form each time, but if I need
to, I can `override' the macro by simply not using it:
(def-corba-component *foo* ...)
;; Avoid name collision.
(defvar *bar* (make-instance 'corba:component
:name "PRINT-CIRCLE"))
(def-corba-component *baz*)
--
~jrm
From: Christophe Turle
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <btm0jq$enr$1@news.irisa.fr>
Joe Marshall wrote:
> I'd like to present my rationale for disagreeing with this statement:
>
>
>> I don't agree there. if it can be generated automaticaly let's do
>> it. Less work for me ( macro-user ) with less errors.
>
>
> I was objecting *specifically* to generating the variable names from
> something else. Whenever you generate a symbol, you have to deal with
> the package system. You were generating the symbol name like this:
>
> (intern (format nil ···@(*~a*~)" abrev))
>
> This will cause a symbol to be interned in whatever package is bound
> to *PACKAGE* when the macro is expanded. This will *usually* be the
> package of the file being compiled, but if for some reason someone
> were to EVAL a DEF-CORBA-COMPONENT form in some other package, they
> may be in for a surprise.
(intern (format nil ···@(*~a*~)" abrev) *my-package*)
Yes, i'm not checking everything. It's too time consuming. My goal is not to have bugless programs since it is utopical for humans. My goal is to program meta-programs which will build bugless programs.
> The is also a possibility of name collision:
>
> (def-corba-component :abrev "print" :name "Printing Device")
> (add-corba-object *PRINT* :name "tower")
> (add-corba-object *PRINT* :name "base")
>
> It isn't immediately obvious that the second object is going to
> collide with CL:*PRINT-BASE*
yes, it's why using the hash table is better.
> Additionally, it isn't possible for the
> user to make an exception just for this symbol. If instead you
> require the user to give the symbol name explicitly, he can do this:
>
> (defvar *printing-device-base* (make-corba-object ....))
>
> and avoid the name collision without having to shadow *PRINT-BASE*.
yes and no.
yes it avoids the name collision. But no, it's not a good idea because you require the user's intervention.
>
> ------
>
> As to having a lot of MAKE-INSTANCE calls around. You can always wrap
> those if you don't like them, but it seems to me that by doing so all
> you have done is created an alias equalivalent to make-instance, but
> with far less functionality.
it's not an alias it's an interface in user-level :
i have 3 level/layer :
1 - one where i define all the "logic/semantic" ( not yet declaratively ... ) of corba definitions. Ex: class definitions.
2 - one where i define the user-interface. So we can use the level 1 without knowing the implementation (the how). Ex: language definition like def-corba-component using make-instance ( lvl 1 ).
3 - the data. Where the user use the language specified in level 2 (the what). ex: pb specification like (def-corba-component ...) using language ( lvl 2 ).
> In addition, you have added a new name
> to the protocol of object creation. If your wrapper around
> make-instance does anything interesting, then someone calling
> `MAKE-INSTANCE' directly would not get the correct behavior.
Only lvl 2 developpers have the rights to use the make-instance ( lvl 1 ). And the wrapper you are speaking about ( name registration ) is not corba dependent so the behavior will always be correct at lvl 1.
> It is
> less suprising to the user
which user ?
> to customize the instance creation protocol
> to handle everything. As an example, if someone were to call
> (make-instance 'corba:component ...),
so a lvl-2 user. a language specificator with my view.
> he would get a more-or-less
> valid component and it would seem to work,
the lvl-1 would work in fact. and the lvl-2 will work according to this lvl-2 user view point => no name finding.
> but no one else
> would be
> able to use FIND-CORBA-COMPONENT to find the object.
it is the goal. It's perfectly correct and wanted.
FIND-CORBA-COMPONENT belongs to the lvl-2 or more exactly ONE lvl-2.
> If you put the
> registration of the object as a method in SHARED-INITIALIZE, the
> object would be `findable' no matter how the object was created.
The problem is here. "Findable" is not at the same lvl that "Creation". You can create object without them being findable or findable differently. It's not an intrinsec property of corba definitions but one way to you use them.
> -----
> To avoid typing,
It was encapsulation. But in fact function/method should be used for this and macros for avoid typing. It's why i removed the macros since in that case they were not necessary.
> rather than define a global macro, define a local one!
> At top level, do something like this:
>
> (macrolet ((define-corba-component (var)
> `(defvar ,var (make-instance 'corba:component :name
> (strip-stars (symbol-name var))))))
>
> (def-corba-component *foo* ...))
>
> This allows me to avoid typing the hairy form each time, but if I need
> to, I can `override' the macro by simply not using it:
>
> (def-corba-component *foo* ...)
> ;; Avoid name collision.
> (defvar *bar* (make-instance 'corba:component
> :name "PRINT-CIRCLE"))
> (def-corba-component *baz*)
local or global you can always not using it.
The advantage of a global one in a judicious package is that you can have a separeted file containing only problem specification. Just adding the right in/use-package.
ctu.
Christophe Turle wrote:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> (in-package CORBA)
>
> (defclass component ()
> ( ( name :reader name :initarg :name )
> ( abrev :reader abrev :initarg :abrev ) ))
>
> (defclass object ()
> ( ( name :reader name :initarg :name )
> ( component :reader component :initarg :component ) ))
>
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> (in-package "CL-USER")
>
> (defmacro def-corba-component ( &key abrev name )
> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
> `(defvar ,var-name (make-instance 'corba:component :name ,name :abrev
> ,abrev)) ))
>
>
> ;; ***** how to remove the "eval" in the 2nd line *****
>
> (defmacro add-corba-object ( component &key name )
> (let ((corba-object-name (intern (format nil ···@(*~a-~a*~)"
> (corba:abrev (eval component)) name))))
> `(defvar ,corba-object-name (make-instance 'corba:object :name ,name
> :component ,component)) ))
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> ;;; examples
>
> (def-corba-component :abrev "MON" :name "monitor")
> (add-corba-object *MON* :name "GraphEH")
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> Once i read there should be no "eval" in code. But here i don't see how
> to do this ...
Have you tried to remove the EVAL, and just use the COMPONENT reference?
This means, it should be ok to just say (corba:abrev component).
As far as I can see, *MON* refers to an already instantiated object that
doesn't need to be eval'd again.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Christophe Turle
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <btjpe7$ui5$1@news.irisa.fr>
Pascal Costanza wrote:
>
> Christophe Turle wrote:
>
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>>
>> (in-package CORBA)
>>
>> (defclass component ()
>> ( ( name :reader name :initarg :name )
>> ( abrev :reader abrev :initarg :abrev ) ))
>>
>> (defclass object ()
>> ( ( name :reader name :initarg :name )
>> ( component :reader component :initarg :component ) ))
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>>
>> (in-package "CL-USER")
>>
>> (defmacro def-corba-component ( &key abrev name )
>> (let ((var-name (intern (format nil ···@(*~a*~)" abrev))))
>> `(defvar ,var-name (make-instance 'corba:component :name ,name :abrev ,abrev)) ))
>>
>>
>> ;; ***** how to remove the "eval" in the 2nd line *****
>>
>> (defmacro add-corba-object ( component &key name )
>> (let ((corba-object-name (intern (format nil ···@(*~a-~a*~)" (corba:abrev (eval component)) name))))
>> `(defvar ,corba-object-name (make-instance 'corba:object :name ,name :component ,component)) ))
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>> ;;; examples
>>
>> (def-corba-component :abrev "MON" :name "monitor")
>> (add-corba-object *MON* :name "GraphEH")
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>>
>> Once i read there should be no "eval" in code. But here i don't see
>> how to do this ...
>
>
> Have you tried to remove the EVAL, and just use the COMPONENT reference?
>
> This means, it should be ok to just say (corba:abrev component).
>
I tried after i read your post. But it failed since "corba:abrev" method should take a "corba:component" argument. And without
"eval", "*MON*" is the passed arg. Not its value ...
> As far as I can see, *MON* refers to an already instantiated object that
> doesn't need to be eval'd again.
yes, *MON* refers to a "corba:component" object.
ctu.
Christophe Turle <······@nospam.fr> writes:
> ;; ***** how to remove the "eval" in the 2nd line *****
>
> (defmacro add-corba-object ( component &key name )
> (let ((corba-object-name
> (intern (format nil ···@(*~a-~a*~)"
> (corba:abrev (eval component)) name))))
> `(defvar ,corba-object-name
> (make-instance 'corba:object :name ,name :component ,component))))
The question that must be answered is this: Must the corba:abrev
operator be applied to the result of evaluating the form "component"
at the time the macro is expanded? I don't know anything about what
this is supposed to do, but as a general rule macros should only
transform code, and presumably this is not about transforming code.
If you want to "defvar" a variable-name that is the result of
evaluating some form, as you do here, then that's probably a bad
design decision somewhere. A defvar (name) is usually a part of the
invariant aspect of a lisp image, with only rare and somewhat esoteric
exceptions, in which cases eval might indeed be appropriate.
So I think the appropriate answer to your question is: Are you sure
you need to generate a variable name like this?
From my cursory understanding of your code, I'd suggest something like
this instead:
(defvar *corba-namespace* (make-hash-table :test #'eq))
(defmacro add-corba-object (component
&key (name (gensym "corba-object-")))
`(setf (gethash ',name *corba-namespace*)
(make-instance 'corba:object
:name ',name ; don't want to evaluate this
:component ,component))) ; do want to evaluate this (?)
--
Frode Vatvedt Fjeld
From: Wade Humeniuk
Subject: Re: help needed in removing an "eval"
Date:
Message-ID: <cCBLb.288$n44.225@clgrps13>