[swift-evolution] Revisiting SE-0110

Elviro Rocca retired.hunter.djura at gmail.com
Fri Jun 23 06:46:31 CDT 2017

This has been a very hard discussion to follow, even for a programmer that mostly just silently reads these threads to get a general understanding of what's going on in the community.

There's an overwhelming amount of messages that point out potential bugs and unexpected behavior by showing code that's marginally different from each other, like one more nesting of parentheses, or one less label for a parameter. It seems to me that distinctions like these are just important at the compiler level, but not particularly useful from an usability standpoint. I might be wrong but there's a lot of discussion about convenience gained or lost by switching different styles of syntax that are in fact completely isomorphic to each other.

I also read some comments about the fact that some functional programmers didn't take well SE-110, and as a fellow FP I can say that the reason in not really about style or convenience.

The point is that, the following type couples are completely isomorphic to each other (meaning that they are, for all means, equivalent) and a smart type system could in theory consider them as the same thing:

(A) == ((A))
(A) == (((A)))
(A) == (A,())
(A) == ((),A,())
(A,B) == ((A,B))
(A,B) == (((A,B)))
(A,B) == (A,B,())
(A,B) == ((),A,B,())
(A,B) == ((),(A,B),())

It's probably late to just casually add a couple of cents to a discussion that has been going for so long, but it seems to me that from a user standpoint, that uses types to structure their programs and define logic and relationships, isomorphic types should be considered the same by the compiler. The added burden of distinguishing between, to say, a function that takes 2 arguments and one that takes a single tuple of two arguments doesn't seem useful at all, at least from the standpoint of the types involves. All the rest, like named parameters or tuple labels, are just really about style and convenience, but isomorphic types, while not strictly equal (the very concept of "equal" is in fact a huge deal in abstract mathematics) are for all means "equivalent" for the world-modeler.

Again, I don't really expect these words to have any impact, considering the huge discussion that has been going, and I don't certainly intend to undermine any other contribution with my extremely generic statements. But I felt like writing this, and I did.



More information about the swift-evolution mailing list