On Thu, Feb 12, 2015 at 12:00 PM, Pal Engstad <[email protected]> wrote:
> I can see why curried syntax is nice in a theoretical sense (and > admittedly also some practical sense), but as you have observed, it has > real associated costs. My opinion is that in a systems programming > language, that you should not support currying syntax. > Pal: You make a number of good points here, but the interest in currying ultimately isn't an issue of syntax. Curry-style application derives from the fact that all function types in these languages have the form 'a -> 'b. This makes a long list of things easier mathematically. We didn't do currying in BitC v0, and the use of arity-aware function types made various things more difficult. Also, there are syntactic constructs that are facilitated by currying (e.g. pipelining) that let us write more trustworthy application code. I don't think we want to shut those out, even though we may not choose to use them in a kernel. I don't necessarily agree that we should not support currying. What I think is that we need to design in such a way that the coder always knows when allocation may occur. > Closures needs memory allocation (whether it is stack or heap), and > therefore the language needs to have hooks in place so that the developer > can specify where the allocation should take place. If given `add : int -> > int -> int`, and you write a term `add x` and nothing more, you have left > out some important information - where do you store the captured x? Even > if it was a constant, where do you store `add 1`? > Region types solve this. > Before you say “the stack”, remember – the stack isn’t free either, > especially in systems with thousands of light-weight threads. > So that's a *very* good point, but I think one cannot have this both ways. If the developer insists on using a construct that allocates, they need to accept that there is going to be a storage cost associated with the allocation. If they are working in highly constrained memory, perhaps that construct wasn't such a good choice. In the end, the real issue here is the idiom conventions that get adopted in the standard library, which is one reason I'm fighting so hard to make sure that allocations are syntactically obvious. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
