Hi, Not that I should have much say, but I'm with Geoffrey. I don't think we should support currying.
PKE -----Original Message----- From: bitc-dev [mailto:[email protected]] On Behalf Of Geoffrey Irving Sent: Tuesday, February 24, 2015 4:24 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Arity inference at call (application) sites On Tue, Feb 24, 2015 at 4:19 PM, Matt Oliveri <[email protected]> wrote: > Here's what I think the situation is in this discussion: > - Matt (me), Shap, and William are skeptical that subtyping can be > implemented without introducing allocations. > - Keean doesn't see how subtyping would make it any harder to avoid > introducing allocations. > - Pal has joined in, but I'm not sure what his take is. > - Matt Rice keeps bringing up SML records, and I'm not sure why. > (Sorry, Matt.) > - Everyone else has been silent for a while. I'm silent mainly because I'm in favor of the option that is already understood by everyone: don't curry. :) We can make the common case look like curried syntax in terms of few parentheses, we've already agreed to ban the most useful kind of currying (fewer arguments) due to allocations, and I don't think the less useful kind of currying (more arguments / implicit sequenced calls) is worth the apparent complexity. Geoffrey > Again this is what I think is the situation. It's how it seems to me. > Please correct me if I'm wrong. > > But if I'm right, can we stop talking about subtyping for a while, and > tie up the other loose ends? The ones that are on my mind are > 1) deep vs. shallow arity variables vs. type constraints > 2) application-driven specialization without using subtyping > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
