[swift-evolution] [Discussion] Parentheses

Jens Persson jens at bitcycle.com
Fri Jul 8 13:48:25 CDT 2016


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 <antonyzhilin at 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 at 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 <jens at 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 <svabox at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:
>>>>> swift-evolution at 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 at swift.org <mailto:
>>>>> swift-evolution at swift.org>
>>>>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>>             _______________________________________________
>>>>>             swift-evolution mailing list
>>>>>             swift-evolution at swift.org <mailto:
>>>>> swift-evolution at swift.org>
>>>>>             https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     swift-evolution mailing list
>>>>>     swift-evolution at swift.org <mailto:swift-evolution at 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: jens at bitcycle.com <mailto:jens at bitcycle.com>
>>>>>
>>>>>
>>>
>>> --
>>> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
>>> http://www.bitcycle.com/
>>> Phone: +46-73-753 24 62
>>> E-mail: jens at bitcycle.com
>>>
>>>
>>>
>>
>>
>> --
>> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
>> http://www.bitcycle.com/
>> Phone: +46-73-753 24 62
>> E-mail: jens at bitcycle.com
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at 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: jens at bitcycle.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/391aedfa/attachment.html>


More information about the swift-evolution mailing list