[m-rev.] for review: clean up string.m

[Julien Fischer]

Hi Zoltan,

On Mon, 10 Nov 2014, Zoltan Somogyi wrote:

> On Mon, 10 Nov 2014 10:58:04 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>> For now, I suggest simply checking whether signbit exists in the configure
>> script as per the other FP macros and calling MR_fatal_error if it doesn't.
>> (I'll add implementations for older C compilers at a later date.)
>
> I will check for signbit with configure, but falling back to < 0.0
> seems less drastic than MR_fatal_error.

As temporary measure calling MR_fatal_error is the right thing to do.
It tells the developers that we need to go and add an implementation for
whatever platform is triggering the abort.

>> I was intending to add signbit and a bunch of other impure low-level float
>> operations to the float module anyway, so if you are going to use it you
>> may as well add it there.
>
> When? I would prefer it if you did it, since you have much more
> recent experience with the innards of FP encodings. I don't need
> such stuff for a while, since I can easily just ignore any test case
> failures resulting from -0.0 vs +0.0 mismatches.

I'll add the signbit implementation to the library later today.
(My other work on the FP stuff has been postponed because I'm quite busy
with Opturion projects at the moment.)

>> I think the bigger question here is: how should string.format (and friends)
>> handle -0.0 in the first place?
>
> Agreed. It seems to me that we have two strong considerations
> that directly oppose each other: the axiom you referred to,
> and the expectations that some users may have about Mercury
> preserving the sign of zero, as other languages may have trained
> them to expect.
> We could try to train users (if any even exist
> that care about sign of zero), or we could restrict that axiom
> to the case where all the involved variables are numbers, not
> strings.
>
> Since I don't usually work with floats, I don't have any
> strong preference. Does anyone else?

My suggestion would be that string.format (i.e. the pure subset of
Mercury) should alway produce positive zero.  Users that care about negative
zero (who are certainly in the minority) are already going to be forced
to work in the impure subset of Mercury.  (Indeed, when the issues
described at the top of the float module are finally fixed, they're
going to be more forced to work in it.)

We should actually have a section in the reference manual that describes
how Mercury aligns (or does not align) with the IEEE FP standard, not
just a comment at the top of the float module.
(I suspect I may have just volunteered to write it.)

>>> I next intend to move the implementation of string.format
>>> to a new submodule of string.m, so that string.m doesn't become
>>> even bigger when I add code for parsing format strings
>>> *without* the values to be printed being present.
>>> The idea is for compiler/format_call.m to use this new capability
>>> to transform *all* calls to string.format and io.format in which

...

>>> the format string is statically known to a sequence of calls to the
>>> predicates that do the actual formatting, thus compiling away
>>> all the format string interpretation overhead.
>>>
>>> This would require turning off using_sprintf, since (a) we cannot
>>> target the innards of a C library function, and (b) having the
>>> interpreted and compiled versions of string.format and io.format
>>> having different behavior is not a good idea.
>>
>> That's fine by me, the differences between the sprintfs on different systems
>> have long made testing things more complicated than they should be.
>
> Based on your work recently with NaNs and Infs, I expected
> you to say that :-)

It's not just that.  Octal conversions were broken on OS X for quite a
while IIRC and the Microsoft "implementation" is weird non-standard
disaster of a thing.

>> The diff itself looks fine except the additions to the require module
>> need to be mentioned in the NEWS file.
>
> Done, though I have long thought that the NEWS file
> would be more useful if it wasn't clogged with such minor
> changes.

Library changes do need to be listed somewhere IMO.  We used to split
the NEWS file into two sections, with summary at the top and then
a detailed listing.  Perhaps, we should to that again?

Cheers,
Julien.