Re: proctype and procedure type checking fully implemented

[Gaius Mulley]

"Fischlin  Andreas" <andreas.fischlin@env.ethz.ch> writes:

> Hi all,
>
> I am having difficulties to follow what you try to convey. Perhaps my 
> thoughts below help to clarify
>
> A code such as
>
>  WriteString ('the value is: ') ; WriteCard (func, 5) ; WriteLn
>
> as most likely intended is first of all "syntactically wrong", as it should 
> be written as
>
>  WriteString ('the value is: ') ; WriteCard (func(), 5) ; WriteLn

Hi Andreas,

indeed, the user intended func() but mistakenly typed: func.

> If written in this manner, it should be accepted by the compiler,
> regardless whether the actual argument of WriteCard is a value
> returned by a function procedure or a variable or a constant. Perhaps
> we do not disagree here, do we?

certainly, agreement.

> However, I find the error message far from helpful. Assignment
> compatibility should be referred to here and not referring to a rather
> vague formal and actual parameter incompatibility.
>
> Following assignments are implicit here assuming 
>
>  VAR x: CARDINAL;
>  TYPE FuncType = PROCEDURE(): CARDINAL;
>
> with a variable CARDINAL x  and procedure type FuncType
>
>  WriteCard (func, 5) implies assignment x := func; 
>
> and
>
>  WriteCard (func(), 5) implies assignment x := func();
>
> In the first case you assign the procedure function ‘func', not its
> result, to x and it becomes obvious that procedure type FuncType is
> not assignment compatible with CARDINAL. In the 2nd case you assign
> the result returned by the function ‘func’ to x and only the type of
> the result returned by func must be assignment compatible with
> x. Therefore, I would suggest to reformulate the error message to
> something similar to this
>
> Type of actual parameter ‘func’ is not assignment compatible with the
> corresponding formal parameter of ‘WriteCard’

yes thanks for the suggestions - I'll improve the message - but perhaps
it should use parameter compatible (or use the assignment compatible for
-fpim and parameter compatible for -fiso)?

Interestingly ISO splits compatibility rules into:

   assignment compatibility,
   expression compatibility
     and
   parameter compatibility.

The parameter compatibility is further split into two:
   pass by value
   pass by reference

and both parameter cases are expected to be expression compatible (ISO P262).
Currently in gm2 type checking separates assignment, expression and
parameter.  But it checks parameters:

   pass by value (using the rules for assignment).
   pass by ref   (using the rules for expression).

(again maybe this should be dependant upon the -fpim -fiso flags).

> This would be a very generic error message that may not always help
> the programmer to understand what the mistake was, e.g.  WriteCard
> (func, 5) written but meant WriteCard (func(), 5) and therefore some
> case distinction as described below may be more appropriate than above
> too generic error message.  Your example WriteCard (func, 5) would
> then lead to following compile time error message
>
> Procedure type of ‘func’ is not assignment compatible with the corresponding 
> formal parameter of ‘WriteCard’
>
> Something like
>
>  PROCEDURE func () : BOOLEAN ;
>
>  BEING
>
>  ...
>
> and a statement such as  WriteCard (func(), 5) should also lead to a 
> compilation error message. Then the compiler error message could perhaps be 
> similar to
>
> Type returned by ‘func’ is not assignment compatible with the corresponding 
> formal parameter of ‘WriteCard’
>
> to avoid using the too generic error message I mentioned first.
>
> Then I assume we are talking only about compile time errors, right? So a 
> function procedure such as
>
>  PROCEDURE func () : INTEGER ;
>
>  BEING
>
>  ...
>
> is accepted by the compiler with WriteCard (func(), 5) and leads at
> most to a runtime error, e.g. if func would return a negative value.

In ISO this should be result in a compile time error.  In PIM this is
compiled without error (gm2 should generate runtime checking in case a
negative value is returned)

regards,
Gaius