On Sat, Nov 13, 2010 at 9:42 AM, Sandro Magi <[email protected]>wrote:
> Given you're introducing kind-level naturals, introducing a specialized > "Bit" constructor ala "High Level Views on Low-Level Representations" > seems the next logical step. Permitting an arbitrary bit-length vector > would be a great extension of that work (those bit fields were limited > to word-size). > Hmm. Yes and no. Since BitC has bit-fields in the type system, our need for the Bit constructor isn't that great. The Bit constructor as they defined it didn't adequately address questions of alignment or packing rules either. The alignment and packing issue is a compelling reason *not* to extend the Bit notion past the size of the underlying type. Finally, bitfields are of arithmetic type for a reason. So no, I don't think that extending the bit construct is the best way to get an arbitrary length Bit sequence. But I definitely anticipate that we will bring the existing bitfield notion more into line with the type system by exploiting the Nat kind in other ways. > > This second point is controversial in the PL community - there is an > > aversion to defaulting the answers in situations like this. What do > > people think about this? > > Aren't you implicitly introducing subtyping with an inference rule to > settle on the most specific type (in this case, bool). Hmm. That's an interesting approach, and it would work in this case, but that wasn't my intention. It's a short step from Testable = bool U bit to Testable = bool U bit U int so I wasn't viewing this as a subtyping issue. And in fact bit is not a subtype of bool, since (if we attempted that approach) they do not differ in their elements at any point. > Can this > subtyping relation be specified by the user? If so, what happens if > conflicting implicits are imported? > If we allow subtyping to be specified by the user, it will be structural, and syntactically constrained to prevent the possibility of conflicting implicits.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
