All: I certainly don't want to shut anybody down, but I think we've gotten to the point in this discussion where further issues may be best revealed by trying to implement what we have. The main new thing we have recognized since my last summary is that the arity really does need an explicit "slot" in the function type syntax. That's very helpful, because we had sort of known this and then forgotten about it.
I have residual concerns about parse ambiguities, but the only way to resolve those is going to be to play with some concrete syntax possibilities and see what happens. I'm hoping we'll be able to support the very spare syntax that ML and Haskell use. At a somewhat higher level, though, I want to say why I felt this conversation was worth the effort. It has very little to do with type theory, and a lot to do with usability and divergence. We presently (BitC v0) have an arity-aware language that seems acceptable for low-level systems kinds of things. In the context of the current discussion, it's main deficiency is that it doesn't have the ability (syntactically or conceptually) to generalize over arity. In very low level code, that is not an impediment. Generalizing over arity (or adopting currying) introduces hidden allocations that cannot always be compiled out. If that is the cost, then from a systems programming perspective the cure (arity generalization) is MUCH worse than the disease (arity specificity). At the same time, BitC can't succeed if it is *just* a low-level programming language. And the further we move up the functional stack in a system, the more compelling the arguments become for functional idioms. I think that is true from an expressiveness and safety-by-design perspective, but also from a performance perspective. At very low levels, the *only* way to get truly high-performance code is to write it intentionally and precisely. At higher levels, the best way to get high-performance code is to write it in such a way that the optimizer faces the fewest constraints on what it can do. One of the under-appreciated "secret sauce" ideas in pure programming and functional idioms is that it enables some very aggressive optimization. So for application code I feel very strongly that I want BitC to be able to express pure programs and (separately) functional idioms. The problem lies in the middle, in two senses: library code that stands between high-level applications and low-level systems code, but also code that will be used by both functional and systems applications and therefore stands in the middle from the perspective of syntactic idiom. This is the place where the "pass a single tuple" idiom breaks things down, because that's not the natural idiom for functional code, and the use of a distinctive *syntactic* idiom makes the use of such functions feel alien to one camp or the other. Because low-level code needs us to be arity aware, we can't go quite as far as adopting the fully liberal currying approach. That is: we can adopt the *syntax*, but not quite the same semantics or behavior. The reason I have pursued this whole thread is that I think it gives us a syntactic position that is, in practice, "close enough". In the majority of places, a programmer who wants to think in the curried style will be able to write code in a curry-style syntax and get the behavior that they naively expect. When they do not, they will get an explicit diagnostic from the compiler advising them that an arity mismatch has occurred, and it should be a fairly small matter to decorate the code with annotations that tell the compiler to introduce the missing lambdas. Conversely, the systems programmer who wishes to strongly avoid hidden allocations is not forced into a semantics that introduces them in hidden form. This is something that no other language having a high-level type system (at least to my knowledge) addresses in a rigorous way. I really want to thank all of you for staying with this conversation over SO many messages. Willingness to do so is one of the wonderful things about this list, and I appreciate it. It may not have occurred to you, but people actually *will* come along and read this these archives years from now and learn things from them. Every now and then I get a note out of the blue telling me how the EROS or Coyotos archives helped somebody learn about microkernels deeply. I suspect this list will have a similar effect one day. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
