Wade Humeniuk <····································@telus.net> writes:
> Jeff M. wrote:
> > Okay, this is a little strange, and there is a lot of code behind this,
> > so I don't really want to post a lot (although I will if needed). I'm
> > using LispWorks with PARSERGEN in a simple package MY-PARSER, which
> > exports PARSE-FILE. From the listener:
> > MY-PARSER 1> (parse-file "some_file.txt")
> > => "Successfully parsed!"
> > But, from CL-USER, I get different results:
> > CL-USER 1> (my-parser:parse-file "some_file.txt")
> > => NIL
> > I was wondering what could possibly be causing this? Is there
> > something
>
> It can be that when you READ from the file in CL-USER the var *package*
> is bound differently. Try wrapping all calls to file IO with
>
> (let ((*package* (load-time-value (find-package :my-parser))))
> <code>)
>
> The reason for this is that symbols read in from would be
> interned in CL-USER and not MY-PARSER. This can create
> problems.
>
This is very likely the problem. I had the same issue with a small
parser I wrote. DEFMACRO is used to define a parser function, and the
function contains various symbols interned in the package where the
macro expansion occurs.
For actual parsing, READ is used to create a token stream, and so
symbols are created in the current package. So if the parser function
is called at a time when *package* is different from the value it had
when the DEFMACRO form is expanded, it breaks. In other words, the
lexical tokenizer part is returning stuff like: ((package1::ident
"name") package1::%openbrace% ...blah blah blah..) but the parser
function is looking for package2::ident and package2::%openbrace%.
I had to make sure to set *package* to the correct value when calling
READ at the time of parsing,