Hi, Am Montag, den 15.07.2013, 21:57 +0000 schrieb Simon Peyton-Jones: > · note that the “seq” nonsense is because we allow user-defined > NT-values
Are you saying that seq is nonsense? Or that are you just telling me why we need seq? > · also note that to determine which NT values we can derive from > in-scope NT values, we have to do something very similar to type-class > solving. Eg. need NT [T] [S], have available ntList :: forall ab. NT > a b -> NT [a] [b], so use ntList to simplify NT [T] [S] to NT T S. Yes, as discussed. > Hence the following suggestion: revert from NT as a data value to NT > as a class. Thus > > class NT a b where > castNT :: a -> b > uncastNT :: b -> a We’ve discussed this proposal before. The only problem with it is that it will not allow the author of a type container which should be abstract to cast it in internal code; if that is ok then type classes are definitely the nicer way. I assume that the “real” NT class will be abstract and castNT/uncastNT exposed as normal functions, not class methods, so that the user does not create custom instances, right? > You might worry that instances are not scopeable. Quite right. If > you make an NT instance, *everyone* can see it. So don’t make a type > an instance of NT unless that’s want. This is not terrible; it just > means that you can’t make *local* NT instances, just as you can’t make > local Eq instances. The thing is that I don’t need local Eq instances; I can just call my local private myCustomEq. But I cannot create a local private coercion. I guess one can argue that if someone has such special needs, he will be able to figure out when to use unsafeCoerce, and just let them play in the rough outsides. So the missing feature can at least functionally approximated (just as it can be now). > Does that make sense? Nothing new here besides the point that the feature „private, unexposed NT coercions“ do not warrant the extra overhead of introducing new syntax and replicating the deriving feature on the function level, and I’ll take that point. I guess it doesn’t change the implementation a lot, although I probably can’t implement that in a plugin any more. Although it would actually be a useful thing if code for deriving new type classes can be added in a plugin :-) So I’ll soon start implementing that. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
