Re: [Caml-list] The Bytecode Interpreter...

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

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