[Discussion] Parentheses

[Jens]

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

[Anton_Zhilin]

Or maybe I have just forgotten the reasons for why there can be no such

thing as (a nested) single element tuple (type).

In Swift, types have their own (built-in) operators: infix '->', postfix
'?', postfix '!'.
Parentheses are required for grouping (setting priorities). If we allow
single element tuples, ambiguities arise:

(Int -> Int)? // is that an optional tuple or just optional function?

By the way, in Haskell, which allows user-defined operators on types, there
is no single element tuple for pretty much the same reason.

[VladimirS (Vladimir)]

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"

···

On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:

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
https://lists.swift.org/mailman/listinfo/swift-evolution

[Joe_Groff]

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.

-Joe

···

On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:

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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Jens]

Ah, thanks Anton!
But wouldn't/couldn't things be different if tuples was written with eg ⊂⊃
instead of parentheses?
(let's ignore the practical implications (difficult to write etc) for the
moment)

For example, here's an optional tuple whose single element is a function:
⊂Int -> Int⊃?

and here is an optional function:
(Int -> Int)?

In this thought-experiment, parentheses are _only_ used for grouping
(setting priorities), and they are the only grouping which is
sloppy/forgiving, so this would also be an optional tuple whose single
element is a function:

((((((((⊂Int -> Int⊃))))))?))

But this would be an optional tuple whose single element is a single
element tuple whose single element is a function:
⊂⊂Int -> Int⊃⊃?

/Jens

···

On Wed, Jul 6, 2016 at 12:23 PM, Anton Zhilin <antonyzhilin@gmail.com> wrote:

> Or maybe I have just forgotten the reasons for why there can be no such
thing as (a nested) single element tuple (type).

In Swift, types have their own (built-in) operators: infix '->', postfix
'?', postfix '!'.
Parentheses are required for grouping (setting priorities). If we allow
single element tuples, ambiguities arise:

(Int -> Int)? // is that an optional tuple or just optional function?

By the way, in Haskell, which allows user-defined operators on types,
there is no single element tuple for pretty much the same reason.

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

bitCycle

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

[VladimirS (Vladimir)]

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.

···

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> wrote:
On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:

-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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Jens]

I'll try to rephrase my initial post a bit, perhaps it will make my point
clearer:

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> 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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

bitCycle

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

[VladimirS (Vladimir)]

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)?`

···

On 06.07.2016 22:37, Jens Persson wrote:

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: jens@bitcycle.com <mailto:jens@bitcycle.com>

[Jens]

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@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: jens@bitcycle.com <mailto:jens@bitcycle.com>

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

bitCycle

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

[Jens]

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@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@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: jens@bitcycle.com <mailto:jens@bitcycle.com>

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

bitCycle

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

[Anton_Zhilin]

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 <jens@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@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: jens@bitcycle.com <mailto:jens@bitcycle.com>

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Jens]

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@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 <jens@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@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: jens@bitcycle.com <mailto:jens@bitcycle.com>

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@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

bitCycle

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com