Types as Interfaces

Post by bombela » Tue, Jul 23, 2024, 7:04 PM UTC

oasisaimlessly wrote: post #130

bombela wrote: post #124

Earlier quoted context omitted.

> In the string -> Email example, it's probably enough to parse your string and just call it an email. You don't need to try to encode all the rules about an email into the type itself. There is also the in-between Rust approach. Start with the user input as a byte array. Pass it to a validation function, which returns it encapsulated within a new type. #[derive(Clone, Hash, Ord, Eq...)] struct Email(Box ); // valida…

AKA the "parse, don't validate" approach [1]. 1: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

    - validate(raw) -> void
    - parse(raw) -> Email | Error

Post by valcron1000 » Tue, Jul 23, 2024, 7:15 PM UTC

spankalee wrote: post #110

This is a lot of complication for in what most OOP languages with interfaces would simply be something like: interface Timestamped { timestamp: UTCTime; } interface Msg { sender: PlayerId; } class Quote implements Timestamped, Msg { timestamp: UTCTime; sender: PlayerId; } Why is this so hard in Haskell? It doesn't have interface polymorphism?

    class HasRecipient a where
      get_receiver :: a -> PlayerId

    class Timestamped a where
      timestamp :: a -> UTCTime

Post by BugsJustFindMe » Tue, Jul 23, 2024, 7:32 PM UTC

CyberDildonics wrote: post #144

BugsJustFindMe wrote: post #35

Earlier quoted context omitted.

> interfaces describe behavior, types describe shape and structure Shape and structure are behavior. There's more to behavior than "abstractly produces X result". Behavior is "produces X result in Y form given Z in W form".

Shape and structure are behavior. They shouldn't be. Conflating two things that can be separated is just compounding complexity. You don't need to know how a database lays out memory or the structure behind a web server.

Post by diffxx » Tue, Jul 23, 2024, 7:36 PM UTC

thesuperbigfrog wrote: post #109

taeric wrote: post #77

Earlier quoted context omitted.

I regret to say that every type level Gordian knot that I have ever been exposed to came from attempts to do this. I think a lot of the problem is that many of the constraints and acceptable values for data are not determined until well after first deployment. The "knot" comes in when you are explicitly changing data and code to add a feature that you didn't anticipate at the start. This is a lot like schemaless data…

>> This is a lot like schemaless databases. The flexibility of not having to fully specify the full schema does not mean that you don't benefit from specifying parts of it? Indeed, if you are indexing things, you have to specify those parts. But it is hard to argue with a straight face that schemaless tools don't have some strong benefits. This is very similar to what Rich Hickey argued in "Simplicity Matters": https…

Post by taeric » Tue, Jul 23, 2024, 7:45 PM UTC

skybrian wrote: post #135

thesuperbigfrog wrote: post #109

Earlier quoted context omitted.

>> This is a lot like schemaless databases. The flexibility of not having to fully specify the full schema does not mean that you don't benefit from specifying parts of it? Indeed, if you are indexing things, you have to specify those parts. But it is hard to argue with a straight face that schemaless tools don't have some strong benefits. This is very similar to what Rich Hickey argued in "Simplicity Matters": https…

Protobufs are an interesting hybrid. They assume a common, linear history of schema versions, where all data generators had access to an arbitrary version in that history. The schemas define field ids and types, but not which combinations of fields can show up. If you can upgrade all the data then you don’t need to worry about versioning, Or you can do it like HTTP headers and hope for the best.