"Jeff M." <·······@gmail.com> wrote in message news:<························@c13g2000cwb.googlegroups.com>...
> 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
Is your parser using the Lisp reader? If so, did you remember to
exercise control over the current package? Otherwise the reader will
intern symbols into whatever package is current: the dynamic binding
of *package*.
If your code relies, for instance, on some EQ comparisons between
symbols that it has parsed, and symbols interned in its own source
code, it's behavior will change:
;; code procsessed in "MY-PARSER" package, but called from "CL-USER"
(eq (read-from-string "FOO") 'foo) -> NIL
;; code processed in "MY-PARSER" package, and called in that
package:
(eq (read-from-string "FOO") 'foo) -> T
The difference is that the first READ-FROM-STRING will return the
symbol CL-USER::FOO, whereas the second one will return
MY-PARSER::FOO.
Kaz Kylheku wrote:
> The difference is that the first READ-FROM-STRING will return the
> symbol CL-USER::FOO, whereas the second one will return
> MY-PARSER::FOO.
Fantasic. Thanks for this tid-bit. Makes sense and I feel like I
/should/ have seen that, but it is a little obscure. Now just to find
the fix/work-around...
Jeff M.
"Jeff M." <·······@gmail.com> writes:
> Along the same lines, how can this be done for macros that "define"
> symbols. For example, say I have a macro that will define the following
> function:
>
> (defmacro some-lambda (&body body)
> `(lambda ($0 &optional $1 $2 .. $n)
> (declare (ignorable $0 $1 $2 .. $n)) ,@body))
>
> $0 is parsed in as MY-PACKAGE::$0 (since the macro is parsed at
> read-time), making it difficult to actually access that symbol inside
> the lambda if SOME-LAMBDA exists in a different package. And I don't
> want to use gensyms
>
> Is there any way to get around this?
Not to endorse this kind of macro but in a case like this what you
probably want is for $0 .. $n to be interned in *package* so they can
be refered to by code in body without package qualification. So you
can do this:
(defmacro some-lambda (&body body)
(let ((args (loop for i from 0 to 10 collect (intern (format nil "$~d" i) *package*))))
`(lambda (,(first args) &optional ,@(rest args))
(declare (ignorable ,@args))
,@body)))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "Jeff M." <·······@gmail.com> writes:
>
> > Along the same lines, how can this be done for macros that "define"
> > symbols. For example, say I have a macro that will define the
> > following function:
> >
> > (defmacro some-lambda (&body body)
> > `(lambda ($0 &optional $1 $2 .. $n)
> > (declare (ignorable $0 $1 $2 .. $n)) ,@body))
> >
> > $0 is parsed in as MY-PACKAGE::$0 (since the macro is parsed at
> > read-time), making it difficult to actually access that symbol
> > inside the lambda if SOME-LAMBDA exists in a different package. And
> > I don't want to use gensyms
> >
> > Is there any way to get around this?
>
> Not to endorse this kind of macro but in a case like this what you
> probably want is for $0 .. $n to be interned in package so they can
> be refered to by code in body without package qualification. So you
> can do this:
>
> (defmacro some-lambda (&body body)
> (let ((args (loop for i from 0 to 10 collect (intern (format nil
> "$~d" i) package)))) `(lambda (,(first args) &optional ,@(rest
> args)) (declare (ignorable ,@args))
> ,@body)))
>
Thanks, Peter. This probably looks bad on the outside, but the
reasoning for it is solid -- I just didn't want to go too far into it.
However, your sample code and other code from this thread, has me
wondering now as to what is happenning "under-the-hood" in Lisp. For
example, given the following snippet:
(defvar *some-value*)
(defun print-some-value ()
(print *some-value*))
(defun test ()
(let ((*some-value* 'foobar))
(print-some-value)))
When I call TEST, it prints FOOBAR to the screen. This isn't what I
would expect to happen -- I would expect it to print NIL -- since
*SOME-VALUE* is local to TEST, and not the global version. Does Lisp
constantly have a lexical scope at runtime instead of at compile-time?
If so, this can be very powerful (as I've learned with redefining
*PACKAGE* in this thread). Can anyone point me to a reference of how
this works? It would seem expensive (time). How does Lisp pull it off?
Since you are writing the book on Lisp, there are several things that
took me quite a while to grok with Lisp -- that once I did, everything
just became easier. So far, I have yet to see any Lisp book cover many
of these issues -- it would be nice if yours did so.
Some of these issues would be:
+ keywords (so simple no one ever covers them)
+ runtime scope (?)
+ reader macros
+ read-time, macro-expand-time, compile-time, run-time, ...
Some of these issues might be considered advanced, but just the initial
knowledge that they exist would be nice. PG's ANSI Common Lisp covers
reader macros not until Ch. 14 or so. That's fine for an in-depth
analysis, but it would have made a world of difference years ago (in my
case) to learn that ' #' and other "special Lisp tokens" were actual
Lisp functions built into the reader and executed at read-time. The
moment I learned that even " was a read macro, a whole world seemed to
open in front of me.
Just some possible suggestions. Don't take them too seriously, I just
feel that over 3-4 years I tried to learn Lisp, but haven't been
introduced to the "voodoo magic" (which seems to be a bunch of
well-guarded secrets) of "why" until the past year -- and it has made a
world of difference. ;)
Thanks again (to you and everyone) for the help!
Jeff M.
"Jeff" <···@nospam.insightbb.com> writes:
> Peter Seibel wrote:
>
>> "Jeff M." <·······@gmail.com> writes:
>>
>> > Along the same lines, how can this be done for macros that "define"
>> > symbols. For example, say I have a macro that will define the
>> > following function:
>> >
>> > (defmacro some-lambda (&body body)
>> > `(lambda ($0 &optional $1 $2 .. $n)
>> > (declare (ignorable $0 $1 $2 .. $n)) ,@body))
>> >
>> > $0 is parsed in as MY-PACKAGE::$0 (since the macro is parsed at
>> > read-time), making it difficult to actually access that symbol
>> > inside the lambda if SOME-LAMBDA exists in a different package. And
>> > I don't want to use gensyms
>> >
>> > Is there any way to get around this?
>>
>> Not to endorse this kind of macro but in a case like this what you
>> probably want is for $0 .. $n to be interned in package so they can
>> be refered to by code in body without package qualification. So you
>> can do this:
>>
>> (defmacro some-lambda (&body body)
>> (let ((args (loop for i from 0 to 10 collect (intern (format nil
>> "$~d" i) package)))) `(lambda (,(first args) &optional ,@(rest
>> args)) (declare (ignorable ,@args))
>> ,@body)))
>>
>
> Thanks, Peter. This probably looks bad on the outside, but the
> reasoning for it is solid -- I just didn't want to go too far into it.
>
> However, your sample code and other code from this thread, has me
> wondering now as to what is happenning "under-the-hood" in Lisp. For
> example, given the following snippet:
>
> (defvar *some-value*)
>
> (defun print-some-value ()
> (print *some-value*))
>
> (defun test ()
> (let ((*some-value* 'foobar))
> (print-some-value)))
>
> When I call TEST, it prints FOOBAR to the screen. This isn't what I
> would expect to happen -- I would expect it to print NIL -- since
> *SOME-VALUE* is local to TEST, and not the global version.
Except that DEFVAR makes the variable name globally special.
> Since you are writing the book on Lisp, there are several things
> that took me quite a while to grok with Lisp -- that once I did,
> everything just became easier. So far, I have yet to see any Lisp
> book cover many of these issues -- it would be nice if yours did so.
Have you read Chapter 6 of my book[1]. If you have and you think there
are no books that cover this topic, I need to do some revising. If you
haven't, why don't you start there and let me know if it cleared
anything up for you.
-Peter
[1] <http://www.gigamonkeys.com/book/variables.html>
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "Jeff" <···@nospam.insightbb.com> writes:
>
> > However, your sample code and other code from this thread, has me
> > wondering now as to what is happenning "under-the-hood" in Lisp. For
> > example, given the following snippet:
> >
> > (defvar *some-value*)
> >
> > (defun print-some-value ()
> > (print *some-value*))
> >
> > (defun test ()
> > (let ((*some-value* 'foobar))
> > (print-some-value)))
> >
> > When I call TEST, it prints FOOBAR to the screen. This isn't what I
> > would expect to happen -- I would expect it to print NIL -- since
> > *SOME-VALUE* is local to TEST, and not the global version.
>
> Have you read Chapter 6 of my book[1]. If you have and you think there
> are no books that cover this topic, I need to do some revising. If you
> haven't, why don't you start there and let me know if it cleared
> anything up for you.
Not bad. I have read several of the chapters, but missed that one.
However (and this isn't a bad thing) you only explain the /effect/ of
dynamic variables. I'm more interested in the reason as I've already
witnessed the effect. Your chapter is just fine :)
For example what does (declare (special x)) do exactly. I know that it
makes x dynamic. ? Inside the LET, when compiled does it just expand to
a {{ save *x* on hardware stack }} ,@body {{ pop *x* from hardware
stack }}? or perhaps something a little more complicated? Perhaps it is
implementation dependant.
I really do appreciate the info. ;)
And I can't wait for your book to be release...
Jeff M.
"Jeff" <···@nospam.insightbb.com> writes:
> For example what does (declare (special x)) do exactly. I know that
> it makes x dynamic. ? Inside the LET, when compiled does it just
> expand to a {{ save *x* on hardware stack }} ,@body {{ pop *x* from
> hardware stack }}? or perhaps something a little more complicated?
> Perhaps it is implementation dependant.
Undoubtedly implementation dependant at that level. Joe and Jane
Programmer only need to know that such a LET does not create a new
local, but rather dynamically binds X to the value so that in this
frame and any new call frames unless or until a new such LET occurs,
any reference to X will yield this "dynamic" value. Lexical structure
(spatial location) is not relevant; the current calling/binding
structure (temporal "location") is.
Now think of threads in terms of say a cactus stack and the value of
this is hard to overestimate. It borders on magic. :-)
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> "Jeff" <···@nospam.insightbb.com> writes:
>
> > For example what does (declare (special x)) do exactly. I know that
> > it makes x dynamic. ? Inside the LET, when compiled does it just
> > expand to a {{ save x on hardware stack }} ,@body {{ pop x from
> > hardware stack }}? or perhaps something a little more complicated?
> > Perhaps it is implementation dependant.
>
> Undoubtedly implementation dependant at that level....
>
> Now think of threads in terms of say a cactus stack and the value of
> this is hard to overestimate. It borders on magic. :-)
No doubt! Which brings me to another question... how does one handle
dynamic variables in multiple threads? Do they just "work" or is there
some more voodoo-magic that must be used ;)?
Jeff M.
"Jeff" <···@nospam.insightbb.com> writes:
> No doubt! Which brings me to another question... how does one handle
> dynamic variables in multiple threads? Do they just "work" or is there
> some more voodoo-magic that must be used ;)?
Implementation dependant (after all, at the moment threads basically
are as well). Various possibilities have been discussed here before
(a recent one was only a few months back, IIRC).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
"Jeff" <···@nospam.insightbb.com> writes:
> jayessay wrote:
>
>> "Jeff" <···@nospam.insightbb.com> writes:
>>
>> > For example what does (declare (special x)) do exactly. I know that
>> > it makes x dynamic. ? Inside the LET, when compiled does it just
>> > expand to a {{ save x on hardware stack }} ,@body {{ pop x from
>> > hardware stack }}? or perhaps something a little more complicated?
>> > Perhaps it is implementation dependant.
>>
>> Undoubtedly implementation dependant at that level....
>>
>> Now think of threads in terms of say a cactus stack and the value of
>> this is hard to overestimate. It borders on magic. :-)
>
> No doubt! Which brings me to another question... how does one handle
> dynamic variables in multiple threads? Do they just "work" or is there
> some more voodoo-magic that must be used ;)?
There is an approach where there is one stack of dynamic bindings
per dynamic variable ("shallow binding"). Looking up a dynamic
variable's value is fast, but if dynamic bindings are to be
thread-specific (usually desirable), switching between threads is
slow.
There is an approach where there is one stack of dynamic bindings
per thread ("deep binding"). Switching between threads is fast, but
looking up a dynamic variable's value is slow.
(When comparing such approaches, one also needs to consider the
speed of establishing bindings, as well as the speed of
disestablishing them, in the latter case for dynamic non-local
exits as well, left as an exercise for the reader...)
Note that all of the stacks involved are "logical stacks", none of
them need be a "hardware stack"; what is important is the LIFO
discipline with regards to execution (while with lexical variables,
the LIFO discipline is with regards to the textual structure of the
program, of course).
Disclaimer: this is just a quick, brief, and incomplete answer, by
all means read a more detailed treatment (the above ought to give
you some search keywords).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Jeff wrote:
> jayessay wrote:
>
>>"Jeff" <···@nospam.insightbb.com> writes:
>>
>>>For example what does (declare (special x)) do exactly. I know that
>>>it makes x dynamic. ? Inside the LET, when compiled does it just
>>>expand to a {{ save x on hardware stack }} ,@body {{ pop x from
>>>hardware stack }}? or perhaps something a little more complicated?
>>>Perhaps it is implementation dependant.
>>
>>Undoubtedly implementation dependant at that level....
>>
>>Now think of threads in terms of say a cactus stack and the value of
>>this is hard to overestimate. It borders on magic. :-)
>
> No doubt! Which brings me to another question... how does one handle
> dynamic variables in multiple threads? Do they just "work" or is there
> some more voodoo-magic that must be used ;)?
This again depends on the implementation because ANSI Common Lisp
doesn't specify anything about threads. However, all the Common Lisp
implementations I know do the Right Thing (tm): If you bind a new value
to a special variable, this change is only visible in the current
thread. All the other threads are unaffected.
However, CL implementations seem to diverge wrt to inheritance of
special variables when new threads are created - do they see the same
binding as the threads that created them, or do they get their own
independent copies? I don't have a complete overview of all the
possibilities here, but I am convinced that it's possible to get the
semantics that you need no matter what the semantics are that the CL
implementation comes with. It just may need some hacking to get things
right.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Different execution in package
Date:
Message-ID: <87mzymygbt.fsf@qrnik.zagroda>
Peter Seibel <·····@javamonkey.com> writes:
> [1] <http://www.gigamonkeys.com/book/variables.html>
You wrote:
"Note that SETF'ing a place that is part of a larger object still has
the same semantics as SETF'ing a variable in terms of the effects on
the place and the object referenced by the value in the place: while
we are modifying the object that contains the place, the SETF has no
effect on the object whose reference was stored in the place prior to
the assignment. Again, this is similar to how = behaves in Java, Perl,
and Python."
Perl is unusual among modern languages in that = actually copies the
value of a scalar, i.e. the whole number or string or pointer; it
does not rebind a reference, because Perl scalar variables and array
elements *contain* scalars, not *point* to them (although a scalar
can also be an explicit pointer, called a reference in perlspeak).
It's still not quite the same as in the Pascal/C/C++ model, because
function arguments are passed by reference. OTOH if a function begins
with "my ($foo, $bar, $baz) = @_" in order to refer to its parameters
by name, arguments are copied at this point.
Yes, in most languages it works like in Lisp, but not in Perl.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> It's still not quite the same as in the Pascal/C/C++ model, because
> function arguments are passed by reference. OTOH if a function
> begins with "my ($foo, $bar, $baz) = @_" in order to refer to its
> parameters by name, arguments are copied at this point.
Ah. I guess I have written so much perl code with that idiom that I
didn't really think about the other possibilities. So you're point is
that this:
perl -e 'sub foo { $_[0] = 11; } $x = 10; foo($x); print "$x\n";'
prints 11 because the value of $_[0] is actually the *variable* $x, not
its value. Weird.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>> It's still not quite the same as in the Pascal/C/C++ model, because
>> function arguments are passed by reference. OTOH if a function
>> begins with "my ($foo, $bar, $baz) = @_" in order to refer to its
>> parameters by name, arguments are copied at this point.
>
> Ah. I guess I have written so much perl code with that idiom that I
> didn't really think about the other possibilities. So you're point is
> that this:
>
> perl -e 'sub foo { $_[0] = 11; } $x = 10; foo($x); print "$x\n";'
>
> prints 11 because the value of $_[0] is actually the *variable* $x, not
> its value. Weird.
But
perl -e 'sub foo { $_[0] = 11; } $x = 10; $y = 20; foo($x+$y); print $x+$y;'
prints 30 nevertheless. Curiouser and curiouser... (Or perhaps
it's simply that old FORTRAN lives?)
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
"Jeff" <···@nospam.insightbb.com> writes:
> However, your sample code and other code from this thread, has me
> wondering now as to what is happenning "under-the-hood" in Lisp. For
> example, given the following snippet:
>
> (defvar *some-value*)
DEFVAR globally proclaims the symbol *SOME-VALUE* to be special.
That means it has dynamic bindings everywhere.
> (defun print-some-value ()
> (print *some-value*))
>
> (defun test ()
> (let ((*some-value* 'foobar))
> (print-some-value)))
>
> When I call TEST, it prints FOOBAR to the screen. This isn't what I
> would expect to happen -- I would expect it to print NIL -- since
> *SOME-VALUE* is local to TEST, and not the global version. Does Lisp
> constantly have a lexical scope at runtime instead of at compile-time?
> If so, this can be very powerful (as I've learned with redefining
> *PACKAGE* in this thread). Can anyone point me to a reference of how
> this works? It would seem expensive (time). How does Lisp pull it off?
I assume that you understand the difference between lexical and dynamic
scoping in Lisp. If not, speak up and someone will explain. The
dynamically scoped variables are called "Special Variables" in Common
Lisp parlance.
--
Thomas A. Russ, USC/Information Sciences Institute