[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 12:51:48 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>
>>
>>
>> On Thu, 29 Mar 2018, Zoltan Somogyi wrote:
>>
>>> BTW, I have an unrelated observation about the above code:
>>> the .m file says "3.3", while the .c file says "3.2999999999999998".
>>> This shows that float constants get to go through decimal to binary
>>> conversion *twice*, when once should be enough, and would yield
>>> more accurate results. Maybe we should consider a lossless
>>> representation, such as strings, for floats in the lexer.
>>
>> IMO, there's no consideration necessary it should be a loseless
>> representation, although probably with more structure than a string.
>> (At some point we need to support hexadecimal float constants too.)
>
> I am pretty sure we want *some* kind of consideration to occur
> when we choose the lossless representation :-)
>
> 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.

> For this, we should consider some form of rational, though a quick
> peek at rational.m in the library shows that it is not particularly
> efficient.

That's because it based on on integer.m and that is not particuarly
efficient ;-)

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

Julien.