proposal of true fuctional module loading
Sat, 28 Apr 2001 14:52:06 +0400
This may sound strange, but
could Haskell think of supporting a true functional module loading?
As the interactive systems exist, with interactive loading, and so
on, maybe, it can be provided a library of Haskell functions:
compile :: Env -> SrcModule -> (Interface, CodeModule)
parse :: Env -> CodeModule -> String -> Expression
load :: Env -> CodeModule -> Env
evaluate :: Env -> CodeModule -> Expression -> Expression
- something like this.
all the code be interpreted (so far),
env :: Env keep all the interface modules and the code modules,
(parse env md str)
returns the value of the type which the compiler would assign
to the data read from str, under the given program scope
The idea is to enable a regular user's Haskell program to create a
source program md :: SrcModule (not a file), compile it
(lightly, as, for example, in Hugs-98) to interpreted code and load
- under (and to) the accumulated total program env :: Env.
env, md are the explicit variables in the user program, and no side
`parse', `evaluate' may use the built-in compiler and interpreter.
This is something like Hugs interactive system given to the user
in the form of the library functions, with the explicit variables
and arguments to hold the values of environment and program code.
This is not extending the language, only the library.
The aim is to enable the user program to create at the run-time new
algebraic domains in the form of types and instances contained in
new source and code modules.
The type resolution remains static, but becomes (I am sorry)
dynamic at the new level.
This is another alternative to the
sample argument approach - disliked by many,
dependent types language extension - concerning a language and
to have problems of it own.
the user program can `load' the domains
(modules with types and instances) P_1 .. P_n
of integer polynomials in variables
[x1], [x1,x2], [x1,x2,x3], ..., [x1..xn]
respectively and compute the needed things, say, 5 minutes in each
domain, while the compilation and loading of P_i will need a
couple of seconds. Also the new loaded and interpreted code may
refer to the compiled library, like it is done in ghc-5.00.
Here n is a variable; it is not known statically how many P_i
will suffice to solve a task. Also the domains P_i have different
properties and even should have different instances, and it is not
good to pile them in one type.
This concerns the same old discussion thread about possibility to
create dynamically, say, the domains of Integer modulo different
m = 2,3,...
Can the Haskell library take a step in this direction?
In some term rewriting logical systems, like Maude,
the `programs' have rich type system (types are called `sorts'), but
still are the first class data (in meta-coding), can be created with
the usual data constructors and then, meta-applied.
But there, I suppose, there is no `loading'. Because Maude has a
particular `import' notion, which is not likely to be supported by