Standardise names for qualified module imports
jamesmckinna opened this issue · comments
Task list to address #2201 , itemised by what needs to change (with proposed changes), rather than where (too many imports to list!):
-
*.Bundles
asBundles
-
*.Bundles.Raw
asRaw
-
*.Consequences{.*}
asConsequences
-
*.Construct.Composition
asComposition
-
*.Construct.Identity
asIdentity
-
*.Definitions
asDefinitions
-
*.Effectful.Transformer
asTransformer
-
*.Structures
asStructures
-
Data.Nat{.*}
asℕ
#2281 -
Data.Integer.Divisibility
: this module makes qualified imports from variousData.Nat
modules, but it doesn't seem easy to import them all under a single qualified nameℕ
, because the structure seems to need to export the constructordivides
ofData.Nat.Divisibility
, leading to a disambiguation error... perhaps this can be renegotiated/refactored viaintroducing a pattern synonym? #2294Data.Nat.Divisibility.Core
-
Data.Product.Base
asProduct
(orΣ
?) #2284 NB Data.Container.* yields non-trivial ambiguities -
Data.Sum.Base
asSum
(or⊎
?) #2290 NB Data.Container.* yields non-trivial ambiguities -
Data.X.Properties
asX
, rather thanXₚ
withX
the datatype name, not the ASCII module name (as inℕ
above) #2283 NB see the caveats on that PR -
Function.*
asFunction
-
Relation.Binary.PropositionalEquality{.*}
#2293 (systematic but terrifyingly pointless) -
Relation.Binary.Reasoning.Setoid
as≈-Reasoning
by analogy with≡-Reasoning
#2282 / #2309 -
Relation.Binary.*
asBinary
-
Relation.Nullary.*
asNullary
(exceptions forDecidable
andNegation
?) -
Relation.Unary.*
asUnary
-
README.*
#2313 - ...
TODO: update style-guide
to incorporate the conventions:
- final choices of names for
Sum
andProduct
- ...
Things to leave alone:
-
Foreign.*
-
System.*
- ...
Design decisions/outstanding questions:
- use of Unicode: we had agreed in #2201 to the use of
ℕ
as the qualified module name for the (most-?) common cases of importing qualified fromData.Nat.*
, and equality as≡
fromRelation.Binary.PropositionalEquality.*
; but as the list above asks: what about the qualified import names forSum
andProduct
? - what to do where the style guide recommendations cannot be followed?
NB. Each of the above tasks/associated PRs seems to have one or two 'leftovers', so a final 'mop-up' PR may well be in order once the above list (or a suitable subset) is completed.
On #2284 @JacquesCarette wrote:
Sigh -
Product
is non-trivially longer thanProd
. But this is the right thing to do.
So... I've been reconsidering this, and wondered if, instead, and in line with the 'datatype name as root module name' heuristic, that we standardise on import Data.Product.Base as Σ
?
Originally posted by @jamesmckinna in #2284 (comment)
Single precedent in stdlib
: Data.Vec.Functional.Relation.Unary.Any
!
And as I said on #2284 , I think that's a reasonable suggestion. (I'm still torn because my math background wants me to see Σ
as a sum, and I can't be the only one. But that ship has sailed a long time ago, so I'm definitely not going to re-litigate that.)
Re: #2284 I think the maintainers should all agree on this, and then revert that PR in favour of the new suggestion, if necessary.