On Mon, Oct 15, 2018 at 7:24 PM, Eric Raymond <e...@thyrsus.com> wrote:
>
> Recent discussion of possible generics designs has forced me to a conclusion
> I'm not happy with, because it requires a feature-cluster that I thought I
> was glad to be leaving behind in Python. That is this:
>
> The simplest and most effective way to solve the generics problem is to
> embrace operator overloading and the kind of magic method designations that
> go with it.
>
> I'm still not a big fan of operator overloading as a surface feature of the
> language. I think the arguments that it encourages overly clever one-liners
> are sound. My argument is not in favor of that. Rather, after reviewing all
> the design strawmen I have seen, I see no way to declare contracts for
> generics that is (a) as simple, and (this is a really important point
> brought out in a recent post) maintains unification with primitive types.
>
> In fact, more and more as I look at the proposals that have failed to catch
> fire I see them as clever but doomed attempts to evade operator overloading
> because most people did not want that camel's nose in the tent. As a matter
> of cold fact I don't either, but I am forced to the conclusion that in the
> portion of design space we can easily reach from Go 1, operator overloading
> and contracts are more joined at the hip than anyone - including me - has
> been willing to face up to now. I therefore propose that we embrace the
> suck and limit the complexity load on the rest of the language as much as
> possible.
>
> Here's a stupid-simple system for describing generic contracts with just one
> new keyword: "implements", having a single argument which is a token that
> may occur as an operator in expressions. Here is what it would look like:
>
> type Sortable interface {
> implements <
> }
>
> type MySortable struct {
> name string
> sortkey id
> }
>
> func (r MySortable) LessThan (s MySortable) bool implements < {
> return r.sortkey < s.sortkey
> }
>
> Because MySortable has a method that "imnplements <", it satisfies the
> Sortable interface.
>
> Each eligible operator has an implied generic signature. For example is we
> use s and t as generic argument placeholders, that of < is
> s.(T).func(t T) bool. That of + would be s.(T).func(t T) T. It would be a
> compile-time error for an "implements" method not to match the signature
> template of its operator as it applies to basic types.
>
> The general insight this leverages is that every primitive-type operator
> implies a description of a contract *without adding any additional
> complexity to the language*.
>
> Notice that we have evaded the methods themselves needing to have magic
> names. The only declaration of contract and overloading is the "implements"
> clause.
>
> This passes Ian's smoke test. That is, it is easy to see how to implement
> min() and max() on generics under this system.
>
> By being able to define relationals and + or * as a composition operator
> for algebras on user-defined types I think we solve a huge part of the
> generic contracts problem. At the cost of adding only one new construct to
> the language, and one that is easy to describe and understand. (Because the
> heavy lifting is done by well-established expectations about the behavior of
> primitive types.)
>
> Perhaps I risk overreaching, for I am relatively new to the language, but it
> seems to me that the simplicity and orthogonality of this proposal are very
> much in the spirit of Go. Enough to that the side effect of overloading as a
> surface syntactic feature is - if grudgingly - forgivable.
>
> Can it even possibly be simpler than this? What, if anything, am I missing?
It's not clear to me what other aspects of various generic proposals
you are picking up here. How are you imagining that we would write
the function that merges two channels? With the current design draft
that looks something like this:
func Merge(type E)(c1, c2 chan E) chan E {
r := make(chan E)
go func() {
for c1 != nil && c2 != nil {
select {
case v, ok = <-c1:
if !ok {
c1 = nil
} else {
r <- v
}
case v, ok := <-c2:
if !ok {
c2 = nil
} else {
r <- v
}
}
}
close(r)
}()
return r
}
Also, how do you write the graph example from the design draft, which
uses two types?
Ian
--
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.
