From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA05312; Fri, 27 Apr 2001 02:54:25 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA05276 for ; Fri, 27 Apr 2001 02:54:24 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f3R0sM519156 for ; Fri, 27 Apr 2001 02:54:22 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id JAA20674; Fri, 27 Apr 2001 09:50:33 +0900 (JST) To: qrczak@knm.org.pl Cc: caml-list@inria.fr Subject: Re: [Caml-list] any way to "clear" the toplevel? In-Reply-To: References: <4.3.2.7.2.20010425165253.00e05ba0@shell16.ba.best.com> <20010426100502B.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010427095033Q.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 27 Apr 2001 09:50:33 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) > Thu, 26 Apr 2001 10:05:02 +0900, Jacques Garrigue 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