[mercury-users] Problem with mmake

[Richard A. O'Keefe]

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

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

	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.

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.

In the old days, the possibility of choking the UNIX environment was a
very real one, and for DOS and Windows it was _certain_ that having more
than a very few environment variables was not going to work well.

That's not a problem these days.  Complexity and convenience for people ARE.
A quick check turned up fourteen MERCURY_ environment variables:
MERCURY_ALL_C_INCL_DIRS MERCURY_ALL_MC_INCL_DIRS MERCURY_C_INCL_DIR
MERCURY_COMPILER MERCURY_DEBUGGER_INT MERCURY_DEFAULT_GRADE
MERCURY_INT_DIR MERCURY_INTERPRETER MERCURY_MKINIT MERCURY_MOD_LIB_DIR
MERCURY_MOD_LIB_MODS MERCURY_NC_BUILTIN MERCURY_NONSHARED_LIB_DIR
MERCURY_OPTIONS.  No, wait a minute, I missed some!

And that's the point, really.  Only a mother could love an interface this
complex.

Netscape gets by with one.

Tcl/Tk gets by with two: one for Tcl and one for Tk.

O'Caml technically has two, but you only ever need to deal with one,
 and that seldom.

The only environment variables I can find in the GHC 4.08 documentation
are the three that PVM requires, and that only applies if you run Parallel
Haskell, which I don't.

HBC has one environment variable, needed only if you couldn't install stuff
in /usr/local.

Clean requires one directory to be added to LD_LIBRARY_PATH.

Java requires two variables: CLASSPATH and JAVA_COMPILER.

SPARK (verifiable Ada) requires six; two of those are for the underlying
Pop-11 system.  I recall thinking that a single variable (with the root
of the installation) could have served for all of them.

Erlang has one for the compiler (and you don't need to set it normally),
none for the runtime.

The record on my system is actually OpenWindows/Common DeskTop, which
has about 19 variables.  It's not surprising, really, that I have never
dared to change much, nor that it never seems to have been configured
_quite_ correctly.

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.

One problem with a "who cares how many environment variables there are"
approach is that environment variables start to proliferate.  Another
problem is that a configuration language is "happening" rather than being
designed.

	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?  You're teasing, right?


		in your style files and then using `source my-style-file.style' from the shell
		
	when appropriate.  E.g. 
	
		sh -c 'source foo.style; ./foo'
	
This has *got* to be a joke.

	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*.  Because of the GC_stackbottom/GC_stack_bottom clash,
I've had to muck around with MERCURY_OPTIONS, and no, you *can't* selectively
override a single configuration setting.

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.  One would follow either the SGML rule that earlier
definitions override later ones, or the shell rule that later definitions
override earlier ones.

	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*.  It is not obvious to me that this is
true; it certainly hasn't been even remotely like my experience with Mercury
so far.

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.

I'd post it, if I thought it would ever be useful.  Because I *don't* think
it would be useful, I don't actually see any force in this objection.

	How do Quintus Prolog and GHC tell which options are for the run-time
	system and which are for the application?
	
GHC hasically reserved *one* special flag:

    yourprog +RTS ((options for GHC library)) -RTS ((options for yourprog))

As for Quintus Prolog, I had as little influence over some aspects of QP
as I have over Mercury.  Quintus Prolog had *far* too many environment
variables.  The technique I'm about to describe was used for saved states,
not standalone executables.

    prolog ((Quintus options)) +z ((options for yourprog))

You normally hid the runtime options by using a shell script or alias,
e.g.
	alias myprog 'prolog +l myprog +z'

You only actually needed a +z option in the command line if you had any
options beginning with + signs; all the QP runtime options began with +.

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