[swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker]

> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m -1 on adding a fixed-sized Array type.
> 
> It goes back to something which I remember reading from John McCall earlier this week but can’t find any more: about tuple indices being nominal and not ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal?

I think he meant that the numbered names for tuple members were originally (?) there because the Swift authors didn’t mandate each member needing a label, so there needed some way to refer to unnamed members. Note that numbered names are not true integer variables, not even useable as such. Array indexes are programmable objects; algorithms on the indexes is how we select array subsets to apply algorithms on.

> The difference between a fixed-size array and the dynamically-sized Array we already have is that the programmer expects specific data at each element. Maybe it’s elements of a vector or matrix, or some other structure, but in general I think that constraints about the size/shape of the sequence implies expectations about what you’re going to find at each location. Maybe you would normally write a struct for it, but it’s not worth writing out. In that sense, how is it different from a homogenous tuple?

I’m not sure what you mean here. How do elements of dynamically-sized arrays not have expectations?

The big innovation arrays (and loops) brought was no longer having a per-sub-object declaration/command for elements. Just tweak a number.

I’m not good at explicit explanations, so having to justify adding a type that’s been around for a long time (at least FORTRAN 4+ decades ago) an almost every systems programming language has is frustrating. I thought the desire would be obvious; if there were FSAs in Swift 1, would there be any “just slap Collection on tuples and be done with it” suggestions now? It doesn’t help that I still don’t know why FSAs where skipped in Swift 1; did they forget or was there some high-level type-theory reason? (Were the type description records in the Swift ABI too fragile for a type that wouldn’t have per-sub-object entries (assuming theoretical Swift-1-FSAs weren’t translated to massive homogenous tuples)?)

I mentioned in my proposal that no language (that I know of) splatted tuple and array syntax together, either declaration syntax or dereferencing syntax. (Lua has shared dereferencing syntax, but they both rip-off dictionaries.) Where do people think every one else over the last few decades went wrong?

Maybe there’s a copy of the FORTRAN design documents out there?...

> Also, what effect would this have on Array as the common-currency for simple lists? And what about the literals - does [myObj, anotherObj] give you a [MyObject] or a [2; MyObject]? Is that what users will intuitively expect? What about if it’s a “let” constant?

Later revisions of the proposal have a distinct grid literal syntax, to clear up any potential confusion. The standard array literals would map to Array. The grid literal, which includes the dimensions of the array before a list of each value, would map to a fixed-size array.

> So overall, I’m unconvinced of the need for fixed-size arrays. My counter-proposal would be a shorthand syntax for more conveniently defining homogenous tuples, and keep them as our go-to objects for ad-hoc groups of things. That’s it. If you would have used a fixed-size Array in C, keep using homogenous tuples in Swift.
> 
> As for the part about the @vector and @parallel attributes, those would be worth a separate proposal. As for @parallel, I suggested something like that before but Dave Abrahams said any such support would look more like a generic concurrent wrapper, e.g. https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572 <https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572>. Vector support is worth thinking about in a separate proposal.

A main point for my FSA design is that I want to allow the default iteration primitive (for-loop) to have a vectorized/parallel implementation (someday). Since Sequence/Collection always has a sequential traversal policy (It’s in the name!), it’s the main reason FSA don’t directly conform to Collection in the design.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/7e62c485/attachment.html>