@@ -60,11 +60,11 @@ Haskell is a language that is older than some of the people currently writing
60
60
it; parts of its ecosystem are not exempt from it. With age comes legacy, and
61
61
much of it is based on historical decisions which we now know to be problematic
62
62
or wrong. We can't avoid our history, but we can minimize its impact on our
63
- current work.
63
+ current work.
64
64
65
65
Thus, we aim to codify good practices in this document _ as seen today_ . We also
66
66
try to avoid obvious 'sharp edges' by proscribing them away in a principled,
67
- consistent and justifiable manner.
67
+ consistent and justifiable manner.
68
68
69
69
## Automate away drudgery
70
70
@@ -155,7 +155,7 @@ difficult to read even without a split screen. We don't _enforce_ a maximum of
155
155
## Naming
156
156
157
157
camelCase MUST be used for all non-type, non-data-constructor names; otherwise,
158
- TitleCase MUST be used. Acronyms used as part of a naming identifier (such as
158
+ TitleCase MUST be used. Acronyms used as part of a naming identifier (such as
159
159
'JSON', 'API', etc) SHOULD be downcased; thus `` repairJson `` and
160
160
`` fromHttpService `` are correct. Exceptions are allowed for external libraries
161
161
(Aeson's `` parseJSON `` for example).
@@ -315,11 +315,11 @@ wrappers around monadic stacks:
315
315
```haskell
316
316
newtype FooM a = FooM (ReaderT Int (StateT Text IO ) a )
317
317
deriving newtype (
318
- Functor ,
319
- Applicative ,
320
- Monad ,
321
- MonadReader Int ,
322
- MonadState Text ,
318
+ Functor ,
319
+ Applicative ,
320
+ Monad ,
321
+ MonadReader Int ,
322
+ MonadState Text ,
323
323
MonadIO
324
324
)
325
325
```
@@ -341,8 +341,8 @@ Thus, even for popularity and compatibility reasons, these should be on by
341
341
default .
342
342
343
343
``InstanceSigs `` are harmless by default , and introduce no complications. Their
344
- not being default is strange. ``ImportQualifiedPost `` is already a convention
345
- of this project, and helps with formatting of imports.
344
+ not being default is strange. ``ImportQualifiedPost `` is already a convention
345
+ of this project, and helps with formatting of imports.
346
346
347
347
``LambdaCase `` reduces a lot of code in the common case of analysis of sum
348
348
types. Without it, we are forced to either write a dummy ``case` ` argument:
@@ -383,7 +383,7 @@ instead of the one from ``base``.
383
383
`` OverloadedStrings `` deals with the problem that `` String `` is a suboptimal
384
384
choice of string representation for basically _ any_ problem, with the general
385
385
recommendation being to use `` Text `` instead. It is not, however, without its
386
- problems:
386
+ problems:
387
387
388
388
* `` ByteString `` s are treated as ASCII strings by their `` IsString `` instance;
389
389
* Overly polymorphic behaviour of many functions (especially in the presence of
@@ -438,8 +438,8 @@ alternatives. This means that, when a non-``base`` ``Prelude`` is in scope, it
438
438
often requires familiarity with its specific decisions, in addition to whatever
439
439
cognitive load the current module and its other imports impose. Given that we
440
440
already use an alternative prelude (in tandem with the one from `` base `` ),
441
- additional alternatives present an unnecessary cognitive load. Lastly, the
442
- dependency footprint of many alternative `` Prelude `` s is _ highly_ non-trivial;
441
+ additional alternatives present an unnecessary cognitive load. Lastly, the
442
+ dependency footprint of many alternative `` Prelude `` s is _ highly_ non-trivial;
443
443
it isn't clear if we need all of this in our dependency tree.
444
444
445
445
For all of the above reasons, the best choice is 'default to Plutus, with local
@@ -470,7 +470,7 @@ Every publically-exported definition MUST have a Haddock comment, detailing its
470
470
purpose. If a definition is a function, it SHOULD also have examples of use
471
471
using [ Bird tracks] [ bird-tracks ] . The Haddock for a publically-exported
472
472
definition SHOULD also provide an explanation of any caveats, complexities of
473
- its use, or common issues a user is likely to encounter.
473
+ its use, or common issues a user is likely to encounter.
474
474
475
475
If the code project is a library, these Haddock comments SHOULD carry an
476
476
[ `` @since `` ] [ haddock-since ] annotation, stating what version of the library they
@@ -502,15 +502,15 @@ also the expected behaviour of its instances.
502
502
## Other
503
503
504
504
Lists SHOULD NOT be field values of types; this extends to `` String `` s. Instead,
505
- `` Vector `` s (`` Text `` s) SHOULD be used, unless a more appropriate structure exists.
505
+ `` Vector `` s (`` Text `` s) SHOULD be used, unless a more appropriate structure exists.
506
506
On-chain code, due to a lack of alternatives, is one place lists can be used as
507
507
field values of types.
508
508
509
509
Partial functions MUST NOT be defined. Partial functions SHOULD NOT be used
510
510
except to ensure that another function is total (and the type system cannot be
511
- used to prove it).
511
+ used to prove it).
512
512
513
- Derivations MUST use an explicit [ strategy] [ deriving-strategies ] . Thus, the
513
+ Derivations MUST use an explicit [ strategy] [ deriving-strategies ] . Thus, the
514
514
following is wrong:
515
515
516
516
``` haskell
0 commit comments