<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker <span dir="ltr"><<a href="mailto:darylew@mac.com" target="_blank">darylew@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><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></div></div></div></blockquote><div><br></div></span><div>Why does any language with multi-dimensional arrays (like Fortran or Ada) have them? By this standard, no language should have multi-dimensional arrays. They exist because of data modeling. Co-equal coordinates in the model should be co-equal in their representation in the program. Yes, they are implemented the same way underneath. We don’t copy C everywhere, so why not take this opportunity to do better. Also, just using nesting could imply that the intermediate array types have a meaning, but they might not if they’re just implementation quirks and not part of the abstract model.</div><div><br></div><div>Nested arrays are not my solution for multi-coordinate indexing; use multi-dimensional arrays for that. I mention nested arrays because:</div><div><br></div><div><ul class="gmail-m_-2788489614445174710MailOutline"><li>Nested arrays fundamentally cannot be banned. (What if an element type is hidden behind a type-alias and is conditionally an array type?)</li></ul></div></div></div></blockquote><div>Doesn’t Swift have to resolve the types at some point anyway? If it’s impossible to ban, we can allow it, but still make it unidiomatic. Nested arrays are much messier to write than multidimensional arrays.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><ul class="gmail-m_-2788489614445174710MailOutline"><li>I need the definition to explain the “inner non-array type”</li><ul><li>I need the inner non-array type to explain which pairings of FSAs for reshaping are legal. (And a similar reason for tuple conversion.) Note the two types can have different nesting levels.</li></ul><li>I need to explain that empty arrays cannot be an array element type. (Should this be changed? What happens with tuples or structures containing empty tuples/structures as members? What about empty tuples/sturctures in “Array”? Banning empty arrays means we don’t have to worry about every array element being at the same address. The other way to solve this is to make them one byte (or word) long.)</li></ul></div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><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></div></div></div></blockquote><div><br></div></span><div>I don’t understand what your incomplete index list idea is. And as I said, the chaining technique is less I desire it and more I can’t ban it and keep Swift features orthogonal.</div></div></div></blockquote><div><br></div><div>Incomplete indexing means <br><br></div><div><span style="font-family:monospace,monospace">let fsa:[5, 2; Int] = [5, 2; 2, 4, 3, 5, 4, 6, 5, 7, 6, 8]<br></span></div><div><span style="font-family:monospace,monospace">fsa[3] // [2; 5, 7]<br><br></span></div><div><span style="font-family:arial,helvetica,sans-serif">this would be the same as writing </span><span style="font-family:monospace,monospace"><br></span><br><div><span style="font-family:monospace,monospace">let fsa:[5; [2; Int]] = [5; [2; 2, 4], </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">[2; </span>3, 5], </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">[2; </span>4, 6], </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">[2; </span>5, 7], </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">[2; </span>6, 8]]<br></span></div><span style="font-family:monospace,monospace">fsa[3] // [2; 5, 7]</span></div><div> <br></div><div>in your current system. This would obviate the need to nest FSAs for the purpose of extracting entire rows of data.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-"><br><blockquote type="cite"><div><div dir="ltr"><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></div></div></div></blockquote><div><br></div></span><div>In other languages, people initialize their arrays in loops with run-time indexes. This frustrates compile-time DI. C doesn’t have this problem because it doesn’t have DI and is willing to risk undefined behavior during uninitialized reads. So it’s either work in the confines of static DI, allow dynamic DI (hopefully under as limited circumstances as possible), or give up on checking for FSAs and allow undefined behavior (which would blow a big hole in static DI). Maybe this can be pushed to version 2. </div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><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></div></div></div></blockquote><div><br></div></span><div>FSAs are compound types, not named types, so there are no methods. (Just like tuples, FSAs don’t follow any protocols.) But since they’re a built-in, I can customize the “for-in” loop to cover all the elements in an implementation-optimized order. (The implementation has the option of multi-threading if it can see there’s no cross-iteration contamination.) Since you can’t control the order without manual looping, the “#indexOf” expression exists to let you know where you are during an iteration loop.</div><div><br></div><div>I first used the iteration variable as the operand to “#indexOf” to determine which array instance to track. Then I saw that the for-loop implements its iteration variable as a pattern in the grammar instead of something simpler. And what happens if a wildcard is used as the iteration variable? And would people question why when the pattern has multiple iteration variables, all are equally valid for “#indexOf”? I moved the operand to be the label because we usually don’t have multiple labels on statements (Is that even legal in Swift?) and can optimize which loops need to be indexable.</div></div></div></blockquote><div><br></div><div>I really dislike the addition of magical builtin variables. Iterating through a FSA should just take the FSA down one dimension level, so<br><br><span class="gmail-"><span style="font-family:monospace,monospace">let data = [2, 3; 1, 2, 3, 4, 8, 12]<br>for x:[3;] in data<br>{<br> total += x[0] + x[1] + x[2]<br>}<span class=""><br><br></span></span></span></div><div><span class="gmail-"><span style="font-family:arial,helvetica,sans-serif"><span class="">would be the pattern.</span></span><span style="font-family:monospace,monospace"><span class=""><br></span></span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>“with” methods should be used sparingly and not be part of common idioms like iterating through an array as a buffer.<br></div></div></div></blockquote><div><br></div></span><div>I need some library function to convert a FSA into a Collection, and to represent the “T[]” function parameter type concept from C, which represents any array size (instead of being locked for one length, or since we have multi-dimensional arrays, one shape). For safety, the callback function uses the buffer version so you have a pointer and size. You generally should be using the for-loop, though.</div><div><br></div><div>Using an unsafe buffer pointer forces the data into addressable memory, which isn’t necessarily the case of an instance’s location by default. (C optimizes the other way. Objects are addressable by default, and that is disabled, and any optimizations by being un-aliased activated, by the “restrict” qualifier.)</div><div><br></div><div>We should have some way to cull specific indexes in loops. (Like “lock index 2 to column 5 but iterate over all the qualifying subset of elements.”) I don’t know if this has to be a new base operation on a loop, or if it can be done through a library function, or if it can be done through a library function after we complete generics. But I think it can wait until version 2.</div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><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.</div></div></div></blockquote><div><br></div></span><div>The nesting-level is “layers.” “Cardinality” is the number of co-equal coordinates. But that second name probably needs some work, although it can be synthesized from the length of “dimensions.” The “cardinality” and “elementCount” properties work around us not having (integer) compile-time constants yet; otherwise we can derive them from compile-time expressions on “dimensions."</div></div></div></blockquote><div><br></div><div>I understand there is currently a distinction due to FSA nesting, however I don’t see why FSA nesting has to be a first-class citizen in this model. Multidimensionality should be the idiomatic way to add nesting to an FSA.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div class="gmail-h5"><div><br></div><div><div><div style="overflow-wrap: break-word;"><div>— </div><div>Daryle Walker<br>Mac, Internet, and Video Game Junkie<br>darylew AT mac DOT com </div><div><br></div></div></div></div><blockquote type="cite"><div><div class="gmail_extra"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>It’s at <<a href="https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb" target="_blank">https://gist.github.com/CTMac<wbr>User/cfffa526b971d0e1f3a079f53<wbr>c6819bb</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="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><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" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>