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

[Julien Fischer]

On Mon, 10 Nov 2014, Zoltan Somogyi wrote:

> On Mon, 10 Nov 2014 12:59:00 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>
>> 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.)
>
> I just looked at float.m. I always knew we didn't fully implement
> IEEE 754, but I didn't remember that things were this bad :-(

The problem is actually that we're too faithful to IEEE 754 at the
expense of purity in Mercury.  At the time that module was written there
wasn't a lot of choice about that since the facilities needed to fix it
portably weren't introduced into C until C99 (and didn't make it into
certain C compilers until last year!).

> Yes, given all that, I agree that printing -0.0 as "0.0" is the right
> thing to do. Any other opinions? (For me, it also means I don't
> need the signbit test.)

I'll add it anyway, although you've spared me having to do it this
afternoon.

...

>>> 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?
>
> I don't think the detailed listing is all that useful between releases,
> because only developers tend to use rotds, and they see the additions
> in mercury-reviews. The list of added library predicates/functions
> in a release would be more likely to be correct if it was done just once,
> when the release is prepared, and not piecemeal, because it could
> be done semi-automatically, using the debugger command that
> lists all the procedures in program. Just create a program that
> imports all the library modules, compile it while disabling the deletion
> of unused procedures, and voila, a complete list of the procedures
> in the standard library. Do this with the current and the previous
> release, and take the diff.

The problem with that is that along with the library changes you
sometims need to add an explanation for *why* that change was made, for
example some of the recent changes to the char module.  In that case
those explanations are far better added by the person who made the
change when they make the change rather than the person preparing the
release 6 months down the track.

Cheers,
Julien.