How must we teach lexical scope?

How must we teach lexical scope?

[Loup Vaillant]

My brother is currently learning Camllight at the Toulouse 3
university, France. Five years ago, I followed the same course.

I don't understand the way were are taught lexical scope. Our
professors used "environments", where free variable would suffice.
(An environment is the set of defined values at a given time. The
environment of a value is the environment of when this value is
defined.)

-> They talk about closures, even in the case of pure functional
style, even in the absence of free variable (except the built in
constructions, such as '+').
-> They take hours and hours of boring an silly looking exercises
about environment, so we can understand how important environments
are.(we even had to learn a specific syntax to talk about them).
-> The promised power of the language is completely overlooked. Even
the crippled Pascal on my calculator looked more powerful.

Luckily, I had later a professor, who showed us the real power of
Caml. He didn't talked about environments.

So here are a few questions:
-> Is lexical scope that important when learning pure functional programming?
-> Are environments helpful (even the slightest bit) when teaching
lexical scope?
-> Where does this idea come from? I have not read a single book, as
single article nor blog talking about environments.
-> How can we teach lexical scope? Is there a simple solution, the
kind of a first year student can understand in less than an hour?

Thanks,
Loup

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

[Luc Maranget]

> So here are a few questions:
> -> Is lexical scope that important when learning pure functional 
> programming?
> -> Are environments helpful (even the slightest bit) when teaching
> lexical scope?
> -> Where does this idea come from? I have not read a single book, as
> single article nor blog talking about environments.
> -> How can we teach lexical scope? Is there a simple solution, the
> kind of a first year student can understand in less than an hour?

An attempt to answer your question 1.


Bon, c'est en français (sorry French only).

http://www.enseignement.polytechnique.fr/profs/informatique/Luc.Maranget/compil/poly/interprete.html#htoc45



--Luc

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

[Loup Vaillant]

2007/3/28, Luc Maranget <luc.maranget@inria.fr>:
> > So here are a few questions:
> > -> Is lexical scope that important when learning pure functional
> > programming?
> > -> Are environments helpful (even the slightest bit) when teaching
> > lexical scope?
> > -> Where does this idea come from? I have not read a single book, as
> > single article nor blog talking about environments.
> > -> How can we teach lexical scope? Is there a simple solution, the
> > kind of a first year student can understand in less than an hour?
>
> An attempt to answer your question 1.

OK, It was about the implementation of first class function in a
Pascal like language.

Personally, I think environments are about the implementation of
lexical scope, not  its specifications. Therefore, teaching them in
the first year of a programming course is premature. I may be wrong,
so I am trying to verify that.

Loup

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

[ls-ocaml-developer-2006]

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

> 2007/3/28, Luc Maranget <luc.maranget@inria.fr>:

>> > So here are a few questions:
>> > -> Is lexical scope that important when learning pure functional
>> > programming?
>> > -> Are environments helpful (even the slightest bit) when teaching
>> > lexical scope?
>> > -> Where does this idea come from? I have not read a single book, as
>> > single article nor blog talking about environments.
>> > -> How can we teach lexical scope? Is there a simple solution, the
>> > kind of a first year student can understand in less than an hour?
>>
>> An attempt to answer your question 1.
>
> OK, It was about the implementation of first class function in a
> Pascal like language.
>
> Personally, I think environments are about the implementation of
> lexical scope, not  its specifications. Therefore, teaching them in
> the first year of a programming course is premature. I may be wrong,
> so I am trying to verify that.

Personally I think you're wrong here. Environments (as mapping from
identifier to values) represent the context in which a given
expression must be read and interpreted (in both senses). I cannot
imagine a way to do so precisely without using a similar
abstraction. With horror I remember some learn-to-program books I read
in my youth and which tried to talk about scope by talking about
wether a identifier is "valid" or something like this:
horrible. Talking about free variables and environments on the other
side makes it very easy to see which parts of an expression must get
"meaning" by being interpreted in some context (environment). I find
that rather useful.

Grasping the idea of a free variable (perhaps in an informal way) and
applying the ideas of environment(s) should take a reasonably bright
student hardly more than an hour (but I might be wrong).

Concerning your

