Nice TWiki > Dev > PartialApplicationSyntax (r1.1 vs. r1.14) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
 <<O>>  Difference Topic PartialApplicationSyntax (r1.14 - 24 Feb 2004 - IsaacGouy)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.13 - 03 Feb 2004 - BrynKeller)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.12 - 02 Feb 2004 - DanielBonniot)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.11 - 01 Feb 2004 - IsaacGouy)
Added:
>
>

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;
-- IsaacGouy - 01 Feb 2004

 <<O>>  Difference Topic PartialApplicationSyntax (r1.10 - 23 Jan 2004 - DanielBonniot)
Added:
>
>

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;
The second line defining a curried function. I don't think that would hurt, since uncurried versions would likely stay the "default". This would just be an easier syntax to define named curried functions. I just think that the PartialApplicationSyntax is more prioritary, but I don't think this syntax for curried functions is incompatible or would hurt in any way.

-- DanielBonniot - 23 Jan 2004


 <<O>>  Difference Topic PartialApplicationSyntax (r1.9 - 22 Jan 2004 - BrynKeller)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.8 - 21 Jan 2004 - ArjanB)
Changed:
<
<

I like this idea of using '...' for curried function. There is a good chance it will get in before 1.0 . But I dont' like the '_' because it suggests that the chosen order of the parameters is wrong and in case of optional parameters the semantics are not clear. An alternative for '_' is using named parameters as in this example:

>
>

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:

Changed:
<
<

String hello(String adjective, String object) = greet("Hello", ...); String helloWorld(String adjective) = hello(object:"world", ....);

>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.7 - 21 Jan 2004 - DanielBonniot)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.6 - 20 Jan 2004 - IsaacGouy)
Changed:
<
<

Couldn't the naming syntax apply to this also?

String hello(String adjective, String object) = greet(salutation: "Hello");
-- IsaacGouy - 14 Jan 2004
>
>

Couldn't the naming syntax apply to this also?

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

-- IsaacGouy - 14 Jan 2004

>
>

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

-- IsaacGouy - 20 Jan 2004


 <<O>>  Difference Topic PartialApplicationSyntax (r1.5 - 14 Jan 2004 - IsaacGouy)
Added:
>
>

From calls to agents presents a very general mechanism that has been introduced into Eiffel. -- IsaacGouy - 14 Jan 2004


 <<O>>  Difference Topic PartialApplicationSyntax (r1.4 - 14 Jan 2004 - IsaacGouy)
Added:
>
>

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");
-- IsaacGouy - 14 Jan 2004

 <<O>>  Difference Topic PartialApplicationSyntax (r1.3 - 05 May 2003 - BrynKeller)
Added:
>
>

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


 <<O>>  Difference Topic PartialApplicationSyntax (r1.2 - 03 May 2003 - ArjanB)
Changed:
<
<

-- BrynKeller? - 13 Feb 2003

>
>

-- BrynKeller - 13 Feb 2003

I like this idea of using '...' for curried function. There is a good chance it will get in before 1.0 . But I dont' like the '_' because it suggests that the chosen order of the parameters is wrong and in case of optional parameters the semantics are not clear. An alternative for '_' is using named parameters as in this example:

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

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

-- ArjanB - 03 May 2003


 <<O>>  Difference Topic PartialApplicationSyntax (r1.1 - 13 Feb 2003 - TWikiGuest)
Added:
>
>

%META:TOPICINFO{author="guest" date="1045172040" format="1.0" version="1.1"}% %META:TOPICPARENT{name="FeatureProposals"}% Imported from SourceForge? RFE #672069

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"
} 
-- BrynKeller? - 13 Feb 2003

Topic PartialApplicationSyntax . { View | Diffs | r1.14 | > | r1.13 | > | r1.12 | More }
Revision r1.1 - 13 Feb 2003 - 21:34 GMT - TWikiGuest
Revision r1.14 - 24 Feb 2004 - 18:11 GMT - IsaacGouy
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.