Normalizing operator's types


(J Charles N. M.) #1

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)

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


(David Sweeris) #2

Function currying wasn’t removed, just some of the confusing syntax for it. This works fine in the Xcode 8 beta:
infix operator <> {} // random operator that doesn’t do anything else
func <> <T, U, V> (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, rhs) } }
func <> <T, U, V> (lhs: T, op: (T, U) -> V) -> ((U) -> V) { return { op(lhs, $0) } }
let divby2 = (/) <> 2
print(divby2(10)) // prints "5"
let invert = 1.0 <> (/)
print(invert(10)) // prints "0.1"

More to the point, though, given this definition:
let foo: (Int) -> (Int) -> (Int)
Would the correct way to use `foo` with today’s syntax be "foo(Int) -> (Int, Int)”, "foo(Int) -> ((Int) -> Int)”, or "foo(Int, Int) -> Int”?

Seems like a lot of confusion and ambiguity for something that, at least as far as I can tell, doesn’t actually provide any functionality.

- Dave Sweeris

···

On Jun 15, 2016, at 2:07 PM, 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)

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


(Jeremy Pereira) #3

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.

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

If we assume -> is right associative we can simplify to

(Int) -> (Int) -> (Int, Bool)

which makes more sense but is less clear to most programmers than the current syntax.

···

On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution <swift-evolution@swift.org> wrote:

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