> I don't understand the way were are taught lexical scope. Our
> professors used "environments", where free variable would suffice.
> (An environment is the set of defined values at a given time. The
> environment of a value is the environment of when this value is
> defined.)

-- I'd say that environment and free variables are "dual" or
complementary concepts. One is not useful without the other.

>From what you write, I'm not sure, the course (at Tolouse 3) you've
been talking about is just badly structured, wether the problem is at
yours or your brothers side or wether (I suggest to consider that) not
all students are as bright as you or your brother and therefore things
can get a bit repetitive. On the other side

> -> Where does this idea come from? I have not read a single book, as
> single article nor blog talking about environments.

I wonder that you have not heard about environments before. Perhaps
it's not your part yet to improve teaching in that area
:-). Nonetheless: If you have a suggestion how to talk about lexical
scope or the "meaning" of an expression without resorting to
environments, I'd be interested to hear more about it.

Regards -- Markus

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

[Loup Vaillant]

2007/3/28, ls-ocaml-developer-2006@m-e-leypold.de
<ls-ocaml-developer-2006@m-e-leypold.de>:
>
> "Loup Vaillant" <loup.vaillant@gmail.com> writes:
>
> > Personally, I think environments are about the implementation of
> > lexical scope, not  its specifications. Therefore, teaching them in
> > the first year of a programming course is premature. I may be wrong,
> > so I am trying to verify that.
>
> Personally I think you're wrong here. Environments (as mapping from
> identifier to values) represent the context in which a given
> expression must be read and interpreted (in both senses). I cannot
> imagine a way to do so precisely without using a similar
> abstraction. With horror I remember some learn-to-program books I read
> in my youth and which tried to talk about scope by talking about
> wether a identifier is "valid" or something like this:

Err, I didn't receive your quotation...

> horrible. Talking about free variables and environments on the other
> side makes it very easy to see which parts of an expression must get
> "meaning" by being interpreted in some context (environment). I find
> that rather useful.
>
> Grasping the idea of a free variable (perhaps in an informal way) and
> applying the ideas of environment(s) should take a reasonably bright
> student hardly more than an hour (but I might be wrong).
>
> Concerning your
>
> > I don't understand the way were are taught lexical scope. Our
> > professors used "environments", where free variable would suffice.
> > (An environment is the set of defined values at a given time. The
> > environment of a value is the environment of when this value is
> > defined.)
>
> -- I'd say that environment and free variables are "dual" or
> complementary concepts. One is not useful without the other.

I find the concept of free variable a bit more natural, and far less verbose.

> From what you write, I'm not sure, the course (at Toulouse 3) you've
> been talking about is just badly structured, whether the problem is at
> yours or your brothers side or whether (I suggest to consider that) not
> all students are as bright as you or your brother and therefore things
> can get a bit repetitive.

In my second year, I took a rather special course (IUP SI, for those
who know it). We students therefore came from different horizons, and
the vast majority has not been exposed to any functional language yet
(although many has been exposed to Pascal or C already).  In less than
two weeks, we almost covered the hole first semester of my first year
(not a single word about environments, however). It felt reasonably
fast, and no one was lagging behind.

> On the other side
>
> > -> Where does this idea come from? I have not read a single book, as
> > single article nor blog talking about environments.
>
> I wonder that you have not heard about environments before. Perhaps
> it's not your part yet to improve teaching in that area
> :-). Nonetheless: If you have a suggestion how to talk about lexical
> scope or the "meaning" of an expression without resorting to
> environments, I'd be interested to hear more about it.
>

Actually, I have. The first thing we see when learning Caml is the
interactive loop (Which I believe is a good thing). So we define
values one after the other. While we stick to a pure functional style,
a value (be it a function or not) never, ever change. The worse we can
do to it is to render it unaccessible, by defining a new value of the
same name. So, to explain this session:

#let a = 3;;
a: int = 3

#let f x = x + a;;
f: int -> int = <fun>

#f 5;;
-: int = 8

# let a = 451;;
a: int = 451

#f 5;;
-: int = 8

we just have to say: "As long as we do not redefine a value, it does
not change. The function 'f' didn't change, because it has not been
redefined. All happened as if the 'a' was replaced by its value at
that moment, '3', in the definition of 'f'."

