Reals are less than ints
Niklas Höglund
annoying for someone using my coding style. Look for example at the
following program:
signature EX = sig
val double : real -> real
end
structure Ex :> EX =
struct
fun double x =
x+x
end
I know I can fix this program by specifying the type of double in the
structure, but I prefer to specify all types in the signature, and leave
the code in the structure uncluttered by types. Adding types to
structures does add unneccessary redundancy.
A clever compiler could handle this case.
Overall, I think SML is a bit schizofrenic when it comes to +-*/. I'd
like to be able to use + to add integers, reals, fractions, matrices,
etc. (Ad hoc overloading or something.) I can also buy the OCaml way
of no overloading, but I think the current way of "a little" overloading
is suboptimal.
The following would be a good solution, I think:
structure Int =
struct
val + = ...
infix +
overloaded +
end
structure Matrix =
struct
val + = ...
infix +
overloaded +
end
open Int
(* + here is Int.+ *)
open Matrix
(* + here is either Int.+ or Matrix.+, like the current situation with
Int and Real, but not hardcoded *)
The top-level environment could contain the following:
overloaded +
val + = Int.+
val + = Real.+
An added benefit of this is that opening say Word to get easy access to
andb, orb, ... would not destroy + as it currently does.
My suggestion of syntax may not be the greatest. Maybe something in
line with "val rec" should be used: "val overloaded + = Int.+". With
this syntax, doing "val + = Int.+" could remove all overloaded
instances.
What do you think? How should this work?
--
Niklas
Aaron Denney
> What do you think? How should this work?
Have you looked at the Numeric typeclasses of Haskell?
--
Aaron Denney
-><-
Niklas Höglund
> In article <bbfuki$b18$1...@wolfberry.srv.cs.cmu.edu>, Niklas Höglund wrote:
>> What do you think? How should this work?
>
> Have you looked at the Numeric typeclasses of Haskell?
Yes. That may be a pretty good solution.
There could be some problems, though. I believe there's too much
structure/organization in the Haskell type classes. This is just a gut
fealing, though.
If I have a type class for the operations +, -, * and /, and want to add
matrices that don't have a / operator, I can't leave that operation out.
On the other hand, that might be an indication that the original classes
were wrong and should be separated into one class for +, - and * and one
for /.
--
Niklas
Aaron Denney
> If I have a type class for the operations +, -, * and /, and want to add
> matrices that don't have a / operator, I can't leave that operation out.
> On the other hand, that might be an indication that the original classes
> were wrong and should be separated into one class for +, - and * and one
> for /.
Yes, there was some discussion on the lists about this a while back.
There were a couple of proposals to restructure the numeric typeclasses,
but no consensus was achieved -- some of the proposals tried to break
things up too far for convenience.
Alex Drummond
> Yes. That may be a pretty good solution.
>
> There could be some problems, though. I believe there's too much
> structure/organization in the Haskell type classes. This is just a gut
> fealing, though.
> If I have a type class for the operations +, -, * and /, and want to add
> matrices that don't have a / operator, I can't leave that operation out.
True, but you could just give a dummy implementation of division, or one
that exited the program with an error message. It's ugly, but workable.
> On the other hand, that might be an indication that the original classes
> were wrong and should be separated into one class for +, - and * and one
> for /.
I think Clean might use this system.
Alex