4 ms·
I don't see how the Haskell example is more type safe than the Python example. In Haskell you will get None or Just a String. In Python you get an exception or
by peq 13y ago
I don't see how the Haskell example is more type safe than the Python example. In Haskell you will get None or Just a String. In Python you get an exception or a String. For me that is equivalent, but maybe you have a different definition of type safety?
I think without a schema for the json data we cannot make this any more type safe.
- tel 13y agoI agree completely that this example is not fully type safe---there is an implicit, partial schema where either Python exceptions or Haskell Nothings imply validation failure, but that's beside the point. The example written has a lot of type resolution done implicitly by the typeclass mechanism. It ensures that only valid lens-like combinators are applied to the traversal chain... which is only an issue due to how far we can flex the lens library to do other things. A better example is the somewhat more explicit version of this code it ^? _JSON . _Array . nth 0 . _Object . key "someObject" . _Object . key "version" . _Array . nth 1 Where the _JSON, _Array, nth, _Object, and key declarations must match otherwise its a type error. Furthermore, the `nth` and `key` calls are both just type-restricted aliases for `ix` which help to convey via types what kinds of very general tools should be applied here. We could also, for instance, throw another _JSON Prism into the chain to do a nested, schema-based validation for any types which have ToJSON/FromJSON instances.