* Ian Lance Taylor <i...@golang.org> [181016 17:59]:
> The contract system in the generics design draft does not have this
> problem. It may have other problems, but it doesn't have this one.
I haven't finished reading the draft (I got to the beginning of the
Contract Details section when it was first mentioned on this list, but
then got sidetracked) nor have I read any of the counter proposals,
which is why I have not responded before now.
I very much like the idea of contracts, but I do not like the specific
design. Programming by example is a cool idea, but it is simply a bad
practice when you want to clearly and unambiguously express the intended
behavior. While the draft design allows the compiler to unambiguously
determine the correct behavior, as has been pointed out many times in
the various discussions on this list, the specific code which the
programmer must use to convey his/her intent to the compiler is
extremely ambiguous to the programmer, and the meaning conveyed by a
previously written contract to a different programmer reading the code
is at least equally ambiguous. The example in the draft document
concerning value method vs. pointer method clearly demonstrates this.
This is contrary to the stated goals of the Go language with respect to
simplicity, scalability and maintainability.
On the other hand, if you replace the body of the contract with a simple
declarative syntax, you regain these core attributes of the Go language.
contract Readable(T) {
T: Implements(io.Reader)
}
contract ComparableInt(U) {
U: EqualMethod(IsSame), ConvertableTo(int), ConvertableFrom(int)
}
contract SortableRecord(V, W) {
V: IsSliceOf(W), Implements(sort.Interface)
W: Implements(Record)
}
Each constraint that a programmer might want to use in a contract must
be specified by the language as a contract keyword. These keywords are
only special inside a contract body, so they do not interact in any way
with other Go code (e.g. there can be a method Implements on a type).
The contract syntax is such that it is unambiguous what tokens are
contract keywords and what are other language identifiers, such as
interfaces and types; e.g. in Implements(Implements) the first
Implements is a contract keyword and the second is the name of an
interface in the current package.
Some contract keywords may not have any arguments. Comparable might
mean that the type is comparable using the primitive == operator.
contract Comparable(X) {
X: Comparable
}
Whether to require, allow, or forbid the empty parentheses is a detail
for later discussion. I.e. the constraint might be X: Comparable().
There would be no ambiguity between the above contract name Comparable
and the contract keyword Comparable, since the contract keyword has no
relevance outside the contract body.
A contract keyword might have more than one argument, such as
M: IsMapOf(K, V).
In the above examples, the contract keyword Implements declares that
type T must implement interface io.Reader. The keyword EqualMethod
declares that type U must have a method IsSame that has an argument and
result signature appropriate for overloading the == operator.
I see no technical or readability reason to require, or even allow, the
extra names on contract arguments, such as in the draft example contract
convertible(_ To, f From). It is just as expressive to write contract
convertible(To, From). The form in the draft was necessary to allow
writing Go expressions that used both values and types to describe what
was permissible. My declarative syntax does not need this.
It might be convenient to have a predefined contract for each contract
keyword that can be used without explicitly declaring the contract. The
predefined contract would be shadowed by an explicit contract with the
same name. The predefined contract will have an additional argument
preceding the arguments required by the keyword. E.g.
func Massage(type T ConvertableTo(T, int))(item T) error {...}
would use the predefined ConvertableTo contract that is equivalent to a
contract with one constraint, T: ConvertableTo(int).
To switch gears to operator overloading, I would like to start by saying
that one of the fundamental beauties of Go is that looking at a small
piece of code out of context, a programmer can still glean a substantial
amount of information about what the code does, _especially_ about when
external code is called. I would very much dislike for the language to
be changed such that looking at «a == b» would leave me wondering if
some method of a or b would be called to evaluate that expression.
I had thought of «a ==() b» as a possible syntax for "if the type of a
has a method that overloads ==, use it, otherwise if the primitive ==
operator can be applied, use it, otherwise fail to compile." Someone
else (was it Michael Jones?) suggested «a (==) b». I kind of like my
syntax better because it has a "function call" look to it, but either
works for me.
The point is that possibly overloaded operators should be explicitly
called out by the programmer writing the code. There should be no
reason to use such syntax outside of functions that have type
parameters. Whether that is allowed by the language (and just uses the
primitive) or produces a compiler error is a detail to be considered.
Now to get to EqualMethod above. This contract keyword specifies that
the type has a method with the given name, and that the method takes one
argument of the same type and returns a bool. Each operator that the
language designers wish to allow to be overloaded will have a contract
keyword that associates the operator with the method specified in the
contract declaration. The method must have a signature given by the
language specification for that particular operator. The type may
forego implementing the method iff the compiler already knows how to
apply the operator to the type.
So, for «type MyInt int» the EqualMethod(IsSame) would be satisfied
without any IsSame method, but if the type has the IsSame method, it
must have the correct signature or the compiler will complain, and the
method will be used in preference to the intrinsic == operator when the
overloaded ==() is used in the code. Using the non-overloaded == will
always ignore the IsSame method, producing a compiler error if the type
is not comparable.
A similar keyword will be defined for each operator that the language
designers wish to allow to be overloaded. Rules such as in «a ==() b»
which operand is used as the method receiver and which is used as the
method argument are specified in the contract keyword definition.
If it makes any sense (and I am not sure it does) to worry about
commutativity or associativity, the behavior will be specified in the
contract keyword definition.
The specific list of contract keywords is left for discussion.
This declarative syntax is much easier to write, read, and understand
than the "declaration by example" used in the draft. It allows for a
much larger variety of constraints than the "generics by interface"
proposals that I have seen described on this list, and it allows for
flexible operator overloading with only a trivial addition to the
language syntax that does not invalidate the Go 1 Compatibility Promise
while ensuring that non-overloaded operators will never be applied as
overloaded operators (no hidden function calls).
The biggest (only?) downside is that it requires a predetermined, but
expandable, list of constraints. This is mitigated by the fact that
adding a new constraint in a future version cannot break existing code.
The fact that each constraint requires a keyword is, to me, a non-issue,
since the contract keyword namespace is completely separate from all
other identifier namespaces.
...Marvin
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
