Dear Richard, Dear All;

I've just read parts of the ANSI Smalltalk Standard, and now I have the
impression, that indeed there are gaps...


What does it say?

<standard>

5.7.5.5 Message: removeAll: oldElements

Synopsis
  For each element in oldElements, remove the first element from the
receiver which is equivalent to this element.
Definition: <extensibleCollection>
  This message is used to remove each element of a given collection from the
receiver's elements. The operation is defined to be equivalent to removing
each element of oldElements from the receiver using the #remove: message
with the element as the parameter. The behavior is undefined if any element
of oldElements is not found.
Parameters
  oldElements <collection> uncaptured
Return Values
  UNSPECIFIED
Errors:
  none

</standard>

UNSPECIFIED return values is clear, but what means
  Parameters
    oldElements <collection> uncaptured
?
I try to make it short, the longer version is below...

<standard>

Essential aliasing of parameters is described using a parameter aliasing
attribute:

*captured*     The receiver always retains a reference to the parameter,
directly or indirectly, as a result of this message.
*uncaptured*   The receiver never retains a reference to the parameter,
directly or indirectly, as a result of this message.
*unspecified*  It is unspecified as to whether or not a reference is
retained as a result of this message i.e. either case may occur.

</standard>

Since we have an 'uncaptured' parameter, the receiver *has* *to* never
retain a reference to the parameter, directly or indirectly, as a result of
this message.

Further: The parameter *is* the receiver in the case of
    a removeAll: a
. Has this receiver a direct reference to itself? I don't think so.
But the *coupling* between receiver and parameter here is much stronger -
identity! - than a mere reference. And the intent of the requirement here -
as *I* read the standard - has been to have *no* coupling between parameter
and receiver here.

My conclusions:
- I think this supports Allen Wirfs-Brock's view, that this special case has
been overlooked.
- The intent of the standard seems to be to *forbid*
    a removeAll: a
.
- At least I think this is a reasonable possible interpretation.


Greetings,

Stephan



Therefrom I have snipped (after a first rough snipping):


+--------------------------------------------+
| NCITS J20 DRAFT of ANSI Smalltalk Standard |
| December, 1997 revision 1.9                |
+--------------------------------------------+

<draft> <snipped>

5.1.2.2 Parameter Specification

A parameter specification is defined by a parameter name, a parameter
interface definition, and a parameter aliasing attribute.

A parameter specification places constraints on the parameter in terms of
protocol conformance, and provides information concerning how the parameter
is used by implementations of the message. The parameter name is the name of
a formal parameter and is used to identify the parameter with a parameter
specification, and to refer to the parameter in textual descriptions.

A parameter interface definition is defined as either:
- A single protocol name <P>.
- A logical OR of two or more protocols, written as <P1> | <P2> | ... | <Pn>

The parameter interface definition identifies the behavioral assumptions the
message makes concerning the parameter. A client must supply an appropriate
actual parameter. An OR of protocols means that the parameter must conform
to at least one of the protocols in the disjunction. This is required to
describe cases where a message accepts objects with diverse behavior and
tests their behavior by sending messages in order to determine the action to
be taken. Note that this is different from the case where a message accepts
objects with diverse behavior, but only makes use of common shared behavior.
In the latter case, the message is not really dealing with diverse cases of
behavior.

When a message specifies that a given formal parameter must conform to a
protocol <P>, it is making a commitment to use only behavior which is
defined in <P> in the message implementation. In this sense, the conformance
statement is a maximal behavioral requirement-at most all of the behavior
described by <P> will be used, and no more.

Aliasing information (for example, whether a parameter is stored, or whether
a returned value is new or returned state) is specified to avoid having
implementors use defensive programming techniques which result in
unnecessary object creation and copying, incurring a performance penalty. We
differentiate between incidental aliasing and essential aliasing, both for
parameters and for return values. Essential aliasing forms a critical part
of the behavior of the interface, and as such it must be specified by the
interface designer. Incidental aliasing should not be specified since it is
a side effect of implementation choices, and is not fundamental to the
specified functionality of the interface.

Essential aliasing of parameters is described using a parameter aliasing
attribute:

*captured*
	The receiver always retains a reference to the parameter, directly or
indirectly, as a result of this message.

*uncaptured*
 	The receiver never retains a reference to the parameter, directly or
indirectly, as a result of this message.

*unspecified*
	It is unspecified as to whether or not a reference is retained as a result of
this message i.e. either case may occur.


5.1.2.3 Return value specification

A return value specification is defined by a return value protocol and a
return value aliasing attribute. Whereas the parameter description is
prescriptive in that it states requirements to which the parameters must
conform, the return value information is descriptive in that it provides
information about the result being returned. Whereas a protocol makes a
conformance requirement statement about parameters, it makes a conformance
commitment concerning the return value. The specification guarantees that
the return value will conform to the specified protocol.

A message specification may have multiple distinct return value
specifications. Conversely, a single return value specification may describe
multiple return values if the return value specification applies to all such
values. Multiple return value specifications are required for cases where a
message is defined to return objects conforming to different protocols, on a
case-specific basis. These are conveniently described with separate
conformance statements and aliasing annotations. In order to establish
correspondence between sets of return value specifications, we do not permit
two distinct return value specifications which promise conformance to the
same protocol.

If a message specification has no return value specification (that is, the
return value is  not specified), then it is not prepared to guarantee
anything about the behavior of the returned object. In this case we denote
the return value as UNSPECIFIED. This can be used to separate procedural
messages from functional messages; to allow for inconsequential differences
in implementations; or to allow conforming implementations which return
different results but are otherwise operationally equivalent.

In order to relate return values through conformance, we define the return
value interface definition for a message specification to be the single
return value protocol, or the logical OR of the protocols in each distinct
return value specification.

Information concerning retained references to return values (by the message
receiver) is described using a return value aliasing attribute, which is one
of the following identifiers:

*state*
	The receiver retains a reference (direct or indirect) to the returned object
after the method returns i.e. the object is returned state.

*new*
	The object is newly created in the method invocation and no reference (direct
or indirect) is retained by the receiver after the method returns.

*unspecified*
	No information is provided as to the origin or retained references to the
object (Note this is different from saying that the return value itself is
UNSPECIFIED.  Here we are committing that the return value conforms to some
protocol, but making no commitment about the aliasing behavior).

Note that we do not attempt to describe the aliasing of the state variables
of the return value itself-the attribute applies only to the first level
returned object. The implication is that second and subsequent level
aliasing of the return value is always unspecified. An exception occurs in
the case where the returned state is an object which the client originally
gave the service provider for safekeeping. This occurs with element
retrieval in collections, for example. In such cases only the client knows
the implications of modifying second level state of the return value.


<snipped>


5.7.5.2 Message: addAll: newElements

Synopsis
  Add each element of newElements to the receiver's elements.
Definition: <extensibleCollection>
  This message adds each element of newElements to the receiver.

The operation is equivalent to adding each element of newElements to the
receiver using the #add: message with the element as the parameter. The
newElements are traversed in the order specified by the #do: message for
newElements.
Parameters
  newElements <collection> unspecified
Return Values
  UNSPECIFIED
Errors
  none


<snipped>


5.7.5.5 Message: removeAll: oldElements

Synopsis
  For each element in oldElements, remove the first element from the
receiver which is equivalent to this element.
Definition: <extensibleCollection>
  This message is used to remove each element of a given collection from the
receiver's elements. The operation is defined to be equivalent to removing
each element of oldElements from the receiver using the #remove: message
with the element as the parameter. The behavior is undefined if any element
of oldElements is not found.
Parameters
  oldElements <collection> uncaptured
Return Values
  UNSPECIFIED
Errors:
  none


<snipped> </draft>

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3