Re: [Caml-list] any way to "clear" the toplevel?

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
> Thu, 26 Apr 2001 10:05:02 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> pisze:
> 
> > The real solution would be to analyze dependencies between modules,
> > and only flush things that depend on a modified module. Promises
> > to be rather hard.
> 
> Glasgow Haskell Compiler 5.00 does this in its interactive toplevel.
> It maintains the dependency graph of loaded modules. Reloading
> checks time stamps and recompiles to in-memory bytecode or reloads
> object code of modules which changed or which depend on modules whose
> interface changed (or something like that).

As you have probably got to know by now, doing things automatically
for the user is very uncamlish. What I was talking about is in fact
even simpler than that: just trash modules that do not match their
signature anymore, and force the user to reload by hand all depending
code. It is not that hard, but of rather limited interest if you don't
go the full way to have automatic reloading also, like in GHC as you
say, and with SML/NJ's compilation manager also I suppose.

My next point was pointing at a more concrete problem, that you may
have to solve even if signatures did not change: values in ADT's.
Either you force ADT's to be different types everytime you reload a
module, which basically means all values whose type is related to an
ADT in the environment cannot be used anymore, or you need some very
clever tracing at the value level this time, and some way to know
whether the representation of an ADT changed or not. Hairy.
What is GHC doing about that? I suppose there is a way to represent
ADT's in Haskell. But I'm not sure whether you can define values at
toplevel, in the way you do in ML.
On this point Caml's policy at toplvel is unsafe: you can still use
all your values, and happily get core dumps. But this is much more
comfortable than flushing all values even when nothing was modified.

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr