proposal of true fuctional module loading

Marcin 'Qrczak' Kowalczyk
30 Apr 2001 20:59:41 GMT

Sat, 28 Apr 2001 14:52:06 +0400, S.D.Mechveliani <> pisze:

> 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

I guess that moving internals of the whole compiler to libraries
would be a large task. They are tons of interdependent modules.
Representation of various intermediate forms is complex.

Including the compiler in a user program would make it as big as
ghc itself.

There is no chance to make this interface functional. Many stages
perform IO.

>   env :: Env  keep all the interface modules and the code modules,

They must be loaded on demand. It's impractical to load all interfaces
of the world before seeing which will be needed.

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

Making it light implies implementing an interpreter from scratch.
ghc is not light.

> This is  not  extending the language, only the library.

The interpreted world and the interpreting world are very different.
Making them interoperate smoothly is not just a library. There are
typing issues, module issues. It can't be simple. Haskell is not Lisp.

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

It's way too heavy for these tasks.

Don't confuse types used in the program with kinds of values the
program operates on. If you want to write Derive or Mathematica in
Haskell, go on, but it won't work to represent runtime values by
compile time types.

Static typing is great when it works, but not everything can be
expressed by different types.

 __("<  Marcin Kowalczyk *
  ^^                      SYGNATURA ZASTĘPCZA