From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id OAA18743 for caml-redistribution; Thu, 19 Oct 1995 14:49:50 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id LAA15729 for ; Thu, 19 Oct 1995 11:31:25 +0100 Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id LAA01024 for ; Thu, 19 Oct 1995 11:31:24 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by margaux.inria.fr (8.6.10/8.6.6) with ESMTP id LAA06809 for ; Thu, 19 Oct 1995 11:31:24 +0100 Received: from isis.u-strasbg.fr ([130.79.200.1]) by nez-perce.inria.fr (8.6.10/8.6.9) with ESMTP id LAA00965 for ; Thu, 19 Oct 1995 11:31:24 +0100 Received: from gr6 (gr6.u-strasbg.fr [130.79.6.86]) by isis.u-strasbg.fr (8.6.11/8.6.9) with SMTP id LAA12910 for ; Thu, 19 Oct 1995 11:20:57 +0100 Received: by gr6 (4.1/SMI-3.2-jjp/4/6/92) id AA19481; Thu, 19 Oct 95 11:31:13 +0100 Date: Thu, 19 Oct 95 11:31:13 +0100 From: boos@gr6.u-strasbg.fr (Christian Boos) Message-Id: <9510191031.AA19481@gr6> To: caml-list@margaux.inria.fr Subject: [Q]: Mutable variant types in Caml Light 0.7 Sender: weis 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.