With regards to representation, it depends very much on the strategy
that you pick for representing structures (or "records"). For instance,
Rust chose to keep it very close to C-layout, aiming to be able to call
external C-functions using native Rust types. Rust is also very much in
the camp of "making a better C language", which may explain that choice.
OCaml on the other hand keeps its structure representation completely
hidden from the programmer. As a matter of fact, a simple type like
Point2d with two floating point members (x and y), may have y first and
then x, or the other way around. They calculate the offset based on a
hash, which in the end works very well when combined with the notion of
extensible records. (Yes, there's some deep magic going on there.)
So, to answer the question, it really boils down to the following:
1. Do you allow programmers to care about layout?
I do care about layout more than most, but that is because I am
working with hardware level data (GPU registers, etc.). But I would
imagine that it is mostly unimportant for most code. (An exception
here is atomics -- you do want to place atomics at specific
locations within a structure in order to avoid cache conflicts.)
2. Should you separate layout from types?
I don't think you need to. You could just as well support (or
annotate) a structure definition, so that we have "structures where
the compiler specifies the layout" and "structures where the
programmer specifies the layout". If you need to work on data that
has two different layouts (hence different types) but differ only in
the way that it is represented, then type classes / traits would be
useful in order to avoid duplicated code.
On bitfields/packed data, that sounds like a premature optimization kind
of thing. If I wanted an u3 to represent numbers [3,7), then accessor
functions would do just as well.
Thanks,
PKE
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
