[M3devel] Mixed arithmetic

[Tony Hosking]

My firm position now is that we continue to disallow both mixed arithmetic *and* assignability, and stick with the status quo as described at:

http://www.cs.purdue.edu/~hosking/m3/reference/index.html
http://www.cs.purdue.edu/homes/hosking/m3/reference/complete/m3-defn-complete.pdf

On 11 Jan 2010, at 19:18, Rodney M. Bates wrote:

> Well, I have been mistaken.  I finally found the statement about argument
> types of builtin operators.  Every time I go looking for this, I have trouble
> finding it.  I had remembered it wrongly.  It does not say an actual argument must
> be assignable to the type in the signature, it says it must be a _subtype_
> of the type in the signature.  Actually, it says the overloading is resolved
> using the subtype relation, but this has the same effect on what is and
> isn't statically legal.
> 
> (2.6.1):  The particular operation will be selected so that each actual
>          argument type is a subtype of the corresponding formal type or
>          a member of the formal type class.
> 
> So mixed INTEGER/LONGINT arithmetic does _not_ fall out of the existing
> rules.  We would have to insert 4 different overloaded signatures for
> +, etc. to allow the mixed arithmetic.  Either way, it makes specifying the
> language changes for LONGINT a lot simpler.
> 
> This weakens my support of mixed arithmetic.
> 
> However, there is still some messiness to be resolved.  The relations do use
> assignability rather than subtyping, in such a way that mixed comparisons
> do fall out of the existing rules.  (The overload resolution is done on
> type class, not type, and doesn't, by itself, preclude mixed INTEGER/
> LONGINT comparisons.)  Then there are a lot of other places
> that use assignability.  They are:
> 
> - assignment statements
> - passing parameters to VALUE or READONLY formals
> - passing VAR open array parameters (a different kind of assignability, not
>     really relevant)
> - RAISE statements
> - RETURN statements
> - Initial value assignment in a VAR declaration
> - array subscripts in designators a[i]
> - elements of set, array, and record constructors
> - relational operators, including IN
> - ISTYPE and NARROW (reference types only, thus irrelevant to INTEGER/LONGINT)
> 
> I too am generally a fan of syntactic explicitness, rather than having things
> happen behind the scenes, without the programmer's coding them.  But if we
> disallow mixed arithmetic operations, it seems to me that it becomes
> quite arbitrary where we are allowing assignability and where we are
> requiring explicit type conversions.
> 
> Without LONGINT in the picture, this arbitrariness didn't happen, because
> there was no case where assignability vs. subtyping for the arguments of
> the arithmetic operators made any difference.
> 
> I do think it would be particularly inconsistent to disallow the mixed
> arithmetic but allow mixed relations.  As Tony has pointed out, these
> two differ from the other uses of assignability in having two expressions
> whose types must be used to infer a common value range to do the operation
> in.  All the other uses of assignability have only one "target" type to
> assign to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100111/92f2fcce/attachment-0002.html>