On Tue, Feb 24, 2015 at 5:57 PM, Matt Rice <[email protected]> wrote: > On Tue, Feb 24, 2015 at 5:21 PM, Matt Rice <[email protected]> wrote: >> On Tue, Feb 24, 2015 at 4:19 PM, Matt Oliveri <[email protected]> wrote: >>> - Matt Rice keeps bringing up SML records, and I'm not sure why. (Sorry, >>> Matt.) >> >> No apology necessary really I probably should though, since i in >> general suck at explaining >> >> In general the places I use currying are more for partial >> specification of type, that is the type of some subprogram (function) >> is a partial specification of the type of the caller, and this usage >> is trivially done without allocation with e.g. real hygenic macros... >> >> from the discussion focusing on currying syntax, and the focus on >> partial application of expressions on some value, It seems like we may >> get that but still lack partially typed subprograms, which is what I >> find important in the whole thing, if it allows me to write these >> curried accessors without the allocations, and in that sml case it >> shows a) how this feature of sml complicates the whole matter through >> functions which return and accept abstract types as parameters that >> can only become concrete through further passed parameters later in >> the chain b) how it leads to unfamiliar types of errors. >> >> that is I don't much care about curried style function application >> except as it pertains to the curry-howard correspondance and typing >> through usage > > I think if i could amend this I think i'd say what i've been trying to > get across, is It seems to me entirely that the > allocation-requirements are a structure of usage and not necessarily > of the arity of the initiating call, and thus fixing this as curried > application syntax is the 'low hanging fruit', given the length of > messages corresponding to this low hanging fruit though I should > probably give up :)
This probably didn't come across as intended, what I mean is that we approach the case in the form only for functions which return functions, but I gather we expect types which are not functions and when returning any type which contains a function this callers choice of whether to allocate breaks down and we end up with a possibly overzealous function annotation which may/may not be optimized out, so this is just general discontent with things I consider to be ad-hoc, but also .. I believe that this callers choice of allocating lambdas *is* an improvement, and it's unforunate there isn't you know... rainbows everywhere. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
