It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Phil
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
David
On 5 Feb 2012, at 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
This must have been just an oversight in the Basis Library design. It is crazy that opening the structure Time.Time prevents you using the natural syntax for arithmetic on the real and integer types that you use to construct values of the abstract type the structure implements.
Regards,
Rob.
5 feb 2012 kl. 17.24 skrev Rob Arthan:
On 5 Feb 2012, at 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
This must have been just an oversight in the Basis Library design. It is crazy that opening the structure Time.Time prevents you using the natural syntax for arithmetic on the real and integer types that you use to construct values of the abstract type the structure implements.
That is because of the semantics of Open and has nothing to do with Time specifically. Opening any library which has its own versions of the overloaded math operations will remove the overloading. Witness:
Poly/ML 5.4.1 Release
open Real;
[...output omitted....]
1+1;
Error-Type error in function application. Function: + : real * real -> real Argument: (1, 1) : int * int Reason: Can't unify int (*In Basis*) with real (*In Basis*) (Different type constructors) Found near 1 + 1 Static Errors
Lars-Henrik Eriksson, PhD, Senior Lecturer Computing Science, Dept. of Information Technology, Uppsala University, Sweden E-mail: lhe@it.uu.se, Web: http://www.it.uu.se/katalog/lhe?lang=en Phone: +46 18 471 10 57, Mobile: +46 705-36 39 16, Fax: +46 18 51 19 25
On 5 Feb 2012, at 16:45, Lars-Henrik Eriksson wrote:
5 feb 2012 kl. 17.24 skrev Rob Arthan:
On 5 Feb 2012, at 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
This must have been just an oversight in the Basis Library design. It is crazy that opening the structure Time.Time prevents you using the natural syntax for arithmetic on the real and integer types that you use to construct values of the abstract type the structure implements.
That is because of the semantics of Open and has nothing to do with Time specifically. Opening any library which has its own versions of the overloaded math operations will remove the overloading. Witness:
Poly/ML 5.4.1 Release
open Real;
[...output omitted....]
1+1;
Error-Type error in function application. Function: + : real * real -> real Argument: (1, 1) : int * int Reason: Can't unify int (*In Basis*) with real (*In Basis*) (Different type constructors) Found near 1 + 1 Static Errors
You are right. What a mess!
Regards,
Rob.
This is discussed in Larry Paulson's MLWP, section 7.14 (page 303 in my paper copy), in his endearing humorous style. Some workarounds suggested.
On 05/02/12 17:14, Rob Arthan wrote:
On 5 Feb 2012, at 16:45, Lars-Henrik Eriksson wrote:
5 feb 2012 kl. 17.24 skrev Rob Arthan:
On 5 Feb 2012, at 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
This must have been just an oversight in the Basis Library design. It is crazy that opening the structure Time.Time prevents you using the natural syntax for arithmetic on the real and integer types that you use to construct values of the abstract type the structure implements.
That is because of the semantics of Open and has nothing to do with Time specifically. Opening any library which has its own versions of the overloaded math operations will remove the overloading. Witness:
Poly/ML 5.4.1 Release
open Real;
[...output omitted....]
1+1;
Error-Type error in function application. Function: + : real * real -> real Argument: (1, 1) : int * int Reason: Can't unify int (*In Basis*) with real (*In Basis*) (Different type constructors) Found near 1 + 1 Static Errors
You are right. What a mess!
It is, but I think the point is that if the Basis Library overloaded infix operators for Time.time values we wouldn't need to rebind them (by whatever means) to make them infix, enabling us to avoid this overloading issue. As Rob says, it must be an oversight.
Phil
On 05/02/12 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
I discovered this when MLton rejected some existing code I had. SML/NJ also follows the Basis Library strictly too. I suppose the question is whether the potential portability problems outweigh the benefits.
Phil
On 05/02/2012 19:13, Phil Clayton wrote:
On 05/02/12 11:51, David Matthews wrote:
On 03/02/2012 15:44, Phil Clayton wrote:
It appears that Poly/ML overloads operators + - < <= >= > for Time.time but they shouldn't be, according to the Basis Library. http://www.standardml.org/Basis/top-level-chapter.html#section:3 Perhaps they were overloaded once upon a Time.time...
Yes, it looks as though strictly speaking you're right. It does seem strange, though, to have these operators and not include them in the overloading. I'm rather reluctant to remove the overloading but I appreciate as it stands it doesn't comply with the definition.
I discovered this when MLton rejected some existing code I had. SML/NJ also follows the Basis Library strictly too. I suppose the question is whether the potential portability problems outweigh the benefits.
Generally, I prefer to conform to the standards whenever possible but in this case I'm not convinced that it would be a good idea to change it. As an experiment I removed the overloading and had to make several changes to the rest of the library code to allow it to compile. Perhaps as a first step I'll ensure that the rest of the library will compile if the overloading is removed and then people can experiment with removing the overloads. They are just the last few lines of basis/Time.sml.
David
-
David.Matthews＠prolingua.co.uk -
itz＠buug.org -
lhe＠it.uu.se -
phil.clayton＠lineone.net -
rda＠lemma-one.com