While thinking about bit sets, I noticed that BitC has no good way to
express a long bit-vector. While there is a rough bit set implementation in
the current library, it's an abstraction rather than a data structure.
What's wanted is an array or vector of bits. The problem is that a) bit
isn't a core datatype [easily fixed] and b) bit fields can only appear
within structures.
So I started to hack in a "bit" type. Most of that is quite easy, but I
quickly ran into a quandry:
1. Bits share a lot in common with type "bool". In fact, one would really
like to use the literals 'true' and 'false' to initialize them.
2. Bits and bool really need to be distinct at the type level. An array of
bits has a different shape than an array of bool, and conversion (either
zero extension or truncation) is required for cross-assignment of these
types.
Now obviously this can be resolved by settling for bTrue/bFalse and
introducing a suitable convert operator, and that's probably the thing to do
in the short term. We could perhaps change the type constraint on
conditionals from "test expression must be boolean" to "test expression must
be 'a\Testable('a)", allowing bit to be used in test expressions (though
that needs some validation by experience).
This raises two issues, though.
The first is that we're inching toward implicit coercions at assignments and
bindings. In contrast to the integer cases, the range of values here is
really equivalent, and implicit conversion is therefore tempting. I don't
think we should do it - it will break inference.
The second is that we're starting to see use-cases where multiple types want
to be allowed but in the absence of resolution by inference a particular
type is preferred. In this case, if we allow {bool | bit} in test
expressions, and the inference process doesn't resolve to one of these, and
the outcome isn't connected to a type variable that will get expanded later,
we end up with an under-specified type that won't compile and we get stuck
inserting an annotation. But I claim that in this case there is a well-known
preferred type - bool - and that forcing the resolution is better than
failing to compile.
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?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
