Je me souviens avoir vu quelques modules (peut-être dans les batteries), comprenant un module Infix
intérieur qui pourrait être ouvert séparément et seulement quand vraiment voulu. Par exemple,
module Rational =
struct
let add a b = ...
let sub a b = ...
module Infix =
struct
let (<+>) = add
let (<->) = sub
end
end
De cette façon, si vous deviez ouvrir le module Rational.Infix
, vous ne de-champ (?) Toutes les fonctions avec le même nom que quoi que ce soit dans Rational
. Je travaille sur un projet où nous utilisons des modules pour délimiter types
. Avoir un module ne définit qu'un type et manipule ce type aide dans l'organisation; en particulier lorsque les modules sont petits et avoir un fichier séparé ne serait pas avantageux, et les types de variantes n'ont pas de sens.
module Node =
struct
end
module Edge =
struct
end
type 'a tree = { nodes : 'a Node.t; edges : 'a Edge.t; }
Nous les utilisons également, bien que fichiers séparés (combinés avec -mlpack), pour tous les parseurs dont nous avons besoin pour --Nexus de données biologiques, Fasta, Phylip, et ainsi de suite. Enfin, souvent lorsque nous prototypons un nouvel algorithme, nous l'écrivons d'abord dans ocaml, puis nous travaillons sur une version en C. Nous conservons généralement la version ocaml dans un module interne avec les mêmes noms de fonctions.
module Align =
struct
module OCaml =
struct
end
end
Les modules imbriqués ont un sens parfait. La question, cependant, pose des questions sur les signatures de module imbriquées *. –
Michael, vous semblez implorer la question. Les avantages concluants des modules imbriqués engendrent la nécessité de signatures de module imbriquées. – nlucaroni