Skip to content

Commit ebbe65d

Browse files
jamesmckinnaMatthewDaggitt
authored andcommitted
Style guide: avoid renaming on qualified import cf. #2294 (#2308)
* recommendation from #2294 * spellcheck * comma --------- Co-authored-by: MatthewDaggitt <[email protected]>
1 parent ce23ff5 commit ebbe65d

File tree

1 file changed

+10
-2
lines changed

1 file changed

+10
-2
lines changed

doc/style-guide.md

+10-2
Original file line numberDiff line numberDiff line change
@@ -134,15 +134,15 @@ automate most of this.
134134
* Naming conventions for qualified `import`s: if importing a module under
135135
a root of the form `Data.X` (e.g. the `Base` module for basic operations,
136136
or `Properties` for lemmas about them etc.) then conventionally, the
137-
qualified name(s) for the import(s) should (all) share as qualfied name
137+
qualified name(s) for the import(s) should (all) share as qualified name
138138
that of the name of the `X` datatype defined: i.e. `Data.Nat.Base`
139139
should be imported as ``, `Data.List.Properties` as `List`, etc.
140140
In this spirit, the convention applies also to (the datatype defined by)
141141
`Relation.Binary.PropositionalEquality.*` which should be imported qualified
142142
with the name ``.
143143
Other modules should be given a 'suitable' qualified name based on its 'long'
144144
path-derived name (such as `SetoidEquality` in the example above); commonly
145-
occcurring examples such as `Algebra.Structures` should be imported qualified
145+
occurring examples such as `Algebra.Structures` should be imported qualified
146146
as `Structures` etc.
147147
NB. Historical legacy means that these conventions have not always been observed!
148148

@@ -152,6 +152,14 @@ automate most of this.
152152
symbol (eg. `` for `Preorder` reasoning), use the qualified name
153153
`<symbol>-Reasoning`, ie. `≲-Reasoning` for the example given.
154154

155+
* Qualified `open import`s should, in general, avoid `renaming`
156+
identifiers, in favour of using the long(er) qualified name,
157+
although similar remarks about legacy failure to observe this
158+
recommendation apply!
159+
NB. `renaming` directives are, of course, permitted when a module is
160+
imported qualified, in order to be *subsequently* `open`ed for
161+
`public` export (see below).
162+
155163
* When using only a few items (i.e. < 5) from a module, it is a good practice to
156164
enumerate the items that will be used by declaring the import statement
157165
with the directive `using`. This makes the dependencies clearer, e.g.

0 commit comments

Comments
 (0)