[M3devel] range analysis?

[Rodney M. Bates]

On 05/23/2011 05:53 PM, Hendrik Boom wrote:
> On Mon, May 23, 2011 at 01:26:52PM -0500, Rodney M. Bates wrote:
>> 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,
>
> Well, the array might be empty, in which case no nonexistent values
> would be required when the array is created.

Good point.  Right now, the compiler does not allow creation of such
arrays, either fixed or open.  The error messages both refer to the
_array type_ whose elements also have empty type as an "empty type",
regardless of whether the element count is zero or positive.

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