On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor <i...@golang.org> wrote: > > On Thu, Sep 6, 2018 at 8:20 AM, <alan.f...@gmail.com> wrote: > > > > As I wasn't happy with some aspects of it, I've rewritten my feedback on the > > Go 2 Generics draft and deleted the original gist. Here's the link to the > > new gist for anybody who's interested: > > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 > > > > This is still based on the type-class idea though I'm now proposing a > > simplified contracts approach to go with it rather than trying to make > > interfaces fit. It seems to deal easily now with all the examples in the > > draft paper though no doubt there will be stuff that it can't do or that > > I've overlooked. > > Thanks for writing this. I never got around to reading the earlier > feedback. And thanks for working out the examples. > > Personally I think an important feature of the current design draft is > that it adds relatively few new concepts to the language. While > concepts are of course a new feature, a contract looks like a > function. If you can read a function, you can read a contract. You > don't need to understand a new set of ideas to know what a contract > is. With your proposal, everybody has to learn a new set of > predeclared identifiers. You list 14 new ones, including $struct. I > count 39 existing predeclared identifiers, so this is a significant > increase. Also, of course, the new identifiers don't look like any > existing ones, with the $, but perhaps that could be changed. I would > very much prefer to not add so many new names.
In practice, reading a contract is not really like reading a function at all. Like the compiler, the reader is interested in understanding the set of operations a contract allows. When reading a function, the reader pieces together a sequence of computations in order to understand the function's behavior. I think we'll find that we need to think and talk about contracts as sets of allowed operations and giving names to those operations makes that easier. Writing contracts as code to avoid naming the operations doesn't mean we can avoid thinking about them, it just hides them a little. > > If new features are added to the language, your approach may require > new predeclared identifiers, whereas the contract approach will > automatically adjust. > > It's worth noting that your suggestion is less powerful than the > design draft, in that you can't express the notion of type parameter > that must be a channel type or a slice type. This may not matter very > much, because the generic function can always write chan T or []T. > > > > It looks to me as though, if it requires a contract at all, you might end > > up writing one from scratch for most generic functions/types you need. Even > > if the commoner ones could be included in a 'contracts' package in the > > standard library, you'd still need to import that package and then write > > stuff like 'contracts.Comparable' which is a bit verbose. > > > > Even if the present design prove workable, I think writing contracts may > > prove a bit of a black art and that, if things are at all complicated, some > > programmers may just give it up and embed the function's code in the > > contract which defeats the object of having them in the first place! > > I believe we can use tooling to make these operations easier. For > example, assuming we can make contracts work at all, it should be > straightforward to write a tool that can minimize a contract given an > existing contract definition, and therefore can produce a minimal > contract for an existing function body. > > Note that while I think it's important that there be some way to > express complex contracts, I think they will be used quite rarely. > > > > The more I look at this, the more complicated it seems to get :( > > Yes. > > 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. -- 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.
