Version française
Home     About     Download     Resources     Contact us    
Browse thread
Best way to choose an implementation of a lib ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] How to compile different implementations of the same lib
On Thu, 2005-12-01 at 20:09 +0000, Richard Jones wrote:

> I don't quite understand this.  I get that if the .cmx isn't
> available, then one obviously cannot inline the code.  But why is it
> that you cannot use a simple call instruction even if the .cmx isn't
> available?

A function is not a piece of code. It is a piece of code
plus an object which together are called a closure. 
The object represents the environment.

It is probably easier to understand the Felix representation:
a function is a C++ class with an apply method. The class
has other members -- local variables of the function, and
a pointer to local variables of the function containing it .. etc.

This object is allocated on the heap.

For example:

	let f x = 
 		let g y = x + y
		g
	;;
	g 42
	;;

here, when you call f x, you get back g. But g is not just
a piece of code -- g remembers 42 somehow :)

Closures are required to implement lexical scoping,
and are what makes it possible to remember the environment
as in the case above -- that is, to provide first class
lexically scoped functions.

Actually I think ML and Ocaml have poor design here.
Ocaml allows:

	let x = 1;;
	let f y = y + x;;

So that top level functions (a) may still have an environment
such as 'x' above, and (b) f itself is initialised at start
up to refer to the environment.

It would be more correct IMHO to ban variables from the top
level and allow only functions, and, instantiate the
functions when they're used. If Ocaml did that, it would
ONLY need the code pointer. (Felix has the same problem,
but I think of a 'library' statement which bans global
scope variables and a 'program' statement which permits
them).

Note that failure to do (a) also plagues C/C++ and has
a high cost -- dynamic linkage of 'static' data is 
very expensive, nasty, and doesn't really work on
most platforms, and, it interferes with re-entrancy,
which is the principal requirement for thread safety.

This mess because actually .. even in C/C++ functions
are closures.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net