From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,NO_REAL_NAME, RCVD_IN_SORBS_WEB autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id C9C04BC69 for ; Thu, 29 Mar 2007 12:52:36 +0200 (CEST) Received: from server2.thinkcrime.de (server2.thinkcrime.de [213.133.110.149]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2TAqatL030065 for ; Thu, 29 Mar 2007 12:52:36 +0200 Received: from hod-sarge-2005-10.lan.m-e-leypold.de (dslb-088-072-215-087.pools.arcor-ip.net [88.72.215.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server2.thinkcrime.de (Postfix) with ESMTP id 452DA488176 for ; Thu, 29 Mar 2007 12:52:37 +0200 (CEST) Received: by hod-sarge-2005-10.lan.m-e-leypold.de (Postfix, from userid 1003) id B0ADC376F9; Thu, 29 Mar 2007 12:59:30 +0200 (CEST) To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] How must we teach lexical scope? References: <6f9f8f4a0703280059m5b9af3a1t3a9541b772af98bb@mail.gmail.com> <20070328084955.GA21199@yquem.inria.fr> <6f9f8f4a0703280734p49ed0b7fk48787a8ba3a76e9e@mail.gmail.com> <6f9f8f4a0703281009i74927505hba3e04227f61e357@mail.gmail.com> <6f9f8f4a0703290117qf0fa062n6430a168e7acf5b7@mail.gmail.com> From: ls-ocaml-developer-2006@m-e-leypold.de Date: Thu, 29 Mar 2007 12:59:30 +0200 In-Reply-To: <6f9f8f4a0703290117qf0fa062n6430a168e7acf5b7@mail.gmail.com> (Loup Vaillant's message of "Thu, 29 Mar 2007 10:17:28 +0200") Message-ID: User-Agent: Some cool user agent (SCUG) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-j-chkmail-Score: MSGID : 460B9A74.000 on discorde : j-chkmail score : XX : 5/20 0 0.000 -> 2 X-Miltered: at discorde with ID 460B9A74.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; invocation:01 foo:01 bindings:01 markus:01 28,:98 beginners:01 lexical:01 syntactic:01 caml-list:01 writes:01 functions:01 functions:01 define:01 closure:01 closure:01 "Loup Vaillant" writes: > 2007/3/28, ls-ocaml-developer-2006@m-e-leypold.de > : >> But perhaps I understand your problem better now: The difference >> you're wanting to make is the substitution of symbols by values at >> definition time vs. at evaluation time (I hope it is clear what I want >> to say). > > Exactly. > >> But you'll have to explain substitution at evaluation time >> anyway (when a function is called and the formal parameters are >> bound). I don't understand what your attempt to avoid to talk about an >> environment (from which a comes in the example above) will buy you. > > Substitution at definition time is how I naturally thought of it. That > is, the definition: > # f x = a + x;; > was automatically replaced by: > # f x = 3 + x;; > in my head, so there were no more need for any environment. > > However, I must admit such a way of thinking has its limits: Yes. One of the limits is that with way of thinking you cannot explain invocation of functions. Furthermore you cannot explain: let make_adder a = fun x -> x + a ;; which exemplifies the very essence of "functional programming". > as long as the substitution is simple, that is easy. When a free > variable is some complicated piece of data (or even code), one (I) > must switch to an environment representation. No, it doesn't depend on the complexity. It just depends on wether variables / identifiers are bound during the specific evaluation you're looking at. As soon as you use functions in functions it becomes really difficult -- if you start to return closure, it is impossible to explain what happens without talking about environments. > In that case, the > environment I think about is only the set of free variables actually > used by the function. The environments our professors talked about > included all values, including the useless ones. Well, of course, after you have enclosed a environment in a closure you can -- technically -- leave out all "unnecessary" variables. But the point is, that all the unnecesarry variables just define which variables are "valid" ro be used in a give context. Consider: ...[1] let f x y = ...[2] ... Which identifiers can be used in [2]? x and y certainly -- but what about k, t and foo? That of course depends on the context inherited from [1] -- and the best expression of the context is the environment which contains all bindings that have been made in [1] > I thought it was unnecessary, but I see the trade-of, now: their > process is quite long (not to mention the syntactic burden of > describing each environment) but it is systematic, and simple. As I said: I wouldn't consider more than (at most) a week to be necessary for the whole shebang, so I'm ready to concede they are perhaps overdoing it (on the other side it's their course and it's not my position to judge them). Perhaps they also miss giving the big picture (how evaluation, free variables, definition and environments mesh together). I wouldn't know. On the other side my experience with beginners is, that they are often, unfortunately, missing the niceties and the big picture even when they are told about them. So the whole thing is perhaps more one of the usual didactic misunderstandings rather the a bad course. > Because it is, it looks silly. I don't like environments, but you > convinced me I haven't came up with a better solution. :-) Good to hear. Now let me buy some stock of Toulouse 3, so ... damn -- they haven't gone public yet? What a waste ... Regards -- Markus