[m-dev.] for review: mention string__format changes in NEWS file

[Peter Ross]

On Thu, Aug 17, 2000 at 04:03:52PM +1000, Fergus Henderson wrote:
> 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.

That looks great, thanks for doing it for me.  Can you check it in
please.

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