On Fri, Mar 26, 2010 at 6:29 AM, Bruno Oliveira <br...@ropas.snu.ac.kr>wrote:
> Neither the system proposed in this paper (In reference to: "Objects to > unify Type Classes and GADTs) nor Scala implicits (credits due to Martin > Odersky, not me :)) do constraint simplification. This also means that we do > not lose any late binding ability. > This makes perfect sense. The bias in the BitC design is a bit different. We're happy to *have* late binding, but very reluctant to be *forced* to late binding. There is more to this bias than issues of optimization. It also touches on concerns about static analysis. > The issue that you mention has been debated in essentially all the > proposals extending or inspired by type classes. Namely "Named instances for > haskell type classes", "Making implicit parameters explicit" and our paper. > You can find a summary in Section 5, under the paragraph "Named Instances > and Explicit Implicit Parameters". > Thanks for the pointers to these papers. These should be very helpful. And while I'm thinking about it, thanks for taking the time to participate here! > Also, I noticed that apparently performance is a big issue, so if you > are really concerned about this, why not something like Sandro has proposed: > > specialized class Eq 'a where > eq :: 'a -> 'a -> bool > > specialized notEquals :: Eq 'a => 'a -> 'a -> bool > > The specialised keyword would impose certain restrictions (perhaps no > explicit parametrization is allowed being one of them) to ensure that for > this particular class no abstraction penalty is paid, or to ensure that a > particular function is always specialized. > Offhand, I don't see any case where specialization is infeasible in the whole-program case. The reason is that all of the candidate dictionaries are compile-time constants. Because of this, our existing polyinstantiation approach would probably work just fine. A middle position would be to admit implicit parameters and just have the compiler emit two editions: one pre-specialized using the implicit defaults (and then partially evaluated to remove the dictionary indirection) and the other that takes a dictionary pointer and uses it. This approach would cover most cases, and it works reasonably when you aren't doing whole-program. My reluctance to introduce a "specialized" keyword is that this really ought to be an optimizer decision. Figuring out which ways the user should be encouraged to steer the optimizer is an interesting language design challenge. At the moment, I think my inclination would be to reserve the keyword but defer the implementation. It's easy to un-reserve the keyword later. shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
