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

[Paul Bone]

On Mon, Nov 10, 2014 at 01:39:25PM +1100, 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 :-(
> 
> 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'm happy with either answer but I lean towards this one, that is -0.0 is
"0.0".

> > > 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.
> 

I like the idea of both a summary and a detailed listing.  A summary is
useful when someone says "Hey there's a new Mercury!" and you want to know
what's cool in this latest version.  The detailed listing is when you have
an existing program and you want to know how difficult it may be to start
using a new version of Mercury.  What's often useful in the detailed listing
is what predicates and functions have gone away or been deprecated.  The
automated diff may capture that but it won't explain why a predicate or
function has been removed or what its replacement is.  Otherwise I'm not
fussed about how the list is generated.


-- 
Paul Bone