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

[Julien Fischer]

On Thu, 29 Mar 2018, Zoltan Somogyi wrote:

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

We want to allow compile time evaluation of float expressions (albeit
under more controlled circumstances than what currently seems to occur).

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

It was primarily an issue of target language support.  Until fairly
recently we (in theory) supported versions of Java tha did not support
hex floats; also, again until receently, we did not require the use of
C99 (which was when they were added to C).   There was no point
supporting hex floats if we were going to be forced to a conversion by
the target language anyway.

As to who will use it, yes, Opturion has code where more precise control
of floating point representations would be desirable.  Also, the Mercury
implementation will almost certainly make use of hex floats at some
point.  (Once I have finished working on the integer types, I intended
to, rework a good deal of Mercury's FP support -- however that's a
discussion for another day.)

Julien.