> On Sep 2, 2018, at 3:19 PM, roger peppe <rogpe...@gmail.com> wrote: > > > > On Sun, 2 Sep 2018, 5:09 pm Bakul Shah, <ba...@bitblocks.com > <mailto:ba...@bitblocks.com>> wrote: > People may find this excellent paper “Datatype-Generic Programming” by Jeremy > Gibbons useful in this discussion. It’s 72 pages long. > https://www.cs.ox.ac.uk/jeremy.gibbons/publications/dgp.pdf > <https://www.cs.ox.ac.uk/jeremy.gibbons/publications/dgp.pdf> > > I want generics but I still don’t know if I like this go2 generics proposal. > At least as an exercise it may be worth reimplementing go1’s builtin generics > using the proposed features (not syntax but functionality). Plus standard > generic collections including things like N dim. vectors. Hopefully this > extended exercise would make it clear if the goal of making it easier to > write correct code is better met with this proposal. > > Writing standard generic collections seems like a worthy goal but > N-dimensional vectors seem to me like they might not fall within scope, as a > large part of getting those right is making them suitably syntactically > convenient to express, and that doesn't sound like a core generics goal.
Two separate issues. The generics code can work out an implementation model for various common formats (dense, sparse etc,). Syntax is the easy part, done in N different languages in a very similar way. M[i, j] -- an element M[i] -- a row alternate: M[i, :] M[,j] -- a column alternate: M[:, j] M[a:b, c:d] -- a sub-matrix Things like linear algebra and matrix multiplication etc. are integral to machine learning, a pretty important field these days. Initially it would be ok to use M.Elem(i, j) M.Row(i) M.Col(j) M.Sub(a, b, c, d) But I am not sure this is doable in the present proposal.... May be there should be a separate proposal but I envision it would be built using some sort of generic code. > > On Sep 2, 2018, at 7:50 AM, Sebastien Binet <seb.bi...@gmail.com > <mailto:seb.bi...@gmail.com>> wrote: > >> Hi, >> >> On Sun, Sep 2, 2018, 12:55 haskell_mustard via golang-nuts >> <golang-nuts@googlegroups.com <mailto:golang-nuts@googlegroups.com>> wrote: >> I prefer seeing the contract by example over having a combination of two >> dozens of interface names like Eq, Lesser, Adder, Muler, Convertible(x), >> Ranger, Lener, Caper, ... that have to be mentally mapped to their actual >> syntactic representation. This smells like taxonomy ("the lowest form of >> academic work" ;) >> >> I am all for original features and perhaps indeed using interfaces in lieu >> of contracts would be better. >> And I guess I could live with a zoo of special interfaces to capture all the >> '+=', == and other special operators. >> But, as it was mentioned in the FAQ of the draft proposal, how would one >> express the need for an explicit field (name + perhaps type too) ? >> >> How would interfaces-as-contracts play out for example if I wanted to make >> sure the Image type passed to that parametric function is a struct, with a >> field Pixels that's a slice of quadruplets R, G, B, A (that hold some type >> of numerical value) >> So redoing some of the x/image/draw kernels, sans the interfaces overhead? >> And without declaring a bunch of SetFoo, SetBar and GetBar methods? >> >> -s >> >> >> >> On Sunday, 2 September 2018 10:14:48 UTC+2, Tristan Colgate wrote: >> It's a great read, clarified stuff for me. An approach that embraces >> interfaces feels preferable to me. >> >> >> On Sun, 2 Sep 2018, 09:09 'Charlton Trezevant' via golang-nuts, >> <golan...@googlegroups.com <>> wrote: >> Link: [Getting specific about generics, by Emily >> Maier](https://emilymaier.net/words/getting-specific-about-generics/ >> <https://emilymaier.net/words/getting-specific-about-generics/>) >> >> The interface-based alternative to contracts seems like such a natural fit- >> It’s simple, straightforward, and pragmatic. I value those aspects of Go’s >> philosophy and consider them to be features of the language, so it’s >> encouraging to see a solution that suits them so well. The author also does >> a great job of contextualizing the use cases and debate around generics, >> which I found incredibly helpful. >> >> Any thoughts? >> >> >> -- >> 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...@googlegroups.com <>. >> For more options, visit https://groups.google.com/d/optout >> <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
