[m-rev.] for review: encode invariants in types when creating constant structures

[Zoltan Somogyi]

On Thu, 29 Mar 2018 14:23:52 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> On Thu, 29 Mar 2018, Zoltan Somogyi wrote:
> > I agree that strings would solve only the simplest cases.
> > For example, when the programs adds two float constants that have
> > exact decimal representations, the result should be the constant
> > that is the sum of those representations.
> 
> Unless a user is explicitly allowing the Mercury compiler to perform,
> e.g.  compile time evaluation of float expressions, what they originally
> wrote in their source code is what should to be going through to the
> target language.

Agreed. The simple string representation would suffice for the
"all hands off" default; you would want something more structured
only for the case where such compile time evaluation is allowed.
 
> > I would have suggested a limited form of rational in which we restrict
> > the denominators to be powers of 10, effectively a form of BCD,
> > but that wouldn't handle hex float constants. What use case do you think
> > we will need such constants for?
> 
> The rationale for hexadecimal float constants it that they allow
> floating point values to be specified precisely without having to worry
> about issues caused by decimal to binary conversion.  They're widely
> supported by other languages (including our target langauges) and
> required by IEEE-754 2008.

Yes, but who needs or wants this capability, and for what application?
I can see it being useful for Opturion, but why now, and not earlier?
I am not opposed; I am simply curious.

Zoltan.