Caml wish list

[Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>]

Here is a list of request for Ocaml that would really make the libray
for formal and numerical calculus better (see
http://www.raffalli.univ-savoie.fr/~RAFFALLI/formel.html) : 


- include with ...

	would allow multiple inheritance in signature !

- include in structure.

	We should also think about multiple inheritance and
	even override in this case. But a simple implementation 
	would already be useful.

- typing of structure containing modules is problematic:

	if you write:

	module F = functor(M:M) -> 
	struct 
	  module M =M
	end

	Then you have a module Q:Q where Q is a subtype of M.

	If you type R = F(Q) then
	the type of R.M is M even if the type system knows that
	R.M = Q.

	This makes it impossible in some cases to put modules as member 
	of structure ! It was for instance impossible to put the Ring of 
	scalar as a member of the structure Vector, because when this
	Ring is a Field, we may loose this information and fail to
	type-check perfectly correct program.

- Infix operator like + ...

	Every body will agree that infix operator are needed. So
	R.+ should be allowed as an infix operator and R.(+) would
	be prefix.

	One could event think to reuse symbols like + for many functions.
	Here is a simple proposal on how to do it that I would really enjoy to 
	see working :

	Two new commands in OCaml structure (the syntax can be changed):

	share + : 'a -> 'a -> 'a

	this makes that + exists and is type-checked with type 'a -> 'a -> 'a

 	share + = add_int
	share + = add_float
	...

	this means that, after type checking, + will take the first value 
	among  add_int, add_float, ... whose type matches the infered type for
+.

	If add_int is tested first, this will be compatible with existing code.
	This is easy to implement (I think).

	One could even allow some kind of recursive macros !

	share + = fun (x,y) (x',y') -> (x+x', y+y')
	share + = List.map2 (+)
	share + = Array.map2 (+)

	This is a bit mode difficult to implement, but it seems feasible.

- The library is too slow when using floating points.

	One need to add inlining for functor and functions 
	before doing the floating point optimisations. 

	A function or functor that is used only once 
	should be inlined regardless of its size (no huge code size 
	explosion even if the function is used once in every .ml files)

	A syntax for inlining on demand (when applying and/or) defining the
	function should be provided. A way would be to have three new
	choices when defining a function or functor:
	- normal
	- always inlined
	- inlined on demand



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