[M3devel] range analysis?

[Tony Hosking]

On May 23, 2011, at 12:45 PM, Rodney M. Bates wrote:

> On 05/23/2011 09:31 AM, Tony Hosking wrote:
>> An empty subrange gives a warning in the compiler.
> 
> By my experiments, empty subrange, empty enumeration, and arrays
> thereof don't warn.

Sorry yes, you're right.  But usage to declare any variable does.

> 
>> But, the semantics is that it is empty, and has no values of the type.
>> You cannot allocate (NEW) an empty type.
>> You cannot declare a field of empty type.
> 
> It seems odd that we have this rule for fields, but no corresponding
> prohibition against arrays with empty element types.  By experiments,
> cm3 allows this, for both fixed and open arrays, but treats such array
> types as empty types, something the language also does not say.
> 
> At the least, the language and the compiler should agree with each other.
> Maybe records/objects and arrays should be treated consistently here?

Yes, I suppose so.

>> Nor can you declare a variable of empty type.
> 
> Again, oddly, there is no such prohibition in the language against
> declaring a formal parameter of empty type.  Cm3 prohibits it,
> and calls it a 'variable' in the error message.

You're right, though it's not the parameter that errors but the variable associated with the parameter.

> Again, language and compiler should agree.

Can you point me to the relevant entries in the language spec?

> 
> The language also prohibits applying FIRST and LAST to the empty
> enumeration, but they are OK applied to an empty subrange.
> This makes sense, because they return values of the base type
> of the argument type, and such values exist for an empty subrange
> but not the empty enumeration, whose base type is only itself.
> 
>> 
>> On May 23, 2011, at 8:41 AM, Hendrik Boom wrote:
>> 
>>> On Sun, May 22, 2011 at 11:18:02PM +0000, Jay K wrote:
>>>> 
>>>> Well, I can build the whole tree and see how many times it helps.
>>>> I think this is a pretty standard optimization technique.
>>>> Though it'd work better with compiler-derived additional information.
>>>> 
>>>> I initially happened upon this idea developing test cases.
>>>> 
>>>>> The code assumes the minimum of a type is less than or equal to its maximum.
>>>> 
>>>> I'll change it not have that problem -- to just fall back to usual pessimistic code for such types, I guess.
>>> 
>>> What *is* the semantics of a range whose minimum is greater than its
>>> maximum?  There plainly can't be any values in this range.  How is a
>>> variable of this tyoe initialized?  Not to some arbitrary value of the
>>> type, because there aren't any.  I can see this type being useful to
>>> admit convenient generalizations -- for example, an array with n
>>> elements can still exist if n happens to be zero, but it seems to me
>>> that any code involving a value of the range for subscripts for this
>>> array must be simple unexecutable.
>>> 
>>> Or is there some latitude available in the principle that a value of a
>>> variable must always be of the correct type?
>>> 
>>> -- hendrik
>> 
>>