[bitc-dev] Function arity (again)

[Steve Jenson]

Scala's explicit currying syntax might be something to model here.

def foo(a: Int, b: Int): Int
 is the standard uncurried form

def foo(a: Int)(b: Int): Int
is the curried form.

You can go from one to the other with curry (I think this is changing
in 2.8, I get deprecation warnings)

scala> (foo _).curry
res0: (Int) => (Int) => Int = <function1>

scala> res0(1)
res1: (Int) => Int = <function1>

scala> res1(2)
res2: Int = 3

Best,
Steve


On Sat, Mar 27, 2010 at 10:23 PM, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> As some of you know, I've gone back and forth on currying. The other
> night I realized that there are really two separate issues involved:
>
> 1. Support for partial application (i.e. application in which not all
> arguments are provided). This actually is not difficult.
> 2. Making sure the programmer is able to understand which applications
> will incur heap allocations. This is somewhat harder.
>
> While currying is useful, and provides key idiom support in ML and
> Haskell, it's something that the programmer would mostly like to avoid
> in systems code. This brings me to two issues:
>
> REPORTING/RESPECTING ARITY
>
> Once you introduce curried-style types and syntax, there really isn't
> a good way to declare arity anymore. For example, in O'Caml:
>
> # let multiply x y = x * y;;
> val multiply: int -> int -> int = <fun>    // correct, and expected
> # let multiply2 x = (fun y -> x * y);;
> val multiply2: int -> int -> int = <fun>  // correct, but undesired
>
> The problem with this is that the information about arity has been
> lost. Given that correct use of native calling conventions actually
> relies on this knowledge, it's moderately awkward to have lost it. For
> the second type, I would have preferred to see:
>
> val multiply2: int -> (int -> int) = <fun>  // correct, but undesired
>
> I fully understand that the two types are mathematically identical,
> but annotating which arrow distinguishes call from return nonetheless
> seems like a good and useful thing in a systems-oriented language, and
> seems fairly harmless to those accustomed to ML/Haskell. Would people
> coming from ML/Haskell find this impossibly strange?
>
> AVOIDING ALLOCATION
>
> When partial applications are permitted, there is still a strong
> desire to avoid performing them inadvertently. Unless an explicit
> application syntax is introduced to indicate that partial application
> is intended, I see no good way to deal with this. I can see two
> sensible ways to annotate this intent:
>
>  1. With a module-level annotation indicating that the module makes
> intentional use of currying
>  2. With an explicit application syntax, e.g.
>        multiply . x
>
> Given the ability to write a lambda explicitly, I'm actually not very
> convinced that partial applications are critical, and they pose a real
> danger of unintended use. Input and suggestions?
>
>
> Jonathan
> _______________________________________________
> bitc-dev mailing list
> bitc-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>