[swift-evolution] [Discussion] Parentheses
Anton Zhilin
antonyzhilin at gmail.com
Thu Jul 7 15:33:20 CDT 2016
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/fd202db7/attachment.html>
More information about the swift-evolution
mailing list