Pretty harsh, I admit, but you get the idea. One can even explain that
the value is not redefined, just covered, if needed.

Better (I think) is to teach the notion of binding from the very
beginning, and draw a sharp distinction between values and symbols
(even if these notions are less crucial in ML than in Lisp). Then:
"Values never change, but symbols can be reassigned new values. So,
the function known as 'f' has not changed, even if the value know as
'a' in no longer '3'."

The notion of lexical scope become critical when we begin to have free
<and> mutable variables. From that point, I think one have no choice
(well, it is easier if students can understand the difference between
binding and assignment).

I just hope that any student can distinguish the name and the thing.

Regards,
Loup

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

[ls-ocaml-developer-2006]

"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>:
>>
>> "Loup Vaillant" <loup.vaillant@gmail.com> writes:
>>
>> > Personally, I think environments are about the implementation of
>> > lexical scope, not  its specifications. Therefore, teaching them in
>> > the first year of a programming course is premature. I may be wrong,
>> > so I am trying to verify that.
>>
>> Personally I think you're wrong here. Environments (as mapping from
>> identifier to values) represent the context in which a given
>> expression must be read and interpreted (in both senses). I cannot
>> imagine a way to do so precisely without using a similar
>> abstraction. With horror I remember some learn-to-program books I read
>> in my youth and which tried to talk about scope by talking about
>> wether a identifier is "valid" or something like this:
>
> Err, I didn't receive your quotation...

Not sure i know what you mean. If you mean "Which books are you
alluding to?" -- thankfully I've forgotten that. What is left is a
memory of really complicated attempts to explain scope and shadowing
(?) of indentifiers -- quite unnecessary if they had concentrated on
free variables first and then explained how "free variables" become
bound (by wrapping something around them that delivers a
environment). Instead there were really jumbled attempts to explain
when identifiers are "valid" and "invalid" or seomthing like
this. Never mind, the details don't matter -- what matters is, that my
conviction that scope can only be explained by introducing something
like an environment into the discussion stems from that experience.

>> horrible. Talking about free variables and environments on the other
>> side makes it very easy to see which parts of an expression must get
>> "meaning" by being interpreted in some context (environment). I find
>> that rather useful.
>>
>> Grasping the idea of a free variable (perhaps in an informal way) and
>> applying the ideas of environment(s) should take a reasonably bright
>> student hardly more than an hour (but I might be wrong).
>>
>> Concerning your
>>
>> > I don't understand the way were are taught lexical scope. Our
>> > professors used "environments", where free variable would suffice.
>> > (An environment is the set of defined values at a given time. The
>> > environment of a value is the environment of when this value is
>> > defined.)
>>
>> -- I'd say that environment and free variables are "dual" or
>> complementary concepts. One is not useful without the other.
>
> I find the concept of free variable a bit more natural, and far less verbose.

Free variables vs. environments are not alternatives. You need both.


>> From what you write, I'm not sure, the course (at Toulouse 3) you've
>> been talking about is just badly structured, whether the problem is at
>> yours or your brothers side or whether (I suggest to consider that) not
>> all students are as bright as you or your brother and therefore things
>> can get a bit repetitive.


> In my second year, I took a rather special course (IUP SI, for those
> who know it). We students therefore came from different horizons, and
> the vast majority has not been exposed to any functional language yet
> (although many has been exposed to Pascal or C already).  In less than
> two weeks, we almost covered the hole first semester of my first year
> (not a single word about environments, however). It felt reasonably
> fast, and no one was lagging behind.

Well -- they must have explained let and lambda/fun somehow: Even if
they didn't call it environment, there it was.

>> On the other side
>>
>> > -> Where does this idea come from? I have not read a single book, as
>> > single article nor blog talking about environments.
>>
>> I wonder that you have not heard about environments before. Perhaps
>> it's not your part yet to improve teaching in that area
>> :-). Nonetheless: If you have a suggestion how to talk about lexical
>> scope or the "meaning" of an expression without resorting to
>> environments, I'd be interested to hear more about it.


> Actually, I have. The first thing we see when learning Caml is the
> interactive loop (Which I believe is a good thing). 

I completely agree. :-)

