Re: A question (confusion) about closure

From: "xah...@xxxxxxxxx" <xah...@xxxxxxxxx>
sometimes something so obvious and clear to me but can't get
other programers to see.

Or you might actually be mistaken, and too stubborn to admit your
mistake. You wouldn't want to get a reputation like Archemedes
Plutonium or JSH or Brad Guth, would you?

Robert Maas came in too. So silly.

Not silly at all. I have a valid complaint with your claim.

People, closures is effectively just function using global vars, alright?

Not allright. Wrong.

Global variables have indefinite duration and global accessibility.
Local variables have dynamic duration and local (private) accessibility.
Fluid bindings have dynamic duration and global accessibility.
Own/static variables have indefinite duration and local (private) accessibility.
No two of those are the same. You are confusing global and own/static variables!!

Closures are just like own/static variables, except the private
accessiblity is potentially shared among more than one function or
other block of code that was defined/generated within the single
lexical scope where the closure(s) were produced.

You want functions to share env? create a naming scheme like
_contextA_var1, _contextA_var2, ... then functions can share
_contextA_* vars.

That's practical only if (1) somebody sets up a system of names
whereby each programmer has his/her own private domain within that
system and each programmer sets up his/her own private sub-domains
within that system, such that never are any two domains or
sub-domains in conflict, and (2) programmers are very very careful
to follow the convention very strictly and never step on each
other's names, and (3) all such names are statically generated in
source code. There is no practical way to generate an unlimited set
of such names automatically from a closure-generating factory,
whereas true closures as implemented in Common Lisp are trivial to
generate in unlimited quantity from a factory method.

C++ gets by with such mangled names being passed to the loader
because all such names are generated automatically, and even so
there are only a fixed set of such names defined at compile time
based on a fixed number of symbols directly appearing in source
code within each of a fixed number of programmer-specified
namespaces. That mechanism doesn't work for generating an unlimited
number of new mangled names at runtime, especially when running an
unlimited number of multiple threads that all share a single common
global naming space.

Now there *is* one thing to say for mangled global names, whether
mangled by ordinary prefixes or suffixes as you suggest (and as C++
uses), or by package prefixes: With prefixes/suffixes, the various
functions that share the global variable don't have to be defined
all at the same time, and can be re-defined individually at any
time without breaking the sharing. By comparison a group of lexical
closures must all be defined in a single lexical context, and
re-defining just one of them without the others doesn't work.

But just because both mangled global names and lexical closures are
useful, doesn't mean they are the same thing, as you claim.

In this way, you have closures, or what closures is supposed to
achieve in a program, in just about any language.

No, you don't. IMO you are mistaken.

Here's some code in Common Lisp, definition of a closure-factory:
(defun make-closures ()
(let ((x 42))
(list (function (lambda (newx) (setq x newx)))
(function (lambda () x))
)))
Each time you call it, it returns an list of two anonymous
functions, a setter with one arg and a getter with zero args, which
share a private static variable.
You can call it ten thousand times without trouble:
(setq closures (loop for ix from 1 to 10000 collect (make-closures)))
Next, a demo they really work:
(funcall (cadr (nth 5 closures))) ;returns 42
(funcall (cadr (nth 9 closures))) ;returns 42
(funcall (car (nth 9 closures)) 7)
(funcall (cadr (nth 5 closures))) ;returns 42
(funcall (cadr (nth 9 closures))) ;returns 7

Please show code written in C which can do something equivalent at runtime.
Feel free to write the closures into an array instead of a linked list
if that's easier for the purpose of a demo.

i hijacked the thread to discuss the concept of closure itself in general.

It would be better if you hijack a thread on a topic you actually understand.

The Kent Pitman fella is a pest.

No, he's a really bright guy, with lots of good insight. I
sometimes disagree with him, because he overlooked something which
I saw, but more often he enlightens me about something I hadn't
realized before he pointed it out.
.

Relevant Pages

  • Re: Getting and Setting and best practise
    ... to interpret which private variable you wanted. ... C - you make seperate getter/setter functions for each private ... if I've been a good little programmer ... interface to the object INSIDE of the object. ...
    (comp.lang.php)
  • Re: fields or properties
    ... All you have to do is change the name of the (now private) field, ... manipulated _only_ within the owning class, ... one class and find _all places_ where that field is changed, and modify ... I'm a lazy programmer and I don't like cluttering my brain ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why less emphasis on private data?
    ... no concept of private data in C either, ... One does not need in C the static keyword to make a variable defined inside a function i.e. a so called 'automatic variable' private to that test. ... To Neil Cerutti: If a programmer in C has got a pointer to some piece of memory, that piece is at the mercy of the programmer. ...
    (comp.lang.python)
  • Re: subroutine references
    ... anonymous function that makes use of closures. ... Objects in Perl do not do a very good job of data hiding. ... you a better programmer. ...
    (perl.beginners)
  • I am Shocked
    ... Until 6 years ago I was a C++ programmer. ... private double d; ...
    (microsoft.public.dotnet.languages.vc)