4 ms·

Language-agnostic schemas based on Haskell's type system

80 points by setra 9y ago

bauerd 9y ago
The argument presented against JSON Schema in the readme is that is is too expressive. Can someone explain to me, as someone who's used JSON Schema before, why this should concern me? If I understand correctly, JSON Schema's semantics allow one to assemble imperative control structures. But so what? Context: I used JSON Schema to validate API responses against a schema (with RSpec in this case). Compiling a subset of Haskell's type system to a JSON Schema just seems completely overengineered to me?
- seagreen 9y ago
  Great questions (author here). > The argument against JSON Schema presented in the readme is that is is too expressive. Can someone explain to me, as someone who's used JSON Schema before, why this should concern me? If it doesn't affect you, then it doesn't affect you:) The people who is does concern are tool authors. Trying to make an editor that handles schemas including things like "if field A is a string and matches regex X, then field B must match schema Foo instead of Bar" is really hard. I believe the name for this in type theory land is dependent types. > Compiling a subset of Haskell's type system to a JSON Schema just seems completely overengineered to me? The subset of Haskell used is actually far, far simpler than JSON Schema. It's basically just parametric polymorphism and algebraic data types. They're my two favorite things from Haskell, and both are really simple.
  - akst 9y ago
    > It's basically just parametric polymorphism and algebraic data types. They're my two favorite things from Haskell, and both are really simple As a Haskell programmer I agree on the simplicity point, but you may want to use simpler terms if you're trying to sell someone on simplicity (in reference to parametric polymorphism and algebraic data types) Cool project though!
    - sjg007 9y ago
      So what are the simpler terms? Any examples?
      - akst 9y ago
        You could probably say Generics instead of Parametric polymorphism, while far less formal a lot more people will grok what you're getting at. I guess it's not so clear for algebraic data types, but I'd probably refer to swift enums or unions in elm as an example. Last time I suggested this, someone likened it to intellectualism, lol. I see it more as a communication, a thing that the typed functional community seems to struggle with
        akst 9y ago
        Sigh, I cannot edit my comment at this stage, but correction I meant *anti-intellectualism
- dom0 9y ago
  https://www.youtube.com/watch?v=3kEfedtQVOY https://www.youtube.com/watch?v=3kEfedtQVOY i.e. it's kinda unwise in some applications (e.g. arbitrary / untrusted schemas) to have to implement & run languages that are powerful enough to perform pretty much arbitrary computation.