> So we define
> values one after the other. While we stick to a pure functional style,
> a value (be it a function or not) never, ever change. 

Yes.

> The worse we can
> do to it is to render it unaccessible, by defining a new value of the
> same name. So, to explain this session:


>
> #let a = 3;;
> a: int = 3
>
> #let f x = x + a;;
> f: int -> int = <fun>
>
> #f 5;;
> -: int = 8
>
> # let a = 451;;
> a: int = 451
>
> #f 5;;
> -: int = 8
>
> we just have to say: "As long as we do not redefine a value, it does
> not change. The function 'f' didn't change, because it has not been
> redefined. All happened as if the 'a' was replaced by its value at
> that moment, '3', in the definition of 'f'."

It's the "value at this moment" which makes me a bit suspicious ...

> Pretty harsh, I admit, but you get the idea. One can even explain that
> the value is not redefined, just covered, if needed.
>
> Better (I think) is to teach the notion of binding from the very
> beginning, and draw a sharp distinction between values and symbols
> (even if these notions are less crucial in ML than in Lisp).

Exactly. Environments associate symbols with values :-).

> Then:
> "Values never change, but symbols can be reassigned new values. So,

No reassignment. Somehow you succeed to put really big holes in your
own concept. There is no "assigment" in purely functional: That would
be imperative. The Ocaml top level example is also a really bad one,
since every let produces a new envionment w/o that being obvious
syntactically. If you forget about the Ocaml top level for a moment,
there is no assigment: Expressions just get evaluated in different
environments. Like in

 let a = 5
 in 
   let f x = x * x * a
   in
      ((f 5), (f 8)

the x didn't "change" between the to calls to f, but the parameter
list of f was used to produce 2 different environments for both
evaluations from the definition environment of f. Exactly the same
happens in the Ocaml top level, only the implicit nesting introduced
after every toplevel let is not so obvious.

I find it really difficult to explain all this without coming up with
something like "environment".

> the function known as 'f' has not changed, even if the value know as
> 'a' in no longer '3'."

But 

> #let a = 3;;
> a: int = 3
>
> #let f x = x + a;;     [1]
> f: int -> int = <fun>
>
> #f 5;;
> -: int = 8
>
> # let a = 451;;
> a: int = 451
>
> #f 5;;                 [2]
> -: int = 8

... the 'a' in [1] is still '3' as evidenced by [2]. How do you
explain that without referring to the place / cirumstances (the
environment!) under which f has been defined?

> The notion of lexical scope become critical when we begin to have free
> <and> mutable variables. 

You unfortunately somewhat cryptic example illustrates (in my eyes)
that scope becomes critical even in the purely functional
case. Mutable only introduces a new concept: That of a (mutable)
memory location, a reference to which is bound to the identifier. That
makes scoping a bit more interesting since referential transparency
isn't working any more (i.e. w/o reference to a global state), but per
se has nothing to do with lexical scoping. IMHO.

> From that point, I think one have no choice (well, it is easier if
> students can understand the difference between binding and
> assignment).

> I just hope that any student can distinguish the name and the thing.

So do I :-). 

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). 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.

Regards -- Markus

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

[Loup Vaillant]

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: 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. 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. 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. Because it is, it looks silly. I don't like environments,
but you convinced me I haven't came up with a better  solution.

Regards,
Loup

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

[ls-ocaml-developer-2006]

"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

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

[Pierre-Evariste Dagand]

2007/3/28, Loup Vaillant <loup.vaillant@gmail.com>:
> So here are a few questions:
> -> Is lexical scope that important when learning pure functional programming?
> -> Are environments helpful (even the slightest bit) when teaching
> lexical scope?
> -> Where does this idea come from? I have not read a single book, as
> single article nor blog talking about environments.
> -> How can we teach lexical scope? Is there a simple solution, the
> kind of a first year student can understand in less than an hour?

You may find the answer to the 3rd question in Structure and
Interpretation of Computer Programs (Abelson, Sussman & Sussman), p.
236 : "The Environment Model of Evaluation".

In one word : Scheme.

-- 
Pierre-Evariste DAGAND

GPG Fingerprint [pgp.mit.edu] :
F8CC 61DD 40B7 933F 17CA  061F 5591 AAE6 D3EC 7357

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

