[swift-evolution] [Discussion] Parentheses

Vladimir.S svabox at gmail.com
Thu Jul 7 07:35:51 CDT 2016


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>
>


More information about the swift-evolution mailing list