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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
