Filtrage curryfie et ambiguite syntaxique

Filtrage curryfie et ambiguite syntaxique

[Marc]

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