Re: [Caml-list] How must we teach lexical scope?

[ls-ocaml-developer-2006@m-e-leypold.de]

"Loup Vaillant" <loup.vaillant@gmail.com> writes:

> 2007/3/28, ls-ocaml-developer-2006@m-e-leypold.de
> <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