A question (confusion) about closure
in [Lisp]
|
Prev: You want abbreviations? You can't handle abbreviations!
Next: Hot Shop Audemars Piguet Royal Oak Watches - Audemars Piguet Minimum Price
From: George Neuner on 5 May 2008 05:01 On Mon, 05 May 2008 00:13:14 -0400, Ken Tilton <kennytilton(a)optonline.net> wrote: > > >George Neuner wrote: >> Conceptually, closures create a parameterized instance of a function >> by capturing the values of the function's free variables. > >Not sure this matters, but it is not just the values being captured, it >is the variables themselves, for I can assign to them and might share >them with other closures. > >kt Yes, the bindings are captured. Sorry ... Xah gets me so riled sometimes that I can hardly see straight. I really should know better. George -- for email reply remove "/" from address
From: xahlee on 5 May 2008 05:16 i'm rather quite surprised how my exposition of the closure concept turn up so many messages, many claiming it being even unhelpful or useless. And now, Kent, the rhetoric master, began his verbose elaboration with my name repeatedly embeded. (i feel, rather, elated by that) (lol) in the beginning, 'was just Rainer and George Neuner. Their problem, is simply not seeing the over all picture, but drilling on Common Lisp technicality and terminology. I point this out but, but as i said, sometimes something so obvious and clear to me but can't get other programers to see. (lisp's cons and list problem, is another example, we've discused at length around Jan) Robert Maas came in too. So silly. People, closures is effectively just function using global vars, alright? You want functions to share env? create a naming scheme like _contextA_var1, _contextA_var2, ... then functions can share _contextA_* vars. You want 2 different env? have it _contextA_*, _contextB_* ... etc. You want nesting? Have it _contextA_ContextA_*..., _contextA_ContextB_*..., _contextA_ContextA_ContextA*, _contextA_ContextA_ContextB*, ..., etc. No, the prefix â_â isn't alluding to Python's object whatnot or anything. It just any random string as a naming convention so it could be programatically identified and hidden from user. (think how you would implement closure) In this way, you have closures, or what closures is supposed to achieve in a program, in just about any language. Closures, function with a state, OOP, are basically the same thing. They just have slightly different perspective, slightly different connotation, and defined and implemented differently in different langs. When you formalize them into mathematics, they amount to the same thing. People, stop tech geeking. Get ya heads out of sand. Stop drilling on definitions and terminologies, or burying yourself deep inside Common Lisp. The originall poster of this thread is perhaps asking about terminologies in CL context and i hijacked the thread to discuss the concept of closure itself in general. At least i wished you could see that. The Kent Pitman fella is a pest. He is the circular priest. Writes long and carefully, and very difficult to deal with. Whatever he didn't like, will become the lamb to be put up for slaughter when the time comes. The Rainer fella insists his posting of Common Lisp code as a way to put the discussion on firm grounds. What a meritable fellow. Try Emacs Lisp Rainer, or Mathemtica. If you have a question on the latter, i can help you. Tim X, shuddap and go do your school work. Kenny!!!!!! I saw your vid on google. On the beach babbling about the wonders of Common Lisp. You crazy!!!! Xah xah(a)xahlee.org â http://xahlee.org/ â
From: Didier Verna on 6 May 2008 15:05 viper-2 <visionat(a)mail.infochan.com> wrote: > Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence > no CLOS. [...] I know all that. History doesn't change the fact that elisp is a really poor dialect of Lisp. >> BTW, what exactly do you mean by "customize and extend [...]" ? > > I quoted this from the GNU EMACS Manual > http://www.gnu.org/software/emacs/manual/html_mono/emacs.html. > > That is how EMACS is commonly referred to by its devotees. Maybe > someone else would clue you in? Ha ha :-) Like I said, for (most) people thinking that "customizing and extending" their favorite editor merely boils down to hacking their ..emacs, yes elisp is probably fine. elisp is *not* fine for writing 30% of the program itself, or a general purpose mailer/newser... -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org
From: Ken Tilton on 5 May 2008 07:10 xahlee(a)gmail.com wrote: > i'm rather quite surprised how my exposition of the closure concept > turn up so many messages, many claiming it being even unhelpful or > useless. And now, Kent, the rhetoric master, began his verbose > elaboration with my name repeatedly embeded. (i feel, rather, elated > by that) (lol) > > in the beginning, 'was just Rainer and George Neuner. Their problem, > is simply not seeing the over all picture, but drilling on Common Lisp > technicality and terminology. I point this out but, but as i said, > sometimes something so obvious and clear to me but can't get other > programers to see. (lisp's cons and list problem, is another example, > we've discused at length around Jan) Robert Maas came in too. So > silly. > > People, closures is effectively just function using global vars, > alright? Possibly not. It depends on how you mean this naming scheme of yours to work (the meta-problem being you not accepting CL as the way to make concrete hence comprehensible normally incomprehensible natural language, but let's soldier on with sign language and see what can be achieved)... > > You want functions to share env? create a naming scheme like > _contextA_var1, _contextA_var2, ... then functions can share > _contextA_* vars. > > You want 2 different env? have it _contextA_*, _contextB_* ... etc. If you at least show us the actual Python code we could understand you better. What I would be looking for is...well, lemme ask: Do you mean that "different env" would be achieved by generating unique names /on each dynamic entry/ into the same block of code, by mucking with the Python dictionary? (defparameter *xah-space* (make-hash-table :test 'equalp)) (map nil 'funcall (loop for x below 2 collecting (let ((yvar (concatenate 'string (symbol-name (gensym)) "-var1"))) (setf (gethash yvar *xah-space*) x) (lambda () (print `(y is ,(gethash yvar *xah-space*))))))) -> (Y IS 0) (Y IS 1) Or did you mean "different env" would be achieved by hard-coding _contextA_var1 one place in the code and hard-coding _contextB_var1 another place in the code? The latter (hardcoding differently prefixed "var1"s) does not cut it, but in the former you are Greenspunning closures (but need to work out when to GC the unique names or in a sufficiently heavy-hit function your Python dictionary will explode). You have mentioned Emacs Lisp as a satisfactory form of communication, perhaps someone could offer this in Emacs form: (map nil 'funcall (loop for x below 2 collecting (let ((y x)) (lambda () (print `(y is ,y)))))) -> (Y IS 0) (Y IS 1) Again, you can Greenspun that with a dictionary and GCing the globals (much harder--when does the anonymous function itself get GCed?), but maybe you did not mean that. > > You want nesting? Have it _contextA_ContextA_*..., > _contextA_ContextB_*..., _contextA_ContextA_ContextA*, > _contextA_ContextA_ContextB*, ..., etc. > > No, the prefix “_” isn't alluding to Python's object whatnot or > anything. It just any random string as a naming convention so it could > be programatically identified and hidden from user. (think how you > would implement closure) > > In this way, you have closures, or what closures is supposed to > achieve in a program, in just about any language. > > Closures, function with a state, OOP, are basically the same thing. > They just have slightly different perspective, slightly different > connotation, and defined and implemented differently in different > langs. > > When you formalize them into mathematics, they amount to the same > thing. > > People, stop tech geeking. Get ya heads out of sand. Stop drilling on > definitions and terminologies, or burying yourself deep inside Common > Lisp. The originall poster of this thread is perhaps asking about > terminologies in CL context and i hijacked the thread to discuss the > concept of closure itself in general. At least i wished you could see > that. > > The Kent Pitman fella is a pest. He is the circular priest. Writes > long and carefully, and very difficult to deal with. Whatever he > didn't like, will become the lamb to be put up for slaughter when the > time comes. > > The Rainer fella insists his posting of Common Lisp code as a way to > put the discussion on firm grounds. What a meritable fellow. Try Emacs > Lisp Rainer, or Mathemtica. If you have a question on the latter, i > can help you. > > Tim X, shuddap and go do your school work. > > Kenny!!!!!! I saw your vid on google. On the beach babbling about the > wonders of Common Lisp. You crazy!!!! Thx! I try. kenny -- http://smuglispweeny.blogspot.com/ http://www.theoryyalgebra.com/ ECLM rant: http://video.google.com/videoplay?docid=-1331906677993764413&hl=en ECLM talk: http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Pascal J. Bourguignon on 5 May 2008 09:15
"xahlee(a)gmail.com" <xahlee(a)gmail.com> writes: > People, closures is effectively just function using global vars, > alright? No, it is not. That is, unless you remove any meaning to the word "global". See below. > You want functions to share env? create a naming scheme like > _contextA_var1, _contextA_var2, ... then functions can share > _contextA_* vars. > > You want 2 different env? have it _contextA_*, _contextB_* ... etc. (defun make-a-closure (x) (let ((y x)) (list (lambda () y) (lambda (v) (setf y v))))) Y is not a global variable. There will be as many different variables denoted by Y as calls to MAKE-A-CLOSURE. Each of these variable is not global, because it cannot be accessed globally. It can only be accessed by the functions that are in the scope of the closure (specifically, for Y, the lexical scope of that LET). > You want nesting? Have it _contextA_ContextA_*..., > _contextA_ContextB_*..., _contextA_ContextA_ContextA*, > _contextA_ContextA_ContextB*, ..., etc. > > No, the prefix â_â isn't alluding to Python's object whatnot or > anything. It just any random string as a naming convention so it could > be programatically identified and hidden from user. (think how you > would implement closure) This is exactly what we would like you to do: think about how closures would be implemented! > In this way, you have closures, or what closures is supposed to > achieve in a program, in just about any language. No. If you speak of just about any language, then just do it! Try to implement the above make-a-closure function in C and see how you just cannot use a global variable for Y! Test your C function with the equivalent in C of: (mapcar (function make-a-closure) (COM.INFORMATIMAGO.COMMON-LISP.LIST:IOTA (progn (princ "Enter an integer: ") (read)))) > Closures, function with a state, OOP, are basically the same thing. Yes. And object slots just ARE NOT global variables, but quite the opposite. Therefore enclosed variable are not global variables, CQFD. Thanks for exposing your own contradictions. > They just have slightly different perspective, slightly different > connotation, and defined and implemented differently in different > langs. > > When you formalize them into mathematics, they amount to the same > thing. Which is not global variables. -- __Pascal Bourguignon__ |