[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