From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 3C7BDBB81 for ; Mon, 24 Oct 2005 08:13:34 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9O6DW8Y007413 for ; Mon, 24 Oct 2005 08:13:33 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j9O6DEZL014424; Mon, 24 Oct 2005 15:13:14 +0900 (JST) Date: Mon, 24 Oct 2005 15:13:12 +0900 (JST) Message-Id: <20051024.151312.52118628.garrigue@math.nagoya-u.ac.jp> To: jonathan.roewen@gmail.com Cc: info@gerd-stolpmann.de, caml-list@yquem.inria.fr Subject: Re: [Caml-list] The Bytecode Interpreter... From: Jacques Garrigue In-Reply-To: References: <1130062899.27787.126.camel@localhost.localdomain> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 435C7B8C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bytecode:01 toploop:01 toploop:01 compiler:01 cmi:01 toplevel:01 interacts:01 cmi:01 toplevel:01 bytecode:01 dynlink:01 dynlink:01 dlopen:01 dlopen:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE autolearn=disabled version=3.0.3 > > When one #loads within a toploop, more or less the same happens. > > However, the toploop is a full compiler, and does not only have the > > symbol table, but also the current environment, i.e. the set of > > currently visible types and values with the still-needed parts of their > > definitions. As far as I know, #load does not modify the environment > > (because nothing changes - the loaded modules are already in scope when > > the .cmi file is in the search path). This is true that #load itself does nothing to the typing environment, but there is probably a slightly confusing point in that the toplevel has a not completely static view of its environment. Namely, it interacts lazily with the filesystem. As a result, the type of a unit is only fixed the first time its .cmi is loaded. So the toplevel lets you do strange things such as generating code and loading it on the fly: you just need to make sure you generate new file names. This does not negate your point: the toplevel sees its typing environment as immutable (outside of direct input), and it has no way to know that any module on the disk is "new". > Yes, but the bytecode itself is not in the environment, or at least > not initialised, hence why you need the #load right? Try using Str > module for instance. Symbols in memory, but that's it. Sure, but the point is that any code accessing a unit does it assuming an immutable type for it, that can be verified when loading the bytecode. Note that one can do this with Dynlink too: if you load unit A with dynlink, and unit B later, then unit B can refer to values in unit A. The only thing the linker doesn't let you do, is to have code that refers to values that are not yet loaded. And this is true both in the toplevel and with Dynlink. > Anyways, my next question is: does the toplevel need dlopen & friends? > I know dynlink module would, as you stated, it performs relocation and > all that other stuff. Yes, sure, it does something similar to dlopen on bytecode. You can just see the code in topdirs.ml. Jacques Garrigue