<div dir="ltr"><div><div><div><div><div><div><div>Hi, I’ve been watching this proposal for a while but didn’t get to read it in detail until now. I really like this idea and it’s very comprehensive and well-thought out. Some feedback:<br><br></div>1. I got very confused reading through the document the first time through. You’re introducing a huge amount of new syntax and jargon, and not defining all of them before first using it. For example, what does <span style="font-family:monospace,monospace">`a[[;3]]`</span> and <span style="font-family:monospace,monospace">`b[[;1, 4]]`</span> after the seventh paragraph mean? This bounds-omission syntax isn’t explained until the Array Values section, and it’s buried in the middle of a paragraph.<br><br></div>2. Using the semicolon as the bounds separator feels a bit weird, especially when combined with the colons in the initializers. In English, semicolons bind closer than colons do, so <span style="font-family:monospace,monospace">`[13, 2; [;0, 0]: 0, [;0, 1]: 0, default: -1]`</span> reads strangely. Also, where does the type annotation go? Having a semicolon after a left square bracket “<span style="font-family:monospace,monospace">[;</span>” also makes for ugly <a href="http://elm-lang.org/blog/compilers-as-assistants">code texture</a>, something to think about considering I’m going to be staring at <i>a lot</i> of these things. Then again, I’m struggling to think up an alternative syntax.<br></div><br></div>3. Some of the syntax rules could benefit from providing a little explanation, as the rationale is not always immediately obvious, for example:<br><br></div>- Allowing a single number for the left side of the dictionary literal pair, but not a comma-separated index list.<br><br><span style="font-family:monospace,monospace">[5, 2; 2, 1: 5]</span><br><br></div>of course, the comma character is already reserved for separating key-element pairs, but I had to think for a while before realizing that.<br><br></div><div>- `func` not being allowed to coexist with other initialization pairs. My first thought was “why can’t <span style="font-family:monospace,monospace">`func:`</span>initialize all the elements that weren’t covered by anything else, like <span style="font-family:monospace,monospace">`default:`</span> does? I guess this is to ensure an efficient implementation of the closure initializer, but again, this is non-obvious.<br><br></div><div>4. Please define terms like “term”, “array-index term” and “single-number term” and “index set”, among others, preferably in boldface at the top of the document. This proposal is hard enough to follow without having to puzzle out what an “array-index term” is. (Isn’t <i>every</i> index an array index term?)<br><br></div><div>5. There’s a lot of awkward and confusing language that I had to go back and reread many times over to figure out what it meant. Examples: “<i>The number to the left of the colon is the index of the element to receive the value on the right of the colon.</i>” (what???), “<i>with an explicit bound (set)</i>” (first thought: Why is “set” in parentheses? Does it not matter whether you set an explicit bound?). Again, this proposal is hard enough to follow without having to puzzle out that “(set)” refers to a list of multiple indices, not <i>setting</i> a single index.<br><br>6. “<i>The element type of the array is determined by either the return type of a function term's closure, or by the type consolidated from all the term values (like in dictionary and standard-array literals).</i>” That second part is going to kill the type checker, since I’m guessing in practice FSAs are going to have much longer literals than flexible arrays or dictionaries do right now.<br><br></div><div>7. You should add a section in the FAQ justifying the use of <span style="font-family:monospace,monospace">`as`</span> for FSA shape conversion. Why not initializer syntax?<br><pre><span class="gmail-pl-k">let</span> d <span class="gmail-pl-k">=</span> [<span class="gmail-pl-c1">4</span>, <span class="gmail-pl-c1">3</span>; <span class="gmail-pl-c1">1</span>, <span class="gmail-pl-c1">2</span>, <span class="gmail-pl-c1">3</span>, <span class="gmail-pl-k">default</span><span class="gmail-pl-k">:</span> <span class="gmail-pl-c1">0</span>]
<span class="gmail-pl-k">let</span> e <span class="gmail-pl-k">=</span> [<span class="gmail-pl-c1">4</span>, <span class="gmail-pl-c1">3</span>; <span class="gmail-pl-c1">Double</span>](d)</pre>I agree that <span style="font-family:monospace,monospace">`as`</span> is better than magical initializers, but there are legitimate arguments against <span style="font-family:monospace,monospace">`as`</span> too. Right now, <span style="font-family:monospace,monospace">`as`</span> is reserved for literals and class types. Applying an <span style="font-family:monospace,monospace">`as`</span> cast to a value type is an entirely new use-context for the keyword.<br></div><div><br></div><div>8. What is a “sub-object”??? This word started randomly appearing halfway through the document with no definition.<br><br></div><div>9. I don’t see the value in having both nested FSAs and multi-dimensional FSAs. Aren’t they the same thing? For example, in the code snippet<br><br><span style="font-family:monospace,monospace">```<br>let a = [;1, 2, 3, 4]<br>assert(a[0] == 1)<br>assert(a[1] == 2)<br>assert(a[2] == 3)<br>assert(a[3] == 4)<br>let b = a as [2, 2; Int]<br>assert(b[0, 0] == 1)<br>assert(b[0, 1] == 2)<br>assert(b[1, 0] == 3)<br>assert(b[1, 1] == 4)<br>let c = a as [2; [2; Int]]<br>assert(c[0][0] == 1)<br>assert(c[0][1] == 2)<br>assert(c[1][0] == 3)<br>assert(c[1][1] == 4)<br>```</span><br><br></div><div>There’s three syntaxes which accomplish two unique things. I lean towards disallowing FSA nesting and instead allowing <i>incomplete</i> index lists to partially unnest multidimensional FSAs. Let’s reserve “<span style="font-family:monospace,monospace">[][][]...</span>” for flexible array chained dereferencing.<br><br></div><div>10. I don’t see much value in runtime DI. It seems to add a lot of complexity to the compiler with little benefit.<br><br></div><div>11. This should have defined behavior:<br><span style="font-family:monospace,monospace"><br>let data = [2, 2; 1, 2, 4, 8]<br>for (i, x) in data.enumerated()<br>{<br> total += x<br>}</span><br><br></div><div>“with” methods should be used sparingly and not be part of common idioms like iterating through an array as a buffer.<br><br></div><div>12. Can we rename the <span style="font-family:monospace,monospace">`cardinality`</span> type property to <span style="font-family:monospace,monospace">`nestingCount`</span> or <span style="font-family:monospace,monospace">`nestingLevels`</span> something similar? That seems a lot clearer and more descriptive of that the property actually represents. I’d also bet that close to no one knows what cardinality is.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 22, 2017 at 3:41 PM, Daryle Walker via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>It’s at <<a href="https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb" target="_blank">https://gist.github.com/<wbr>CTMacUser/<wbr>cfffa526b971d0e1f3a079f53c6819<wbr>bb</a>>.</div><div><br></div><div>* Try to clarify that fixed-size arrays are a new kind of compound type, <b>not</b> a (ridiculously magical) library generic type.</div><div>* Change the separator between the bounds and element type from a colon to a semicolon.</div><div>* Specify that violating the bounds of an array during indexing is a run-time error.</div><div>* Reword how the mapping of static-indexing elements for multi-dimensional arrays works.</div><div>* Completely redo array values/literals. A literal for a fixed-size array always includes a semicolon, which separates the bounds from the values. (The separator in FSA types was changed to a semicolon to match.) A value can be a plain expression or a dictionary expression where the right side of the colon is the value and the left side is the index of the target element or “default” for all un-targeted elements. The left side can also be “func”, with the right side being an initialization closure.</div><div>* Move the “Reshaping Arrays” section and add an example.</div><div>* Right now, deterministic initialization is unchanged, so an initializing loop has to be changed to initializing the array with a function term, moving the loop to the closure.</div><div>* Remove the “parallel” declaration attribute. Add a future note about it and the “fragmentary” attribute.</div><div>* Change the for-loop example to conform to deterministic initialization. Reword how the flattening buffer functions work.</div><div>* Add examples to element-wise casting.</div><div>* Reword tuple conversion section, and add an example.</div><div>* Reword various vector-mode attribute sections. Note that there need to be two ABI additions for FSA, one for non-vectorized FSAs and one for vectorized FSAs. These two kinds of arrays need conversion functions at our (i.e. the ABI) level, but are transparent for the user.</div><div><br></div><div> let v1: @vector [3; Int] = [; 1, 3, 5]</div><div> let v2: [3; Int] = v1 // Not a type-mismatch error</div><div><br></div><div>* Due to FSA’s literals including the bounds, or using automatic bounds mode, array-placeholder syntax is not longer needed for type annotations and has been removed.</div><div>* Renamed “nestings” to “layers”.</div><div><br></div><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div>— </div><div>Daryle Walker<br>Mac, Internet, and Video Game Junkie<br>darylew AT mac DOT com </div></div>
</div>
<br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>