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: j...@bitcycle.com <mailto:j...@bitcycle.com>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
