Subject: Filtrage curryfie et ambiguite syntaxique
To: caml-redistribution@margaux
Date: Thu, 28 Jan 1993 10:09:37 +0100 (MET)
Subject: Filtrage curryfie et ambiguite syntaxique
Merci pour vos reponses! Je comprends effectivement maintenant les messages
plutot abscons du systeme.
Le probleme vient dites-vous d'une ambiguite syntaxique entre constructeur
et identificateur (de variable). On peut certes imposer une discrimination via
le type du premier caractere (majuscule/minuscule), mais ne peut-on egalement
imposer que les champs lexicaux soient distincts? Je veux dire: des qu'un type
a ete declare, on n'a plus le droit de se servir des noms de ses constructeurs
comme identificateurs de variables. Est-ce trop restrictif?
Quoi qu'il en soit, les noms de tous les constructeurs de tous les types sommes
d'un programme Caml semblent devoir etre distincts (sinon le typage est impos-
sible): le programmeur doit donc s'efforcer de les avoir tous en tete. La si-
tuation est radicalement differente en C par exemple: les noms de 'champs'
doivent seulement etre distincts au sein d'un meme type 'union'. On peut les
reutiliser ailleurs et c'est tres pratique. En Caml on est oblige de proceder
de facon un peu lourde:
Supposons le type homme defini par ailleurs.
#type etre_humain = 'Homme of homme
| 'Femme of homme
| 'Enfant of homme ;;
#type etre_vivant = 'Homme1 of homme (* ! *)
| 'Animal of animal ;;
#type facteur_de_production = 'Homme2 of homme (* ! *)
| 'Machine of machine ;;
Comment pourrait-on eviter cela? Ce probleme est-il important (je pense no-
tamment aux grammaires concretes avec beaucoup de definitions de ce genre)?
D'autre part la situation 'mixte' des types produits (dixit le Manuel de Refe-
rence: le typechecker se debrouille comme il peut pour decider, et il ne peut
pas toujours...) quant a ce probleme d'identite des noms est-elle tenable?
Merci d'avance de votre patience et/ou de votre indulgence,
Marc Foissotte (foissott@poly.polytechnique.fr).
[Note du mode'rateur:
Ce message est re'dige' en Caml V3.1: la distinction des
constructeurs est faite par "'", et le proble`me e'voque' pour les
types produits fait re'fe'rence a` la surcharge des e'tiquettes de
champs d'enregistrement de la version V3.1.
Pour re'pondre a` la question: nous n'avons pas e'te' jusqu'au bout
et n'avons pas admis la surcharge des constructeurs, alors que les
ope'rateurs et les e'tiquettes peuvent e^tre surcharge's. La raison
principale est technique: la re'solution de la surcharge est un
proble`me difficile en pre'sence de polymorphisme. Les algorithmes
employe's dans la version 3.1 ne sont pas publie's ni prouve's. Ils
ont e'te' abondamment teste's et nous avons raisonnablement confiance
en eux, mais il reste du travail pour aller jusqu'a` la surcharge des
constructeurs. Il faut en particulier e'tudier la complexite'
(pratique) de cette me'thode de re'solution statique de la surcharge.
La solution que vous proposez pour re'soudre l'ambiguite' des noms
d'identificateurs n'est pas suffisante. Il est ne'cessaire qu'un
constructeur mal orthographie' dans un filtre soit de'tecte' comme
constructeur inconnu, pas pris pour une variable qui filtre tout. De
plus cette distinction est de'ja` faite par le contro^leur de type:
vous ne pouvez de'finir un identificateur portant le me^me nom qu'un
constructeur. C'est tre`s insuffisant pour permettre une de'tection
su^re des fautes d'orthographe dans les noms de constructeurs, et
pour autoriser une lecture facile des programmes, sans avoir a`
connai^tre l'ensemble des de'clarations de type pre'ce'dant la phrase
qu'on est en train de lire.
Pierre Weis
----------------------------------------------------------------------------
Formel Project
INRIA, BP 105, F-78153 Le Chesnay Cedex (France)
E-mail: Pierre.Weis@inria.fr
Telephone: +33 1 39 63 55 98
----------------------------------------------------------------------------
]