Re: [Caml-list] environment idiom

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

On Fri, 2004-12-10 at 21:52, Andrej Bauer wrote:

> All in all, I want to convey my experience: in sane programming
> languages it is ok to pass around arguments explicitly, even if it looks
> like there will be a lot of uncessary passing. In fact, this is an
> illusion. The language  forces you to organize your code neatly and you
> will end up passing just the right things to just the right functions.

IMHO the issue is not whether to pass arguments explicitly,
there is clearly no alternative. The question is how
to organise them.

For example you can use several actual arguments, but
at some point there are too many for sanity and
you need to, for example, pass a smaller number
of records.

However this provides no abstraction.

> Perhaps one piece of information that you want to pass around, and is
> not stored in the object describing the cgi request, is database info.
> You want to know what database you're connected to. Since my application
> is not multi-threaded, I cheated and used a global variable for that.

Hah -- at least you're admitting you cheated -- LOL!
So how would you fix this?

> In my experience, you should always pass precisely the arguments a given
> function needs, and no others. 

IMHO you are almost right but not quite. The reason is
that code gets changed.

If you pass exactly the arguments needed, your calls
would be very long winded and even a minor change
in implementation details or code structure would
propagate to every caller, direct or indirect,
of that function.

So that isn't even a marginally viable option
in an unstable code base, and in a stable one
information hiding serves no purpose.

Instead of 'precisely', change the requirement
to 'roughly'. What does that mean? It means you need
to factor your argument sets so you pass precisely
the argument classes needed by each function,
even if the function doesn't need all the members
of each set.

Now if you make a detail change to the code,
you have a *buffer* of 'a few extra arguments
you might or might not need when you change the code'
which will dampen the propagation shock wave caused
by a small reorganisation.

The 'classic' example of this affecting a massive
number of programs and programmers is the
const-propagation phenomena in C/C++ when you take
a program not using 'const' typing, and try
to adapt it to provide the extra type safety
'const' makes available.

Doing this was made mandatory by the ISO C committee,
since they decided that some library functions
should be const exact -- in particular return
const pointers where previously only non-const
ones were returned.

Modularity, then, provides some protection
against this. 'Correct' structure is not
something you can determine for an unstable
code base. If you could, that would be an admission
the requirements were stable. (In that case
there is no point refactoring the code to make
it prettier.. unless you are just researching
or intend to publish it ..)

I'll add my data point: in the Felix compiler
I used to pass individual arguments around.
However the lookup in particular consists
of a large number of mutually recursive
functions all with slightly different
needs, which are the sum of both what they
need, but also any function they call .. 
and worse, they're combined with 'let rec'
which is basically not expressive enough to
reflect the true call graph (but the alternatives
such as open recursion have other problems
like adding to the number of parameters ..)

I did three things to try to fix this. 
(1) I grouped some of the data into a record
(2) I forward defined a couple of functions at
    the expense of passing extra arguments.
(3) I simplified the requirements in one case,
   and totally dropped a whole section of
   functionality

The current situation is still FAR from satisfactory however.
most of the function require about 10 arguments -- still
too many. The *problem* is that i AM calling the functions
with 'exactly the required number of arguments* and it
makes changing the code very hard.

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