Re: [swift-evolution] Normalizing operator's types

[Vladimir.S via swift-evolution]

Just checked with Swift 3.0 (Jun 6, 2016),

func f(_ arg: (Int, Int)) -> Int { return arg.0 + arg.1 } // type :  (Int, 
Int) -> Int


This won't compile:
f(4, 5) // returns 9
ERROR : extra argument in call

This works as expected:
f((4,56)) // returns 60

On 16.06.2016 21:08, J. Charles N. MBIADA via swift-evolution wrote:



--
J. Charles


Le 16 juin 2016 à 15:57, Jeremy Pereira 
a écrit :



On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution
 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


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Normalizing operator's types

[J. Charles N. MBIADA via swift-evolution]

--
J. Charles 


Le 16 juin 2016 à 15:57, Jeremy Pereira  a 
écrit :


On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution 
 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

Re: [swift-evolution] Normalizing operator's types

[Jeremy Pereira via swift-evolution]

> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution 
>  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.

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.

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

Re: [swift-evolution] Normalizing operator's types

[David Sweeris via swift-evolution]

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 <>  (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, 
rhs) } }
func <>  (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 
>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution