Further to IR2100

Folks,

I traced back the change to the LRM in which operator methods of protected
types are required to have one less parameter. It's identified in
P1076-2000/D5 as LCS-26, which is attached. I've also searched my archives
for relevant discussion. It appears I thought at the time that the LCS
didn't provide enough detail. Following is a partial thread of discussion
that I've been able to reconstruct:

------------------------------------------------------------------------

From Peter Ashenden, 21-Apr-1999:

Re LCS 26:

Some of the language design questions that come to mind are:

How can you declare an operator function with parameters of protected
types?  Parameters of functions must be of mode in, but parameters of
protected types must be of mode inout.  Introduction of operators on
protected types must resolve this restriction.

Suppose you do resolve it and allow protected type parameters to
functions.  I guess then taht we would be looking at allowing something
like the following:

  type T is protected
    impure function get return integer; 
    impure function "=" (L, R : T) return boolean;
  end protected T;

  type T is protected body

    variable X : integer;

    impure function get return integer is
    begin
      return X;
    end function get; 
    
    impure function "=" (L, R : T) return boolean is
    begin
      return L.get = R.get;
    end function "=";

  end protected body T;

Do I understand correctly that the intention be that, for methods that
overload operator symbols, the leftmost parameter be the same as the
implicit parameter?  So the call

  sv1 = sv2

would be the same as

  sv1."="(sv2)

with sv1 associated with the formal parameter L and sv2 being associated
with the formal parameter R.

What does "same" mean?  Does it mean that within the body of the
function "=", the name X is an alias for the object X within sv1?  Since
the normally implicit parameter is implicit in this case, can I say L.X
within the function body?  How does this related to parameter passing
mechanisms?  What restrictions are implied for named parameter
association?  Can I also say

  sv1."="(sv2, sv3)

since to do so matches the signature of the function?

These just come off the top of my head.  I know some of them might
appear to have obvious answers, but others don't.  It seems to me that
there is a lot of detail behind the proposed language change, and it
would be easy to miss things by doing the change in a rush.  Unless John
or Paul already have thought these details through and haven't yet told
us, I think it would be asking for trouble and delay to try and address
them now.  I would rather avoid the risk for now and defer the question
to the next round.

------------------------------------------------------------------------

From Peter Ashenden, 12-Jan-2000:

LCS 26
------

Steve's initial review assignment listed LCS26 as requiring no change.
I believe this to be incorrect.  The LCS said that the issue would be
resolved through LRM edits, and Paul has indeed done so.

Chapter 2, p. 26: The changes specify that an overloaded operator in a
protected type has one less parameter than required for the operator
in other contexts.  This is the only change.

The implication is that operator methods can only be called using
prefix notation, e.g., X."+"(Y), X."abs", giving the expected
semantics of two "operands" for binary operators and one "operand" for
unary operators.

A point to note is that there is no way to define an operator with an
operand of protected type.  Operators must be functions, which must
have constant-class parameters.  Protected type parameters must be
variable-class.

------------------------------------------------------------------------

Thereafter, the issue seems to have died. Looks like Paul did the LRM edits,
but the issue I raised in my 12-Jan-2000 review didn't get addressed. So
here we are...

Cheers,

PA

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone (mobile):  +61 414 70 9106
Australia