On Thu, Feb 12, 2015 at 1:52 AM, Keean Schupke <[email protected]> wrote:
> On 12 Feb 2015 09:21, "William ML Leslie" <[email protected]> > wrote: > >> BitC cannot entertain the same level of magic as other languages might be >> able to get away with. We want native performance out of what may be >> generic or higher-order calls. > > I disagree with this. The type system has nothing to do with the > implementation. I think you can have c/c++ performance with a 'magic' type > system. > Hold up, guys. William is saying something important, but so is Keean. Let's back up. I would personally prefer not to encode arity in function types. It's undesirable for quite a number of reasons. The reason we are looking at arity in function types is that (a) we need to be able to declare function signatures for *external* functions in such a way that the external calling convention will be honored, and (b) nobody has been able to show me how to get a native argument passing convention from arity-less function types without whole-program compilation, and in some cases not even then. If Keean knows a way to do that, I'm very happy to listen. We haven't found one, and we've been looking for several years. Don Syme didn't find one either, and he knows a lot more about this stuff than I do. Keean says: "the type system has nothing to do with the implementation". The BitC perspective rejects this. I feel that it is a very good summary of why functional languages are mostly useless for building performance-intensive programs. The type theory community is very enamored with the mathematics of type systems, and has paid little attention to pragmatics. From a historical point of view this was intentional. An active decision was made to learn how to do typings without regard to representation, because they were too hard to do at the same time. At some point that rationale failed to get conveyed forward, with the result that many people in the type theory community now perceive pragmatics as somehow "impure" (in the religious sense) or even sacrilegious. BitC doesn't have an int32 type because I am in love with two's compliment arithmetic over a ring algebra. BitC has an int32 type because a systems language *must* be able to express an arithmetic type that allows the user to express specifically what the underlying machine should do. If it will help us, somehow, to use the term "type" to refer to all of that clean mathematical stuff, and to separately talk about "pragmatics inference", that's fine. I personally don't feel that is helpful, but if it assists people to think about the problem that's a useful thing. Getting back to arity, the *only* reason that I am looking to encode arity in function types is that we have never been able to find a way to infer arity without breaking other design constraints on the language. Our choices are to encode arity or to adopt the F# solution (which is to pass an argument tuple). There are two reasons that I do not like the "pass by tuple" approach: 1. It places the burden of greater syntactic weight on the more efficient calling approach. This does not seem like a good choice for a systems language. 2. It will lead to code bifurcation in various libraries. If we can find a way to reconcile the two calling conventions, the entire "system" of the language will benefit. I'm not at all happy about boogering our type system in order to get arity inferred. Keean: You've made a number of statements about inferring arity that rely on whole-program analysis or static visibility of a function definition. Neither assumption can be admitted in BitC in the general case. Given that we cannot rely on those two assumptions, do you know a solution? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
