Global variables are accessible everywhere except in expressions that
create a new local variable with the same name. So how do I alter the
value of the global variable within a function? Wouldn't this be
considered a new variable and leave the global version intact.
Thanks.
On Mon, 24 Oct 2005 01:19:22 -0400, tachyon <·······@gmail.com> wrote:
> Global variables are accessible everywhere except in expressions that
> create a new local variable with the same name. So how do I alter the
> value of the global variable within a function? Wouldn't this be
> considered a new variable and leave the global version intact.
> Thanks.
>
(defvar *x* 0)
(defun add-five-to-x ()
(setf *x* (+ *x* 5)))
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
You may find a mix of local and special variables. You can use
declarations to unravel this (or as some would note, to make it really
confused). Example,
(note: special variables with * around is just a convention)
(defvar foo 5)
(defun bar (foo)
;; at this point, the global binding of foo is shadowed
(setf foo 27) ;; the local value is 27
(let (foo) ; set up a new binding of foo
(declare (special foo)) ; now you're dealing with the global
binding
(setf foo 100)))
(bar 1)
(print foo) => 100
tachyon wrote:
> Global variables are accessible everywhere except in expressions that
> create a new local variable with the same name. So how do I alter the
> value of the global variable within a function? Wouldn't this be
> considered a new variable and leave the global version intact.
> Thanks.
"Jerry Boetje" <·······@cs.cofc.edu> writes:
>
>
> (note: special variables with * around is just a convention)
>
> (defvar foo 5)
> (defun bar (foo)
> ;; at this point, the global binding of foo is shadowed
> (setf foo 27) ;; the local value is 27
> (let (foo) ; set up a new binding of foo
> (declare (special foo)) ; now you're dealing with the global
> binding
> (setf foo 100)))
>
> (bar 1)
> (print foo) => 100
Actually, this should still be "5", since the SETF happens
inside of a binding of FOO that restores the special value
once that LET binding is exited.
In fact, looking more closely, this example is flawed because DEFVAR
declares FOO to be globally special. And Common Lisp doesn't have any
declaration to make a variable be NON-SPECIAL. That means that there
will be binding of the special variable FOO created with each call to
the function BAR.
That means that you can't really do anything inside BAR that will affect
the global value of FOO.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
Thomas A. Russ <···@sevak.isi.edu> wrote:
> "Jerry Boetje" <·······@cs.cofc.edu> writes:
> > (note: special variables with * around is just a convention)
> >
> > (defvar foo 5)
> > [...]
>
> In fact, looking more closely, this example is flawed because DEFVAR
> declares FOO to be globally special. And Common Lisp doesn't have any
> declaration to make a variable be NON-SPECIAL.
Which is of course why special variables with * around the name is such an
important convention, to the point where some implementations issue style
warnings if variables don't look right. :-)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
tachyon wrote:
> Global variables are accessible everywhere except in expressions that
> create a new local variable with the same name. So how do I alter the
> value of the global variable within a function? Wouldn't this be
> considered a new variable and leave the global version intact.
> Thanks.
Special variables (created with DEFVAR or DEFPARAMETER) can be
reassigned with LET, which I assume you're doing, but outside the LET
the variable reassumes its old value.
But you can also SETQ or SETF the variable. If you do that inside a
LET, again the change is only visible while you're in the LET, but if
you assign a non-local variable, then the value stays.
(defvar *foo* 5)
(defun bar ()
(setf *foo* 8)
(format t "Hi there"))
(bar) ; call the function
*foo* ; evaluates to 8
--
Blessed are the young for they shall inherit the national debt.
Herbert Hoover
In article <··············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
> tachyon wrote:
> > Global variables are accessible everywhere except in expressions that
> > create a new local variable with the same name. So how do I alter the
> > value of the global variable within a function? Wouldn't this be
> > considered a new variable and leave the global version intact.
> > Thanks.
>
> Special variables (created with DEFVAR or DEFPARAMETER) can be
> reassigned with LET
No, they can be rebound with LET. They can be reassigned with setf or
(setf symbol-value).
Both of you should read www.flownet.com/gat/specials.pdf
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Ulrich Hobelmann <···········@web.de> wrote:
>
>> tachyon wrote:
>>> Global variables are accessible everywhere except in expressions that
>>> create a new local variable with the same name. So how do I alter the
>>> value of the global variable within a function? Wouldn't this be
>>> considered a new variable and leave the global version intact.
>>> Thanks.
>> Special variables (created with DEFVAR or DEFPARAMETER) can be
>> reassigned with LET
>
> No, they can be rebound with LET. They can be reassigned with setf or
> (setf symbol-value).
That's what I meant, since the variable's symbol binding reassumes the
old value outside the LET. Underneath probably only the binding is
shadowed, but other implementations are possible, like
* save old special binding
* assign new value to special (= global) variable
* restore old special binding
inside an unwind-protect. I guess it depends if unwind-protect, or the
dynamic variable lookup is cheaper.
--
Blessed are the young for they shall inherit the national debt.
Herbert Hoover
In article <··············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
> Ron Garret wrote:
> > In article <··············@individual.net>,
> > Ulrich Hobelmann <···········@web.de> wrote:
> >
> >> tachyon wrote:
> >>> Global variables are accessible everywhere except in expressions that
> >>> create a new local variable with the same name. So how do I alter the
> >>> value of the global variable within a function? Wouldn't this be
> >>> considered a new variable and leave the global version intact.
> >>> Thanks.
> >> Special variables (created with DEFVAR or DEFPARAMETER) can be
> >> reassigned with LET
> >
> > No, they can be rebound with LET. They can be reassigned with setf or
> > (setf symbol-value).
>
> That's what I meant, since the variable's symbol binding reassumes the
> old value outside the LET. Underneath probably only the binding is
> shadowed, but other implementations are possible, like
>
> * save old special binding
> * assign new value to special (= global) variable
> * restore old special binding
>
> inside an unwind-protect. I guess it depends if unwind-protect, or the
> dynamic variable lookup is cheaper.
That fails if you have multiple threads. This was discussed to death
last January. Google for the thread called "Smug Scheme weenies."
rg
Ron Garret wrote:
>> That's what I meant, since the variable's symbol binding reassumes the
>> old value outside the LET. Underneath probably only the binding is
>> shadowed, but other implementations are possible, like
>>
>> * save old special binding
>> * assign new value to special (= global) variable
>> * restore old special binding
>>
>> inside an unwind-protect. I guess it depends if unwind-protect, or the
>> dynamic variable lookup is cheaper.
>
> That fails if you have multiple threads. This was discussed to death
> last January. Google for the thread called "Smug Scheme weenies."
If you have multiple threads referencing the same special variable, yes.
I'd consider that very bad style though and make all special variables
per-thread by default (I think some Lisp or Scheme implementations
actually do that). If people want ITC, they should use messages,
semaphores, conditions, whatever... (IMHO)
--
Blessed are the young for they shall inherit the national debt.
Herbert Hoover
Ulrich Hobelmann <···········@web.de> wrote:
+---------------
| Ron Garret wrote:
| > That fails if you have multiple threads. This was discussed to death
| > last January. Google for the thread called "Smug Scheme weenies."
|
| If you have multiple threads referencing the same special variable, yes.
| I'd consider that very bad style though and make all special variables
| per-thread by default...
+---------------
That doesn't work, either! How could you possibly share global data
if *all* special variables were per-thread?!? Remember, Common Lisp
has nothing *but* special variables as globals.
No, what most Common Lisp implementations which provide threads
actually do is "the right thing":
1. If a thread has not LET-bound (or LAMBDA-bound) a global/special
variable, it sees the same binding as other threads which have not
bound it. A SETF by any such thread is seen by all such threads.
2. If a thread LET-binds (or LAMBDA-binds) a special variable, then
that binding is thread-local for the dynamic duration of that
binding. A SETF or rebinding of that special variable while so
bound will be seen only by that thread. [Other special variables
which have not been LET/LAMBDA-bound by that thread will behave
as in #1.]
Conversely, such a thread will not see any SETFs to a variable
it has bound by non-binding threads (as in #1) until it exits the
LET/LAMBDA- binding contour, at which point it will see whatever
the current "global" value happens to be.
Said more succinctly: If you want a special variable to be thread-
local, bind it. If you want it to be global, SETF it.
To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
and probably others as well. [LW?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <······················@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Ulrich Hobelmann <···········@web.de> wrote:
> +---------------
> | Ron Garret wrote:
> | > That fails if you have multiple threads. This was discussed to death
> | > last January. Google for the thread called "Smug Scheme weenies."
> |
> | If you have multiple threads referencing the same special variable, yes.
> | I'd consider that very bad style though and make all special variables
> | per-thread by default...
> +---------------
>
> That doesn't work, either! How could you possibly share global data
> if *all* special variables were per-thread?!? Remember, Common Lisp
> has nothing *but* special variables as globals.
>
> No, what most Common Lisp implementations which provide threads
> actually do is "the right thing":
>
> 1. If a thread has not LET-bound (or LAMBDA-bound) a global/special
> variable, it sees the same binding as other threads which have not
> bound it. A SETF by any such thread is seen by all such threads.
>
> 2. If a thread LET-binds (or LAMBDA-binds) a special variable, then
> that binding is thread-local for the dynamic duration of that
> binding. A SETF or rebinding of that special variable while so
> bound will be seen only by that thread. [Other special variables
> which have not been LET/LAMBDA-bound by that thread will behave
> as in #1.]
>
> Conversely, such a thread will not see any SETFs to a variable
> it has bound by non-binding threads (as in #1) until it exits the
> LET/LAMBDA- binding contour, at which point it will see whatever
> the current "global" value happens to be.
>
> Said more succinctly: If you want a special variable to be thread-
> local, bind it. If you want it to be global, SETF it.
>
> To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
> and probably others as well. [LW?]
This behavior is required by the standard, so any CL that doesn't work
this way is non-compliant.
rg
Ron Garret <·········@flownet.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > Said more succinctly: If you want a special variable to be thread-
| > local, bind it. If you want it to be global, SETF it.
| >
| > To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
| > and probably others as well. [LW?]
|
| This behavior is required by the standard, so any CL that doesn't work
| this way is non-compliant.
+---------------
Uh... Where does the standard talk about *threads*?!?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ron Garret <·········@flownet.com> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) wrote:
> | > Said more succinctly: If you want a special variable to be thread-
> | > local, bind it. If you want it to be global, SETF it.
> | >
> | > To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
> | > and probably others as well. [LW?]
> |
> | This behavior is required by the standard, so any CL that doesn't work
> | this way is non-compliant.
> +---------------
>
> Uh... Where does the standard talk about *threads*?!?
It doesn't necessarily need to talk about threads, but may place
restrictions on the semantics of special variables such that only one
(or few) possible semantics are possible when you add threads.
Indeed, I think that rebinding a special variable must make it
thread-local. However, I don't see how special variables are required to
be global to all threads when they are not rebound...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Rob Warnock wrote:
> > Ron Garret <·········@flownet.com> wrote:
> > +---------------
> > | ····@rpw3.org (Rob Warnock) wrote:
> > | > Said more succinctly: If you want a special variable to be thread-
> > | > local, bind it. If you want it to be global, SETF it.
> > | >
> > | > To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
> > | > and probably others as well. [LW?]
> > |
> > | This behavior is required by the standard, so any CL that doesn't work
> > | this way is non-compliant.
> > +---------------
> >
> > Uh... Where does the standard talk about *threads*?!?
>
> It doesn't necessarily need to talk about threads, but may place
> restrictions on the semantics of special variables such that only one
> (or few) possible semantics are possible when you add threads.
>
> Indeed, I think that rebinding a special variable must make it
> thread-local. However, I don't see how special variables are required to
> be global to all threads when they are not rebound...
I suppose it is debatable, but I infer this requirement from the titles
of sections 3.1.1.1 and 3.1.1.2. The standard refers to "dynamic
environments" plural, but "the global environment" singular.
rg
Ron Garret wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>>Indeed, I think that rebinding a special variable must make it
>>thread-local. However, I don't see how special variables are required to
>>be global to all threads when they are not rebound...
>
> I suppose it is debatable, but I infer this requirement from the titles
> of sections 3.1.1.1 and 3.1.1.2. The standard refers to "dynamic
> environments" plural, but "the global environment" singular.
Some Common Lisp implementations create new bindings for global specials
when new threads are spawned. Since ANSI CL indeed doesn't talk about
threads, it's perfectly ok to define such semantics for operators that
are outside the scope of ANSI CL.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Rob Warnock wrote:
> Ulrich Hobelmann <···········@web.de> wrote:
> +---------------
> | Ron Garret wrote:
> | > That fails if you have multiple threads. This was discussed to death
> | > last January. Google for the thread called "Smug Scheme weenies."
> |
> | If you have multiple threads referencing the same special variable, yes.
> | I'd consider that very bad style though and make all special variables
> | per-thread by default...
> +---------------
>
> That doesn't work, either! How could you possibly share global data
> if *all* special variables were per-thread?!? Remember, Common Lisp
> has nothing *but* special variables as globals.
Exactly, and I don't use global variables in other languages (C) either;
Java doesn't even have them (except for static class variables).
I consider globals bad style for multithreading and prefer messaging
instead. Of course, if you don't offer that as a language primitive,
then you would indeed need some kind of global globals.
> No, what most Common Lisp implementations which provide threads
> actually do is "the right thing":
>
> 1. If a thread has not LET-bound (or LAMBDA-bound) a global/special
> variable, it sees the same binding as other threads which have not
> bound it. A SETF by any such thread is seen by all such threads.
>
> 2. If a thread LET-binds (or LAMBDA-binds) a special variable, then
> that binding is thread-local for the dynamic duration of that
> binding. A SETF or rebinding of that special variable while so
> bound will be seen only by that thread. [Other special variables
> which have not been LET/LAMBDA-bound by that thread will behave
> as in #1.]
>
> Conversely, such a thread will not see any SETFs to a variable
> it has bound by non-binding threads (as in #1) until it exits the
> LET/LAMBDA- binding contour, at which point it will see whatever
> the current "global" value happens to be.
>
> Said more succinctly: If you want a special variable to be thread-
> local, bind it. If you want it to be global, SETF it.
>
> To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
> and probably others as well. [LW?]
Ah, thanks for the information. That's sounds quite good (and would
allow me to build messaging on top).
I should really look into threading in Lisp. I only hope that the APIs
are somewhat similar between OpenMCL, SBCL, and maybe others.
--
Blessed are the young for they shall inherit the national debt.
Herbert Hoover
Ulrich Hobelmann <···········@web.de> wrote:
+---------------
| Rob Warnock wrote:
| > Said more succinctly: If you want a special variable to be thread-
| > local, bind it. If you want it to be global, SETF it.
| >
| > To my knowledge, ACL, Corman Lisp, CMUCL, & SBCL all behave this way,
| > and probably others as well. [LW?]
|
| Ah, thanks for the information. That's sounds quite good (and would
| allow me to build messaging on top).
| I should really look into threading in Lisp. I only hope that the APIs
| are somewhat similar between OpenMCL, SBCL, and maybe others.
+---------------
I think a lot of them copied the multiprogramming model expected by
CLIM (often called "multiprocessing" in the older literature, even
when it was no such thing!), so they all ended up looking somewhat
similar. Some refs (courtesy Don Geddis a couple of years ago):
http://www.lispworks.com/reference/lwl42/CLIM-U/html/climguide-330.htm
http://alu.cliki.net/com-metacircles-clim-sys-mp
http://www.franz.com/support/documentation/6.2/doc/multiprocessing.htm
The CMUCL [and thus SBCL?] threads are also "based roughly on the
CLIM-SYS spec. and support needed for cl-http".
Corman Lisp supports Windows O/S threads:
http://www.cormanlisp.com/CormanLisp/CormanLisp_2_5.pdf [Chapter 20]
http://www.cormanlisp.com/Multi-threaded%20Lisp.ppt
[Google will display an HTML version...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> http://alu.cliki.net/com-metacircles-clim-sys-mp
"It may rebind special variables: the new bindings are local to that
thread. The effect of assigning to these variables without rebinding
them is implementation-defined." - Why isn't it specified to change
the global binding? Of course a mutex should be used if the same
binding is used by other threads, i.e. most of the time.
"destroy-process [...] it is implementation-defined whether the
process's cleanup forms run, or whether it releases locks that it may
be holding." - It's not the only problem. A process should be able to
declare in which regions it is safe or unsafe to interrupt it.
"condition-notify [...] Notify one or more of the processes waiting
for CONDITION-VARIABLE" - There should be separate functions for
notifying all processes and notifying a single process. Notifying all
is a good default, but if only one process at a time is able to react
to the condition and many processes might be waiting, notifying all
would unnecessarily wake up the others.
> http://www.franz.com/support/documentation/6.2/doc/multiprocessing.htm
http://www.franz.com/support/documentation/6.2/doc/gc.htm#finalizations-2
doesn't say that finalizers are run in a separate thread. It makes most
non-trivial finalizers unsafe. See Hans-J. Boehm "Destructors, Finalizers,
and Synchronization", <http://citeseer.ist.psu.edu/640926.html>.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Sat, 29 Oct 2005 13:54:20 +0200, Marcin 'Qrczak' Kowalczyk
<······@knm.org.pl> wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
>> http://alu.cliki.net/com-metacircles-clim-sys-mp
>
> "It may rebind special variables: the new bindings are local to that
> thread. The effect of assigning to these variables without rebinding
> them is implementation-defined." - Why isn't it specified to change
> the global binding? Of course a mutex should be used if the same
> binding is used by other threads, i.e. most of the time.
>
> "destroy-process [...] it is implementation-defined whether the
> process's cleanup forms run, or whether it releases locks that it may
> be holding." - It's not the only problem. A process should be able to
> declare in which regions it is safe or unsafe to interrupt it.
>
> "condition-notify [...] Notify one or more of the processes waiting
> for CONDITION-VARIABLE" - There should be separate functions for
> notifying all processes and notifying a single process. Notifying all
> is a good default, but if only one process at a time is able to react
> to the condition and many processes might be waiting, notifying all
> would unnecessarily wake up the others.
>
>> http://www.franz.com/support/documentation/6.2/doc/multiprocessing.htm
>
> http://www.franz.com/support/documentation/6.2/doc/gc.htm#finalizations-2
> doesn't say that finalizers are run in a separate thread. It makes most
> non-trivial finalizers unsafe. See Hans-J. Boehm "Destructors,
> Finalizers,
> and Synchronization", <http://citeseer.ist.psu.edu/640926.html>.
>
I remember reading Rodger Corman's report on how he implemented threading
in Corman lisp. He adresses some of your questions.
It is available at: www.cormanlisp.com/Multi-threaded%20Lisp.ppt
Unfortunately it's in powerpoint formar so I don't know if you can read it.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Rob Warnock wrote:
> Ulrich Hobelmann <···········@web.de> wrote:
> +---------------
> | Ron Garret wrote:
> | > That fails if you have multiple threads. This was discussed to death
> | > last January. Google for the thread called "Smug Scheme weenies."
> |
> | If you have multiple threads referencing the same special variable, yes.
> | I'd consider that very bad style though and make all special variables
> | per-thread by default...
> +---------------
>
> That doesn't work, either! How could you possibly share global data
> if *all* special variables were per-thread?!? Remember, Common Lisp
> has nothing *but* special variables as globals.
I'm expecting to be corrected, but couldn't one envision an FFI-like
non-standard interface to global quantities, without violating the
standard?
Depending on such a facility would be annoying, and probably inferior
to using specials, but might be a route open to implementations by the
standard.
In article <·······················@g43g2000cwa.googlegroups.com>,
···············@hotmail.com" <············@gmail.com> wrote:
> Rob Warnock wrote:
> > Ulrich Hobelmann <···········@web.de> wrote:
> > +---------------
> > | Ron Garret wrote:
> > | > That fails if you have multiple threads. This was discussed to death
> > | > last January. Google for the thread called "Smug Scheme weenies."
> > |
> > | If you have multiple threads referencing the same special variable, yes.
> > | I'd consider that very bad style though and make all special variables
> > | per-thread by default...
> > +---------------
> >
> > That doesn't work, either! How could you possibly share global data
> > if *all* special variables were per-thread?!? Remember, Common Lisp
> > has nothing *but* special variables as globals.
>
> I'm expecting to be corrected, but couldn't one envision an FFI-like
> non-standard interface to global quantities, without violating the
> standard?
You don't need an FFI. You can create non-dynamic globals using symbol
macros.
But that is beside the point. The reason globals are global and not
per-thread is because the standard (arguably) requires it.
rg