Hi Robert,
* Compatibility-breaking changes to the bytecode file format.
The second problem is the one I wish to discuss. Since I began work
on the Yhc bytecode library in May, there have been at least two
instances of compatibility-breaking changes. One relates to Hat
integration, I believe, and the other has to do with the switch to
libFFI.
Both of these changes were made without bumping the version
number that appears in the file header. I would like to suggest that
such changes be avoided in the future.
While there is still work ongoing I think its unfortunate but a
definate reality that things will have to be broken in binary file
formats - we want to put the .hi information in .hbc files, that will
require breaking. We want to do a linking pass to merge multiple
.hbc's into one - that will require breaking.
However, you're entirely right, any change that breaks anything from
now on needs a version bump.
It may also be a good time to think about a ways to future-proof the
file format so that future additions can be made without breaking
compatibility. Right now the format is quite fragile. Perhaps we
could take inspiration from the Java classfile format. The basic
idea is that there are named blocks of data with a minimal header
which gives the name of the block and the size of the data payload.
The name of the block defines the meaning of the data. Eg, the
'CODE' block contains bytecode instructions, etc. If any block is
encountered with an unrecognized name, it is ignored. That way, one
can have optional blocks, or one can add blocks without breaking
compatibility. One can also have optional information (like
debugging symbols) and things of that nature.
That was always the intention, I'm hoping that once we move to having
Yhc.ByteCode handle everything, we can treat that as an abstraction
over the file format, and then we can work on defining a new .hbc file
format designed to last a very long time without changes. Me and Tom
did a brain storm a while on the "perfect" .hbc file format, but
unfortunately we've never had time to implement or document it...
As a side note, all these issues apply equally to .ycr files, for
which there are now 3 projects making active use of. For that I have
defined a Haskell interface which is the only supported way of getting
at the data (that can't be done for the .hbc files, as the C needs
access to them). I am also very agressively bumping the version number
- the tiniest change gets a new version. I am also ignoring backwards
compatability, at every version bump I just ignore all old files.
Thanks
Neil
_______________________________________________
Yhc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/yhc
