read-from-string and packages
in [Lisp]
|
Prev: Shape Symbology as a Basis for Lisp or Other AI Software Development
Next: Make Money From Home - How to Deal With Distractions
From: Joubert Nel on 24 Dec 2009 16:53 Hi, I'm using XMLisp (http://code.google.com/p/xmlisp/source/browse/trunk/ XMLisp/sources/XMLisp/XMLisp.lisp) to parse strings that contain XML into CLOS objects. I define a class and an element to class name mapping in a package. This package also contains a function that reads XML from a string, and it is then the job of XMLisp's reader macro to lookup the corresponding class and instantiate an object given the XML. However, I notice that READ-FROM-STRING does symbol lookup in the package from whence the enclosing function is called, and not within the package in which the function is defined. Code to illustrate: http://pastebin.com/fd5b2a62 AUTHENTICATE fails if you call from outside this package, because READ- FROM-STRING apparently does symbol lookup from the calling package. AUTHENTICATE-WITH-PACKAGE-GYMNASTICS works. I figured out the solution by looking at ACL's read-from-string-safely, which has an optional package param: http://www.franz.com/support/documentation/current/doc/operators/cg/r/read-from-string-safely.htm The hyperspec doesn't seem to indicate this unexpected behavior. Is this the expected behavior for READ-FROM-STRING?
From: Barry Margolin on 24 Dec 2009 17:08 In article <b28517e5-41b6-4c6b-bdea-bea9c20970e5(a)p8g2000yqb.googlegroups.com>, Joubert Nel <joubert.nel(a)gmail.com> wrote: > Hi, > > I'm using XMLisp (http://code.google.com/p/xmlisp/source/browse/trunk/ > XMLisp/sources/XMLisp/XMLisp.lisp) to parse strings that contain XML > into CLOS objects. > > I define a class and an element to class name mapping in a package. > This package also contains a function that reads XML from a string, > and it is then the job of XMLisp's reader macro to lookup the > corresponding class and instantiate an object given the XML. > > However, I notice that READ-FROM-STRING does symbol lookup in the > package from whence the enclosing function is called, and not within > the package in which the function is defined. Functions aren't defined in packages. Symbols are read in packages. Associating a symbol with a function is a separate, unrelated action. > Code to illustrate: http://pastebin.com/fd5b2a62 > AUTHENTICATE fails if you call from outside this package, because READ- > FROM-STRING apparently does symbol lookup from the calling package. > > AUTHENTICATE-WITH-PACKAGE-GYMNASTICS works. I figured out the solution > by looking at ACL's read-from-string-safely, which has an optional > package param: > http://www.franz.com/support/documentation/current/doc/operators/cg/r/read-fro > m-string-safely.htm Why not just bind *PACKAGE* around your call to READ-FROM-STRING? > > The hyperspec doesn't seem to indicate this unexpected behavior. > > Is this the expected behavior for READ-FROM-STRING? Yes. The default package is the value of the variable *PACKAGE*. See http://www.lispworks.com/documentation/HyperSpec/Body/11_aa.htm. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Joubert Nel on 25 Dec 2009 09:09 On Dec 24, 5:08 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote: > In article > <b28517e5-41b6-4c6b-bdea-bea9c2097...(a)p8g2000yqb.googlegroups.com>, > JoubertNel <joubert....(a)gmail.com> wrote: > > > Hi, > > > > However, I notice that READ-FROM-STRING does symbol lookup in the > > package from whence the enclosing function is called, and not within > > the package in which the function is defined. > > Functions aren't defined in packages. Symbols are read in packages. > Associating a symbol with a function is a separate, unrelated action. You're right. But when functions execute, don't symbols they encounter get read in the same package as the home package of the function's name symbol? > > > Code to illustrate:http://pastebin.com/fd5b2a62 > > AUTHENTICATE fails if you call from outside this package, because READ- > > FROM-STRING apparently does symbol lookup from the calling package. > > > AUTHENTICATE-WITH-PACKAGE-GYMNASTICS works. I figured out the solution > > by looking at ACL's read-from-string-safely, which has an optional > > package param: > >http://www.franz.com/support/documentation/current/doc/operators/cg/r... > > m-string-safely.htm > > Why not just bind *PACKAGE* around your call to READ-FROM-STRING? Yeah, that's what I figured out (as shown in the example in the pastebin (see AUTHENTICATE-WITH-PACKAGE-GYMNASTICS). Joubert Workstax http://www.workstax.com The Corporate Grapevine Separate the important from the irrelevant
From: joswig on 25 Dec 2009 09:33 On 25 Dez., 15:09, Joubert Nel <joubert....(a)gmail.com> wrote: > On Dec 24, 5:08 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote: > > > In article > > <b28517e5-41b6-4c6b-bdea-bea9c2097...(a)p8g2000yqb.googlegroups.com>, > > JoubertNel <joubert....(a)gmail.com> wrote: > > > > Hi, > > > > However, I notice that READ-FROM-STRING does symbol lookup in the > > > package from whence the enclosing function is called, and not within > > > the package in which the function is defined. > > > Functions aren't defined in packages. Symbols are read in packages. > > Associating a symbol with a function is a separate, unrelated action. > > You're right. > > But when functions execute, don't symbols they encounter get read in > the same package as the home package of the function's name symbol? Symbols are already in a package, usually. If anything is read in your code and the read operation reads a normal symbol, the symbol is by default interned into the package that is the value of the variable cl:*package*. If you change the variable, for example by binding it in a LET, then the symbols will be interned in the package you have specified. (defun foo (&optional (package-name "MY-PACKAGE")) (let ((*package* (find-package package-name))) (read))) Try it with a package of your choice... > > > > > > Code to illustrate:http://pastebin.com/fd5b2a62 > > > AUTHENTICATE fails if you call from outside this package, because READ- > > > FROM-STRING apparently does symbol lookup from the calling package. > > > > AUTHENTICATE-WITH-PACKAGE-GYMNASTICS works. I figured out the solution > > > by looking at ACL's read-from-string-safely, which has an optional > > > package param: > > >http://www.franz.com/support/documentation/current/doc/operators/cg/r.... > > > m-string-safely.htm > > > Why not just bind *PACKAGE* around your call to READ-FROM-STRING? > > Yeah, that's what I figured out (as shown in the example in the > pastebin (see AUTHENTICATE-WITH-PACKAGE-GYMNASTICS). > > Joubert > > Workstaxhttp://www.workstax.com > The Corporate Grapevine > Separate the important from the irrelevant
From: Pascal J. Bourguignon on 25 Dec 2009 12:57
Joubert Nel <joubert.nel(a)gmail.com> writes: > But when functions execute, don't symbols they encounter get read in > the same package as the home package of the function's name symbol? There's no CL:ENCOUNTER function. What do you mean by a "function encounters a symbol"? The symbol used in the definition of the function are read or produced long before the function is compiled or executed. When the function is executed, no reading occurs, unless of course the function calls CL:READ (directly or indirectly, including CL:READ-FROM-STRING). Then the run-time value of CL:*PACKAGE* is used to intern the symbols read, as specified by clhs intern, which is called by CL:READ (check also clhs read). This run-time value of CL:*PACKAGE* is unrelated to the read-time value of CL:*PACKAGE* when the function was read, or the package passed to INTERN by a macro called in that function to produce some of the symbols used by that function. -- __Pascal Bourguignon__ http://www.informatimago.com/ |