Re: defvar affecting captured closure variables ?

Eli Bendersky <eliben@xxxxxxxxx> writes:

I realize this can be solved by following the naming convention.
However, I think you'll have to agree that this is not a clean
solution. Using a naming convention to avoid wrong behavior of the
environment shouldn't be the panacea.

It's probably hard to see, but global specials used to be the DEFAULT
in Lisp and lexical variables were on a VERY short list of one of the
most controversial choices that Common Lisp designers did, risking
alienating the entire community. It was one of the few cases where
those of us on the CLTL design team basically said something very close
to "look, we don't care that many users are afraid of lexicals, they
are still the right thing and we're going to do this transition because
it will make programs more correct". Globally pervasive specials were
an accommodation to the fact that this is exactly how SPECIAL used to
work in older lisps, and we needed to preserve a body of legacy programs.

At the time, the *foo* naming convention was not widely used in most
legacy applications, so we couldn't depend on it.

I think the reason we didn't ultimately repair it to work differently
is that, in fact, true reasons for new specials (as opposed to the
many accidental reasons for legacy specials) are scarce, and making an
elaborate new facility didn't seem worth it.

Sometimes then playing with complex code I find it useful to define
many global vars on the top environment. Adding earmuffs to each is
tiresome because these vars are not true globals of my code which I
want to mark, but just temporary places to hold stuff while I'm
testing how the code works.

But it makes your code more readable to others, and many compilers are
willing to warn you about mismatches between notation and
binding/setting/reference.

In practice, I agree it's baroque in notational style, and it's not
presented very clearly in many teaching texts. (I don't count ANSI CL,
nor CLHS, as a teaching text.)

I don't agree it's broken, in the sense that it has a clear design and
the design serves a specific purpose that was not subject to debate.

If it were new design without such constraints, I'd certainly do it
differently.

But among the things worth worrying about in the language, it's hardly
worth mentioning. Once one learns how to do it, it's pretty easy to
reliably use correctly.

Incidentally, ignore the advice about global lexicals. For better or
worse, I'm pretty sure all you want is this:

(define-symbol-macro foo (symbol-value 'foo))

Don't forget to use explicit special bindings when you really mean to
bind these globals, since otherwise you'll get a lexical foo when you
bind foo.
.

Relevant Pages

  • Re: WSAStartup, WSADATA, and class hierarchy
    ... >>> class Winsock ... > Then call it from ctor of each of your globals. ... configured for public availability via .conf files, ... It's possible my design is flawed, I'll admit, but I think that ...
    (microsoft.public.vc.language)
  • Re: Singleton Pattern
    ... that uses the singleton pattern to create just about everything. ... When you skip globals and start to pass variables ... you alter your design so that you don't have to do that as ... you discover that not everything needs the database and your design ...
    (comp.object)
  • Re: DTS SQL 2000 Global Variable initialization problem - please h
    ... What I was trying to say is that globals to persist. ... Many people put "settings" in them at design time that control execution. ... will be cleared, others will be set from config files, database lookups, etc. ...
    (microsoft.public.sqlserver.dts)
  • Re: 3E, 4E, and video games
    ... encounter, even if this is in 4e. ... of a critter, you either don't take full advantage of its specials, or you ... to design things yourself. ...
    (rec.games.frp.dnd)
  • Re: Dynamic variables in CL
    ... You went wrong from the start, not all specials are globals ... GCL is notorious for not being compliant and, ...
    (comp.lang.lisp)
Loading