On Tue, Feb 10, 2015 at 11:11 PM, Keean Schupke <[email protected]> wrote:
> Does the compiler do anything with curried arguments? A mistake I gave made
> in the past is to link currying with partial evaluation. They are not the
> sane thing, currying is simply a transform on the function type so the type
> system sees everything as a unary function. Many languages simply accumulate
> the arguments in a data structure and only run the function when complete.
> How aggressive is BitC's partial evaluation?
Partial-evaluation-the-compiler-optimization is certainly a different
thing, but currying does mean possible partial evaluation in all
curried languages. For example, the following two definitions make
very different beasts in ocaml *before* optimization:
let f x y = g x + h y
let f x = let gx = g x in fun y => gx + h y
Occasionally the compiler will be able to hoist the first into the
second, but I believe it's a requirement of bitc that the performance
semantics are sensible without worrying about optimization. Also, g x
could have side effects.
Geoffrey
> On 11 Feb 2015 00:41, "Geoffrey Irving" <[email protected]> wrote:
>>
>> Thanks for the detailed explanations, and apologies for the delay in
>> reply!
>>
>> On Sun, Feb 8, 2015 at 6:51 AM, Jonathan S. Shapiro <[email protected]>
>> wrote:
>> > There is another way we could possibly go on the currying issue: attach
>> > a
>> > Nat to the fn type. This would annotate every arrow with its preferred
>> > arity. So something like:
>> >
>> > define f x y = x + y:int;
>> > f : fn 2 int->int->int
>> >
>> > For output purposes, it's probably clearer to emit that as (int ->
>> > int)->
>> > int, though that won't work as an input syntax.
>>
>> Output syntax that doesn't work as input syntax seems sketchy.
>>
>> > A function typed this way could still be called in curried fashion, so
>> > it
>> > doesn't have any effect on the programs you can write. The advantage is
>> > that
>> > we can now express at module and assembly boundaries which calls will
>> > *not*
>> > induce closure formation. In consequence we are now able to perform
>> > efficient calls across module boundaries where previously we didn't have
>> > enough information to do that.
>> >
>> > Alternatively, we could continue to write function types similarly to
>> > the
>> > way we do now, which in this case would be:
>> >
>> > fn (int, int) -> int
>> >
>> > and simply allow a curried application syntax. I'm inclined to think
>> > that
>> > the important issue here is less about how the type is written than it
>> > is
>> > about whether curried application is supported/enabled.
>>
>> The "fn (int, int) -> int" way seems better, mostly because the int
>> approach doesn't generalize very well to complicated examples. In
>> particular, I routinely fine myself writing functions that look
>> something like
>>
>> f :: a -> b -> c -> d -> e
>>
>> except that it's really
>>
>> f : (a,b) -> c -> d -> e
>>
>> and significant amounts of precomputation happen after (a,b) and c
>> (before d). Thus, you really need an arbitrary number of ints, which
>> doesn't seem like it ends well.
>>
>> Geoffrey
>> _______________________________________________
>> 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
