[M3devel] range analysis?

[Rodney M. Bates]

This needs more thought.  On the one hand, 2.2.3 on array types allows
the explicit element type in either kind of array type definition to
be empty, unlike the way 2.2.4 on record types requires a field type
to be nonempty.

On the other hand, 2.2 has a general prohibition against declaring a
variable of empty type, and it is all over the language spec that the
elements of arrays are "variables".  The general definition of variable
in 2.1 would apply to array elements.  Thre are numerous places that
describe things that can be done with a variable that we all informally
know can be done to an element, as it should be and we all have done
many times.  Moreover, 2.2.3 says in the first paragraph that the
elements are variables.

So here, the compiler is too liberal, and the language would be clearer
with an explicit rule against empty element types.

I haven't spotted anywhere a parameter is specifically called a variable,
and it is not required to have a nonempty type in the description of
parameter declarations.  However, it certainly seems to me to fit
the definition of variable, and as above, there are lots of things
we know can be done with it that the language simply describes as
doable to a variable.  Moreover, for every mode, there is a rule
that at call time, the formal is "bound to" a variable, which pretty
well makes it variable in any context where it can be used.  Even in
a keyword binding, we are getting ready to bind it to a  variable
very soon.

So maybe we need to 1) say a formal parameter is a variable, and
2) say the type in a parameter declaration must be nonempty.

The language definition is also full of an ambiguity in its use
of "variable" that I have been bothered by in talking about programming
languages in general for years.  One meaning is the meaning I have been
talking about,  The other is the kind of variable that is declared by a
VAR declaration (not a VAR parameter).  There are some uses in the
language that I think need to have this latter meaning in order to be right.

So we need a different or qualified term for this narrower meaning.

On 05/23/2011 11:54 AM, Tony Hosking wrote:
>
> 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
>>>
>>>
>
>