English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
How must we teach lexical scope?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-03-28 (17:09)
From: Loup Vaillant <loup.vaillant@g...>
Subject: Re: [Caml-list] How must we teach lexical scope?
2007/3/28, 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.