You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 2717 Reporter: administrator Status: closed (set by @mshinwell on 2016-12-06T21:19:20Z) Resolution: not a bug Priority: normal Severity: feature Category: ~DO NOT USE (was: OCaml general)
Bug description
Bonjour à vous,
Dans:
Parameterized Programming and Software Architecture, de Joseph
Goguen, dans Proceedings, Fourth International Conference on
Software Reuse, IEEE Computer Society, April 1996, pages 2-11.
(http://www.cs.ucsd.edu/users/goguen/pps/orlando96.ps),
l'auteur décrit des opérateurs (du langage LILEANA) qui
permettent de renommer a posteriori les types contenus dans un
module ou une signature. Je me demandais donc dans quelle mesure
cela pourrait être également possible en OCaml.
En effet, le programmeur ML est confronté à un dilemme: soit il
tente de nommer la plupart de ses types par un nom uniforme (en
général "t"), soit il tente d'en distinguer les appelations.
Le nommage uniforme permet de maximiser la compatibilité avec les
signatures disponibles. Mais ça n'est pas très informatif et ça
ne marche évidemment pas pour les multi-sortes.
Accessoirement, cela pose aussi des problèmes lors de l'union de
deux signatures ou modules par simples inclusions:
module type OPER = sig type t val oper : t -> t -> t end
module type EQUAL = sig type t val equal: t -> t -> bool end;;
module type OPER_EQUAL = sig include OPER include EQUAL end;; ==> CLASH
Alors que si l'on en distingue les noms, il est possible d'écrire:
module type OPER = sig type t val oper : t -> t -> t end
module type EQUAL = sig type s val equal: s -> s -> bool end;;
module type OPER_EQUAL = sig include OPER include EQUAL with type s = t end;;
On pourrait aussi probablement rendre plus élégantes les manips
du genre de celles qui ont été faites dans la bibliothèque
standard pour les modules String, Char, Int32 ou Int64 (cf. leurs
deux dernières lignes).
Le renommage permettrait d'adapter donc parfois les noms des
types à ses besoins. Ceci dit, je ne mesure pas toutes les
implications que cette opération pourrait avoir pour le système
de type.
pn
The text was updated successfully, but these errors were encountered:
Original bug ID: 2717
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-06T21:19:20Z)
Resolution: not a bug
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Bonjour à vous,
Dans:
Parameterized Programming and Software Architecture, de Joseph
Goguen, dans Proceedings, Fourth International Conference on
Software Reuse, IEEE Computer Society, April 1996, pages 2-11.
(http://www.cs.ucsd.edu/users/goguen/pps/orlando96.ps),
l'auteur décrit des opérateurs (du langage LILEANA) qui
permettent de renommer a posteriori les types contenus dans un
module ou une signature. Je me demandais donc dans quelle mesure
cela pourrait être également possible en OCaml.
En effet, le programmeur ML est confronté à un dilemme: soit il
tente de nommer la plupart de ses types par un nom uniforme (en
général "t"), soit il tente d'en distinguer les appelations.
Le nommage uniforme permet de maximiser la compatibilité avec les
signatures disponibles. Mais ça n'est pas très informatif et ça
ne marche évidemment pas pour les multi-sortes.
Accessoirement, cela pose aussi des problèmes lors de l'union de
deux signatures ou modules par simples inclusions:
module type OPER = sig type t val oper : t -> t -> t end
module type EQUAL = sig type t val equal: t -> t -> bool end;;
module type OPER_EQUAL = sig include OPER include EQUAL end;; ==> CLASH
Alors que si l'on en distingue les noms, il est possible d'écrire:
module type OPER = sig type t val oper : t -> t -> t end
module type EQUAL = sig type s val equal: s -> s -> bool end;;
module type OPER_EQUAL = sig include OPER include EQUAL with type s = t end;;
On pourrait aussi probablement rendre plus élégantes les manips
du genre de celles qui ont été faites dans la bibliothèque
standard pour les modules String, Char, Int32 ou Int64 (cf. leurs
deux dernières lignes).
Le renommage permettrait d'adapter donc parfois les noms des
types à ses besoins. Ceci dit, je ne mesure pas toutes les
implications que cette opération pourrait avoir pour le système
de type.
pn
The text was updated successfully, but these errors were encountered: