Re: Closures, was Re: What does Tcl lack?

From: Bruce Stephens (bruce+usenet_at_cenderis.demon.co.uk)
Date: 02/24/05 

Date: Thu, 24 Feb 2005 22:22:38 +0000

maurice.ulis@wanadoo.fr (ulis) writes:

> I've two feelings about that:
> - environment is a complex idea and beginners take some time to
> understand that the execution environment can be different of the
> definition environment (what means [namespace::proc $arg] is not an
> evidence)
> - mastering the environment in Tcl is matter of using namespaces (as
> substitutes of objects).

I think you're oversimplifying what happens in Tcl.

Tcl has (optionally) a kind of dynamic scope, in the sense that a
procedure can get hold of variables from the stack of procedures that
called it.

That tends to be easy to understand, because it's almost always used
to access an array or variable in the procedure that called you, so
you do things like:

    proc foo {arrVar} {
        upvar 1 $arrVar array
        set array(something) something
    }

In theory one can do "upvar 17 $a b" or even "upvar $n $a $b" and
stuff, but as far as I know that kind of thing is only ever going to
be useful for debugging, where you *know* you're doing unusual things.

I think users need to learn the current environment, the global
environment, and namespaces. You can't do without understanding the
global environment because so many things happen in it.

Arguably it's possible to avoid some of this in a language with proper
lexical scoping. In those, a name which doesn't have a more local
binding is a global variable, so you can do:

     proc foo {} {
         set x 1
         label .c -textvariable x
     }

and that kind of thing, and the two x's are the same variable since no
other binding for x has been created. Of course in Tcl you really
have to do:

     proc foo {} {
         set ::x 1
         label .c -textvariable x
     }

(It would also be legal to use ::x in both places, of course.) (You
can also use "global x" to indicate that the x is in the global scope,
but that seems less readable to me than marking each time using "::".)

Anyway, I'm not at all convinced that Tcl's semantics are particularly
simple in this respect. I'm not sure that any other way of doing
things is particularly simpler; lexically scoped languages tend to
want to have *some* dynamically scoped names, too, and then you tend
to have other scopes like packages or namespaces or objects.

Relevant Pages

  • Re: Reintroducing fish, the friendly interactive shell
    ... Fish supports universal variables, which are variables whose value is ... Universal variables have the outermost scope, ... Universal variables make it much more practical to use environment ... Can you specify the normal behaviour of shell? ...
    (comp.unix.shell)
  • Re: A question about lexical binding
    ... from SICP uses a deep binding environment. ... However, deep binding has the problem that depending upon the caller, ... Whether you get lexical or dynamic scope depends on how you terminate the ... toplevel frame, you have lexical references; ...
    (comp.lang.lisp)
  • Re: What Does Lexical Mean?
    ... or an environment can occur. ... places where that something is "in scope", that is, has a certain ... you now probably have enough context to go ... A binding is ... ...
    (comp.lang.lisp)
  • Exception using Isolated Storage in ASP.NET on a hosted server
    ... I'm getting the following exception on the hosted environment: ... scope) at ... scope, Type domainEvidenceType, Type assemblyEvidenceType) at ...
    (microsoft.public.dotnet.framework)
  • Re: Closures, was Re: What does Tcl lack?
    ... > some aspects of its environment, ... Tcl already has a notion of a proc being associated with a namespace. ... >>And I never understoud why Tcl needs closures. ... > described in terms of string substitution and eval (in other languages ...
    (comp.lang.tcl)