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

[Zoltan Somogyi]

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

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?

Zoltan.