On 09-Feb-2000, Mark P Jones <[EMAIL PROTECTED]> wrote:
>
> The Numeric.showFloat function is there for the more expert programmers
> who care about the last few bits after the floating point. That's the
> function that a Haskell programmer should use if they need this kind of
> functionality. I can imagine a complaint along the lines of: but I can't
> use Numeric.showFloat because I'm really using "show" on a more complex
> data structure, and it doesn't use Numeric.showFloat. Indeed. But that's
> an argument against the use of overloading, not about how numbers are
> displayed. An overloaded operator can only have one interpretation at
> any given type, and if you find yourself with two useful operations, then
> you have a problem. Whichever you choose will be wrong for somebody.
> (Possible solutions to this might be found in the use of implicit parameters,
> or in a beefed up showsPrec function that takes more than an integer
> precedence as its argument.)
That's not an argument against the use of overloading --
the solution is to use _more_ overloading, i.e. if you have
two useful operations, then use two different overloaded functions.
How about adding a new method to the `Show' class, called
say `show_pretty', with this by default being equivalant
to `show'?
We considered this issue in quite a bit of detail in the design of
the Mercury standard library. Our design was influenced by that
of Prolog, amoung other languages. Mercury has `write' and `read'
for text I/O in a portable format where anything that is written can
be read in again; `write_binary' and `read_binary' for binary I/O with the
same guarantee about reading anything that you write, but not necessarily
portable; and `print' for output in a "pretty" form intended for human
consumption, which is not necessarily readable by `read'.
I think if you try to make do with any less than this set of
operations, you will probably run into difficulties. Even this
set may not be quite enough; there is a good argument for supporting
portable binary I/O too.
> The argument that show/read can be used as a portable way to store data
> doesn't work for Haskell because the report does not guarantee a portable
> implementation for Float and Doubles.
So long as your Floats and Doubles are within the
range supported by all implementations (or at least all that you
care about), and so long as you accept that some accuracy may be
lost for I/O between different implementations, read/show
should be OK as a portable way of storing data.
> String representations are for
> humans; for the benefit of machines, a binary representation would be
> better.
Often it is desirable to have a representation that both machines
_and_ humans can parse. Ease of debugging is an important consideration.
> Double precision floats can be supported in Hugs, but their implementation
> requires a non-portable hack, and so they are turned off by default (much
> to Jerzy's frustration, I'm afraid :-().
What's the non-portable hack, and why is it required?
We manage to support double precision floats in Mercury
without requiring the use of non-portable hacks ;-)
(We do use some GNU C extensions in our floating point
implemenation, but they are only used to improve performance,
and they are conditionally enabled so that it works fine,
albeit probably a bit slower, with other C compilers.)
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
