On 2010-11-13 12:02 PM, Jonathan S. Shapiro wrote:
> 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.
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).
> 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?
Aren't you implicitly introducing subtyping with an inference rule to
settle on the most specific type (in this case, bool). Can this
subtyping relation be specified by the user? If so, what happens if
conflicting implicits are imported?
Sandro
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
