On 21/08/12 15:52, Matthew Fluet wrote:
On Tue, Aug 21, 2012 at 6:08 AM, David Matthews
<david.matth...@prolingua.co.uk> wrote:
On 20/08/2012 23:56, Phil Clayton wrote:
I have to say, if find it surprising that compilers even allow
Word.word to match the equivalent size Word<N>.word given the
specification in the Basis Library
<http://www.standardml.org/Basis/word.html>
structure Word :> WORD
where type word = word
structure Word<N> :> WORD (* OPTIONAL *)
which uses opaque signature matching and has no 'where type' clause for
Word<N>.
This seems to be a bit of a mess as far as I can see. I don't understand
how to deal with the sentence that says:
If LargeWord is not the same as Word, then there must be a structure WordN
equal to LargeWord.
But LargeWord is required while WordN is optional. And what does "equal to"
mean for structures?
I've always understood "equal to" to simply mean that the "word" types
are equal. It is perhaps wording leftover from SML'90 days, with
structure sharing.
As for "there must be a structure WordN equal to LargeWord", I've
understood that to mean that an implementation should include a
structure with the explicit width of LargeWord, such that
LargeWord.word = WordN.word.
This view appears to be a fairly standard interpretation across
compilers for all WORD/INTEGER structures of the same
wordSize/precision. For example, the following all type check on my
platform:
MLton: (0w0 : Word32.word) : Word.word;
SML/NJ: (0w0 : Word31.word) : Word.word;
Poly/ML: (0 : IntInf.int) : Int.int;
and none of these port to the other compilers (where structures are
available).
Admittedly, I disagree with the Basis Library specification in this
regard. I think it makes more sense for all of the INTEGER.int and
all of the WORD.word types to be distinct; that is, "Word32.~ o
LargeWord.~" should not type check, even if LargeWord.wordSize = 32.
I share this opinion. Unfortunately the current interpretation creates
a source of non-portability, for almost no benefit that I can see.
I'll see if I can get any comment on the sml-basis-discuss list.
Phil
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
