Re: Motion 31 Suggestions - constants
JP> Different viewpoints on the same events.
Yes, two different ways of viewing the same thing. They need different wording in the standard but in the end are equivalent. It's arguable which is simpler.
My preference for treating constants and functions differently is primarily that treating constants as functions means every mention of functions has to be examined to see if it is true for constants as well as other functions. My secondary reason is that it makes the standard closer to programming languages and applications implementing it, which I think is a good not bad thing. It is more intuitive to me.
The counterargument is that treating them differently means that every place either is mentioned has to be examined to see if the other should be, and if in that place they should be treated in the same way or in different ways. It may also be more intuitive to some even if it is less so to me.
But in the end, if properly specified they are equivalent.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
John Pryce ---02/13/2012 04:07:38 AM---Ian On 8 Feb 2012, at 19:59, Ian McIntosh wrote:
From: |
John Pryce <j.d.pryce@xxxxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
02/13/2012 04:07 AM |
Subject: |
Re: Motion 31 Suggestions - constants |
Ian
On 8 Feb 2012, at 19:59, Ian McIntosh wrote:
> ...It makes more sense to me to treat constants differently from functions. We do in real life.
>
> Here's how I'd define it:
> Interval "operations" and "functions" deal with (consume and/or produce) interval "values". Some values are calculated; others are "constants". Some constants are "named constants" which represent specific interval values (eg, Entire defined by 1788 represents [-oo,+oo]); others are numeric and are converted from text to interval values by "constant conversion functions". Both named constants and constant conversion functions may be defined by 1788 and/or programming languages/environments/applications and/or users. The 1788 constraints on constant (and other) conversion functions are that (1) they must either produce a valid interval or in some way report an error and (2) they must not violate containment of the value represented by a reasonable interpretation of the text.
At a language level, I'ld entirely agree. In the context of Level 1 expressions, I would say this:
We treat integer-power pown(x,n), in an _expression_, as an instance of an infinite "schema", x^0, x^1, x^(-1), ... because the n is not treated as a continuous variable, by contrast with pow(x,y). In the same way, a real constant "1.23" or interval constant "[1.23,4.56]" is an instance of an infinite schema of text strings defined by some syntax. A "power conversion function" interprets pown, e.g. converting pown(x,0) to the constant 1 in all cases. Usually this is done inside the compiler, but in a fully interpreted, unoptimized, system it would happen at run time each time the statement containing the string was executed.
In the same way your "constant conversion function" is a machine for understanding instances of another infinite schema. It converts a text string to a value, which is in the first instance an exact real or interval value before it is forced into some finite-precision form. I see no contradiction. Level 1 sees 1.23 as a symbol representing the function 1.23() (that returns 1.23). You see an argument to a function call, say convertRealConstant("1.23") (that returns 1.23). Different viewpoints on the same events.
John