> Just because Haskell currently resolves its types through type-classes > does not mean we are forced to stop at type-classes for every aspect > of the implementation.
No, we are not forced to use type classes for everything. But it makes the language much cleaner, more flexible, easier to learn and easier to implement if we use existing structures rather than creating new ones. > Moreover, with our best proposal here we are > left in the peculiar position of declaring victory of resolving > through type-classes without annotations, but now requiring a new form > of type annotation for all record updates. It would make more sense > just to not go full force on the type-class resolution and instead > require a normal type annotation. If you have a notation for this which actually solves the update problems, you should say what it is. I haven't seen any such suggestion which really works. > The semantics that will be exposed to users have already been largely > decide upon. Please tell us what this agreed semantics is, so that we know what we have agreed to! > If we like, we can continue to debate the fine details of > the semantics we would like to expose. The problem is that we have > been mixing the semantics with the implementation details and using it > as an excuse to hold up any implementation. What? I have seen no discussion of implementation details at all. The translations I gave in my proposal could be used as the basis for an implementation, but the point of them was to give an unambiguous semantics for the new language features. I read the translations given by others in the same way: as semantics, not implementation. I assume that implementers would use some equivalent but more efficient method depending on the internals of ghc. Barney. _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
