Re: [Caml-list] environment idiom

[skaller <skaller@users.sourceforge.net>]

On Fri, 2004-12-10 at 10:11, Jacques Garrigue wrote:

> But you're right that in practice global variables are in general
> sufficient to solve this problem, and they are often used in ocaml for
> that. They have of course one disadvantage: they are not reentrant.

Yes but global/local is a relative thing in sane languages
like Ocaml which support nested scopes. One might even
say it is one of *the* fundamental software engineering
design problems, to try to make variables as local
as possible without pointless explicit passing.

Since software changes, this may not be the theoretically
optimal position.

A simple example is an array search in C where the loop variable
needs to be external to the loop to actually return the desired
result. For Ocaml I find often, I have repeated code handling
match cases which share variables and that when I lifted the 
common code into a subroutine, I often want to make it
slightly more global than the scope containing the match,
and in doing so I have to now explicitly pass extra variables.

I often don't actually know what they are -- the compiler
reports unbound variables and I add paramaters until it
compiles, thus discovering something previously hidden.

Occasionally this procedure fails .. in one case I had
used the common Ocaml trick of hiding a more global variable
with a more local one .. and in lifting the code outside
the scope of the local one but still within the scope
of the more global one, I inadvertantly changed the
semantics of the code without breaking it, as my lifting
procedure required.. that bug took hours to find.

The lack of re-entrany Jacques mentions is thus not
limited to absolutely global variables as in C statics.
It not only applies to *all* variables in functional
languages .. it is particularly applicable in Ocaml
which is not referentially transparent.

One final point of some interest is that even 
'absolutely' global variables may not be.
In Pascal, globals are actually just elements
of the deepest stack frame. In Posix C,
some variables can be designated thread local,
such as 'errno'. In Felix, all globals may be
microthread local, since they're collected into
a single struct which is passed explicitly
to all functions or stored in a C static,
depending on a compilation time switch.
I guess in Haskell with monads, global
has yet another meaning, as indeed it does
in with classes in OO languages, which provide explicit 
object construction.

I would argue that data and code are categorical
duals concepts, and localistion is *the* principal
engineering issue of software design. Indeed,
it is central to lambda calculus where 
lambda abstraction is the fundamental operation,
and is nothing more than a way of moving between
a local and global variable -- here the relativity
of the local/global distinction in manifest directly
as a fundamental principle.

Indeed one may say 'languages' lacking abstraction,
such as C, aren't even candidates for consideration
as 'programming' languages -- because it is impossible
to exercise the very design judgements a programmer
must make about locality.

Interestingly, I think Object Orientation -- which as
a complete paradigm I despise -- has made one of the
most important steps forward in language design.
This is because it provides a second construction
for expressing localisation which expands considerably
the programmers choices compared to the localisation
available merely from lambda abstraction (ie. function
closures/stack frames). This is because it allows
one to localise *code* with groups of data, whereas
closures allow one to localise data within a code
structure -- so given the duality of code and
data this capability seems somehow fundamental.

The fact that in Ocaml these two dual constructions
are not syntactically symmetric is an indication
of how poorly this duality is understood.
Compared to functions/lexical scoping classes
in Ocaml seem too 'heavy' -- I think I mean
that the simplicity of changing the the locality
of variables with functions is not present with
classes .. but I don't understand how locality
could be better represented: Ocaml inheritance
is somehow just tricky sugar instead of being
fundamental, as the duality principle says
it should be.

BTW: I think it is a fault to emphasise entirely the
typing theory, which somehow seems more advanced
than the theory of that which it is typing!

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net