[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