Re: [swift-evolution] SE-0066 Reaction

2016-04-28 Thread Vladimir.S via swift-evolution
Support your opinion on 100%. IMO Swift is language that has *elements* of FP that help us to build our software, but it was not born to be Pure FP language like Haskel https://en.wikipedia.org/wiki/Purely_functional And I believe will never be, as then we should implement Haskell's I/O system

Re: [swift-evolution] SE-0066 Reaction

2016-04-28 Thread Gwendal Roué via swift-evolution
> Hey, > > I'm inserting these opinions into almost every FP discussion, for which I'm > sorry, but I believe it's important to remind everyone that there's the rest > of us who will run away from Swift if it becomes too FP-y. > >> One of the things that I have noticed over the last year or

Re: [swift-evolution] SE-0066 Reaction

2016-04-28 Thread Andrey Tarantsov via swift-evolution
Hey, I'm inserting these opinions into almost every FP discussion, for which I'm sorry, but I believe it's important to remind everyone that there's the rest of us who will run away from Swift if it becomes too FP-y. > One of the things that I have noticed over the last year or so of working

Re: [swift-evolution] SE-0066 Reaction

2016-04-28 Thread Tino Heth via swift-evolution
> What I’m trying to say is that there are a lot of reasons that the Swift > type system works the way it does (e.g. inout has very specific behavior that > doesn’t work when partially applied, we have specific promotion rules that > apply only in argument lists etc). These reasons and

Re: [swift-evolution] SE-0066 Reaction

2016-04-27 Thread Mishal Awadah via swift-evolution
Thanks for the feedback Chris! I am happy with this proposal given the discussion here. - Mish On Wed, Apr 27, 2016 at 7:01 AM, Andrew Bennett wrote: > I initially had similar concerns to Mishal, but I worked my way through it > and found I was wrong. > > In current Swift you

Re: [swift-evolution] SE-0066 Reaction

2016-04-27 Thread Andrew Bennett via swift-evolution
I initially had similar concerns to Mishal, but I worked my way through it and found I was wrong. In current Swift you can have a function: A -> B -> C Adding brackets for clarity, that is equivalent to this (current Swift): A -> (B -> C) After this proposal this will become: (A) -> ((B) -> C)

Re: [swift-evolution] SE-0066 Reaction

2016-04-26 Thread Chris Lattner via swift-evolution
On Apr 26, 2016, at 3:37 PM, Mishal Awadah wrote: > This analogy doesn’t exist in Swift, languages like Haskell have > auto-currying behavior like this, but Swift does not. > > Indeed, my point is that this proposal drives the distance further from this > analogy, which is

Re: [swift-evolution] SE-0066 Reaction

2016-04-26 Thread Chris Lattner via swift-evolution
On Apr 26, 2016, at 10:52 AM, Mishal Awadah via swift-evolution wrote: > Concern 1: > I feel like we're forgetting about the functional programming syntax of > declaring function types like this: > > A -> B -> C > > for a function foo(a: A, b: B) -> C This

[swift-evolution] SE-0066 Reaction

2016-04-26 Thread Mishal Awadah via swift-evolution
Hi, I missed the original thread, but here are my thoughts on SE-0066 right after Chris's email ends with "thoughts?". Concern 1: I feel like we're forgetting about the functional programming syntax of declaring function types like this: A -> B -> C for a function foo(a: A, b: B) -> C This