On Thu, Feb 19, 2015 at 11:16 PM, Matt Oliveri <[email protected]> wrote:
> So if we start with > fn arity a->b->c->d->r > > and we want call it with two arguments, you say we get > fn 2 a->b->c->d->r > > ...There's still a choice of native arity to be > made. So I propose it should really be written: > fn a b -> fn newarity c->d->r > Yes. Sorry. That's correct, and with the arity variable made explicit that is how it should be written. > Well OK, so actually I hate that notation. What I'm trying to say is > that your arity-indexed family version of things doesn't seem to > capture how things can be specialized in multiple steps. In this > Frankenstein notation, we have an arity-concrete function returning an > arity-abstract function, which is what I think should happen when you > pick its arity. But where does newarity come from? > I'm not interested in defending the notation, except to the extent that it is allowing us to talk through this with a common lexicon at the moment. newarity will unify out. Usually because that arity-2 function has a concrete result type, but possibly later when a parameter specializes shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
