4 ms·
For context, Haskell's story for orphan instances is currently as follows: - orphan instances are allowed and emit a warning - duplicate instances are not all
by kreetx 2y ago
For context, Haskell's story for orphan instances is currently as follows:
- orphan instances are allowed and emit a warning
- duplicate instances are not allowed
- overlapping instances where one is different from the other, are allowed
- incoherent instance use sites are not allowed (where 2+ instances match and neither is more specific than the other)
- but you can enable this by adding {-# INCOHERENT #-} to instances. You shouldn't do this though unless you really know why you need it (and perhaps even then there is a better way)
- a typical library sets all warnings as errors with -Wall, so you'll notice when you're adding orphans
- exceptions in specific files can be made by adding -fno-orphans to the file
- defining orphan instances in executables is not a problem as the only user of them will be the program itself
- this is what you do if you are writing a package which only provides instances: where both the data types and the type classes are implemented elsewhere and you have no other choice. These libraries should not be used in other libraries, but only in executables and tests
- a different instance can also be defined by wrapping the original type with a newtype (thus defining that new instance for this new type, thus not making an orphan)
- since newtypes have no runtime overhead, also, with DerivingVia, syntactic overhead is quite low. This is "the way" to override already defined instances.
IMO, all the above makes sense when you prefer correctness over flexibility. From the post, this appears to be Rust's choice as well.
- klabb3 2y agoThe newtype pattern is a special case of type composition which is incredibly useful, has low complexity, and if done right almost no boilerplate overhead. It's much dumber and easier to reason about than type-acrobatics with generics, imo.
- kreetx 2y agoDo you mean `Generically`[1]? I've only ever vaguely seen its use - perhaps it can do something a `newtype` can't (or can, but with more boilerplate)? But don't have any first-hand experience currently to comment. [1] https://hackage.haskell.org/package/base/docs/GHC-Generics.html#t:Generically https://hackage.haskell.org/package/base/docs/GHC-Generics.h...
- klabb3 2y agoI meant in a general context (I know Go or Rust allows it in a decent way), not familiar enough with Haskell..
- itishappy 2y agoIt's the same in Haskell as in Rust. Using the example from the article: struct A2(A); impl BTrait for A2 { fn random_number(&self) -> usize { 4 // chosen by fair dice roll, still! } } In Haskell that translates to: newtype A2 a = A2 a instance BTrait (A2 a) where random_number _ = 4 Unfortunately, I also share GP's confusion. Can you share an example of what you mean by "type acrobatics with generics"?
- kreetx 2y agoIf it's the same, what is the blog posts problem then?
- itishappy 2y agoIt kinda sucks in both! If you want to interact with your newtypes, you need to either unwrap it or reimplement each typeclass/trait. Haskell does make this a bit nicer with deriving strategies, and Rust with macros, but it's a lot of boilerplate. The article had this to say about the example: > I’m sure it won’t take much to convince you; this is unsatisfying. It’s straightforward in our contrived example. In real world code, it is not always so straightforward to wrap a type. Even if it is, are we supposed to wrap every type for every trait implementation we might need? People love traits. That would be a stampede of new types. > Wrapper types aren’t free either. a_crate has no idea A2 exists. We’ll have to unwrap our A2 back into an A anytime we want to pass it to code in a_crate. Now we have to maintain all this boilerplate just to add our innocent implementation.
- filleduchaos 2y ago> If you want to interact with your newtypes, you need to either unwrap it or reimplement each typeclass/trait ...or you could just e.g. implement Deref in Rust? In my experience that solves almost all use cases (with the edge case being when something wants to take ownership of the wrapped value, at which point I don't see the problem with unwrapping)