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).
hey thanks for the extensive comments. We were not ready to hit HN per se, our web pages and examples certainly can use some brushing up. André Videla has been doing some nice work on tutorials, but it is hard to find. https://github.com/typedefs/typedefs/blob/master/TUTORIAL_UN...
As for your last question, for this we have been working on "specialization" where you would say Bool is actually Bool in Haskell and not Either Unit Unit etc.
I will try to see if I can address your questions properly as I refresh some copy on the homepage.
No problem! Glad if I can do a little part to help -- It's not that the tutorial / guide that is there is bad, it's just the order! I think a lot of people might try to jump in, since you can basically read protobuf/thrift as-is, but many might not have even heard of GADTs. It might make sense to put just a tiny blurb of an introduction (or even a code sample like bool) on that first page.
I think protobuf's main page[0] is the best example, and thrift's[1] isn't terrible.
Would probably make it easier for lazy developers like me to immediately understand what's going on, and how to be productive.
- 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:
The code that came out on the haskell side looks like this: 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/