Hi guys, I am playing with Lush Lisp, which is a dialect that
encourages you to program imperitively as well as functionally. It has
a GUI library that allows you to create buttons by passing a string (to
display on the button) and a callback function.
However I am new to lisp and confused about the scoping here. I want
to create 10 buttons with numbers 1 to 10, so that when you click on
one it passes its number to a function. However when I run this, the
values of i that gets passed for all the bottons is 10, as the value of
i is only evaluated at the moment I click the button! How do I get
around this?
(setq i 1)
(while (mycondition)
;blah blah blah
(create-button i (lambda(c) (my-fun i)))
(setq i (+ 1 i)
)
(defun my-fun (i)
(print i))
>Hi guys, I am playing with Lush Lisp, which is a dialect that
>encourages you to program imperitively as well as functionally.
This newsgroup is for the Common Lisp dialect. There are also a few
Schemers lurking about. I have never heard of Lush Lisp, so if it is
very different from Common Lisp then you might have a hard time finding
help here. You should consider trying to find a mailing list that is
more specific to your chosen dialect.
What you have shown looks a lot like Common Lisp (the dialect I know)
so I will pretend that is what I am looking at... except for "while."
Common Lisp has a "while" ... but the way you use it makes it look more
like the "while" in C than the while in Common Lisp. In Lisp, the body
would be evaluated once if mycondition is true. In C, the body would be
evaluated repeatedly until mycondition became false. You use it as
though it behaves like a C while. Are you sure that this is how it
works?
>the value of i is only evaluated at the moment I click the
>button! How do I get around this?
Instead of
(create-button i (lambda(c) (my-fun i)))
try this
(let ((new-var i))
(create-button i (lambda(c) (my-fun new-var))))
In Common Lisp, that would create a new variable, called new-var, which
starts out with the same value as i. A different version of new-var is
created for each of your buttons (each has the same name but different
scope). By the way, what is the purpose of c? It seems not to be used.
Maybe you want a function that doesn't take any arguments? (lambda ()
(my-fun new-var))
Another little issue... you use setq to change the value of i. Before
you change its value, you first should create the variable. So replace
(setq i 1) with (let ((i 1)) and put an additional closing parenthese
at the end of your while loop. Of course I am still thinking Common
Lisp. Lush Lisp could be totally different...
Good luck
Eric Lavigne wrote:
> This newsgroup is for the Common Lisp dialect. There are also a few
Is that so?
From the charter: "Discussion about LISP."
I see no explicit mentioning of Common Lisp in the charter, neither in
the newsgroup's name. If the newsgroup is for Common Lisp, as you claim,
where should one then discuss the other Lisp dialects?
mkb.
Eric> This newsgroup is for the Common Lisp dialect. There are also a
few
Matthias>Is that so?
Matthias>From the charter: "Discussion about LISP."
I judge a group by the people who frequent it and by the topics that
are usually discussed there. On this group that means Common Lisp and
occassionally Scheme.
Matthias>I see no explicit mentioning of Common Lisp in the charter,
neither in
Matthias>the newsgroup's name.
I offered practical advice about where to find help on an obscure
language. Unless you know of other Lush Lisp users on this newsgroup,
why would comp.lang.lisp be a good place?
As for the charter, I suspect that comp.lang.lisp is older than Common
Lisp and that other groups which once frequented comp.lang.lisp have
faded away.
Matthias>If the newsgroup is for Common Lisp, as you claim,
Matthias>where should one then discuss the other Lisp dialects?
For the Scheme programmers, I recommend comp.lang.scheme.
For Lush Lisp, try the lush-users mailing list on sourceforge
http://sourceforge.net/mail/?group_id=34223
It is lower volume than comp.lang.lisp, but I expect that people on
that list would know more about Lush Lisp.
Matthias Buelow wrote:
> Eric Lavigne wrote:
>
>>This newsgroup is for the Common Lisp dialect. There are also a few
>
> Is that so?
>
> From the charter: "Discussion about LISP."
>
> I see no explicit mentioning of Common Lisp in the charter, neither in
> the newsgroup's name. If the newsgroup is for Common Lisp, as you claim,
> where should one then discuss the other Lisp dialects?
This was discussed before quite a number of times. Check the archives.
It's _factually_ a Common Lisp newsgroup. Discussions about other Lisp
dialects tend to be solitary ventures.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Matthias Buelow wrote:
>
> > Eric Lavigne wrote:
> >
> >>This newsgroup is for the Common Lisp dialect. There are also a few
> >
> > Is that so?
> >
> > From the charter: "Discussion about LISP."
> >
> > I see no explicit mentioning of Common Lisp in the charter, neither in
> > the newsgroup's name. If the newsgroup is for Common Lisp, as you claim,
> > where should one then discuss the other Lisp dialects?
>
> This was discussed before quite a number of times. Check the archives.
>
> It's _factually_ a Common Lisp newsgroup. Discussions about other Lisp
> dialects tend to be solitary ventures.
The only dialects we actively discourage here are the ones that have
more appropriate newsgroups: comp.emacs or gnu.emacs.help for Emacs
Lisp, the Autocad newsgroup (I don't remember its full name) for
Autolisp, and comp.lang.scheme for Scheme.
But if there's no specific group for a dialect, where else do you expect
them to discuss it other than comp.lang.lisp?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>It's _factually_ a Common Lisp newsgroup. Discussions about other Lisp
>>dialects tend to be solitary ventures.
>
> The only dialects we actively discourage here are the ones that have
> more appropriate newsgroups: comp.emacs or gnu.emacs.help for Emacs
> Lisp, the Autocad newsgroup (I don't remember its full name) for
> Autolisp, and comp.lang.scheme for Scheme.
>
> But if there's no specific group for a dialect, where else do you expect
> them to discuss it other than comp.lang.lisp?
Hm, maybe I didn't find the right wording because I am not a native
speaker. I don't want to discourage discussions about other Lisp
dialects. It's just like Eric said, it's more likely that the OP will
find better help elsewhere. This can, of course, change in the future,
and I don't think this would be a problem.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> It's _factually_ a Common Lisp newsgroup. Discussions about other Lisp
> dialects tend to be solitary ventures.
Well, that's most likely because it reflects what most readers are
currently discussing, and not some inherent law that it Shall Be So.
And it's of course something that can change, given an influx of new
readers, or some general evolution kind of thing. I agree on the matter
of Scheme, though.. simply because there's a separate newsgroup for
that. I personally would like to see more discussions about other Lisp
dialects aswell, such as ISLISP but I'm a bit doubtful that there are
enough people currently who would want to discuss them, unfortunately. ;)
mkb.
On Sun, 12 Jun 2005 20:30:14 +0200, Matthias Buelow wrote:
> Eric Lavigne wrote:
..
> where should one then discuss the other Lisp dialects?
..
comp.lang.scheme comes to mind
the other less common lisps (heh) probably has mailinglists or own forums
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
On Sun, 12 Jun 2005 22:29:23 +0200, Lars Rune Nøstdal wrote:
> On Sun, 12 Jun 2005 20:30:14 +0200, Matthias Buelow wrote:
>
>> Eric Lavigne wrote:
> ..
>> where should one then discuss the other Lisp dialects?
> ..
>
> comp.lang.scheme comes to mind
>
> the other less common lisps (heh) probably has mailinglists or own forums
..like this one:
http://sourceforge.net/forum/forum.php?thread_id=1300314&forum_id=106861
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
Matthias Buelow wrote:
> Eric Lavigne wrote:
>
>
>>This newsgroup is for the Common Lisp dialect. There are also a few
>
>
> Is that so?
>
> From the charter: "Discussion about LISP."
>
> I see no explicit mentioning of Common Lisp in the charter, neither in
> the newsgroup's name. If the newsgroup is for Common Lisp, as you claim,
> where should one then discuss the other Lisp dialects?
The morgue.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
>> From the charter: "Discussion about LISP."
>>
>> I see no explicit mentioning of Common Lisp in the charter, neither in
>> the newsgroup's name. If the newsgroup is for Common Lisp, as you claim,
>> where should one then discuss the other Lisp dialects?
>
>
> The morgue.
You just made my day :D
--
Don't let school interfere with your education. -- Mark Twain
Eric Lavigne wrote:
>
> What you have shown looks a lot like Common Lisp (the dialect I know)
> so I will pretend that is what I am looking at... except for "while."
> Common Lisp has a "while" ... but the way you use it makes it look more
> like the "while" in C than the while in Common Lisp. In Lisp, the body
> would be evaluated once if mycondition is true. In C, the body would be
> evaluated repeatedly until mycondition became false. You use it as
> though it behaves like a C while. Are you sure that this is how it
> works?
>
You're thinking of the WHEN macro. WHILE is a LOOP keyword.
David Sletten
From: Christopher C. Stacy
Subject: lush, variable scope, iteration [was: Newbie scope question]
Date:
Message-ID: <ur7f66fjf.fsf_-_@news.dtpq.com>
"foxx" <·············@hotmail.com> writes:
> Hi guys, I am playing with Lush Lisp, which is a dialect that
> encourages you to program imperitively as well as functionally.
Lisp has always been a language based on imperative programming,
although it also allows a limited kind of "functional" programming.
(Sometimes in school, people are given the impression that Lisp
is about functional programming, since historically it was the
first language that provided something like that.)
> However I am new to lisp and confused about the scoping here.
> I want to create 10 buttons with numbers 1 to 10, so that when you
> click on one it passes its number to a function. However when I run
> this, the values of i that gets passed for all the bottons is 10, as
> the value of i is only evaluated at the moment I click the button!
> How do I get around this?
>
> (setq i 1)
> (while (mycondition)
> ;blah blah blah
> (create-button i (lambda(c) (my-fun i)))
> (setq i (+ 1 i)
> )
>
> (defun my-fun (i)
> (print i))
Style note: It would be better to not leave that dangling
parenthesis on the last line of your WHILE clause.
Instead, put it directly after that last SETQ form there
(without any whitespace). This goes for all forms.
Lush uses "dynamic binding", rather than lexical binding.
In this way, it is similar to Emacs Lisp, and other old dialects
of Lisp. Common Lisp, by contrast, uses lexical binding by default,
but also allows supports dynamic ("special") binding.
I've never heard of Lush before today.
Nevertheless, by looking at what happened,
we can guess what's going on in your example.
You are creating a callback function with LAMBDA,
but it's making a "free reference" to the variable I.
That is, the variable I has not been "captured" by
the LAMBDA. You have not created a "closure" over
a binding environment - just a regular function.
> However when I run this, the values of i that
> gets passed for all the bottons is 10
This is because you ran your toplevel function,
which set the value to 10. After that, your
callback function referenced that same variable.
> as the value of i is only evaluated at the moment
> I click the button!
What he said.
> How do I get around this?
Good question! I downloaded lush and tried all kinds
of things to create a lexical closure using LET, LET*,
DEFUN, DE, and LAMBDA. Nothing obvious would do it.
The "Open Discussion" forum on the lush SourceForge
page has a thread which is very similar to this one.
I suspect that the poster named "godelback" is you.
The answer that you came up with was (equivalent to) this:
(let ((x 69)) (setq f (eval `(lambda () ,x))))
it would appear that lush doesn't have lexical closures.
Note that the variable "X" is not being captured here.
Rather, you are creating function F that refrences a
constant value 69. The variable X is only referenced
by that explicit EVAL. The variable X is destroyed when
the LET exits. Any global variable X is irrelevent.
This would appear solve your immediate problem, which is
to create a bunch of callback functions that each use a
different constant variable (the "button number" or whatever).
But that function doesn't have any persistent state.
If you need to do that, maybe use the OO features of lush.
Subclass the button and give it an instance variable
that contains your state. When your callback function
runs, it is passed the button object, and can access
the state contained therein (eg. by calling methods on it).
There's a lush-devel mailing list (on SourceForge);
you might want to subscribe to that, if you're using lush.
Leon Bottou recently wrote some messages there saying that he's
changing lush into a lexically scoped language. He mentioned that
there's now a compiler for lush, something about dynamic binding
being hard to compile, and about the compiler having different scoping
than the interpreter. He said "The introduction of the compiler in
lush has slowly changed the dialect towards lexical scoping. The
intermediates states is messy." He also said that he's added DEFVAR
to the language, and that people should start updating all their code
to declare global variables. When people are used to doing that,
then they will change the language to have lexical scoping.
(And I guess maybe they'll add lexical closures, then.)
"Eric Lavigne" <············@gmail.com> writes:
> Common Lisp has a "while" ... but the way you use it makes it look more
> like the "while" in C than the while in Common Lisp. In Lisp, the body
> would be evaluated once if mycondition is true. In C, the body would be
> evaluated repeatedly until mycondition became false. You use it as
> though it behaves like a C while. Are you sure that this is how it
> works?
No; Common Lisp does not have any form named WHILE.
It would be easy to write your own WHILE macro.
It's better to use the perfectly good iteration
operators built into the language, instead.
If you like the word "while", Common Lisp _does_ have
a hairy macro called LOOP, which has its own sublanguage,
and you can write this:
(loop with x = 1 while (< x 3) do (print x) (incf x))
In this case, the test is performed before the body
is executed. So that will print out 1 and 2.
It does _not_ evaluate the body of the DO clause
before the WHILE test the first time.
Here's a simpler example to convince you:
(loop with x = t while (null x) do (print 'surprise))
which will not print anything, because the body is never executed.
The way it really works in LOOP is that termination clauses
are tested in the order where they appear. A body can come
either before or after the WHILE or UNTIL, whichever you want.
(loop with x = 1 while (< x 3)
do (print x) (incf x)
finally (return x))
This is the same as my first example.
It returns 1, 2 and returns the value 3.
Maybe something like that would confuse you into thinking
that the order of execution of the clauses was done in some
absolute order. But it's merely doing things in the order
that you stated: first test, then do. The confusion here
is that the termination condition is whether X >= 3.
By the way, there is also an UNTIL clause, which is
the logical compliments of WHILE.
Returning the iteration variable's value and using it
afterward is often confusing. You have to think about
whether the programmer made a fencepost mistake.
If you're going to return the value, write your
termination condition like this:
(loop with x = 1 until (= x 3)
do (print x) (incf x)
finally (return x))
which prints 1,2, and returns 3.
Same answer, but this code makes it clear, without any
logical induction, that X will reach 3 before returning.
In general, you can make many loops less confusing by not
side-effecting the iteration value in the body. Sometimes
that's unavoidable, but very often the control variable
is really independant of the body (which might only use
it as an index, or maybe not even use it at all).
This is why it's better to write it like this:
(loop for i from 1 to 3 do ....)
or (loop repeat 3 do ...) ;no variable needed.
or (loop for i below 4 do (print x))
and not return the iteration control variable's value.
Those are all just the most trivial examples of LOOP.
LOOP has many other powerful features.
LOOP was a controversial addition to the standard.
Half the community hates it, while the others ranges from
pragmatic acceptance to really liking it. The main issue
is aesthetic. As you can see, LOOP introduces its own
("non-Lispy") language syntax. And it's possible to write
incomprehensible LOOP code by combining the features in
various ways. Usually people write LOOP code that makes
the iteration very clear and concise.
Common Lisp has a lot of other iteration primitives built-in.
These predate LOOP, and are plain good Lisp syntax.
Besides your basic goto (GO), there's the powerful and
venerable DO macro (unrelated to the "DO" clasuse in LOOP).
some people find DO a little difficult to read.
(do ((i 1 (incf i)))
((> i 3) i)
(print i))
That prints out 1,2,3, and returns the value 4.
You can bind multiple variables. Each variable's
stepping form, as well as the end-test and return-forms,
and of course the body, can be any lisp expressions at all.
DO is Lisp's grand old man of iteration macros.
For iterating a certain number of times, there's the newer
and obviously comprehensible DOTIMES, and for iterating
across a list, there is DOLIST.
(dotimes (i 1000)
(format t "~&Blah blah blah number ~A" i))
(dolist (x '(blah bleah blough))
(print x))
Common Lisp also has mapping functions, which take one or more
sequences, and a function to apply to them, and can return an
accumulated result. For example, MAPCAR.
Some people who dislike LOOP use some third-party iteration
macro called ITERATE. It's not standard. I've never used it.
There's also a very interesting library called SERIES,
which was considered for inclusion into the standard
but didn't make it. It provides a framework for writing
(potentially lazy) series expressions.
The best place to learn about this stuff up is in
the Common Lisp Hyperspec, which is a version of
the ANSI spec that is widely available on the web.
It's not a tutorial. There's a new book out called
"Practical Common Lisp" which is highly recommended.
"Eric Lavigne" <············@gmail.com> writes:
> This newsgroup is for the Common Lisp dialect.
> There are also a few Schemers lurking about.
> I have never heard of Lush Lisp, so if it is very different
> from Common Lisp then you might have a hard time finding help
> here. You should consider trying to find a mailing list that
> is more specific to your chosen dialect.
There are seperate newsgroups for Scheme, XLISP,
Emacs Lisp, and possibly other Lisp languages.
Mostly people here discuss Common Lisp, which is
the ANSI standard dialect that most people who
self-identify as "Lisp programmers" program in.
Help with other Lisp dialects that don't have their own
newsgroup, comparisons, and theoretical discussions are not
necessarily entirely off-topic here (as long as one is not
trolling, of course). But the odds of finding help on random
things like Lush is rather low. Any posting here that is not
specially labeled as _not_ being about Common Lisp is likely
to cause confusion.
Christopher C. Stacy a �crit :
>
> Leon Bottou recently wrote some messages there saying that he's
> changing lush into a lexically scoped language. He mentioned that
> there's now a compiler for lush, something about dynamic binding
> being hard to compile, and about the compiler having different scoping
> than the interpreter. He said "The introduction of the compiler in
> lush has slowly changed the dialect towards lexical scoping. The
> intermediates states is messy." He also said that he's added DEFVAR
> to the language, and that people should start updating all their code
> to declare global variables. When people are used to doing that,
> then they will change the language to have lexical scoping.
> (And I guess maybe they'll add lexical closures, then.)
>
Last time I checked about Lush (was around three years ago) it seemed
like it suffered from the interpreter/compiler schizophreny of the elder
lisps : dynamically scoped variables in interpreted, interactive mode,
lexical in compiled (in fact Lush compiles to C).
The OP could try his code in compiled mode just to check that.
Aur�lien.
"foxx" <·············@hotmail.com> writes:
> Hi guys, I am playing with Lush Lisp, which is a dialect that
> encourages you to program imperitively as well as functionally. It has
> a GUI library that allows you to create buttons by passing a string (to
> display on the button) and a callback function.
>
> However I am new to lisp and confused about the scoping here. I want
> to create 10 buttons with numbers 1 to 10, so that when you click on
> one it passes its number to a function. However when I run this, the
> values of i that gets passed for all the bottons is 10, as the value of
> i is only evaluated at the moment I click the button! How do I get
> around this?
Switch to Common Lisp?
> (setq i 1)
> (while (mycondition)
>
> ;blah blah blah
>
> (create-button i (lambda(c) (my-fun i)))
> (setq i (+ 1 i)
> )
>
> (defun my-fun (i)
> (print i))
Perhaps this would do:
(create-button i (eval `(lambda(c) (my-fun ,i))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
"foxx" <·············@hotmail.com> writes:
> However I am new to lisp and confused about the scoping here. I want
> to create 10 buttons with numbers 1 to 10, so that when you click on
> one it passes its number to a function. However when I run this, the
> values of i that gets passed for all the bottons is 10, as the value of
> i is only evaluated at the moment I click the button! How do I get
> around this?
>
> (setq i 1)
This line implicity creates a global variable "i" in most Lisp
systems.
> (while (mycondition)
>
> ;blah blah blah
>
> (create-button i (lambda(c) (my-fun i)))
^ ^
1 2
There are two references to "i" in this line. Assuming that
CREATE-BUTTON is a function and not a macro that doesn't evaluate all
its arguments, the first reference to "i" will evaluate it and use the
value. The second reference to "i" is inside a lambda expression. The
lambda expression will use the value "i" has when the lambda expression
is invoked. That is really what is supposed to happen inside the lambda.
> (setq i (+ 1 i)
> )
>
> (defun my-fun (i)
> (print i))
First of all, I would not use a global variable for this at all, but
instead use a local variable. Although I'm not familiar with your
particular dialect, I will assume that LET is among the features it
supports.
You should also take advantage of the Lisp's feature that data and
programs share a datastructure to construct new lambda expressions for
each of the buttons. If your lisp supports backquote, this is trivially
easy. If it doesn't it can also be done, but with a bit more effort.
Look at the following:
(let ((i 1))
(while (mycondition)
...
(create-button i `(lambda (x) (my-fun ,i)))
(setq i (+ 1 i))))
Note that if you don't have backquote, you will have to create the
lambda expression using normal list construction operators instead:
(list 'lambda '(x) (list 'my-fun i))
Note that "i" is NOT quoted in this expression. You want the value of
"i" and not the symbol I.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> "foxx" <·············@hotmail.com> writes:
> (let ((i 1))
> (while (mycondition)
> ...
> (create-button i `(lambda (x) (my-fun ,i)))
> (setq i (+ 1 i))))
foxx, As Thomas explains the problem is that all
the created (lambda (x) (my-fun i)) refer to the
same variable. Therefore you can solve the problem
by capturing the value of i in another variable j
before creating the closure.
(let ((i 1))
(while (mycondition)
...
(let ((j i)) (create-button j (lambda (x) (my-fun j))))
(setq i (+ 1 i))))
Now there are as many j's as there are closures.
--
Jens Axel Søgaard