> On Aug 3, 2017, at 12:45 AM, Daryle Walker <dary...@mac.com> wrote: >> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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.
Yes, essentially. I was making this argument on a slightly higher level, just thinking about the meaning of values separate from any syntax. A fixed-sized array is still fundamentally an array: it's a sequence of homogenous elements, where relative positions generally have some level of meaning. In an array like [A,B,C,D], it's probably *significant* that A comes first and that C comes before D. On some level, if it wasn't true that the order was significant, it wouldn't "really" be an array, it would be a set (or multiset) being represented using an array. In contrast, a tuple is more like a jumble of independent values, ordered only because in this benighted world we can't really write them down at the same time. If you know someone's name and age, and you have to scribble them both down on a piece of paper, it doesn't really change anything which one you write first. At most there's some arbitrary convention for the order, like putting x before y in Cartesian coordinates. We can choose different types for different purposes because they convey different things about the values they store. Isomorphism is not meaning. >> 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)?) They just weren't a priority. There are many things I wish we had done more work on before we released Swift 1, but trying to perfectly represent everything in C type system is not one of them. Reasons not to prioritize fixed-sized arrays: 1. Variably-sized arrays are a much more important data structure. Fixed sized arrays are easier to make perform well, but they are inflexible and only narrowly useful. 2. The bound introduces significant expressional complexity to the type system. What types are eligible as bounds? What sorts of inference and meta-programming are possible on bounds? etc. 3. The language/library interactions are complex. It's a general data structure that demands proper integration with the rest of the collections library, but the language also really needs to hard-code an exact representation. So it would take a lot of work to integrate. Honestly, a lot of this still applies. I would like to see fixed-sized arrays in the language eventually, but they are not going to become a priority, because there's a lot of other stuff that is more important to work on. John. > > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
