On 18/01/2012, Greg Weber <g...@gregweber.info> wrote: > On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones > <simo...@microsoft.com>wrote: > >> >> But, the Has constraints MUST exist, in full glory, in the constraint >> solver. The only question is whether you can *abstract* over them. >> Imagine having a Num class that you could not abstract over. So you >> could write >> >> k1 x = x + x :: Float >> k2 x = x + x :: Integer >> k3 x = x + x :: Int >> >> using the same '+' every time, which generates a Num constraint. The >> type signature fixes the type to Float, Integer, Int respectively, and >> tells you which '+' to use. And that is exactly what ML does! >> >> But Haskell doesn't. The Coolest Thing about Haskell is that you get >> to *abstract* over those Num constraints, so you can write >> >> k :: Num a => a -> a >> k x = x + x >> >> and now it works over *any* Num type. >> >> On reflection, it would be absurd not to do ths same thing for Has >> constraints. If we are forced to have Has constraints internally, it >> woudl be criminal not to abstract over them. And that is precisely >> what SORF is. >> > > So I understand that internally a Has constraint is great for resolving the > type. > What is the use case for having the Has abstraction externally exposed? > > I think there is a great temptation for this because we would have a > functionality we can point to that has some kind of extensible record > capability. > > But I believe the Has abstraction to be a form of weak-typing more so than > a form of extensibility. Just because 2 records have a field with the same > name, even with the same type in no way signifies they are related. Instead > we need a formal contract for such a relation. We already have that in type > classes, and they can already be used for this very capability in a more > type-safe way. > > My point is that Has abstractions are weak types and that likely we should > be searching for something stronger or using type classes. If I am wrong > then we should have convincing use cases outlined before we make this a > goal of a records implementation, and still I don't see why it needs to be > a blocking requirement if we are just trying to solve the basic records > issue. > > > Greg Weber >
Has *is* a type class. It can be used and abused like any other. Record members with the same key ought to have the same semantics; the programmer must ensure this, not just call them all "x" or the like. Weak types these are not. The selector type is well-defined. The value type is well-defined. The record type is well-defined, but of course we define a type-class to let it be polymorphic. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users