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

[Zoltan Somogyi]

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.

> 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 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?
 
> > 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
> 
> What about calls to stream.string_writer.format?

compiler/format_call.m already recognizes it and treats it
similarly to io.format and string.format, and I don't plan to
change that fact. It is just clunky to list it in conversation every time :-(
 
> > 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 :-)

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


Zoltan.