Could someone point me in the right direction?
(defvar *bar* "Testme")
(princ (let ((foo "Testme"))
(parenscript:compile-script '(setf x (parenscript:lisp *bar*)))))
=> (works) x = 'Testme';
but
(princ (let ((foo "Testme"))
(parenscript:compile-script '(setf x (parenscript:lisp foo)))))
=> (error) The variable FOO is unbound.
Thanks
Kelly McDonald
In article
<····································@w7g2000hsa.googlegroups.com>,
Kelly <·····@fammcdonald.net> wrote:
> Could someone point me in the right direction?
>
> (defvar *bar* "Testme")
>
> (princ (let ((foo "Testme"))
> (parenscript:compile-script '(setf x (parenscript:lisp *bar*)))))
>
> => (works) x = 'Testme';
That's using the global special variable *bar*.
>
> but
>
> (princ (let ((foo "Testme"))
> (parenscript:compile-script '(setf x (parenscript:lisp foo)))))
That's trying to access the lexical variable foo.
CL-USER 15 > (let ((foo 3)) (eval 'foo))
Error: The variable FOO is unbound.
1 (continue) Try evaluating FOO again.
2 Specify a value to use this time instead of evaluating FOO.
3 Specify a value to set FOO to.
4 (abort) Return to level 0.
5 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
CL-USER 16 : 1 > :top
CL-USER 17 > (defparameter *bar* 4)
*BAR*
CL-USER 18 > (eval '*bar*)
4
CL-USER 19 >
>
> => (error) The variable FOO is unbound.
>
> Thanks
> Kelly McDonald
--
http://lispm.dyndns.org/
I understood that the first was a global variable, and that the second
was a lexical, but I was wondering why the second doesn't evaluate -
I have a guess:
compilation of the parenscript code happens prior to the lexical var
being 'set up' causing the error. The parenscript:lisp macro (well its
a psmacro - haven't looked that far yet) appears to do an eval which
would happen at compile time rather at run time when the foo var is
actually set up.
Does this sound about right?
If so, Do I have any way to use a lexical variable here??
I see the 'rebind' psmacro right behind the lisp macro, but this
doesn't seem to be exported. I may toy with this a bit.
Thanks for your help
Kelly
On Jun 5, 5:35 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@w7g2000hsa.googlegroups.com>,
>
> Kelly <·····@fammcdonald.net> wrote:
> > Could someone point me in the right direction?
>
> > (defvar *bar* "Testme")
>
> > (princ (let ((foo "Testme"))
> > (parenscript:compile-script '(setf x (parenscript:lisp *bar*)))))
>
> > => (works) x = 'Testme';
>
> That's using the global special variable *bar*.
>
>
>
> > but
>
> > (princ (let ((foo "Testme"))
> > (parenscript:compile-script '(setf x (parenscript:lisp foo)))))
>
> That's trying to access the lexical variable foo.
>
> CL-USER 15 > (let ((foo 3)) (eval 'foo))
>
> Error: The variable FOO is unbound.
> 1 (continue) Try evaluating FOO again.
> 2 Specify a value to use this time instead of evaluating FOO.
> 3 Specify a value to set FOO to.
> 4 (abort) Return to level 0.
> 5 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or :? for other options
>
> CL-USER 16 : 1 > :top
>
> CL-USER 17 > (defparameter *bar* 4)
> *BAR*
>
> CL-USER 18 > (eval '*bar*)
> 4
>
> CL-USER 19 >
>
>
>
> > => (error) The variable FOO is unbound.
>
> > Thanks
> > Kelly McDonald
>
> --http://lispm.dyndns.org/
From: Sohail Somani
Subject: Re: Parenscript - Do I need a dope slap?
Date:
Message-ID: <nr12k.1381$Gn.513@edtnps92>
Kelly wrote:
> I understood that the first was a global variable, and that the second
> was a lexical, but I was wondering why the second doesn't evaluate -
>
> I have a guess:
>
> compilation of the parenscript code happens prior to the lexical var
> being 'set up' causing the error. The parenscript:lisp macro (well its
> a psmacro - haven't looked that far yet) appears to do an eval which
> would happen at compile time rather at run time when the foo var is
> actually set up.
>
> Does this sound about right?
>
> If so, Do I have any way to use a lexical variable here??
>
> I see the 'rebind' psmacro right behind the lisp macro, but this
> doesn't seem to be exported. I may toy with this a bit.
Try:
(let ((foo "bar"))
(ps:ps* `(do-something ,foo)))
Its either ps or ps* but I've written my own wrappers and have long
forgotten what the actual API looks like...
Note that this will generate javascript code everytime that code gets
evaluated, not just once.
On 2008-06-06 02:51:56 +0100, Kelly <·····@fammcdonald.net> said:
> I understood that the first was a global variable, and that the second
> was a lexical, but I was wondering why the second doesn't evaluate -
You're just passing a list to a function, you can't afterward refer to
the lexical environment where you created the list
What you can do is save the lexical environment by creating a lambda
and then use the lisp form to call that lambda:
(let ((b 3))
(setq tmp (lambda () b))
(compile-script '(setq x (lisp (tmp)))))
but that tmp must be in the top-level environment.
Otherwise, you can also use backquote:
(compile-script `(setq x ,tmp))
-- Filipe Cabecinhas
Thanks Filipe,
I just realized that I should be using a backquote this morning. It
was about 35degC inside when I wrote the first post. Your explanation
is helpful !
Kelly
On Jun 6, 6:20 am, Filipe Cabecinhas <·················@ist.utl.pt>
wrote:
> On 2008-06-06 02:51:56 +0100, Kelly <·····@fammcdonald.net> said:
>
> > I understood that the first was a global variable, and that the second
> > was a lexical, but I was wondering why the second doesn't evaluate -
>
> You're just passing a list to a function, you can't afterward refer to
> the lexical environment where you created the list
>
> What you can do is save the lexical environment by creating a lambda
> and then use the lisp form to call that lambda:
> (let ((b 3))
> (setq tmp (lambda () b))
> (compile-script '(setq x (lisp (tmp)))))
>
> but that tmp must be in the top-level environment.
> Otherwise, you can also use backquote:
> (compile-script `(setq x ,tmp))
>
> -- Filipe Cabecinhas
On 6 Jun., 12:20, Filipe Cabecinhas <·················@ist.utl.pt>
wrote:
> On 2008-06-06 02:51:56 +0100, Kelly <·····@fammcdonald.net> said:
>
> > I understood that the first was a global variable, and that the second
> > was a lexical, but I was wondering why the second doesn't evaluate -
>
> You're just passing a list to a function, you can't afterward refer to
> the lexical environment where you created the list
>
> What you can do is save the lexical environment by creating a lambda
> and then use the lisp form to call that lambda:
> (let ((b 3))
> (setq tmp (lambda () b))
> (compile-script '(setq x (lisp (tmp)))))
>
I think you mean (compile-script '(setf (lisp (funcall tmp)))) here.
ciao,
Jochen
--
Jochen Schmidt
CRISPYLOGICS
Julienstr. 1, 90419 Nuremberg
Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83
mailto:(format nil "~(····@~36r.~36r~)" 870180 1680085828711918828
16438) http://www.crispylogics.com
On Jun 5, 6:51 pm, Kelly <·····@fammcdonald.net> wrote:
> I understood that the first was a global variable, and that the second
> was a lexical, but I was wondering why the second doesn't evaluate -
>
> I have a guess:
>
> compilation of the parenscript code happens prior to the lexical var
> being 'set up' causing the error.
The code being compiled simply isn't in the scope of the lexical
variable. It's just a piece of data being treated as code.
This is analogous to:
(let ((local 21))
(eval '(+ local local)))
Or, somewhat more accurate analogy:
(let ((local 21))
(compile nil '(lambda () (+ local local)))
In both of these, LOCAL is a piece of literal data in a quoted list;
it has no connection to the LET. When that quoted list is treated as
Lisp code within the evaluator or compiler, the occurences of LOCAL
are free varaible references, and are evaluated or compiled as such.
EVAL wants to resolve the references prior to returning; if a dynamic
binding for LOCAL exists, the free references will be resolved to
that. Otherwise an unbound variable error is signaled.
COMPILE will return a compiled function in which the free references
to LOCAL are translated to dynamic variable references. When that
function is called (via FUNCALL, etc), if there is no dynamic binding,
an error is signaled.