Hi Jonathan,
On 27 Mar 2010, at 05:29, Jonathan S. Shapiro wrote:
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.
I can understand such concerns. May I ask the static analysis concerns
that you mention? I am quite interested in static analysis these days
as I moved to a static analysis group recently.
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.
Aha. So BitC does whole-program compilation? That would be very
interesting because I think you could remove quite a bit of overhead.
I will look at your work on polyinstantiation.
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.
Sounds reasonable, I would prefer not to introduce the keyword as
well, but since there seems to be an emphasis on performance, I
thought it could be helpful. However, if you can do whole-program
compilation then maybe, as you say, there is a good opportunity to
avoid the keyword.
Bruno
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
