Re: Is there ever a good reason to create globals in Lisp?

"Yves S. Garret" <[email protected]>
Newsgroups gmane.lisp.clisp.devel
Message-ID <CAJ=2b05wkoV4ExvqSQQTRi9z0coY8OT+QXgEH2RCLUpnmOM1eg@mail.gmail.com>
I wouldn't say I "worry" about it.  The concept of not having global vars
at all (well, unless there's a damn good reason, avoid at all costs like
the 'goto') has been drilled down into my skull ever since I finished my
first C++ programming class in college.

>From a design perspective, this makes sense.  Fewer global vars are a good
thing.  They can give you quirky behavior unless you're super careful.  I
was more curious when you guys design Lisp apps, how you treat global
variables (yes, classes, functions, etc. are global as well, but this is
not exactly the same thing) in Lisp.  Even in imperative and OO languages
globals have a time and place (but very seldom and there has to be a damn
good reason why).  Do professional Lisp developers actively embrace them?
 Stay away from them like you would in other programming languages?  Or is
there some other middle-ground that I'm not aware of.

The example that you provide is exactly where I could see how things could
go very wrong in terms of undefined behavior :-) .  How are global variable
regarded in Lisp?

On Wed, Apr 25, 2012 at 12:09 AM, Pascal J. Bourguignon <
[email protected]> wrote:

> "Yves S. Garret" <[email protected]> writes:
>
> > Hi, going through Land of Lisp and I get to a part of the book where
> > you define global variables.  I realize that the author is trying to
> > educate the students about this, but is there ever a good reason for
> > globals in Lisp?  In Java, C/C++, PHP, etc. it's frowned down upon at
> > best.
>
> Functions, classes, types, constants, packages, etc,  are global
> bindings.
>
> There are so many things that have global names, why do you worry about
> a few global variables?
>
>
> Yes, there are good reasons to have global variables.
>
> The main one is to keep references to "persistent" data.  The scope of
> persistence being that of the lisp image (and remember that
> implementations provide operators to save the lisp images and reload
> them).
>
> Given the REPL, global variables allow passing data between two
> functions called independently, and with the programmer intervention at
> the REPL in the middle.
>
>
>    cl-user> (defvar *data*)
>    *data*
>    cl-user> (defun compute-phase-a () (setf *data* (random 42)))
>    compute-phase-a
>    cl-user> (defun compute-phase-b () (* 2 *data*))
>    compute-phase-b
>    cl-user> (compute-phase-a)
>    40
>    cl-user> *data*
>    40
>    cl-user> (compute-phase-b)
>    80
>    cl-user> *data*
>    40
>
>
> Also, in Common Lisp global variables defined with defvar and
> defparameter are special variables.  All the bindings involving the
> symbol naming them are dynamic bindings.  This allow passing pervasive
> parameter unconspicuously.
>
>    cl-user> (defun do-something () (print *data*) (terpri))
>    do-something
>    cl-user> (setf *print-base* 16.)
>    10
>    cl-user> (do-something)
>
>    28
>    nil
>    cl-user> (setf *print-base* 10.)
>    10
>    cl-user> (do-something)
>
>    40
>    nil
>
>
>
> --
> __Pascal Bourguignon__                     http://www.informatimago.com/
> A bad day in () is better than a good day in {}.
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.