In BitC, we have been leaning toward a lexical order resolution rule to resolve issues like this, but it hasn't been implemented yet.
On Wed, Mar 31, 2010 at 3:48 PM, Bruno Oliveira <br...@ropas.snu.ac.kr>wrote: > Hi, > > On Apr 1, 2010, at 4:19 AM, Jonathan S. Shapiro wrote: > > > On Tue, Mar 30, 2010 at 4:31 AM, Bruno Oliveira > > <br...@ropas.snu.ac.kr> wrote: > >> Hi Jonathan, > >> On 27 Mar 2010, at 05:29, Jonathan S. Shapiro wrote: > >> 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 is the obvious one: when any form of existential mechanism > > is introduced, the static analysis tool is forced into one of two bad > > positions (a) it must be conservative, or (b) it must do all-cases > > analysis. > > > > Existentials are necessary, but perhaps the language design for a > > reliable language should not make promiscuous use of existentials any > > easier than necessary. > > > >> 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. > > > > BitC does not specify whole-program compilation. The current compiler > > does whole-program compilation and compete static specialization, but > > that approach obviously won't scale. > > > > A correction to my statement above: specialization becomes infeasible > > when candidate instances are not unique. > > Just to be clear, with implicits multiple *implicit* candidate > instances lead to a > compile-time error just like type classes. In other words you can only > have *one* > candidate instance. Although you can have multiple dictionaries of the > same type > (which are not implicit) around. > > One situation that can happen is that you import two modules each with > their own > implicit candidate instances. In Scala what happens is that > essentially you have > to pass things explicitly to avoid a compile-type error. But another > possible alternative > would be to reject the module because such multiple instances exist. > If you have > a module system that allows selective import or hiding members (like > Haskell or Scala) > you could then resolve the conflicts by hiding one of the implicits. > > > So, for example, we can't > > easily specialize away sortBy. Or actually, we could (because the > > ultimate call site that supplies the ord instance is, in effect, > > supplying a literatl), but the code explosion would be quite horrible. > > > > Bruno > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
