Thank you all, I guess it's impossible / very hard to come up with a design without such inconsistencies and ambiguities, especially when parentheses are used for so many different things in the language. /Jens
On Thu, Jul 7, 2016 at 10:33 PM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > I guess you are suggesting to: > 1. Add single-element tuples to the language (not convertible to "plain" > types) > 2. Make all otherwise unnecessary parentheses signify single-element tuples > > In my first answer, I mentioned Haskell, because it treats types and > variables in pretty much the same way. > In that context, it is consistent to allow "extra" parentheses in types. > Compare: > > a + (b!) vs A -> (B?) > > Both are not the best code style, but both are allowed. I see how > separating single-element tuples solves one inconsistency, but notice how > it creates another one. > Of course, we are discussing Swift, not Haskell, and here we may want to > go the other way and disallow extra parentheses on types. I don't really > like that way, though. > > P.S. Since we now allow converting types to variables without 'self', the > following would be ambiguous: > > Optional(0).map { _ in return (((Int))) } > > Do parentheses belong to type or to value? Currently it does not really > matter, but with the change it would. > > 2016-07-07 22:16 GMT+03:00 Jens Persson via swift-evolution < > swift-evolution@swift.org>: > >> Also, regarding the special case of single element tuples, ie Int being >> the same type as (Int) and ((((Int))): >> I'm wondering if that can be viewed as an irregularity baked in at the >> foundation of the system (parenthesized expressions), sending ripples of >> perhaps needless complexity through the rest of the (parentheses-using >> parts) of the language. I'm not knowledgable enough to analyze this myself >> though. >> /Jens >> >> >> On Thu, Jul 7, 2016 at 5:01 PM, Jens Persson <j...@bitcycle.com> wrote: >> >>> As previously mentioned, I was talking about using those symbols only as >>> a thinking-tool to possibly simplify language design, making the "real" >>> differences and similarities easier to see while thinking about the design. >>> The final syntax could perhaps still use normal parentheses for all >>> these parts of the language. Please reread my previous two posts for more >>> details. >>> /Jens >>> >>> >>> On Thursday, July 7, 2016, Vladimir.S <sva...@gmail.com> wrote: >>> >>>> On 06.07.2016 22:37, Jens Persson wrote: >>>> >>>>> I'll try to rephrase my initial post a bit, perhaps it will make my >>>>> point >>>>> clearer: >>>>> >>>> >>>> I got your idea. Although I don't know if it is easy to implement in >>>> compiler/parser, I know that it is hard to find such symbols (as >>>> replacement of parentheses) that will be easy to type on keyboard. Don't >>>> you really propose to type unicode chars like ⊂ ? I believe no. >>>> >>>> <> - used for generics >>>> {} - for code blocks >>>> [] - for subscripts/arrays/dicts >>>> >>>> what I can think of is vertical bar | symbol as parentheses for tuples: >>>> >>>> var x = |5,5| >>>> >>>> func foo(tuple: |Int,Int,String|) {..} >>>> >>>> (|Int,Int|)->Int >>>> (|Int,Int|)->|String, String| >>>> >>>> ((Int) -> Int)? -- optional function >>>> |(Int) -> Int|? -- optional tuple >>>> >>>> I feel like such syntax for tuples more clearly separates tuple >>>> declaration from other parts of code. >>>> Don't know if that makes sense :-) >>>> And not sure if we really needs one-element tuple even if we can >>>> clearly parse it in source. >>>> >>>> Btw, parentheses are required for argument list in function type now, >>>> so we can't write `Int -> Int`, but only as `(Int) -> Int`, and not `(Int >>>> -> Int)?` but as `((Int) -> Int)?` >>>> >>>> >>>>> 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. >>>>> >>>>> 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). >>>>> >>>>> Let's say we carry out a thought-experiment in which we assume >>>>> that 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. >>>>> >>>>> 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: >>>>> Int >>>>> ⊂Int ⊃ >>>>> ⊂⊂ Int ⊃⊃ >>>>> and also, for example, that it is ok to have single element tuples >>>>> with an >>>>> element label. >>>>> And: >>>>> >>>>> ((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated >>>>> as >>>>> usual / as before. >>>>> >>>>> ⊂ String, Int ⊃ // Two element tuple type whose elements are a String >>>>> and >>>>> an Int. >>>>> >>>>> ⊂ Int ⊃ // Single element Tuple type. >>>>> >>>>> ⊂⊂ Int ⊃⊃ // Single element Tuple type whose only element is another >>>>> single >>>>> element tuple type whose only element is an Int. >>>>> >>>>> ≪ Int ≫ -> Int // Function type from Int to Int. >>>>> >>>>> Perhaps the ≪≫ would prove to be unnecessary, so: >>>>> >>>>> Int -> Int // Function type from Int to Int. >>>>> (Int -> Int)? // Optional function type from Int to Int. >>>>> ((((Int -> Int))))? // Optional function type from Int to Int. >>>>> (remember >>>>> parens are _only_ used for grouping this way) >>>>> >>>>> ⊂ Int, Int, Int ⊃ -> Int // Function type from a 3-Int-tuple to an Int. >>>>> ⊂⊂ Int, Int, Int ⊃⊃ -> 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.) >>>>> >>>>> ... Well, I think you get the idea. >>>>> >>>>> 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). >>>>> >>>>> /Jens >>>>> >>>>> >>>>> On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> On 06.07.2016 20:51, Joe Groff wrote: >>>>> >>>>> >>>>> On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution >>>>> <swift-evolution@swift.org <mailto: >>>>> swift-evolution@swift.org>> >>>>> wrote: >>>>> >>>>> On 06.07.2016 3:57, Jens Persson via swift-evolution wrote: >>>>> >>>>> Please feel free to ignore this naive attempt to >>>>> engage in >>>>> this discussion. >>>>> >>>>> My understanding of the history of Swift's tuples, >>>>> argument >>>>> lists, pattern >>>>> matching, associated values, etc. in two steps: >>>>> >>>>> 1. Initial Idealism *: >>>>> Simple powerful heavily reused general concept. >>>>> >>>>> 2. Iterative pragmatism / reality *: >>>>> Complicated (exceptions to) rules. >>>>> >>>>> (* Inevitably not taking everything in to account.) >>>>> >>>>> Has there been any recent attempts to outline a more or >>>>> less complete >>>>> redesign for these things, returning to step 1 so to >>>>> speak, >>>>> but taking into >>>>> account what has now been learned? >>>>> >>>>> >>>>> As a side note (and supposedly trivial to most but me): >>>>> >>>>> Parentheses (parenthesized expressions in the >>>>> grammar?) are >>>>> used for all of >>>>> these parts of the language, and they probably should >>>>> be, >>>>> but perhaps the >>>>> similarities and differences between the language >>>>> constructs can be made >>>>> clearer to see by pretending that argument and >>>>> parameter >>>>> lists are written >>>>> with eg ≪≫ and tuples with eg ⊂⊃, etc.? >>>>> >>>>> For example, I think most people agree that we should >>>>> be >>>>> able to use >>>>> "sloppy/forgiving" parenthetical grouping in code such >>>>> as: >>>>> ((1 + (2 * 3)) * (x + (-5))) - y >>>>> This is fine and can be used to express meaning for >>>>> the person >>>>> reading/writing, even though it means that some of the >>>>> parens can become >>>>> superfluous to a machine interpretation. >>>>> >>>>> AFAICS this need not have anything to do with tuples >>>>> and/or >>>>> parameter >>>>> lists, but the fact that Swift is treating eg: >>>>> func foo(x: ((((Int))))) { print(x) } >>>>> as >>>>> func foo(x: Int) { print(x) } >>>>> and >>>>> ((Int, Int)) >>>>> as >>>>> (Int, Int) >>>>> >>>>> >>>>> 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" >>>>> >>>>> >>>>> ((Int, Int)) would still be equivalent to (Int, Int). SE-0110 >>>>> only >>>>> concerns parameter lists in function types. >>>>> >>>>> >>>>> Yes, I'm talking about parameter list in function. Perhaps I'm >>>>> missing >>>>> something... Quotation from proposal: >>>>> >>>>> >----------------< >>>>> 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: >>>>> >>>>> let a : ((Int, Int, Int)) -> Int = { x in return x.0 + x.1 + x.2 } >>>>> >----------------< >>>>> >>>>> Oh... Or do you(and Jens) mean that this: >>>>> let x : (Int, Int) = (1,2) >>>>> will be the same as this: >>>>> let x : ((Int, Int)) = (1,2) >>>>> ? and about >>>>> func foo(_ x: ((Int, Int))) { print(x) } >>>>> vs >>>>> func foo(_ x: (Int, Int)) { print(x) } >>>>> ? >>>>> 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 >>>>> foo((1,2)) - clearly that tuple is sent as argument. >>>>> >>>>> >>>>> >>>>> -Joe >>>>> >>>>> >>>>> seems to suggest that it somehow does. >>>>> >>>>> Or maybe I have just forgotten the reasons for why >>>>> there >>>>> can be no such >>>>> thing as (a nested) single element tuple (type). >>>>> >>>>> I also can't remember what the pros & cons of >>>>> disallowing >>>>> labeled single >>>>> element tuples were. >>>>> >>>>> Happy to be corrected and pointed to relevant reading >>>>> : ) >>>>> >>>>> /Jens >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto: >>>>> swift-evolution@swift.org> >>>>> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto: >>>>> swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden >>>>> http://www.bitcycle.com/ >>>>> Phone: +46-73-753 24 62 >>>>> E-mail: j...@bitcycle.com <mailto:j...@bitcycle.com> >>>>> >>>>> >>> >>> -- >>> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden >>> http://www.bitcycle.com/ >>> Phone: +46-73-753 24 62 >>> E-mail: j...@bitcycle.com >>> >>> >>> >> >> >> -- >> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden >> http://www.bitcycle.com/ >> Phone: +46-73-753 24 62 >> E-mail: j...@bitcycle.com >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > -- bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden http://www.bitcycle.com/ Phone: +46-73-753 24 62 E-mail: j...@bitcycle.com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution