[M3devel] range analysis?

[Tony Hosking]

On May 23, 2011, at 6: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.

You cannot instantiate an empty array type.

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