[Omake] Type dependencies

Jason Hickey jyh at cs.caltech.edu
Mon Mar 13 10:27:11 PST 2006


While looking into this smarter command-line parsing, I ran into the 
usual problem with circular type dependencies.  In this particular case, 
it is because commands need to be represented as pipelines (instead of 
string lists).  The pipelines are defined in Omake_shell_type, which 
depends on Omake_env, but Omake_env needs the definition.

This issue comes up a lot.  The way we "solve" it now is one of two ways:
    - make the types polymorphic over 'value, then instantiate them
      in Omake_env
    - move all their code into Omake_env
This means Omake_env gets loaded with a lot of stuff.

The root of all this trouble is that the type venv is abstract, as it 
should be.  But it means we can't just define all the types before 
defining all the code, and so we get highly-constrained compile 
dependencies.

I don't know of a good solution to this problem.  There are some 
not-quite-satisfying ones:
    1. Make the type venv public, and tell programmers not to use it
       directly.
    2. Keep it abstract, but define a bunch of constructors/destructors.
       This is basically the same as making it public.
    3. Define a "unpack_venv_hack : venv -> venv_internal = %identity"
       so we can grep for occurrences.
    4. Keep on using our current scheme, and allow Omake_env to
       keep growing as we add unrelated stuff to it.

Perhaps there is another way?

One other proposal might be to functorize all the circularly-defined 
modules, then wrap them up in a fixpoint later.  This is probably the 
most correct, and most complicated approach.

Jason

-- 
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257


More information about the OMake-Devel mailing list