OK. I'm done messing with Unicode REs for a bit, and I'm back staring at the grammar. It's surprising how messy the grammar got when we added layout, but that's not today's topic. Today I'm looking at type declarations.
>From BitC v0, I have several conclusions: 1. Mutability is part of type, and that's a complication that I'm not ready to talk about yet. 2. A given type declaration either produces a value type or a reference type. The "boxedness" is (regrettably) part of the type. 3. You can't explicitly unbox a reference type anymore, because this makes a mess for mutability types. I now think that stack allocation of boxed objects should probably be treated as a region problem. 4. A reference always points into a region. Therefore any "position" in a type where a reference appears potentially needs to have a region variable. So between mutability, type, and region we already have a lot to pack in, and then we need to deal with representation. The further constraint is that I want a syntax that will allow us to support kinding and kind classes. This mainly means that we want to go very light on syntactic punctuation in the type system so that we can do type-level operator overloading in the style of Habit. It's a mess. :-) All of which brings me to a couple of questions: *Representation*: Representation is *logically* separable from type. Can anybody give a serious use case where it would be advantageous to specify two different bit-level representations for a type *without* changing the type itself? I am not aware of any. If we can't identify one, then declarations of representation should continue to be part of the type declaration syntax for composite types. Representation and type are separated in Ada, for example see here<https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Pack-for-Records.html#Pragma-Pack-for-Records> (look at the example at the bottom that gives ranges). Not saying I like the bit-boundary approach to specification, but it's certainly precise, and it at least separates the issues. I'm asking for input more about the notion of separating the layout declaration from the type declaration in this kind of way. For overall struct layout issues, I think that the CLI layout rules cover a lot of ground, though they made a mistake deciding that the rules only need to be honored when objects are exposed to unmanaged memory. I'd like to see a general attribute scheme in BitC in any case, so maybe this is a reasonable way to encode layout. *Bitfields vs Packed Data*: As part of going to a kind classes, we get to express range constraints on values. This puts some strain on the bitfield notion. A bitfield in BitC is viewed as a fixed-precision integer with an unusual number of bits. From an algebraic perspective, int32 differs from int30 only in the number of bits. But if we introduce ranges we can start to have a type "T having a value >= 3 and < 7". Such a value is obviously representable in two bits. The question then becomes: should we introduce a more general notion of a "packed" value? My inclination is to say "no". I think I want to take the position that bitfield packing only applies to integral types (interpreted loosely, thus including enumeration and tag values), but the method of representation is to take the value directly and encode it as a [signed or unsigned] integer. A bitfield can be used for that type exactly if it can represent all of the values required. Under this rule, the type "T having a value >= 3 and < 7" requires 3 bits (unsigned) or 4 bits (signed). Any reactions or thoughts to any of this? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
