Anonymous user
Talk:Partial function application: Difference between revisions
m
→Suggested changes to the task description
| (6 intermediate revisions by 4 users not shown) | |||
Line 148:
:: Hi Kernigh, if fs were defined as taking 3 arguments and currying would still refer to fs(f1,_) and not fs(f1,_,_) then I would be inclined to accept it as the '_' would stand for "any other arguments" rather than "any one argument" and would retain most of the insensitivity to the number of arguments of the Haskel-type implementations.
: <lang scala>scala> def rot(x: Int, y: Int, z: Int) = (y, z, x)
rot: (x: Int,y: Int,z: Int)(Int, Int, Int)
scala> rot(2, 3, 7)
res0: (Int, Int, Int) = (3,7,2)
scala> def a(y: Int) = rot(_: Int, y, _: Int)
a: (y: Int)(Int, Int) => (Int, Int, Int)
scala> a(3)(2, 7)
res1: (Int, Int, Int) = (3,7,2)</lang>
: It seems that _ is any one parameter. So, the Scala "partial application underscore" fails the task requirement that "other parameters are not explicitely mentioned". --[[User:Kernigh|Kernigh]] 02:17, 21 April 2011 (UTC)
I hope I have fixed this by clearly stating up front that Scala doesn't follow the description and where. This means that there is no doubt as to where the Scala moves away from the task description. The alternative is to delete the example and omit the language from the task. --[[User:Paddy3118|Paddy3118]] 05:35, 21 April 2011 (UTC)
: I've never written any Scala code and only seen a few samples, but this does look like partial application to me (quite similar to Perl 6's Whatever-Star). The fact that you have to mention a type signature might just be a limitation of Scala's type inferencer. The key question is: can you use this to pass an arity 3 function to map without using any intermediate definitions or lambda's? —''[[User:Ruud Koot|Ruud]]'' 07:05, 21 April 2011 (UTC)
:: <lang scala>scala> def f(a: Int, x: Int, b: Int) = a * x + b
f: (a: Int,x: Int,b: Int)Int
scala> List(1, 2, 3).map(f(10, _, 1))
res4: List[Int] = List(11, 21, 31)</lang>
:: Yes, you can pass arity 3 function to map. The _ has no type signature. A _ without a type signature can be an error, so I am not sure why it worked here. (I am new to Scala, and not the author of the Scala solution.) --[[User:Kernigh|Kernigh]] 19:00, 21 April 2011 (UTC)
==Is Lisp correct?==
Line 316 ⟶ 342:
::: Using common sense and discussion? I don't think the task should be overspecified either. For example, specifying that you have to define a function similar to Python's <code>partial</code> would rule out ML's and Haskell's implicit partial application or perhaps a clever, but reasonable, trick involving C's preprocessor or C++'s templates. On the other hand, the current Java implementation might follow the the task to the letter, but certainly violates the spirit as it's not applicable to idiomatically defined functions from the standard library. —''[[User:Ruud Koot|Ruud]]'' 17:54, 20 April 2011 (UTC)
== What is partial application? ==
It occurred to me that when one speaks of "partial application" one can refer to several distinct things:
# The ''syntactic sugar'' that allows one to write <code>map (f 7 9) [1..9]</code> or <code>map(f(7,_,9),{1,...,9})</code> instead of <code>map (lambda x: f 7 9 x) [1..9]</code> or <code>def g(x): return f(7,9,x); end def in map(g,(1..9))</code>.
# The ''higher-order function'' <code>functools.partial</code>.
# The ''compilation technique'' that allows function thunks or closures to be "partially applied" instead of only unapplied or fully applied.
The task here should probably be about the first, perhaps also the second. —''[[User:Ruud Koot|Ruud]]'' 15:35, 21 April 2011 (UTC)
== Suggested changes to the task description ==
1) There is no need to require functions to be named <code>f1</code>, <code>f2</code>, <code>fsf1</code> or <code>fsf2</code>, and doing so excludes solutions in languages that don't allow digits to be used in identifiers.
2) The wording "partially apply <code>f1</code> to <code>fs</code>" should be changed to "partially apply <code>fs</code> to <code>f1</code>" because it's more conventional to speak of functions being applied to arguments than vice versa, and in this case <code>f1</code> is the argument.
3) Please be consistent about distinguishing between functions themselves and expressions in which they are applied to an argument. The wording "create a function <code>fs(f,s)</code> that takes a function <code>f(n)</code> ..." should be changed to "create a function <code>fs</code> that takes a function <code>f</code> ...". The expression <math>f(n)</math> refers conventionally not to the whole function <math>f</math> but to the single output associated with the argument <math>n</math> (unless you're an economist, in which case you'll infer an implied universal quantification with respect to the variable <math>n</math>, except when you don't).
--[[User:Sluggo|Sluggo]] 18:09, 14 June 2011 (UTC)
| |||