| <<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. |