Hi,
Trying to port my code from SML/NJ to Poly/ML, I'm stuck with the Word31 structure.
In SML/NJ, Word = Word31 and WORD signature defines operators <<, >> and ~>> like this: val op << : word * Word31.word -> word
This means that Word31 is the right operand for this operator, even in word32 and in Word64 structures.
My code base is built on this signature (would be hard to change it everywhere; and would no more be OK for SML/NJ).
Does someone have a trick to port this to Poly/ML ?
Thanks,
Gael.
On 20/08/12 23:03, Gael Mulat wrote:
Hi,
Trying to port my code from SML/NJ to Poly/ML, I?m stuck with the Word31 structure.
In SML/NJ, Word = Word31 and WORD signature defines operators <<, >> and ~>> like this:
val op << : word * Word31.word -> word
which is the same as
val op << : word * Word.word -> word
This means that Word31 is the right operand for this operator, even in word32 and in Word64 structures.
E.g. no problem with
Word64.<< (0w1, 0w8 : Word.word);
My code base is built on this signature (would be hard to change it everywhere; and would no more be OK for SML/NJ).
Does someone have a trick to port this to Poly/ML ?
Assuming you don't really need 31 bit words, my advice would be to use Word (which all platforms have) rather than Word31. Although Word.wordSize can vary across platforms, I find it highly unlikely that this will be an issue for representing the number of bits to shift. With SML/NJ it is 31 and with Poly/ML it is 63 (at least on x86_64 platforms). So hopefully you can fix this by replacing references to Word31.
Relying on Word31 is not advisable for portability as this is an optional structure in the Basis Library.
Also, if you must make use of Word31, don't assume that Word31 = Word. For example, if a Word<N>.word is used where a Word.word is specified in the Basis Library, convert with
(Word.fromLarge o Word<N>.toLarge)
On platforms where unnecessary, the conversion should be optimized away. 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>.
Phil
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?
David
On Tue, Aug 21, 2012 at 6:08 AM, David Matthews David.Matthews@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.
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.
On 21/08/12 15:52, Matthew Fluet wrote:
On Tue, Aug 21, 2012 at 6:08 AM, David Matthews David.Matthews@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
On 22/08/2012 23:37, Phil Clayton wrote:
On 21/08/12 15:52, Matthew Fluet wrote:
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.
In Poly/ML LargeWord is 62 bits in 32-bit mode (2*31-bits) and 126 bits in 64-bit mode (2 * 63-bits). This is sufficient to implement SysWord. It seems a bit artificial to insist that there must be Word62 and Word126 structures. Perhaps it would be better to implement Word32 and Word64 more efficiently (currently Word32 is implemented in terms of LargeWord or Word) and then use that for LargeWord.
David
On 22/08/12 23:37, Phil Clayton wrote:
I'll see if I can get any comment on the sml-basis-discuss list.
From sml-basis-discuss:
On 23/08/12 01:11, John Reppy wrote:
This issue was a point of debate during the basis design discussion.
There was an argument by some that distinct types would make code more portable (which I believe is correct), but there was a counter argument that making the type distinct would make programmers work harder.
In the end it was decided to keep the status quo, which was that the
types are not distinct.
See the following for previous discussion. You need to be subscribed to the list to view archives.
Subject: [Sml-basis-discuss] "same" and "equal" structures https://mailman.cs.uchicago.edu/mailman/private/sml-basis-discuss/2004-Janua...
Subject: [Sml-basis-discuss] abstract numeric types https://mailman.cs.uchicago.edu/mailman/private/sml-basis-discuss/2004-April... https://mailman.cs.uchicago.edu/mailman/private/sml-basis-discuss/2004-May/t...
Phil
-
David.Matthews＠prolingua.co.uk -
Gael.Mulat＠mathworks.fr -
matthew.fluet＠gmail.com -
phil.clayton＠lineone.net