> On 3. Aug 2017, at 07:26, John McCall <rjmcc...@apple.com> wrote: > >> On Aug 3, 2017, at 12:45 AM, Daryle Walker <dary...@mac.com >> <mailto: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
I’m not saying that tuple member names are “true integers” (although, with Reflection…). I understood that, semantically, the reason we refer to elements .0, .1 and .2 of a tuple because that’s their name, not necessarily because its their position in the tuple. My point is that for a fixed-size array like a [3; Double] vector, because you know what to expect at each location, those indices are *both* ordinal *and* nominal. Subscripting [0] or [1] from that FSA has the same conceptual meaning as accessing .x or .y on an equivalent struct. What I’m trying to say is: for a FSA, the index *is* the member name, just like the declaration-order number is for tuples. > > 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. I think the difference is that, for a fixed-size Array, the absolute positions also generally have external meaning which is known to the programmer but not reflected in the type-system. For example, that a [3; Double] vector is supposed to be interpreted as (x, y, z) components, in that order. We can do better than to expose a 3-element vector as a list of 3 unlabelled values. Or even a n-dimensional matrix just as a series of numbers. A better system may require meta-programming features we don’t support yet, and that’s fine, but I would really like us to focus on the actual use-cases of FSAs and to consider ways of making those great, rather than checking off a feature that we have to have ‘just because’. > > 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. I remember that in the first Swift beta, you were allowed to mutate a “let” Array as long as you didn’t change its length. The community didn’t like it and things moved to COW instead. > > 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
