Well with an array, there's a non-type-specific meaning for the indexes--they're just unsigned integers. But with records, the indexes are offsets and are type-specific. You could have "offset types", but you'd probably want a different offset type for each record type. In other words, if you try to have a single type of "literal identifiers", it's not clear to me how you'd implement efficient record projection. (If you ignore implementation issues, like offsets providing fast projection, then yeah, all these things are basically dependent functions.) So I wouldn't try to think of records as dependent arrays.
But copy-and-update does seem like adding environment entries, assuming the type is allowed to change. (I guess I'm not following your train of thought, from copy-and-update to literal identifiers.) On Sat, Dec 27, 2014 at 8:38 AM, Jonathan S. Shapiro <[email protected]> wrote: > In reading through the F# specification, an old issue came to my mind: > anonymous records. > > F# has a copy-and-update syntax that looks like: > > { recordValue WITH name = "Bill"; Height = 176.0 } > > > We talked about something similar for BitC years ago. I like the idea, but > there is something that bugs me about it. Let's look at a related construct: > > let x = 1 in > let y = 2.5 in > ...body > > > Doesn't that seem awfully similar to (making up a syntax): > > using { environment WITH x = 1 WITH y = 2.5 } do ... > > > and aren't both pretty closely related to named parameters at procedure > calls? Aren't all of these constructs, in some sense extending an > environment by adding and/or shadowing names? And what about: > > struct S is > i : int > f : float > > S { i = 1; f = 2.5 } > > > Can't we view initialization of a named record type instance as proceeding > from a type-compatible anonymous record type instance? > > And for that matter, aren't applications really applications of a procedure > to an environment whose formal parameters have names and whose actual > parameters are named positionally? > > f x y with namedArg = 2 => > f { #1 = x; #2 = y; namedArg = 2 } => > > > Horrible syntax, I know. Sorry. > > > Doesn't it seem like all of these are variations on environments and/or > environment updates? If so, is it possible that they should perhaps have a > common syntax and semantics? > > Maybe I'm barking up a tree here. Maybe it just feels like "r with name = > value; name = value" should be an infix operator (with) acting on a set of > values of some sort. > > David Gelernter did some work in this direction many years ago. Here's a > link to the paper: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.9662 > > But let me take this a step further: > > Suppose, for just a moment, that we admit a new Kind into BitC: literal > identifiers. This would mess up the story for identifier resolution quite a > bit, but let me waive my hands about that for a moment. If we admit > identifier literals, then what is the difference between > > someRecord.fieldName > someRecord[fieldName] > > > That is: isn't an environment just a map from literals to values? And isn't > an array just a map from literals to values in which all values have like > type? > > It feels to me like there really ought to be a way to reduce all this down > to something practically helpful, but it escapes me how to do that at the > moment. I'm looking for ideas and/or suggestions. I'm more concerned about > semantics here than I am about syntax simplification, though simpler syntax > is always nice to have. > > > shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
