Some questions and proposals...

Some questions and proposals...

[Francisco Valverde Albacete]

Hello mailing list,


	I hope you don't get discouraged when you see the number of question I
address you...

	1) Has anybody developed a module for trees with a variable number of
	branches? If so, can I borrow it?

		My own solution comes from Reade's:

	(* Variable trees *)
	type 'a vtree = Vtree of 'a * 'a vtree list;;

	type 'a forest = 'a vtree list;;

	though, for the sake of efficient updating I have used mutables in the
	design (yes, the nasty "can't generalize type.." etc.

		I would also thank any ideas for the functionals around the
	base type. I have already done some: it_vtree, exists_vtree,
	for_all_vtree, do_vtree in the spirit of their list counterparts...

	OOPS, I must say I'm coding it in CAML (Heavy)!

	2) This is a question mainly to CAML and Camllight implementors: has
	anybody thought of a way to migrate in an automatic, or at least semi-
	automatic way, modules from one of the systems to the other? I have this
	huge quantity of modules in CAML wanting to be compiled in Camllight...!

	3) Finally (or so I think), I guess many of us have types and functions
	that could be of use for the rest ("reuse" they call it, I think).Is 	
	there anythihg like a freeware repository for CAML and Camllight
	modules?
	If so, where? If not, could we discuss such a thing? At least a list
	or sort of FAQ for people whom to ask for them? I volunteer to receive
	and compile a list of people and things (cut and paste, you know) and
	send the list back to caml-mailing-list. That'd be something to start
	with!

   Hope the mail comes in handy for someone else! Au revoir mailing-list!


		Francisco Valverde
		fva@die.upm.es

Some questions and proposals...

[Vale'rie Me'nissier-Morain]

>	2) This is a question mainly to CAML and Camllight implementors: has
>	anybody thought of a way to migrate in an automatic, or at least semi-
>	automatic way, modules from one of the systems to the other? I
>	have this huge quantity of modules in CAML wanting to be
>	compiled in Camllight...!

In fact the difficulties to port Caml programs to Caml-Light seem to
me of three orders:

1. 
   a. Functions written in the prelude file of Caml that are not
defined by Caml-Light: this is easy to correct, just try to compile
and for each unbound name, go in Caml prelude and copy-paste the
definition in a compatibility file loaded before your programs, for
example 
  b. Functions that are curryfied in only one version, generates a
typical typechecking error, so it seems easy to change
  c. Functions with arguments in another order, either generates a
typechecking error and it is easy to change, or for example functions
like "move src dest" changed in "move dest src", and it seems very
difficult to detect 
  d. Same function, same arguments, but not same result, for example 
"index" function for which in one version the first character is
number 1 and in the other version it is number 0

2. Functions that use the fact that the order of evaluation of Caml is
from left to right: it seems very difficult to automatize this phase

3. Functionalities that are different in Caml and Caml-Light like
parsers&printers vs. grammars or some differences in arithmetic, it
seems very difficult to automatize this phase

Vale'rie Me'nissier-Morain