Best way to choose an implementation of a lib ?

Best way to choose an implementation of a lib ?

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]


Let say I want two distribute two(or more) implementations of a library
with the .mli for all ...

Is there a way to choose the implementation at link time ?

Lets say I have a.mli compiled to a.cmi and a1.ml and a2.ml

I think (did not test) that putting the cmos in separate directory as
a1/a.cmo and a2/a.cmo should allow the choice using the -I option ...

Any better solution (no dynlink, I want also native code) ?

Thanks




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [Caml-list] Best way to choose an implementation of a lib ?

[Jacques Garrigue]

From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>

> Let say I want two distribute two(or more) implementations of a library
> with the .mli for all ...
> 
> Is there a way to choose the implementation at link time ?
> 
> Lets say I have a.mli compiled to a.cmi and a1.ml and a2.ml
> 
> I think (did not test) that putting the cmos in separate directory as
> a1/a.cmo and a2/a.cmo should allow the choice using the -I option ...
> 
> Any better solution (no dynlink, I want also native code) ?

Directories seem a possible solution.
Note that with native code you must be careful to compile without any
.cmx around (only .cmi's), as this would induce dependencies on a
specific version. This also means that you lose inlining (one major
advantage of native code.)

An alternative to distinct directories is to create libraries (.cma/.cmxa).
You could name them a1.cma and a2.cma, and link choosing either one.
Libraries are only used at link time, so their names are not
hard-coded. This solution has exactly the same pitfalls with native code.

Note that ocaml itself does something similar for vmthreads.
Distinct libraries for stdlib.cma and unix.cma are installed in a
distinct directory, but the .cmi's are not duplicated.
This library is bytecode only.

Jacques Garrigue

How to compile different implementations of the same lib

[Daniel Bünzli]

Le 30 nov. 05 à 13:19, Jacques Garrigue a écrit :

> Note that with native code you must be careful to compile without any
> .cmx around (only .cmi's), as this would induce dependencies on a
> specific version. This also means that you lose inlining (one major
> advantage of native code.)

I don't understand this. Careful to compile what without which cmx  
around ? And where do you lose inlining ?

I recently got into the same kind of situation and I couldn't solve  
it. So I'm seeking advice on how to solve the following the best way.  
I want to give the choice between three implementation of a library  
lib (which also calls C) in both byte and native code.

1. A debugging version compiled with -g, libdebug.cm(x)a.
2. A normal version, lib.cm(x)a
3. An unsafe version compiled with -unsafe and with some validation  
of input parameters removed, libunsafe.cm(x)a.

The input parameter validation code is centralized in a module Check.  
This module has two implementation : one with the actual checks, and  
the other with dumb checks equal to unit. Functions of the library  
are implemented with this idiom :

let f x = Check.arg x; ...

The idea is to compile the unsafe version with the dumb  
implementation of Check and that the optimizer will remove the calls  
to the validation functions.

My questions are,

1. Is it possible for all versions of this library to share the same  
cmi interfaces ? When I tried to do this, I got these inconsistent  
assumption errors.

2. For the unsafe version, will the calls to the Check functions be  
removed by the optimizer ? My understanding is that they will but  
only for native code compilation, i.e. libunsafe.cmxa. In  
libunsafe.cma we will still have the function call overhead.

Thanks for your help,

Daniel

Re: [Caml-list] How to compile different implementations of the same lib

[Daniel Bünzli]

Le 30 nov. 05 à 15:38, Daniel Bünzli a écrit :

> Le 30 nov. 05 à 13:19, Jacques Garrigue a écrit :
>
>> Note that with native code you must be careful to compile without any
>> .cmx around (only .cmi's), as this would induce dependencies on a
>> specific version. This also means that you lose inlining (one major
>> advantage of native code.)
>
> I don't understand this. Careful to compile what without which cmx  
> around ? And where do you lose inlining ?

Now I think I understand this. You mean when you compile client code  
client.ml against the library. Then functions from the lib will not  
be inlined in client code. This allows to switch implementations of  
the library without recompiling client.ml. More precisely, if you  
statically link with the lib you only need to relink and if you  
dynamically link you don't even need to do anything, you can just  
play with CAML_LD_LIBRARY_PATH. Right ?

Daniel

how to detect .cmx incompatibility

[Stefano Zacchiroli]

On Wed, Nov 30, 2005 at 09:19:30PM +0900, Jacques Garrigue wrote:
> Directories seem a possible solution.
> Note that with native code you must be careful to compile without any
> .cmx around (only .cmi's), as this would induce dependencies on a
> specific version. This also means that you lose inlining (one major
> advantage of native code.)

On this subject, is there a way to look at two .cmx and decide whether
they link against a common module, but make different assumption about
its implementation?

With .cmos this is possible using the "objinfo" tool, but it does not
work on .cmx ....

TIA,
Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

Re: [Caml-list] Best way to choose an implementation of a lib ?

[Eric Cooper]

On Wed, Nov 30, 2005 at 09:19:30PM +0900, Jacques Garrigue wrote:
> From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
> 
> > Let say I want two distribute two(or more) implementations of a library
> > with the .mli for all ...
> > 
> > Is there a way to choose the implementation at link time ?
> > [...]
> 
> Directories seem a possible solution.
> [...] 
> An alternative to distinct directories is to create libraries (.cma/.cmxa).

And yet another is to use symbolic links, for example
    a.ml -> a_optimized_impl.ml
or
    a.ml -> a_reference_impl.ml

(Note that when using "make", you have to be careful about stale
object files after switching the symlink.  It's a good idea to do a
"make clean" at the same time.)

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] How to compile different implementations of the same lib

[Jacques Garrigue]

From: Daniel Bünzli <daniel.buenzli@epfl.ch>

> Le 30 nov. 05 à 15:38, Daniel Bünzli a écrit :
> 
> > Le 30 nov. 05 à 13:19, Jacques Garrigue a écrit :
> >
> >> Note that with native code you must be careful to compile without any
> >> .cmx around (only .cmi's), as this would induce dependencies on a
> >> specific version. This also means that you lose inlining (one major
> >> advantage of native code.)
> >
> > I don't understand this. Careful to compile what without which cmx  
> > around ? And where do you lose inlining ?
> 
> Now I think I understand this. You mean when you compile client code  
> client.ml against the library. Then functions from the lib will not  
> be inlined in client code. This allows to switch implementations of  
> the library without recompiling client.ml. More precisely, if you  
> statically link with the lib you only need to relink and if you  
> dynamically link you don't even need to do anything, you can just  
> play with CAML_LD_LIBRARY_PATH. Right ?

Yes, that's the idea.
I should have been more specific:
In order to create a clean separation between the library and the
client, such that you will be able to change the implementation of the
library, you must write .mli's for all the modules the library
exports, and compile the client with only the .cmi's in the path.
Note of course that the .mli/.cmi must also be copied to the directory
where you compile the library (the compiler only looks for them there
when compiling the .ml).

A result is that there cannot be any inlining between client and
library. Actually, this is even worse than that: this also prevents
direct function calls, as the concrete information about functions is
also in the .cmx. All calls will have to go through closures. Just
like when you call a function received as parameter, or inside a
functor.

This suggests the other evident alternative: write the client as a
functor. This will not be slower! But this can be more painful if
there are several modules in the client...

Jacques Garrigue

Re: [Caml-list] How to compile different implementations of the same lib

[malc]

On Thu, 1 Dec 2005, Jacques Garrigue wrote:

<snip>

> Yes, that's the idea.
> I should have been more specific:
> In order to create a clean separation between the library and the
> client, such that you will be able to change the implementation of the
> library, you must write .mli's for all the modules the library
> exports, and compile the client with only the .cmi's in the path.
> Note of course that the .mli/.cmi must also be copied to the directory
> where you compile the library (the compiler only looks for them there
> when compiling the .ml).
>
> A result is that there cannot be any inlining between client and
> library. Actually, this is even worse than that: this also prevents
> direct function calls, as the concrete information about functions is
> also in the .cmx. All calls will have to go through closures. Just
> like when you call a function received as parameter, or inside a
> functor.

A long while ago i wrote an unliner for .cmx to fight precisely this
problem, was quite trivial too, not that i ever understood the full
implications of this ofcourse.

>
> This suggests the other evident alternative: write the client as a
> functor. This will not be slower! But this can be more painful if
> there are several modules in the client...

-- 
mailto:malc@pulsesoft.com

Re: [Caml-list] How to compile different implementations of the same lib

[Christophe Raffalli]

> A result is that there cannot be any inlining between client and
> library. Actually, this is even worse than that: this also prevents
> direct function calls, as the concrete information about functions is
> also in the .cmx. All calls will have to go through closures. Just
> like when you call a function received as parameter, or inside a
> functor.
> 

I you actually decide that the dependancy is for .cmx instead of .cmi in
the makefile (which is mandatory for nativecode) with proper -I option,
it should also work (maybe with a make clean when you switch
implementation) ?

May be I still do not get the problem

Anyway, there should be better support for implementation choice at link
time, because this is a nice feature of ML ...

> This suggests the other evident alternative: write the client as a
> functor. This will not be slower! But this can be more painful if
> there are several modules in the client...
> 
> Jacques Garrigue
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------

Re: [Caml-list] Best way to choose an implementation of a lib ?

[Christophe Raffalli]

Eric Cooper a écrit :
> On Wed, Nov 30, 2005 at 09:19:30PM +0900, Jacques Garrigue wrote:
> 
>>From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
>>
>>>Let say I want two distribute two(or more) implementations of a library
>>>with the .mli for all ...
>>>
>>>Is there a way to choose the implementation at link time ?
>>>[...]
>>
>>Directories seem a possible solution.
>>[...] 
>>An alternative to distinct directories is to create libraries (.cma/.cmxa).
> 
> 
> And yet another is to use symbolic links, for example
>     a.ml -> a_optimized_impl.ml
> or
>     a.ml -> a_reference_impl.ml
> 

This is not reasonable for a library. You can not ask the user to
change symbolic link in /usr/lib/ocaml ...

> (Note that when using "make", you have to be careful about stale
> object files after switching the symlink.  It's a good idea to do a
> "make clean" at the same time.)
> 

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------

Re: [Caml-list] Best way to choose an implementation of a lib ?

[Eric Cooper]

On Thu, Dec 01, 2005 at 06:05:12PM +0100, Christophe Raffalli wrote:
> Eric Cooper a crit :
> > And yet another is to use symbolic links, for example
> >     a.ml -> a_optimized_impl.ml
> > or
> >     a.ml -> a_reference_impl.ml
> > 
> 
> This is not reasonable for a library. You can not ask the user to
> change symbolic link in /usr/lib/ocaml ...

The original poster said he wanted to distribute two versions of a
library with the same interface (.mli).  This is just a way of
*building* those two different library versions, only the binaries of
which would get distributed.

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] How to compile different implementations of the same lib

[skaller]

On Thu, 2005-12-01 at 18:03 +0100, Christophe Raffalli wrote:

> May be I still do not get the problem

Simple. Ocaml cheats. When you *compile* against a cmx
or cmi/cmx pair, Ocaml 'cheats' and lifts non-interface
information out of the cmx. This allows it to, for
example, inline functions by cheating and grabbing their
implementations from the cmx.

This 'cheating' is typesafe and transparent at the program
code level but NOT the compilation model level.

To enforce abstraction, you have to ensure the cmx is
not present when the dependent module is compiled,
this forces the generated code to use indirection
(closures, etc) -- marginally later binding at the
cost of some performance. Given how fast the Ocaml
compiler is it hardly seems worth bothering to me --
it's not as though you can link Ocaml code without
the compiler.

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

Re: [Caml-list] How to compile different implementations of the same lib

[Richard Jones]

On Fri, Dec 02, 2005 at 04:54:07AM +1100, skaller wrote:
> On Thu, 2005-12-01 at 18:03 +0100, Christophe Raffalli wrote:
> > May be I still do not get the problem
> 
> Simple. Ocaml cheats. When you *compile* against a cmx
> or cmi/cmx pair, Ocaml 'cheats' and lifts non-interface
> information out of the cmx. This allows it to, for
> example, inline functions by cheating and grabbing their
> implementations from the cmx.
> 
> This 'cheating' is typesafe and transparent at the program
> code level but NOT the compilation model level.
> 
> To enforce abstraction, you have to ensure the cmx is
> not present when the dependent module is compiled,
> this forces the generated code to use indirection
> (closures, etc) [...]

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?

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] How to compile different implementations of the same lib

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

skaller a écrit :
> On Thu, 2005-12-01 at 18:03 +0100, Christophe Raffalli wrote:
> 
> 
>>May be I still do not get the problem
> 
> 
> Simple. Ocaml cheats. When you *compile* against a cmx
> or cmi/cmx pair, Ocaml 'cheats' and lifts non-interface
> information out of the cmx. This allows it to, for
> example, inline functions by cheating and grabbing their
> implementations from the cmx.
> 

Yes, I knew that but ..

if I have

toto.cmi in /usr/lib/ocaml

toto.cmx and toto.o in /usr/lib/ocaml/totov1/ compiled from totov1.ml

toto.cmx and toto.o in /usr/lib/ocaml/totov2/ compiled from totov1.ml

tata.ml that does "open Toto"

then use either

ocamlopt -I +totov1 toto.cmx tata.ml

ocamlopt -I +totov2 toto.cmx tata.ml

shouldn't this work ?

Indeed, I tried using "the ln -s" trick for compilation as suggested ...
and it seems to work ?

It is a bit painfull both for compilation and usage ...

BTW: I can not miss inlinig for bindlib, since there will be many calls
to small functions (even 1 line ones) in code using bindlib (I guess,
but did not try).








[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [Caml-list] How to compile different implementations of the same lib

[skaller]

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

Re: [Caml-list] How to compile different implementations of the same lib

[Jacques Garrigue]

From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
> if I have
> 
> toto.cmi in /usr/lib/ocaml
> 
> toto.cmx and toto.o in /usr/lib/ocaml/totov1/ compiled from totov1.ml
> 
> toto.cmx and toto.o in /usr/lib/ocaml/totov2/ compiled from totov1.ml
> 
> tata.ml that does "open Toto"
> 
> then use either
> 
> ocamlopt -I +totov1 toto.cmx tata.ml
> 
> ocamlopt -I +totov2 toto.cmx tata.ml
> 
> shouldn't this work ?

Of course it will.
You were asking for _link time_ choice.
If it's ok to downgrade to compile time choice, knowing that the
interfaces guarantee that you will be able to recompile with an
alternative library, then this is just the standard ocaml approach.
This is also the reason one doesn't use functors often in ocaml:
implementation choice, with abstraction guarantees, can already be
done by setting some path, which is simpler than parameterizing all
your code.

In your example, it would then be cleaner to put toto.cmi in both totov1
and totov2, since you will need anyway one of the two when compiling.

> Indeed, I tried using "the ln -s" trick for compilation as suggested ...
> and it seems to work ?

It will work, but -I is enough, and seems simpler to me for a library.

Jacques Garrigue

Re: [Caml-list] How to compile different implementations of the same lib

[Jacques Garrigue]

From: Richard Jones <rich@annexia.org>

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

There are many causes:
The first one is that functions in ocaml are represented as closures,
which are data generated at runtime, including a code pointer.
When you access a function without the .cmx, you're just extracting
data at a certain offset from an array representing the module the
function belongs to. The name of the code pointer, on which C linking
is usually based, doesn't appear in this scheme: everything is extracted
from a single data pointer to the module.

If you want to call functions directly, you would first have to reveal
the names of their code pointers, which is currently generated in a code
dependent way, and stored in the cmx. The generation could be made
uniform for exported functions (not as easy as it seems), but this
would still be the easy part.

The hard part is that you also need to know which representation the
optimized version of the function is using.

Has it a closure? For many functions, you need to pass them some
environment data as an extra parameter. However not all functions need
this extra parameter (some functions don't access any external data),
and in that case there optimized form doesn't expect such an extra
parameter. If you don't know that, you can only call the non-optimized
form, looking up the data, which happens to be empty.

What is its arity? Because of currying, the arity of the type of a
function is not necessarily equal to the arity of its
implementation. That is, some partial applications might actually
produce side-effects. The optimized version of the function is based
on the actual arity, not that of the type. So you cannot call it
wihout knowing this arity.

All this might be solved in one way or another, but the solution would
be sub-optimal, and would not allow for the inlining one would expect
for native code.

Jacques Garrigue