[Pal-Kristian Engstad]

I've probably got the nomenclature wrong, but this is how I would 
explain it. I do think this is an advanced topic though - it definitely 
does not belong in an introductory programming course.

Caml, and many other languages, has the interesting concept of being 
able to create functions on-the-fly. That is to say, you can define an 
auxiliary helper-function within the function you are working on. This 
is a very powerful concept, because it allows you to re-factor code 
quite easily. Somewhere along the line, you see that: "Oh, I need to do 
.... another time, this time using variable ..." If this happens, you 
can simply create a sub-function within the function, and start using that.

Now, a function needs input parameters to work. However, it would be 
quite tedious to have to specify all the parameters for all your 
sub-functions. Therefore, Caml lets you use variables from the 
"outside", or the outer scope, as we say. An example:

# type env = { mutable scale : int; mutable offset : int };
type env = { scale : int; offset : int; }
# let work env a b =
    let linear x = env.scale * x + env.offset in
       linear a + linear b
;;
val work : env -> int -> int -> int = <fun>
#

As you can see in this contrived example, we introduced a new function 
linear, since we needed to use that calculation twice. But notice also 
that we did not specify the "env" variable as an input to linear. Thus, 
functions in OCaml are slightly more complicated than appears at first 
sight. Now, in OCaml it is also possible to return functions. For 
instance, we could change the above function to the following:

# let work' env =
    let linear x = env.scale * x + env.offset in
       (fun a b -> linear a + linear b)
;;
val work' : env -> int -> int -> int = <fun>

So, when you call "work' env", you get returned a function that adds 
together the results of the "linear" functions. [Note: For the observant 
reader, work' is actually the same function as work.].

Example:

# let env1 = { scale = 0; offset = 1 };;
val env1 : env = {scale = 0; offset = 1}
# let fun = work' env1;;
val fun : int -> int -> int = <fun>
# fun 1 2;;
- : int = 2
# env1.scale <- 1;;
- : unit = ()
# fun 1 2;;
- : int = 5

The first call to fun works, because: fun 1 2 = linear 1 + linear 2 = 
(env.scale * 1 + env.offset) + (env.scale * 2 + env.offset) = 
(0*1+1)+(0*2+1) = 2. But, in the second call to fun, the environment has 
changed, now env.scale is 1, so fun 1 2 = linear 1 + linear 2 = 
(1*1+1)+(1*2+1) = 5.

So, to conclude. For this to work, the function fun can not only depend 
on the input arguments. The function must retain a pointer to the 
environment that was used to create it. We call this a "closure". 
Scoping in this respect is important, because it tells us which external 
variables are captured by the function. This is cool, because it means 
that we don't have to use "function objects" (C++) or anything like that.

Flame on,

PKE.

Loup Vaillant wrote:
> My brother is currently learning Camllight at the Toulouse 3
> university, France. Five years ago, I followed the same course.
>
> I don't understand the way were are taught lexical scope. Our
> professors used "environments", where free variable would suffice.
> (An environment is the set of defined values at a given time. The
> environment of a value is the environment of when this value is
> defined.)
>
> -> They talk about closures, even in the case of pure functional
> style, even in the absence of free variable (except the built in
> constructions, such as '+').
> -> They take hours and hours of boring an silly looking exercises
> about environment, so we can understand how important environments
> are.(we even had to learn a specific syntax to talk about them).
> -> The promised power of the language is completely overlooked. Even
> the crippled Pascal on my calculator looked more powerful.
>
> Luckily, I had later a professor, who showed us the real power of
> Caml. He didn't talked about environments.
>
> So here are a few questions:
> -> Is lexical scope that important when learning pure functional 
> programming?
> -> Are environments helpful (even the slightest bit) when teaching
> lexical scope?
> -> Where does this idea come from? I have not read a single book, as
> single article nor blog talking about environments.
> -> How can we teach lexical scope? Is there a simple solution, the
> kind of a first year student can understand in less than an hour?
>
> Thanks,
> Loup
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

-- 
Pål-Kristian Engstad (engstad@naughtydog.com), Lead Programmer, ICE
team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
                       Jonathan Blow, 2/1/2006, GD Algo Mailing List