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 e
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 analogy doesn’t exist in Swift, la
On Tue, Apr 26, 2016 at 11:23 AM, Chris Lattner wrote:
> On Apr 26, 2016, at 10:52 AM, Mishal Awadah via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Concern 1:
> > I feel like we're forgetting about the functional programming syntax of
> declaring function types like this:
> >
> > A
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 a nice one, because f
> SE-0066 is a very narrow proposal - it only affects syntax, not
> semantics. The type system semantics that you seem interested in are
> unlikely to happen regardless of the syntax changes SE-0066 imply, and
> SE-0066 doesn’t have anything to do with that.
It is most disappointing to read thes
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)
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 can have a functio
> On Apr 27, 2016, at 6:05 AM, Ryan Lovelett wrote:
>
>> SE-0066 is a very narrow proposal - it only affects syntax, not semantics.
>> The type system semantics that you seem interested in are unlikely to happen
>> regardless of the syntax changes SE-0066 imply, and SE-0066 doesn’t have
>> a
> 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 featur
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
> 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
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 i
12 matches
Mail list logo