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
