release 0.1.1

Author: raehik

CHANGELOG.md

@@ -1,3 +1,7 @@
+## 0.1.1 (2023-07-20)
+  * add work-in-progress store-style generic `foldMap`, encoding constructors by
+    their index, at `Generic.Data.Function.FoldMap.SumConsByte`
+
 ## 0.1.0 (2023-06-23)
 Initial release.
 

README.md

@@ -7,6 +7,36 @@ Haskell data types. We handle the sums of products representation; you only need
 to pass a handful of definitions. Obtain simple, type-safe generic
 serializers/reducers and parsers for almost zero effort.
 
+Well, OK, so really this is a generic binary serialization library. It just so
+happens that the generics look like `foldMap` and `traverse`.
+
+## Really?
+Kind of. We only handle *sequential concatenation*, being cleanly represented by
+builtin type classes. Weirder cases like JSON parsing/serialization have more
+going on, and aren't sensibly discussed generically. So you are probably only
+going to use this with bytestrings and simple binary formats.
+
+## Why?
+It is 2023. There are a number of competing parsing and serialization Haskell
+libraries, recently some notable high-performance ones. These are often fairly
+experimental. Maybe you want some generics to benchmark some real-world use case
+against popular libraries like binary and cereal. But maybe generics aren't
+provided. Shucks.
+
+That's a shame, because a binary/cereal-esque generic binary parser or
+serializer doesn't have much work to do:
+
+  * traverse the generic sum-of-products tree of the given type left to right
+  * defer to the appropriate type class for base cases
+
+Sum types necessitate a little more work. Otherwise, most such parsers and
+serializers look fairly comparable to each other. Why are we rewriting this
+stuff over and over again?
+
+generic-data-functions provides *reusable generics* which have holes in for your
+favorite parsers and serializers. Fill out a few definitions to receive a fresh
+new generic instance for your own library, without all the boilerplate.
+
 ## Functions
 ### `foldMap` (L->R)
 ```haskell
@@ -45,47 +75,3 @@ life, Jim.
 
 ## License
 Provided under the MIT license. See `LICENSE` for license text.
-
----
-
-senserial is a small library providing reusable generics for (binary) parsers
-and serializers. No need to muddle through boilerplate generics that look the
-same as everyone else's; just provide a few definitions and senserial can give
-you powerful generic instances.
-
-Currently an unofficial library, distributed as part of binrep. Reader, please
-let the author know if you'd like it released separately.
-
-## Why?
-It is 2023. There are a number of competing parsing and serialization Haskell
-libraries, and some notable high-performance binary serialization libraries.
-These are often fairly experimental. Maybe you want some generics to benchmark
-some real-world use case against popular libraries like binary and cereal. But
-maybe generics aren't provided. Shucks.
-
-That's a shame, because a pure generic binary parser or serializer doesn't have
-much work to do:
-
-  * traverse the generic sum-of-products tree of the given type left to right
-  * defer to the appropriate type class for base cases
-
-Sum types necessitate a little more work. Otherwise, most generic binary parsers
-and serializers look fairly comparable to each other. Why are we rewriting this
-stuff over and over again?
-
-senserial provides *reusable generics* which have holes in for your favourite
-parsers and serializers. Fill out a few definitions to receive a fresh new
-generic instance for your own library, without all the boilerplate.
-
-## Really?
-Kind of. In reality, this library can only handle cases where no configuration
-is needed other than what is provided in the data type itself. senserial
-provides the generic traversal, and you can't alter that. Plus, the only
-often rewritten and straightforward traversal I can think of is sequential field
-concatenation. So though the code isn't limited to bytestrings and binary
-serialization formats, you will have trouble using it for anything else, because
-anything else will probably require a very different traversal (e.g. JSON
-serialization).
-
-In short, the primary use of this library is to pull out the common generics
-patterns from binary serialization libraries for easy reuse.

TODO.md

@@ -1,5 +1,5 @@
 # generic-data-functions to-dos
-  * release on Hackage, it's super useful
+  * add tests (steal some from binrep?)
   * provide a different `traverse` that inspects field names, to eventually
     replicate Gabriella's optparse-generic
   * provide a mixed sum & non-sum generic derivation like my original (& Aeson)

generic-data-functions.cabal

@@ -5,7 +5,7 @@ cabal-version: 1.12
 -- see: https://github.com/sol/hpack
 
 name:           generic-data-functions
-version:        0.1.0
+version:        0.1.1
 synopsis:       Familiar functions lifted to generic data types
 description:    Please see README.md.
 category:       Data, Serialization

package.yaml

@@ -1,5 +1,5 @@
 name: generic-data-functions
-version: 0.1.0
+version: 0.1.1
 synopsis: Familiar functions lifted to generic data types
 description: Please see README.md.
 extra-source-files: