Skip to content

Commit

Permalink
release 0.11.0
Browse files Browse the repository at this point in the history
  • Loading branch information
raehik committed Oct 17, 2024
1 parent fd746ff commit 35831d7
Show file tree
Hide file tree
Showing 4 changed files with 8 additions and 17 deletions.
5 changes: 5 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,8 @@
## 0.11.0 (2024-10-17)
* add `WeakenN` and `SWN` for chaining weakenings
* clarify instance design: even zero-invariant coercible newtypes aren't allowed
to recursively weaken their inner type!

## 0.10.0 (2024-10-13)
* rename `Weak` to `Weakened`, to separate from `Weak :: Strength`
* update rerefined dependency
Expand Down
2 changes: 1 addition & 1 deletion package.yaml
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
name: strongweak
version: 0.10.0
version: 0.11.0
synopsis: Convert between strong and weak representations of types
description: Please see README.md.
extra-source-files:
Expand Down
16 changes: 1 addition & 15 deletions src/Strongweak.hs
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ with the overall design. Here is some relevant guidance.
If you want to handle multiple invariants, chain the weakens/strengthens.
You may do this by nesting 'SW' uses, but you will then have to write your own
instances, as the generics cannot handle such chaining. Alternatively, you may
use 'SWChain'. This will add another newtype layer to the strong representation,
use 'WeakenN'. This will add another newtype layer to the strong representation,
but the generics are happy with it.
Some types may not have any invariants which may be usefully relaxed e.g.
Expand All @@ -67,18 +67,4 @@ necessarily what you want - indeed, it appears this sort of design would require
a @'Weak' a = a, weaken = id@ overlapping instance, which I do not want. On the
other hand, @[a]@ /does/ weaken to @['Weak' a]@, because there are no invariants
present to remove, so decomposing is all the user could hope to do.
Another problem is coercible newtypes such as @Tagged@ from the @tagged@
package. These have no invariants for us to weaken, so one's knee-jerk reaction
might be to weaken the inner type. But what if the user doesn't want to weaken
that inner type? They might be happy with using 'Data.Word.Word' instead of
'Numeric.Natural.Natural', for example.
strongweak provides a special type 'Coercibly' which permits precisely defining
how to weaken a newtype/pair of coercible types. For this reason, zero-invariant
coercible newtypes are excluded from the strongweak ecosystem (e.g.
'Data.Functor.Identity.Identity', 'Data.Functor.Const.Const', @Tagged@).
If your newtype puts the wrapped type as the final type variable, use
'Coercibly1' for a considerably simpler invocation.
-}
2 changes: 1 addition & 1 deletion strongweak.cabal
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ cabal-version: 1.12
-- see: https://github.com/sol/hpack

name: strongweak
version: 0.10.0
version: 0.11.0
synopsis: Convert between strong and weak representations of types
description: Please see README.md.
category: Data
Expand Down

0 comments on commit 35831d7

Please sign in to comment.