@@ -2171,7 +2171,20 @@ system-dependent values for these fields.
2171
2171
2172
2172
Supported only in GHC 8.2 and later. A list of packages mentioned in the
2173
2173
:pkg-field: `build-depends ` field, each optionally accompanied by a list of
2174
- module and module signature renamings.
2174
+ module and module signature renamings. A valid mixin obeys the
2175
+ following syntax:
2176
+
2177
+ ::
2178
+
2179
+ Mixin ::= PackageName IncludeRenaming
2180
+ IncludeRenaming ::= ModuleRenaming { "requires" ModuleRenaming }
2181
+ ModuleRenaming ::=
2182
+ {- empty -}
2183
+ | "(" Renaming "," ... "," Renaming ")"
2184
+ | "hiding" "(" ModuleName "," ... "," ModuleName ")"
2185
+ Renaming ::=
2186
+ ModuleName
2187
+ | ModuleName "as" ModuleName
2175
2188
2176
2189
The simplest mixin syntax is simply the name of a package mentioned in the
2177
2190
:pkg-field: `build-depends ` field. For example:
@@ -3333,6 +3346,114 @@ a few options:
3333
3346
library for all or part of the work. One option is to copy the source
3334
3347
of ``Distribution.Simple``, and alter it for your needs. Good luck.
3335
3348
3349
+ .. _Backpack:
3350
+
3351
+ Backpack
3352
+ --------
3353
+
3354
+ Cabal and GHC jointly support Backpack, an extension to Haskell' s module
3355
+ system which makes it possible to parametrize a package over some
3356
+ modules, which can be instantiated later arbitrarily by a user. This
3357
+ means you can write a library to be agnostic over some data
3358
+ representation, and then instantiate it several times with different
3359
+ data representations. Like C++ templates, instantiated packages are
3360
+ recompiled for each instantiation, which means you do not pay any
3361
+ runtime cost for parametrizing packages in this way. Backpack modules
3362
+ are somewhat experimental; while fully supported by cabal-install, they are currently
3363
+ ` not supported by Stack < https://github.com/commercialhaskell/stack/issues/2540> ` __.
3364
+
3365
+ A Backpack package is defined by use of the
3366
+ :pkg-field:` library:signatures` field, or by (transitive) dependency on
3367
+ a package that defines some requirements. To define a parametrized
3368
+ package, define a signature file (file extension ` ` hsig` ` ) that
3369
+ specifies the signature of the module you want to parametrize over, and
3370
+ add it to your Cabal file in the :pkg-field:` library:signatures` field.
3371
+
3372
+ .. code-block:: haskell
3373
+ :caption: .hsig
3374
+
3375
+ signature Str where
3376
+
3377
+ data Str
3378
+
3379
+ concat :: [Str] -> Str
3380
+
3381
+ .. code-block:: cabal
3382
+ :caption: parametrized.cabal
3383
+
3384
+ cabal-version: 2.2
3385
+ name: parametrized
3386
+
3387
+ library
3388
+ build-depends: base
3389
+ signatures: Str
3390
+ exposed-modules: MyModule
3391
+
3392
+ You can define any number of regular modules (e.g., ` ` MyModule` ` ) that
3393
+ import signatures and use them as regular modules.
3394
+
3395
+ If you are familiar with ML modules, you might now expect there to be
3396
+ some way to apply the parametrized package with an implementation of
3397
+ the ` ` Str` ` module to get a concrete instantiation of the package.
3398
+ Backpack operates slightly differently with a concept of * mix-in
3399
+ linking* , where you provide an implementation of ` ` Str` ` simply by
3400
+ bringing another module into scope with the same name as the
3401
+ requirement. For example, if you had a package ` ` str-impl` ` that provided a
3402
+ module named ` ` Str` ` , instantiating ` ` parametrized` ` is as simple as
3403
+ just depending on both ` ` str-impl` ` and ` ` parametrized` ` :
3404
+
3405
+ .. code-block:: cabal
3406
+ :caption: combined.cabal
3407
+
3408
+ cabal-version: 2.2
3409
+ name: combined
3410
+
3411
+ library
3412
+ build-depends: base, str-impl, parametrized
3413
+
3414
+ Note that due to technical limmitations, you cannot directly define
3415
+ ` ` Str` ` in the ` ` combined` ` library; it must be placed in its own
3416
+ library (you can use :ref:` Internal Libraries < sublibs> ` to conveniently
3417
+ define a sub-library).
3418
+
3419
+ However, a more common situation is that your names don' t match up
3420
+ exactly. The :pkg-field:`library:mixins` field can be used to rename
3421
+ signatures and modules to line up names as necessary. If you have
3422
+ a requirement ``Str`` and an implementation ``Data.Text``, you can
3423
+ line up the names in one of two ways:
3424
+
3425
+ * Rename the requirement to match the implementation:
3426
+ ``mixins: parametrized requires (Str as Data.Text)``
3427
+ * Rename the implementation to match the requirement:
3428
+ ``mixins: text (Data.Text as Str)``
3429
+
3430
+ The :pkg-field:`library:mixins` field can also be used to disambiguate
3431
+ between multiple instantiations of the same package; for each
3432
+ instantiation of the package, give it a separate entry in mixins with
3433
+ the requirements and provided modules renamed to be distinct.
3434
+
3435
+ .. code-block:: cabal
3436
+ :caption: .cabal
3437
+
3438
+ cabal-version: 2.2
3439
+ name: double-combined
3440
+
3441
+ library
3442
+ build-depends: base, text, bytestring, parametrized
3443
+ mixins:
3444
+ parametrized (MyModule as MyModule.Text) requires (Str as Data.Text),
3445
+ parametrized (MyModule as MyModule.BS) requires (Str as Data.ByteString)
3446
+
3447
+ Intensive use of Backpack sometimes involves creating lots of small
3448
+ parametrized libraries; :ref:`Internal Libraries <sublibs>` can be used
3449
+ to define all of these libraries in a single package without having to
3450
+ create many separate Cabal packages. You may also find it useful to use
3451
+ :pkg-field:`library:reexported-modules` to reexport instantiated
3452
+ libraries to Backpack-unware users (e.g., Backpack can be used entirely
3453
+ as an implementation detail.)
3454
+
3455
+ For more information about Backpack, check out the
3456
+ `GHC wiki page <https://gitlab.haskell.org/ghc/ghc/-/wikis/backpack>`__.
3336
3457
3337
3458
.. include:: references.inc
3338
3459
0 commit comments