Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] any way to "clear" the toplevel?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] any way to "clear" the toplevel?
From: Chris Hecker <checker@d6.com>

> I fixed this in my own toplevel by adding an #init.  Here's the code:
> 
> (* To init the toplevel env *)
> let _ = Hashtbl.add directive_table "init" (Directive_none
>                                               (fun () -> Env.reset_cache ();
>                                                 toplevel_env := Compile.initial_env()))
> 
> Just add that somewhere in toplevel/topdirs.ml and #init;; will
> clear out the environment.  It turns out the Env module's hash cache
> of the .cmi CRCs is what was preventing a reload of my file.  Not
> sure if that's a bug or not.

This is not a bug: if you don't cache you would have to reload the .cmi
everytime you try to access a module.

Indeed, I also get bitten by the problem you describe quite
frequently. Not that frequently because I mostly avoid the toplevel,
and this is one of the reasons to avoid it, the other being that
reloading (somehow) works only for very small projects.

Unfortunately, your solution is only partial: it is almost equivalent
to quitting and starting a new toplevel (which is my personal solution :-))
You do not only erase things that have changed, but just everything.
But it has the advantage of being very simple.

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.

Finally, I think you are stuck anyway by the static scope semantics:
what you probably would want to do is replace a module in the running
environment by its new version, witout recompiling everything else. ML
semantics do not allow that. That is, doing that would involve not
only tracing types, but also values created by a module.

To give you an idea of the problem, here is an example that breaks the
current toplevel at the value level:

test.mli:
type t
val put : int -> t
val get : t -> int

test.ml:
type t =int
let put x = x
let get x = x

test2.ml:
type t = int ref
let put x = ref x
let get x = !x

        Objective Caml version 3.01+1 (2001-04-19)

# #load"test.cmo";;
# let a = Test.put 3;;
val a : Test.t = <abstr>
# Test.get a;;
- : int = 3
# #load"test.cmo";;
# Test.get a;;
- : int = 3
(* rename test2.ml to test.ml and compile it *)
# #load"test.cmo";;
# Test.get a;;
Segmentation fault

Cheers,

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