Structural Typing for Clojure
github.com
Structural Typing for Clojure
1–10 of 14 posts
Re: Structural Typing for Clojure
#2This seems to me like a very practical way to approach Clojure typing. Similar to the author, I have often needed to make a series of transformations on complex objects. Those transformations mostly depended on the presence of certain keys, so having strict types was unnecessarily rigid. Derived typing would also be useful, of course.
One point to appreciate about this approach is the flexibility in only worrying about the relevant pieces. In my case, I may be worrying about whether a continuous variable has been tagged "datetime", requiring additional processing steps. Merely checking for such tags allows the input data to implicitly direct the flow of the program, reducing the coupling between data and specific processing implementations.
Re: Structural Typing for Clojure
#3Our software system currently uses Redis as a central bus, and around that we have a dozen apps that send a hashmap back and forth among themselves. We use Carmine/Nippy to serialize and deserialize the hashmap, so we never have to think about anything other than a hashmap. All the bugs we face are because of missing or misused fields in the hashmap. For us, a combination of structural typing and Nippy could potentially protect us from 90% of the bugs we have seen so far.
Re: Structural Typing for Clojure
#4Important to note that this isn't STATIC typing (which detects errors at compile-time), rather this is more like a validation library to make sure structures have certain properties at run-time.
Not saying it isn't useful, in fact I have a project in which this would be a very good fit and I might even implement it there.
Re: Structural Typing for Clojure
#5I've had good luck with prismatic schema https://github.com/Prismatic/schema, which seems to be along a similar direction. It's fairly low commitment and can lead to big gains fairly quickly. I assume this would be similar.
Re: Structural Typing for Clojure
#6Important to note that this isn't STATIC typing (which detects errors at compile-time), rather this is more like a validation library to make sure structures have certain properties at run-time. Not saying it isn't useful, in fact I have a project in which this would be a very good fit and I might even implement it there.
Indeed. Elm implements extensible record types that can be inferred and checked statically. Similarly to object types in OCaml, which additionally supports structural subtying of of other sorts as well (e.g., polymorphic variants). It's a little strange to compare this library with Elm.
This looks like a contract library, which I assume already exists in Clojure. It'd be interesting to see what's unique about this implementation, if anything.
Re: Structural Typing for Clojure
#7I've also been thinking about types, validation, and structure. I see room for various approaches, including static typing, validation, and more. For example, here's an in-progress library that I plan to build out soon: https://github.com/bluemont/shape
Re: Structural Typing for Clojure
#8"somewhat inspired by Elm".
We are seeing a trend here.
Speaking as one who is trying to use more functional languages and starting to love Elm.
Re: Structural Typing for Clojure
#9Important to note that this isn't STATIC typing (which detects errors at compile-time), rather this is more like a validation library to make sure structures have certain properties at run-time. Not saying it isn't useful, in fact I have a project in which this would be a very good fit and I might even implement it there.
Right, this is basically a validation library
Re: Structural Typing for Clojure
#10I've had good luck with prismatic schema https://github.com/Prismatic/schema , which seems to be along a similar direction. It's fairly low commitment and can lead to big gains fairly quickly. I assume this would be similar.
After assessing the lib, I still prefer schema. I find that it's always more convenient that you can separate the schema and the data itself.