This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Jamison, that patch fixed the function space lookup issues I was having, thanks!
But I've been puzzling over a follow-up namespace related problem. Hopefully with all that information loaded into your head, you might be able to throw some clues my way :-)
(defun dummy () 'top-level) (funcall #'dummy) ;=> top-level (flet ((dummy () 'shadow)) (funcall #'dummy)) ;=> shadow (funcall #'dummy) ;=> shadow
Line 1 does a
lexical.push: Declaration[dummy/2]
and when I do a decl.setProcedureDecl(true) on the flet'ed function line 3, I'm fiddling with a Declaration[dummy/39], so definitely a different object, and it's in a new scope (a new LetExp), which gets popped after FLET's extent.
The call to FUNCTION inside the FLET correctly looks up dummy/39, and outside the FLET, correctly looks up dummy/2, so how is dummy/2's function binding getting changed? Any clues on where I might find a smoking gun?
$ cat /tmp/flet-test.lisp
(defun funcall (fn &rest args) (display (apply fn args)) (newline)) (defun dummy () 'top-level) (funcall #'dummy) (flet ((dummy (lambda () 'shadow))) (funcall #'dummy) (funcall #'dummy)
$ kawa --lisp #|kawa:1|# (load "/tmp/flet-test.lisp") top-level shadow shadow
$ kawa -f /tmp/flet-test.lisp top-level shadow shadow
$ kawa /tmp/flet-test.lisp top-level shadow top-level
Good thing we've got Charles around to figure everything out for us now!
Can I have his email address? I could use someone like that! :-)
-- Jamison Hope The PTR Group www.theptrgroup.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |