I'd love to use this (and probably will try eventually) , but the try.typedefs.com[0] example is hard to penetrate.

    ; Booleans correspond to a sum of unit types.
    (name Bool (+ 1 1))

I'm familiar with Lisp/S-Expressions, Haskell, ADTs and this still threw me for a loop, even with the generated Haskell code on the right. Why have you chosen terseness at the cost of approachability? Without looking at the intro page[1], I couldn't figure out how in the world this syntax created a boolean type. Here's my thought process:

- OK, we're making a name (I guess that's a type? why is it not called that?)

- "Bool" -- OK we're making the haskell Boolean type

- "(+ 1 1)" -- What? Bool is 2?

- (At this point I looked over to the right at the Haskell code, read it to discover that it's 0/1)

- Oh OK, '+' must be sum? but why would I sum 1 with itself? is it a 1 and 1? 1 must not be numeral...

At this point I went back and read the introduction and it was clear but please, don't point people to the try page without giving them a brief syntax intro. That, or change the syntax to actually be a bit more approachable -- why not `unit` instead of `1` or `sum` instead of `+`? At least the option would be nice..

I wonder if there's been consideration of leaving some space/ability for people to add custom implementations/overrides for some of the translations? Less so in the Haskell case since it just compiles to something byte-encodable, but I don't want booleans in my JSON to be represented by {"case0": "singleton"} and {"case1": "singleton"}. I know this breaks the purity and generality of the solution but if it's going to see real-world use I think this complaint will come up.

Also, there's the distinction when structure is included or not -- it looks like there is a discrepancy between haskell and jsonschema in that one is structure/schema included and the other is not, is that intended? Any client can read the JSON schema, but not any Haskell client can read the haskell code -- AFAICT boolean is just... 0/1 sitting in a byte stream, untagged. I guess this is another thing that goes against the generality and purity of the solution, but I sure would like to be able to have tooling that can tell me I'm dealing with Product type containing two bools... I tried it out:

    ; Booleans correspond to a sum of unit types.
    (name Bool (+ 1 1))

    (name BoolTuple (* Bool Bool))

The code that came out on the haskell side looks like this:

   -- ... snip ....

   encodeBoolTuple :: Serialiser BoolTuple
   encodeBoolTuple x = case x of
                      (y,y0) -> mconcat [(encodeBool y),(encodeBool y0)]

    decodeBoolTuple :: Deserialiser BoolTuple
    decodeBoolTuple = do
                    x <- decodeBool
                    x0 <- decodeBool
                    return (x,x0)

So just... two 0/1s on the wire and that's it? Efficient yes, but I think it'd be nice to be able to tell I got handed a tuple with 2 elements (even if I don't necessarily know they're both booleans, though it'd be nice to know they were a well-known boolean type).

[0]: https://try.typedefs.com

[1]: https://typedefs.com/introduction/