[Openmcl-devel] eval-in-package

[Daniel Dickison]

Let's say you type "here" when it waits on READ and you're currently  
in CL-USER...

>>> (defun eval-in-package-1 (pkg) ; wrong
>>>  (let ((req (read))
At this point REQ holds CL-USER::HERE.
>>> 	(*package* (find-package pkg)))
>>>    (eval (read-from-string (format nil "~S" req)))))
The FORMAT returns "CL-USER::HERE", which gets read as a symbol in CL- 
USER.


>>> (defun eval-in-package-2 (pkg)  ; correct
>>>  (let ((req (format nil "~S" (read)))
READ returns CL-USER::HERE, but FORMAT returns "HERE" (without the  
package prefix) since the current package is the same package as the  
symbol.
>>> 	(*package* (find-package pkg)))
>>>    (eval (read-from-string req))))
Reading "HERE" returns a symbol in the current package, which is now  
the package that you have specified.

Maybe this will help...

? (format t "~S" (read-from-string "FOO"))
FOO
NIL
? (format t "~S" (read-from-string "CCL::FOO"))
CCL::FOO
NIL

(Hope I didn't offend if some of this was already obvious to you -- I  
could be mistaken exactly what you were confused with).

Daniel

On Jun 1, 2009, at 4:53 PM, Taoufik Dachraoui wrote:

> I would like to have more details, I do not understand why there is a
> difference.
>
> If you look at (eval (read-from-string str)) form, in both functions
> read-from-string
> is supposed to read from a string and I think that at that point in
> both function the
> string is the same "(setq a 1)"
>
> so why ther eis a difference? thank you giving me more details.
>
> I am planning to use this in production for lisp server allowing many
> clients to connect to a lisp server and executes lisp commands.
>
> I will try to modify the reader so that no one can access internal
> symbols
> from any other package. (I am not sure about how yet)
>
> -Taoufik
>
> On Jun 1, 2009, at 10:44 PM, Dan Weinreb wrote:
>
>>
>> The difference is that the first one is printing
>> in the context of "pkg" but the second is
>> printing in the context of the current package.
>>
>> This is probably all educational for you, but
>> you should know that no real Lisp program
>> would do anything like this.
>>
>>
>>
>> Taoufik Dachraoui wrote:
>>> Hi
>>>
>>> I wrote 2 functions slightly different to evaluate a lisp body in
>>> a  given package
>>> one is wrong and the other is correct at least for the test I run).
>>>
>>> The problem I could not understand why this is so, both functions
>>> looks correct
>>> as far as I can tell;
>>>
>>> (make-package 'here)
>>> (make-package 'there)
>>>
>>> (in-package 'here)
>>>
>>> (defun eval-in-package-1 (pkg) ; wrong
>>>  (let ((req (read))
>>> 	(*package* (find-package pkg)))
>>>    (eval (read-from-string (format nil "~S" req)))))
>>>
>>> (defun eval-in-package-2 (pkg)  ; correct
>>>  (let ((req (format nil "~S" (read)))
>>> 	(*package* (find-package pkg)))
>>>    (eval (read-from-string req))))
>>>
>>>
>>> ? (eval-in-package-1 'there)
>>> (setq a 1)
>>>
>>> 1
>>> ?
>>> ? (eval-in-package-2 'there)
>>> (setq b 1)
>>>
>>> 1
>>> ?
>>> ? here::a								;;;;;;;;;; wrong; a must be defined in package  
>>> there
>>> 1
>>> ? here::b								;;;;; this correct, b is defined in package there
>>>> Error: Unbound variable: B
>>>> While executing: CCL::TOPLEVEL-EVAL, in process listener(1).
>>>> Type :GO to continue, :POP to abort, :R for a list of available
>>> restarts.
>>>> If continued: Retry getting the value of B.
>>>> Type :? for other options.
>>> 1 > :pop
>>>
>>> ? there::a									
>>>> Error: Unbound variable: THERE::A
>>>> While executing: CCL::TOPLEVEL-EVAL, in process listener(1).
>>>> Type :GO to continue, :POP to abort, :R for a list of available
>>> restarts.
>>>> If continued: Retry getting the value of THERE::A.
>>>> Type :? for other options.
>>> 1 > :pop
>>>
>>> ? there::b				;; correct
>>> 1
>>> ?
>>>
>>>
>>>
>>> Kind regards
>>>
>>> -Taoufik
>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel