TWiki > Dev > FeatureProposals > PartialApplicationSyntax	TWiki webs: Dev | Doc | Main | TWiki | Sandbox
	Dev . { Changes | Index | Search | Go }

Background:

Many functional languages provide "curried" functions, of the form a -> b -> c, rather than the more typical (in Nice) (a,b) -> c. I think providing curried functions by default causes much confusion (and obscure error messages), so I think Nice's approach is good. But curried functions are often handy too.

Feature:

It would be good to have a compact syntax for partially applying a function. I'll suggest '_' and '...' as the symbols to use, where '_' means "omit this argument" and '...' means "omit all remaining arguments". So, for example:

String greet(String salutation, String adjective, String object) = salutation + ", " + adjective + " " + object;

test()
{
   (String, String)->String helloFun = greet("Hello", ...); //Fill first param only
   String->String helloWorldFun = helloFun(_, "world"); //Skip first param
   String message = helloWorldFun("currified"); 
   println(message);         //prints "Hello, currified world"
}

Which would be equivalent to:

test()
{
   (String, String)->String helloFun = (String adjective, String object) => greet("Hello", adjective, object));

   String->String helloWorldFun = String adjective => helloFun(adjective, "world");

   String message = helloWorldFun("currified");
   println(message);    //prints "Hello, currified world"
} 

I like this idea of using '...' for curried function. There is a good chance it will get in before 1.0 . But I'm not sure about using '_'. An alternative for '_' is using named parameters as in this example:

String greet(String salutation, String adjective, String object) = salutation + ", " + adjective + " " + object;
let (String adjective, String object)->String hello = greet("Hello", ...);
let (String adjective)->String helloWorld = hello(object:"world", ....);

test()
{
   String message = helloWorld("currified"); 
   println(message); 
}

-- ArjanB - 03 May 2003

That sounds like a better solution to me. We need a something for when the parameter names are not known, however:

(int,int)->int partialApplicator((int,int,int)->int theFunction)
{
  return theFunction(_,5,_);
}

A better solution might be to allow to name the sub-components of the function type:

(int,int)->int partialApplicator((int a,int b,int c)->int theFunction)
{
  return theFunction(b: 5, ...);
}

... or to allow arguments to be referred to by number (starting from 0 in this example):

(int,int)->int partialApplicator((int,int,int)->int theFunction)
{
  return theFunction(1: 5);
}

I think I prefer the naming syntax over the positional syntax.

-- BrynKeller - 05 May 2003

I like this idea of using '...' for curried function

Couldn't the naming syntax apply to this also?

String hello(String adjective, String object) = greet(salutation: "Hello"); 

From calls to agents presents a very general mechanism that has been introduced into Eiffel.

Here's another syntax for Currying, multiple parameter lists modN(n: Int)(x: Int) = ((x % n) = 0);

-- IsaacGouy - 20 Jan 2004

I think this last syntax is not special, it's just what you get when you define a function with multiple arguments as a function taking one argument and returning a function. That is, you could already do this in Nice:

int->boolean modN(int n) = int x => (x % n) == 0;

OK, we could accept the syntax modN(int n)(int x), but I'm not sure it brings much. -- DanielBonniot - 21 Jan 2004

Isn't this syntax just implicit curry, a la ML or Haskell? This is exactly what I don't want to see in Nice, I think explicit currying is better. I think it needs to be easy, but not implicit.

-- BrynKeller - 22 Jan 2004

Yes, it's a form of implicit curry. Note that we could perfectly have both:

int modN(int n, int x) = (x % n) == 0;
int modN(int n)(int x) = (x % n) == 0;

-- DanielBonniot - 23 Jan 2004

While we're discussing syntax, is there a rationale for using -> in the type but => in the definition? Would it be reasonable to use one of those in both places?

int->boolean modN(int n) = int x => (x % n) == 0;

Yes, that's a valid remark. I think in that case we should settle on -> for functions, which would allow to use => for logical implication. Is there a consensus on this change? -- DanielBonniot - 02 Feb 2004

I think I objected to this suggestion a while ago, because things could get confusing with anonymous functions:

[ `+`, `*`, `-`, `/`].map( (int,int) -> int func -> func(4,5));

but on the whole I'm not really convinced of this danger anymore, and parentheses can always be used if clarification is necessary. I'd go along with getting rid of => for functions.

-- BrynKeller - 03 Feb 2004

Mildly amusing that Scala chose to use => for both and we seem to be chosing -> for both. -- IsaacGouy - 24 Feb 2004