[mercury-users] Problem with mmake

[Fergus Henderson]

On 05-Jun-2001, Richard A. O'Keefe <ok at atlas.otago.ac.nz> wrote:
> Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > I'm sorry, I'm still having trouble understanding why
> > minimizing the number of environment variables would be
> > an improvement.
> 	
> I can explain it in two words.
> c o m p l e x i t y
> c o n v e n i e n c e

I'm afraid I remain unenlightened.

I don't see how changing N environment variables into N configuration file
commands would reduce complexity.  I also remain unconvinced that it would
increase convenience.

At the implementation level I think it might well *increase* complexity.
Environment variables are very easy to access from shell scripts.
Any other mechanism is likely to be more complex.

(Hmm... I guess we could use configuration files in shell syntax,
and parse them using the shell's source command (`.' in Bourne shell).
That would be simple enough.  But I'm still not convinced that doing
this would be worth the hassle that such a change would entail.)

> The mechanism is already groaning in every joint with some variables
> having more-or-less simple values and other variables having structured
> values (complete with rather pointless, given the context, double dashes).

For the Mercury runtime system we use the getopt_long() routine
to parse the runtime options.  It seemed pointless to invent a new
options syntax and to write a parser for it, just because we were
passing options via an environment variable rather than on the command line.

> > I understand why you should use a hopefully unique prefix
> > (e.g. `MERCURY_' for the University of Melbourne Mercury implementation)
> > on your environment variable names, to avoid name clashes.
> > But I don't understand what is special about the number one that makes
> > it the best number of environment variables.
> 	
> It is the simplest thing that can possibly work.
> Amongst other things, if I want to flip from one configuration to
> another, there is *ONE* thing to change; there is no possibility
> of an "incomplete edit" leaving me part way between two configurations.

OK, that is one thing that would be more convenient with the approach
that you suggest.

But the drawback of your approach is that changing a single configuration
parameter while leaving the others unchanged is more difficult.
And that is in my experience a significantly more common operation.

> I am really confused that anyone would find this a difficult concept to
> grasp.  The more knobs there are, and the more places they are, the harder
> it is to get them right.

But we're not talking about reducing the number of nobs,
or even about reducing the number of places where they are,
just about moving them!

> A quick check turned up fourteen MERCURY_ environment variables:
...
> Netscape gets by with one.

I don't think counting the number of environment variables
is always the best way to measure complexity.
Netscape probably has more than fourteen different configuration files,
each of which contain many different configuration settings.
I don't think that changing environment variables into configuration
commands will by itself reduce complexity, unless you choose to
measure complexity simply be the number of environment variables.

> As for the claim that having so many environment variables makes it easy
> to change just part of the setup, take a look at MERCURY_OPTIONS and I think
> that claim will be withdrawn.  With MERCURY_OPTIONS, Mercury is already a
> little bit pregnant, and might as well go all the way to parturition,
> bringing forth a clean "one variable points to a complete configuration"
> approach.

You're right that there are two approaches taken in the Mercury implementation,
one used by the runtime system, and one used by the remainder of the
development environment.  That has arisen mainly as a result of the way
way they were each implemented.

But the Mercury runtime system's use of MERCURY_OPTIONS isn't an example of
the "one variable *points to* a complete configuration" approach.
Rather, it is a "one variable *contains* a complete configuration" approach.

This is actually a quite significant difference, because this approach
makes it much easier to selectively override individual seetings.
It is common to use a shell construct such as

	MERCURY_OPTIONS="$MERCURY_OPTIONS <some new options>"

to retain the previous settings and selectively override just one.
Indeed, in my experience that is *much more common* than overriding
the entire MERCURY_OPTIONS unconditionally.

Another approach which is about half way between what you are proposing
and what we use with MERCURY_OPTIONS would be to have a single environment
variable which contains that contained a *list* of configuration files.
That would allow you to selectively override individual options,
by using e.g.

	MERCURY_CONFIG="$MERCURY_CONFIG myconfigfile"

However, if you just want to override one option, it would still be less
convenient to do it that way, since you'd have to create a separate
configuration file just for that one option.

> > If you want to set up "style" files, you can do it by putting
> > 
> > 	MERCURY_FOO=foo
> > 	export MERCURY_FOO
> > 
> > 	MERCURY_BAR=bar
> > 	export MERCURY_BAR
> > 
> > 	...
> 
> MORE environment variables?

No, the FOO and BAR here are meta-variables; by "MERCURY_FOO" I mean
any of the MERCURY_* variables previously referred to.

> > However, if you have configuration files, and a single environment variable
> > which points to the current configuration file, then there's no easy way to
> > selectively override a single configuration setting and keep the remaining
> > settings unchanged.
> 
> There isn't *NOW*.  [...]
> I've had to muck around with MERCURY_OPTIONS, and no, you *can't* selectively
> override a single configuration setting.

It *is* possible to override a single configuration setting selectively
using MERCURY_OPTIONS, as explained above.

> The claim that pointing-to-configuration-files would mean that there would
> be "no easy way to selectively override a single configuration setting" is,
> as I explained in a previous message, simply false.  That's what a "source"
> mechanism is for.

That doesn't work, as I explained, because you don't know the name of
the previous configuration file to source:

> > The problem is that overriding the environment variable
> > discards to name of the previous configuration file.  To just override one
> > setting, you need to do something like creating a new configuration file
> > on-the-fly, which first includes the config file referred to in the
> > old setting of the environment variable and then overrides the one setting
> > you want to change, and then make the environment variable point to the
> > configuration file that you created on the fly.
> 	
> You are assuming that it is common to twiddle one configuration parameter
> *in a way you'll never want again*.

No, just in a way that preserves the rest of the current environmen's
configuration parameter settings, whatever that environment is.

> In the unlikely event that this *shold* be common practice in the Mercury
> world, I have now spent the last 20 minutes writing and testing a UNIX
> utility
>     setvar variable value command...
> that creates a temporary file, copies $CONFIG (if that exists) or
> ~/.config (if that exists) to it, adds
> 	export variable; variable="value"
> _with_ appropriate backslashes in "value", runs command, and then deletes
> the temporary file.  It took just 70 SLOC.  I don't call that hard.

Now *you're* kidding *me*, right? ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------