
Structural Typing for Clojure - ahjones
https://github.com/marick/structural-typing
======
bmh100
This 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.

------
lbradstreet
I've had good luck with prismatic schema
[https://github.com/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.

~~~
loevborg
Prismatic Schema is wonderful. One useful property is that a schema is just a
regular data structure (often a map). So you're free to use regular data
structure processing functions:

    
    
        (def Customer {:customer-id s/Int, :address-id s/Int}
    
        (def ProcessedCustomer (merge Customer {:external-id s/Int}))

------
seivadmas
Important 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.

~~~
seliopou
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.

------
dj-wonk
I'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](https://github.com/bluemont/shape)

------
escherize
It would be interesting to see a "When structural-typing is better than
prismatic/schema" section in the readme. I read the readme, and I don't see
why you can't use something like s/validate instead of built-like. So instead
of:

    
    
        (type! :Point (requires :x :y))
        (some->> points
             (all-built-like :Point)
             (map color)
             (map embellish))
    

To keep it simple, as in the first example of the whirlwind tour, we could
use:

    
    
        (def Point {:x s/Any :y s/Any})
        (some->> points
             (s/validate [Point])
             (map color)
             (map embellish))
    
    

It's good that structural-typing does not use macros, instead building ontop
of specter which is pretty cool. So is there a performance enhancement?

It's clear that one should use structural-typing where an expertise with
specter has been attained, Not sure when else it's the best choice.

------
lkrubner
Our 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.

------
twsted
"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.

