[MLton] MLB path variables and path maps

[Stephen Weeks]

I am intrigued by the idea of defining MLB path variables inside MLBs.
However, I am leery of building a complex solution to a simple
problem.  I think it would be worthwhile to step back and ask
ourselves what is the problem that MLB path variables are intended to
solve.  I asked myself and I didn't have good answer, so I re-read all
the discussions we've had on MLBs to get a feel for the origin and
history of path variables.  I've included the history below for those
who are interested.

The upshot of my study is that, as far as I can tell, MLB path
variables exist for a sole simple purpose: to refer to standard
libraries in MLB files without using hardwired absolute paths.  MLB
path maps (and ~/.mlton/mlb-path-map) are there to provide the user a
convenient way to refer to their own libraries in MLB files without
using hardwired absolute paths.

Given this very simple purpose, I'm not convinced of the need for a
more complex mechanism in which path variables are defined in MLB
files.  It may be that such a mechanism would solve some other problem
-- I think it would be worth articulating that problem before
attempting a solution.


----------------------------------------------------------------------
History of MLBs and MLB Path Variables
----------------------------------------------------------------------

The genesis of MLBs is the July 2003 thread "A CM replacement for
MLton".  The original proposal suggested MLB path variables based on
environment variables to avoid the use of hardwired absolute paths.

  http://mlton.org/pipermail/mlton/2003-July/023952.html

  Using a hardwired absolute path like /usr/lib/mlton is bad.  So, I
  propose to allow environment variables to appear in path names in
  the form $(VAR).  MLton will ensure that the following variable is
  always set correctly:

  SML_LIB = /usr/lib/mlton/basis-library

  So, the user can access the basis library by $(SML_BASIS)/2002.mlb

Henry proposed in a followup to avoid using environment variables.

  http://mlton.org/pipermail/mlton/2003-July/023976.html

  I tend to dislike using the environment because of its completely
  flat unstructured name space.  A modification would be to have
  variables for our system, which would communicate from parent .mlb
  files to child .mlb files, and then to have an option which would
  set a .mlb variable from the environment.

Amusingly enough, this is similar to Vesa's recent proposal.

Not much happened with MLBs until March 2004, when Martin Elsman
joined the MLton list and mentioned wanting something like them for
the ML Kit.  See the "mlb files and the ML Kit" thread.

  http://mlton.org/pipermail/mlton/2004-March/025181.html

Finally, in June 2004, Matthew started implementing MLBs.  See the
"mlb support" thread.

  http://mlton.org/pipermail/mlton/2004-June/025463.html

He immediately noticed the need for annotations, which we designed the
syntax for.  Matthew also cleaned up the semantics and tex'ed it at
this point.  There was further discussion in July to clarify some
issues, and Matthew finished the implementation.  MLBs were added to
the repository on July 28, 2004.

In August 2004, we added support for ~/.mlton/mlb-path-map in the "the
next public release" thread

  http://mlton.org/pipermail/mlton/2004-August/025707.html

Matthew:

  Also, looking forward to future libraries, I'm wondering if SML_LIB
  is the best name for the root, and where should it be initialized.
  Right now, it's set in the mlton script.  Should we provide a
  convenient way for users to add additional environment variables,
  without polluting their process environement?; for example, we could
  read in a $(HOME)/.mlton-env file with user specific
  environment/path pairs.

Stephen:

  This sounds good to me.  I agree with you and with Henry that using
  a file is better than polluting the process env.  I wonder if we
  should call the file .mlton, or possibly even have a .mlton/
  directory, with an eye toward future extensions.

MLB's haven't changed much since then.