<div dir="ltr"><div>I'll try to rephrase my initial post a bit, perhaps it will make my point clearer:</div><div><br></div><div>Might it be that some of the confusion regarding the evolution (design/redesign) of tuples, parameter lists, etc. stems from the fact that they all use parentheses? Or put differently: Parentheses, being used for so many different (and similar) things, is perhaps blurring the "real" (possibly simpler) similarities and differences.</div><div><br></div><div>I'm not saying they should not all use parentheses in the final design, I'm only saying that perhaps it is making it harder to think clearly about these things (while designing the language).</div><div><br></div><div>Let's say we carry out a thought-experiment in which we assume that<span style="font-size:13px"> argument and parameter lists use eg ≪≫ and tuples use eg ⊂⊃, and normal parentheses are _only_ used for grouping and controlling priority in eg mathematical expressions, but not when creating tuples, parameter lists, pattern matching and closure types.</span></div><div><br></div><div>Using this notation (which is just a thinking-tool, not meant as a final syntax), and reimagining these things from scratch, we could for example try and see what happens if we assume that these are three _different_ types:</div><div><span style="font-size:13px">Int</span></div><div><span style="font-size:13px">⊂Int </span><span style="font-size:13px">⊃</span></div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂ </span><span style="font-size:13px">Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span></div><div><span style="font-size:13px">and also, for example, that it is ok to have single element tuples with an element label.</span></div><div>And:</div><div><br></div><div>((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated as usual / as before.</div><div><br></div><div><span style="font-size:13px">⊂ String, Int ⊃ // Two element tuple type whose elements are a String and an Int.</span><br></div><div><br></div><div><span style="font-size:13px">⊂ Int </span><span style="font-size:13px">⊃ // Single element Tuple type.</span><br></div><div><br></div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂</span><span style="font-size:13px"> Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span><span style="font-size:13px"> // Single element Tuple type whose only element is another single element tuple type whose only element is an Int.</span></div><div><br></div><div><span style="font-size:13px">≪ Int ≫ -> Int // Function type from Int to Int.</span><br></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Perhaps the </span><span style="font-size:13px">≪</span><span style="font-size:13px">≫ would prove to be unnecessary, so:</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Int -> Int // Function type from Int to Int.</span></div><div><div><div><span style="font-size:13px">(Int -> Int)? // Optional function type from Int to Int.</span></div></div></div><div><div><span style="font-size:13px">((((Int -> Int))))? // Optional function type from Int to Int. (remember parens are _only_ used for grouping this way)</span></div></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">⊂ Int, Int, Int </span><span style="font-size:13px">⊃ -> Int // Function type from a 3-Int-tuple to an Int.</span><br></div><div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂</span><span style="font-size:13px"> Int, Int, Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span><span style="font-size:13px"> -> Int // Function type from a single element tuple whose element is a 3-Int-tuple to an Int. (Yes, nobody would probably write a function of such a type, but allowing it could perhaps make the rules a lot simpler.)</span></div></div><div><span style="font-size:13px"><br></span></div><div>... Well, I think you get the idea.</div><div><br></div><div>I'm wondering if there has been any attempts at such from-the-scratch redesigns of all these parentheses-related-things in the language (including eg pattern matching, associated values and more).</div><div><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06.07.2016 20:51, Joe Groff wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please feel free to ignore this naive attempt to engage in this discussion.<br>
<br>
My understanding of the history of Swift's tuples, argument lists, pattern<br>
matching, associated values, etc. in two steps:<br>
<br>
1. Initial Idealism *:<br>
Simple powerful heavily reused general concept.<br>
<br>
2. Iterative pragmatism / reality *:<br>
Complicated (exceptions to) rules.<br>
<br>
(* Inevitably not taking everything in to account.)<br>
<br>
Has there been any recent attempts to outline a more or less complete<br>
redesign for these things, returning to step 1 so to speak, but taking into<br>
account what has now been learned?<br>
<br>
<br>
As a side note (and supposedly trivial to most but me):<br>
<br>
Parentheses (parenthesized expressions in the grammar?) are used for all of<br>
these parts of the language, and they probably should be, but perhaps the<br>
similarities and differences between the language constructs can be made<br>
clearer to see by pretending that argument and parameter lists are written<br>
with eg ≪≫ and tuples with eg ⊂⊃, etc.?<br>
<br>
For example, I think most people agree that we should be able to use<br>
"sloppy/forgiving" parenthetical grouping in code such as:<br>
((1 + (2 * 3)) * (x + (-5))) - y<br>
This is fine and can be used to express meaning for the person<br>
reading/writing, even though it means that some of the parens can become<br>
superfluous to a machine interpretation.<br>
<br>
AFAICS this need not have anything to do with tuples and/or parameter<br>
lists, but the fact that Swift is treating eg:<br>
func foo(x: ((((Int))))) { print(x) }<br>
as<br>
func foo(x: Int) { print(x) }<br>
and<br>
((Int, Int))<br>
as<br>
(Int, Int)<br>
</blockquote>
<br>
If SE-0110 will be accepted, ((Int, Int)) will mean "1 tuple with Int,Int fields" and (Int, Int) will mean only "list of two Ints in parameters"<br>
</blockquote>
<br>
((Int, Int)) would still be equivalent to (Int, Int). SE-0110 only concerns parameter lists in function types.<br>
</blockquote>
<br></div></div>
Yes, I'm talking about parameter list in function. Perhaps I'm missing something... Quotation from proposal:<br>
<br>
>----------------<<br>
To declare a function type with one tuple parameter containing n elements (where n > 1), the function type's argument list must be enclosed by double parentheses:<br>
<br>
let a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 }<br>
>----------------<<br>
<br>
Oh... Or do you(and Jens) mean that this:<br>
let x : (Int, Int) = (1,2)<br>
will be the same as this:<br>
let x : ((Int, Int)) = (1,2)<br>
? and about<br>
func foo(_ x: ((Int, Int))) { print(x) }<br>
vs<br>
func foo(_ x: (Int, Int)) { print(x) }<br>
?<br>
In this case yes, sorry for misunderstanding, SE-0110 will not change this. I don't see any ambiguity here: foo will be called as<br>
foo((1,2)) - clearly that tuple is sent as argument.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Joe<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
seems to suggest that it somehow does.<br>
<br>
Or maybe I have just forgotten the reasons for why there can be no such<br>
thing as (a nested) single element tuple (type).<br>
<br>
I also can't remember what the pros & cons of disallowing labeled single<br>
element tuples were.<br>
<br>
Happy to be corrected and pointed to relevant reading : )<br>
<br>
/Jens<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
<br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>