Bonjour,

J'aimerais avoir un avis sur le problème suivant.

Pour définir des types "union", il y a deux approches possibles :

a)	type t = A of int * float * string

ou bien

b)	type t = A of record
	and record = { a:int; b:float; c:string; }


Je crois être en présence du dilemme suivant : 
 - sur le plan efficacité, a) > b) :
    a) 'allocation à plat' -> économe en espace
    b) indirection vers l'enregistrement -> lent

 - sur le plan souplesse d'utilisation, b) > a) :
    a) une indication 'mutable' s'applique obligatoirement à
       l'ensemble des champs, qui de ce fait sont alloués en tant que
       n-uplets. On perd donc les avantages mentionnés précedemment,
       sans avoir de réel confort d'utilisation.
    b) bien sûr, il est ici possible de déclarer chaque champ
       'mutable'.

Si ce raisonnement est correct, une amélioration pourrait alors être
effectuée, permettant de cumuler efficacité et souplesse :
  - soit une grosse refonte de la syntaxe des types, pour avoir des
déclarations à la SML (mais plus expressives, en raison du 'mutable') :
	
	type t = A of { a:int; mutable b:float; c:string; }

  - soit en faisant une modification sur la syntaxe de l'extension 3.6
permettant d'avoir des types "union" mutables :

	type t = A of int * (mutable float) * string


... par ailleurs, qu'en est-il de ce problème en CSL ?


Merci pour vos conseils !


------------------------------------------------------------------
Christian Boos
Doctorant en Informatique
ULP - Strasbourg.