On 2 May 2015 06:43, "Matt Oliveri" <atma...@gmail.com> wrote:
> Hmm, what I remember is he was comparing typeclasses to ML modules, > and saying that typeclasses were more convenient for 95% of the code. > I don't know if this is what you're saying. You need to keep in mind > that the usefulness of typeclasses in Haskell is partially that it > complements explicit function arguments. It seems plausible to me that > typeclasses but no first-class functions would be miserable. Right, but ML modules are just a way of factoring out a common argument over several functions. The point is its still explicit. It seems passing ordering as a first class function is the least preferred solution, as you have to pass it everywhere. A module is slightly better because you can factor out the order, and have a whole set package that assumes the order is the same inside the package. However now you have to pass the package around explicitly. Type classes are even better because now you can have a set package that assumes everything had the same order and the code using the package does not have to pass the package nor the ordering around. > I guess what you're trying to say that the kind of resolution Prolog > does is like typeclass instance resolution, except not at the type > level. That makes sense. Yes, modulo backtracking, but actually backtracking is not that weird an extension to type class resolution, and with constraint kinds, you can directly ask logic problems to the type class resolver. > Well I dunno. Maybe. I don't know all that much about typeclasses or > logic programming. But you'd have a hard time getting me to write > anything serious in Prolog. And I rather doubt that this is what the > guy in the video had in mind. Prolog-like logic languages are great. Just look at how small the type inference algorithms I was showing are in logic, and how easy to read. They deal directly with tree-like structures, I often think Prolog is to trees what lisp is to lists. I am seriously considering writing the bootstrap compiler for my project in Prolog as a nanopass framework. I think this would be even better/easier for compilers than scheme due to the close match between pattern matching and clause resolution that allows you to directly write tree rewrite rules. I guess the guy in the video didn't have this in mind, but I think it is interesting. > Thank you for explaining what you meant. I think it's crucial to keep > in mind that coherent typeclasses complement other mechanisms for > organizing code. I don't see anyone trying to sell typeclasses as a > cure-all. Especially not me, since I'm still not all that clear on how > it helps. I think it is good to consider what each language feature brings to the table in isolation. I also think it is interesting to map the solution space and look for combinations that are not seen in actual languages. There may be good reasons for avoiding those combinations, or it may be that they are interesting points in the design space. Going back to the set problem, one thing we know is that all sets passes to fast-union must have the same order, so: - we can assume the order inside the definition of fast-union. - if we can determine the order from the type then we can specialise fast union, and we don't need to pass the order as it is implied from the type (type class case) - if the order is passed in as a value we cannot specialise it, here order is a record containing the cmp function identical to the dictionary that would be referenced at compile time in the type class case. This seems to fit with the use of implicits. The problem comes in deciding whether to use the passed instance or the global one. This only gets worse in nested functions, if you pass an instance of Ord do we expect all sub functions to respect it if we do not explicitly forward it. If we do, then we have no choice but to dynamically resolve all type classes as you never know which ones are in scope in the callers runtime environment (and I think dependent types have this problem too?). So I seem to have changed my position from one of supporting implicits, to one of rejecting them. But this means having two separate implementations of everything, one using type classes and one explicitly passed functions, which I don't like either. Keean.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
