[m-dev.] for review: mention string__format changes in NEWS file
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu Aug 17 16:03:52 AEST 2000
On 11-Aug-2000, Peter Ross <peter.ross at miscrit.be> wrote:
> On Fri, Aug 11, 2000 at 02:51:00PM +1000, Fergus Henderson wrote:
> > - If the changes are sufficiently large that they might reasonably
> > be expected to cause backwards compatibility problems, then
> > even though interface design principles suggest we should only
> > have one string formatting function, the way we should achieve
> > that while retaining backwards compatibility is to give the
> > new code a new name and to deprecate the old version,
> > giving it a `pragma obsolete' declaration, rather than
> > removing it. (Sorry I wasn't clear about this earlier.)
> > As I understand things, the changes to string__format are indeed
> > such that they might well cause backwards compatiblity problems
> > for our existing users. Is that correct?
> >
> Having now done all the test cases, and seeing some of the generated
> output, I believe that we should remove the support for string__format
> as it was still buggy.
OK, having seen some of the bugs in the old string__format, I agree with this.
However, it would be a good idea to at least mention the changes in the
NEWS file. How about the following?
----------
Estimated hours taken: 0.5
NEWS:
Mention the changes to string__format.
Workspace: /home/pgrad/fjh/ws/hg
Index: NEWS
===================================================================
RCS file: /home/mercury1/repository/mercury/NEWS,v
retrieving revision 1.170
diff -u -d -r1.170 NEWS
--- NEWS 2000/08/17 05:47:35 1.170
+++ NEWS 2000/08/17 06:02:22
@@ -63,6 +63,30 @@
are now deprecated; the new existentially typed predicate
`store__new/1' should be used instead.
+* We've reimplemented the `string__format/3' procedure.
+
+ The new implementation is a lot more efficient and fixes several
+ bugs in the old implementation. The new implementation also
+ eliminates some subtle differences in behaviour between
+ string__format and the standard ANSI/ISO C printf() function:
+
+ - For the old string__format, the default precision was 15
+ (i.e. the number of significant figures in an IEEE double
+ precision float), but for ISO C's printf(), the default
+ precision is 6.
+
+ - For the old string__format, for the e, E, f, F, g and G conversions,
+ the "precision" field in the format always specified the
+ number of significant figures, but for ISO C's printf(), the
+ precision only specifies as the number of significant
+ figures for the g and G conversions, whereas for the e, E,
+ f, and F conversions the precision specifies the number of
+ digits after the decimal point.
+
+ - For the old string__format, floating point numbers were
+ truncated to the specified precision, but for ISO C's
+ printf(), they are rounded rather than being truncated.
+
Changes to the Mercury implementation:
* We've implemented a new back-end for the Mercury compiler.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list