moomin 9y ago
Saying that something is like Haskell's type system raises more questions than it answers: are there GADTs? Type Families? Phantom Types?
- seagreen 9y ago
  It's only like Haskell's type system compared to other schema languages (most of which don't even have product and sum types). Plate has parametric polymorphism, phantom types, and algebraic data types. It doesn't have typeclasses however (I don't see a way to implement them, thoughts here: https://github.com/seagreen/plate/issues/1#issuecomment-302893806 https://github.com/seagreen/plate/issues/1#issuecomment-3028...) and so advanced Haskell features like type families are out.
Ixiaus 9y ago
Neat. This reminds me quite a bit of the dhall language: https://github.com/Gabriel439/Haskell-Dhall-Library/blob/master/README.md https://github.com/Gabriel439/Haskell-Dhall-Library/blob/mas...
- seagreen 9y ago
  Interesting. I see Plate as a much less ambitious project since Plate values can't be functions. However, any comparison to one of Gabriel Gonzalez's projects can't fail to make my day:)
m-j-fox 9y ago
I love everything about this until he presents the syntax: album :: Schema album = ProductType (HM.fromList [ ("title", Builtin SString) , ("artist", Builtin SString) , ("tracks", Builtin (SSequence (Builtin SString))) ]) No thanks! > (It won't be hard to make this conversion automatic, though I haven't gotten around to it yet.) Well let me know when you get around to it.
holri 9y ago
What is the advantange to a relational sql/ddl schema?
- seagreen 9y ago
  Plate isn't really in the same space as SQL. SQL is such a shockingly good engineering choice that if you can use it I would. So even if Plate was done I would use Postgres instead of a Plate-based datastore inside my apps. Plate serves a different purpose: schema'ing human-readable formats like iCalendar (https://en.wikipedia.org/wiki/ICalendar)[1] https://en.wikipedia.org/wiki/ICalendar)[1] or JSON APIs. So even if you're using SQL within your app Plate may come in useful at the boundaries. [1] Even if iCalendar was in JSON you couldn't write a Plate schema for it for the reasons listed here (https://github.com/seagreen/plate/blob/master/docs/priorities.md#-ability-to-describe-existing-data-types-with-plate https://github.com/seagreen/plate/blob/master/docs/prioritie...), but it serves as an example of a common human-readable data format.
ewrcoffee 9y ago
If you are already a haskell shop and need some way to write JSON schema, this probably doesn't seem too much over engineer. On the other hand, if the purpose is just to limit the expressiveness of JSON schema, I think a runtime checking is more than enough (that's how we solved our problem). Since any data schema we write inevitably has a "validation" phase during our build process. And doing runtime checking during the build phrase allows more flexible and extensible validation; with less abstraction to be understood by the strawman.

80 points by setra 9y ago

The argument presented against JSON Schema in the readme is that is is too expressive. Can someone explain to me, as someone who's used JSON Schema before, why this should concern me? If I understand correctly, JSON Schema's semantics allow one to assemble imperative control structures. But so what? Context: I used JSON Schema to validate API responses against a schema (with RSpec in this case). Compiling a subset of Haskell's type system to a JSON Schema just seems completely overengineered to me?

seagreen 9y ago
Great questions (author here). > The argument against JSON Schema presented in the readme is that is is too expressive. Can someone explain to me, as someone who's used JSON Schema before, why this should concern me? If it doesn't affect you, then it doesn't affect you:) The people who is does concern are tool authors. Trying to make an editor that handles schemas including things like "if field A is a string and matches regex X, then field B must match schema Foo instead of Bar" is really hard. I believe the name for this in type theory land is dependent types. > Compiling a subset of Haskell's type system to a JSON Schema just seems completely overengineered to me? The subset of Haskell used is actually far, far simpler than JSON Schema. It's basically just parametric polymorphism and algebraic data types. They're my two favorite things from Haskell, and both are really simple.
- akst 9y ago
  > It's basically just parametric polymorphism and algebraic data types. They're my two favorite things from Haskell, and both are really simple As a Haskell programmer I agree on the simplicity point, but you may want to use simpler terms if you're trying to sell someone on simplicity (in reference to parametric polymorphism and algebraic data types) Cool project though!
  - sjg007 9y ago
    So what are the simpler terms? Any examples?
    - akst 9y ago
      You could probably say Generics instead of Parametric polymorphism, while far less formal a lot more people will grok what you're getting at. I guess it's not so clear for algebraic data types, but I'd probably refer to swift enums or unions in elm as an example. Last time I suggested this, someone likened it to intellectualism, lol. I see it more as a communication, a thing that the typed functional community seems to struggle with
      - akst 9y ago
        Sigh, I cannot edit my comment at this stage, but correction I meant *anti-intellectualism
dom0 9y ago
https://www.youtube.com/watch?v=3kEfedtQVOY https://www.youtube.com/watch?v=3kEfedtQVOY i.e. it's kinda unwise in some applications (e.g. arbitrary / untrusted schemas) to have to implement & run languages that are powerful enough to perform pretty much arbitrary computation.

moomin 9y ago

Saying that something is like Haskell's type system raises more questions than it answers: are there GADTs? Type Families? Phantom Types?

seagreen 9y ago
It's only like Haskell's type system compared to other schema languages (most of which don't even have product and sum types). Plate has parametric polymorphism, phantom types, and algebraic data types. It doesn't have typeclasses however (I don't see a way to implement them, thoughts here: https://github.com/seagreen/plate/issues/1#issuecomment-302893806 https://github.com/seagreen/plate/issues/1#issuecomment-3028...) and so advanced Haskell features like type families are out.

Ixiaus 9y ago

Neat. This reminds me quite a bit of the dhall language: https://github.com/Gabriel439/Haskell-Dhall-Library/blob/master/README.md https://github.com/Gabriel439/Haskell-Dhall-Library/blob/mas...

seagreen 9y ago
Interesting. I see Plate as a much less ambitious project since Plate values can't be functions. However, any comparison to one of Gabriel Gonzalez's projects can't fail to make my day:)

m-j-fox 9y ago

I love everything about this until he presents the syntax: album :: Schema album = ProductType (HM.fromList [ ("title", Builtin SString) , ("artist", Builtin SString) , ("tracks", Builtin (SSequence (Builtin SString))) ]) No thanks! > (It won't be hard to make this conversion automatic, though I haven't gotten around to it yet.) Well let me know when you get around to it.

holri 9y ago

What is the advantange to a relational sql/ddl schema?

seagreen 9y ago
Plate isn't really in the same space as SQL. SQL is such a shockingly good engineering choice that if you can use it I would. So even if Plate was done I would use Postgres instead of a Plate-based datastore inside my apps. Plate serves a different purpose: schema'ing human-readable formats like iCalendar (https://en.wikipedia.org/wiki/ICalendar)[1] https://en.wikipedia.org/wiki/ICalendar)[1] or JSON APIs. So even if you're using SQL within your app Plate may come in useful at the boundaries. [1] Even if iCalendar was in JSON you couldn't write a Plate schema for it for the reasons listed here (https://github.com/seagreen/plate/blob/master/docs/priorities.md#-ability-to-describe-existing-data-types-with-plate https://github.com/seagreen/plate/blob/master/docs/prioritie...), but it serves as an example of a common human-readable data format.

ewrcoffee 9y ago

If you are already a haskell shop and need some way to write JSON schema, this probably doesn't seem too much over engineer. On the other hand, if the purpose is just to limit the expressiveness of JSON schema, I think a runtime checking is more than enough (that's how we solved our problem). Since any data schema we write inevitably has a "validation" phase during our build process. And doing runtime checking during the build phrase allows more flexible and extensible validation; with less abstraction to be understood by the strawman.