[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