--
J. Charles
Le 16 juin 2016 à 15:57, Jeremy Pereira <jeremy.j.pere...@googlemail.com> a
écrit :
On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution
<swift-evolution@swift.org> wrote:
Hi Swift,
Since the "removal" of curried function, I am looking for some elegant ways to
work with partial functions (and reduce creation of closure and nested func for the
developper).
And now I am asking myself if it's not better to align operator's types to the
arrow style instead of using tuple argument style.
For example:
Why Int.multiplyWithOverflow's type is (Int, Int) -> (Int, overflow: Bool) instead of
(Int -> Int) -> (Int, overflow: Bool)
That looks wrong to me. That says that Int.multiplyWithOverflow is a function that
takes another function (of type (Int) -> Int) and returns a tuple.
Function which takes a function require parenthesis as you showed up: (Int) ->
Int I am saying that using this fact, we can bring back auto curried function by
eliminating parenthesis.
Int -> Int -> Int will be interpreted as a func which permit to generate
partial function when arguments are missing.
What you really want is a function that takes an Int and returns another
function that takes an Int and returns the tuple i.e. its signature would look
like this
(Int) -> ((Int) -> (Int, Bool))
This last one will be interpreted as a final function which need exactly one
parameter to be valid when it's called.
Plus seeing the example below work show how things are not clear if programmers
doesn't want to go in a deep understanding of the language.. But it works
well...
func f(_ arg: (Int, Int)) -> Int { return arg.0 + arg.1 } // type : (Int, Int)
-> Int
f(4,5) // returns 9
f((4,56)) // returns 60
func g(_ arg: Int, _ a: Int) -> Int { return arg + a } // type : (Int, Int) ->
Int
g(4, 5) // returns 9
g((4,56)) // fails
// Ok putting label could help to distinguish but
func f( a:Int, b:Int) -> Int { return a + b } and func h(_ arg: (a:Int, b:Int))
-> Int { return arg.0 + arg.1 } still has the same type
Clearifying this situation IMHO seem to me as complicated (maybe more) as clarifying
Int -> Int -> Int. Explaining the lambda concept once should be sufficient to
clarify this one. Explaining Tuple concept could not help to clarify the behavior of
the example above.
If we assume -> is right associative we can simplify to
(Int) -> (Int) -> (Int, Bool)
Chris proposal to enforce parenthesis around arguments could be the opportunity
to use that syntax to distinct curried functions from the others.
Then (Int) -> (Int) -> (Int, Bool) is valid and say that full implementation was
handled by the developer since Int -> Int -> (Int, Bool) is valid too but some
workaround could be handled by the compiler.
Making these functions some how different in programmer's intent.
fun f(a:Int, b:Int) -> Int { return (a/b, a%b != 0)} has type Int -> Int ->
(Int, Bool)
and h(a:Int) -> Int { return { b:Int in return (a/b, a%b != 0)} } has type (Int)
-> (Int -> (Int, Bool))
f(4, 5); f(4)(5) // OK
h(4)(5) // OK
h(4, 5) // fails, or why not works as well
f(a:Int) -> Int { return { b:Int in return (a/b, a%b != 0)} } has type (Int) ->
(Int -> (Int, Bool))
Of course this need to be refined and formalized.
which makes more sense but is less clear to most programmers than the current
syntax.
In my opinion, what are clear for programmers are what they understand, a
reference section explaining these concepts could do the work of clarifying
things.
When curried function will come back (if it come back, which is a personal
hope) that will avoid many refactoring.
I think that, write this : let f:(Int, Int) throws -> Int = (+) seem a bit ugly
for this purpose
let f:(Int -> Int) -> Int = (+) seem more suitable.
We could imagine that in the future the compile could automatically create a
closure if the programmer define something like
let lmul: (Int) -> (Int) -> (Int) = (*)
and then, doing the habitual stuffs : let mulOfTwo = lmul(2)
Kind regards,
--
jcnm
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
