[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