On Wed, Jul 9, 2014 at 9:30 PM, Matt Oliveri <[email protected]> wrote:
> I disagree with your strong preference for neat type > inference. I think it would be a shame if BitC's type system gives up > useful expressiveness just because it makes type inference too hard. > Then I think you are missing something very, very important. For the most part, the big advantage of Python/Perl/etc. for prototyping is brevity: there's lots of stuff you don't have to write or think about. Type inference spans most of that gap, and I think it will be important to acceptance that BitC gives some of that prototyping feel. But the more important issue is that humans *can't* write static types correctly. In today's systems, the types involved are complex enough that when humans are asked to state them they come up with typings that are not complete. These two things become especially important when we start implementing DSLs using mixfix, which should be wildly popular if we can get that right. > On Wed, Jul 9, 2014 at 10:06 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > > > 1. Require type annotations, at least in certain cases > > 2. Give up complete inference, identifying the cases where the inference > > algorithm will require annotations. > > I'm not sure I can tell the difference in meaning between those two. > Are you saying only in the second case would we have some precise > general understanding of the limitations of the inferencer? I'm saying that if you are willing to sacrifice completeness of inference, you can choose not to *attempt* to infer some things in order to stay decidable. One problem with that is that if the programmer cannot correctly express the types, then it's not realistic to expect them to override the inference engine in places where the inference engine isn't doing the job automatically. But BitC already has a lot more annotation than, say, Haskell. It could well turn out that our termination conditions are different as a result. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
