[CraigJPerry]

>> Is this refinement types

Well it does include that kind of behaviour but it's quite a bit more than just that. E.g. you could express something like "the parameter must be a date within the next 5 business days" - there's no static restriction. I'm not necesarily saying you should but just to give an illustrative example that there's less restrictions on your freedom to express what you need than in a static system.

>> types are isomorphic with schemas

I don't think that's a good way to think of this, you're imagining a rigid 1:1 tie of data and spec yet i could swap out your spec for my spec so that would be 1:n but those specs may make sense to compose in other data use cases so really it's m:n rather than 1:1

[dharmaturtle]

> E.g. you could express something like "the parameter must be a date within the next 5 business days" - there's no static restriction

Hm, I don't follow. If I were to write this in F#, there would be a type `Within5BusinessDays` with a private constructor that exposes one function/method `tryCreate` which returns a discriminated union: either an `Ok` of the `Within5BusinessDays` type, or an `Error` type with some error message. Once I have the type, I can then compose it with whatever and send it wherever and since F# records are immutable, I won't have to worry about invariants not holding. And since it's a type, I have the compiler/type system on my side to help with correctness.

(Side note, this is a bad example since the type can become invalid after literally 1 second... but since Clojure has the same problem I'm just running with it.)

I'm still learning Clojure (only a few months into it), but if I were to to write a spec, I'd have to specify what to do do if the spec failed to conform - same as returning the `Error` case in F#.

> i could swap out your spec for my spec so that would be 1:n but those specs may make sense to compose in other data use cases so really it's m:n rather than 1:1

Sorry, but I'm still not following - I believe you can do the same with types, especially if the type system support generics.

[CraigJPerry]

> If I were to write this in F#, there would be a type `Within5BusinessDays`

That’s not really the same thing - it’sa valid alternative approach but you’ve lost the benefits of a simple date - from (de)serialisation to the rich support for simple date types in libraries and other functions, the simple at-a-glance understanding that future readers could enjoy. Now the concept of date has been complected with some other niche concern.

> the type can become invalid after literally 1 second

Every system I’ve ever seen that has the concept of a business date strictly doesn’t derive it from wall clock date. E.g. it’s common that business date would be rolled at some convenient time (and most often not midnight) so you’d be free to ensure no impacts possible from the date roll.

>> I believe you can do the same with types, especially if the type system support generics

You can do something similar but you’ll need to change the system’s code.

It would be almost like gradual typing, except you could further choose to turn it off or to substitute your own types / schema without making changes to the system / code.

It’s quite a lot more flexible.

(Apols for slow reply - i 1up’d your reply earlier when i saw it but couldn’t reply then)

[dharmaturtle]

> but you’ve lost the benefits of a simple date

I see what you mean - thanks!

> you could further choose to turn it off or to substitute your own types / schema without making changes to the system / code

This is still unclear to me. How can you make changes (turning off gradual typing/substituting your own schema) without making changes to code?