Re: [go-nuts] Algorithm Club
That's an interesting thought: one can generate a generic from a type which has an ordering, and identity and perhaps a few other functions as its interface. That eliminates the "grad student slave writing tests" from the algorithm (;-)) and makes it, in principle, computable in a Go kind of way. --dave On 31/03/17 04:55 PM, Bakul Shah wrote: IMHO sort() is best thought of as a higher order function (one taking a functional argument, the comparison function). It would be perfectly fine to use a > b as this comparison function or a < b or any other compare function a given type (e.g. case ignoring compare function on strings). Some confusion may be due to the way Go sort package shoehorns a generic function into Go's existing machinery. Ideally I’d want something like func sort(vector []T, func compare(a, b T)bool) with T to be specified at the call site. You can achieve this with a parametric package extension (the only new syntax is in package header and package import. So it is limited but simple to understand). What you are asking for (flagging a “semantic fail” at compile time) is perhaps way beyond what a generics package in a language like Go can do. On Mar 31, 2017, at 9:19 AM, Michael Jones> wrote: There is part of the topic that has always been slightly beyond my grasp. (Maybe I do understand...but just lack absolute certainty.) Maybe others know the answer... In a template system (which is what I prefer but that's not the point of this email) we have the notion of the TYPE(s) being a formal argument. We presume that the code will compile or fail based on the suitability of the instantiated type. That is, a templated Min would fail on the comparison "<" if the TYPE was "Map[something]something." Call that a lexical fail. My question is, what about a semantic fail. Say, "<" for floating point. In the sort package the Less function does !Less(a,b)&&!Less(b,a) to figure out Equal(a,b). That works for ints and strings, but when I templated sort I found that it failed in tests with float32 and float64 because of NaN values, which are !Less(a,b)&&!Less(b,a) yet !Equal(a,b). I had to make two templates, one for floating point values and one for integral/string values. My uncertainty is in the fact that I only discovered the problem through testing--i had failed to anticipate it. It was easy to fix, but only after the fact. That makes me wonder about the truly perfect generality of templated reusable software, which would be most perfect if it failed to compile rather than fail in some rare edge condition under use or testing. The closest solution I have known about this was IBM Research's AXIOM symbolic mathematical system, which had a robust and mathematically pure concept of types and operators and commutativity and inverses and the like. It was possible to make a function for "two arguments that were elements of a ring with property A and B." That made sense to me, but was off-putting to some users. I recalled it i the sort case because I wanted to kinds of typed clients for "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b), and the kind where that is not the case--and ideally--a way to have instantiation for the first kind use path A and the second kind use path B. That would have made the code truly general. I fear this pedantry will make Russ suspicious of slowing compilation AND programmers. :-) Michael On Fri, Mar 31, 2017 at 2:46 AM, Egon > wrote: On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote: >Because it can also be implemented in other ways. Do you mean interface{} can be implemented in other ways? I couldn't make out your meaning. There are multiple ways of implementing "boxing generics" and "interface{}". Implying it has same perf. characteristics as interface{}, implies the same implementation as interface{}. >As said... there is a performance upside for some other approaches. The other approaches have downsides, or at least generation does. Compared to using interface{} as is done now, boxing generics improves type safety and expressiveness and has no performance regression. That's a clear net win. I meant other generics approaches (not alternatives). Boxing generics adds complexity to the compiler, without solving some of the problems that generics intends to solve. Mainly, implementing highly performant data-structures would still require code-generation/copy-paste. And that is a pretty big downside. On Wednesday, March 29, 2017 at 9:18:01 PM UTC-7, Egon wrote: On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote: Egon: >See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
Re: [go-nuts] Algorithm Club
Parametric polymorphism is enabled by generics. On Friday, 24 March 2017 19:16:24 UTC, Rob 'Commander' Pike wrote: > > Algorithms are not helped by generic types as much as by polymorphism, a > related but distinct subject. > > -rob > > -- 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.
Re: [go-nuts] Algorithm Club
This is just what I dream of. (Well, not dream really as I do it already with a macro processor, but I dream of it being integrated and robust.) On Sat, Mar 25, 2017 at 8:30 PM Will Faughtwrote: > Generics is polymorphism, though; actually, it's a kind of polymorphism > called parametric polymorphism. It's program behavior that doesn't depend > on the types of the data it uses. It's useful for algorithms for types that > contain variable types. There are numerous slice, map, and chan utility > functions, for example, which aren't possible for users to make in Go. > > > On Friday, March 24, 2017 at 12:16:24 PM UTC-7, Rob 'Commander' Pike wrote: > > Algorithms are not helped by generic types as much as by polymorphism, a > related but distinct subject. > > -rob > > On Fri, Mar 24, 2017 at 12:10 PM, Mandolyte wrote: > > The recent survey reveled that generics was thing that would improve Go > the most. But at 16%, the responses were rather spread out and only 1/3 > seemed to think that Go needed any improvement at all - see link #1. I > think most will concede that generics would help development of algorithms, > libraries, and frameworks. So in the spirit of friendly rivalry, here is a > list of algorithms developed for Swift: > > https://github.com/raywenderlich/swift-algorithm-club > > As you might guess, it is chock-full of generics. Yeah, I'm a little > envious. :-) enjoy... > > > > #1 https://blog.golang.org/survey2016-results > > -- > 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. > > -- > 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. > -- Michael T. Jones michael.jo...@gmail.com -- 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.
Re: [go-nuts] Algorithm Club
Generics is polymorphism, though; actually, it's a kind of polymorphism called parametric polymorphism. It's program behavior that doesn't depend on the types of the data it uses. It's useful for algorithms for types that contain variable types. There are numerous slice, map, and chan utility functions, for example, which aren't possible for users to make in Go. On Friday, March 24, 2017 at 12:16:24 PM UTC-7, Rob 'Commander' Pike wrote: > > Algorithms are not helped by generic types as much as by polymorphism, a > related but distinct subject. > > -rob > > > On Fri, Mar 24, 2017 at 12:10 PM, Mandolyte> wrote: > >> The recent survey reveled that generics was thing that would improve Go >> the most. But at 16%, the responses were rather spread out and only 1/3 >> seemed to think that Go needed any improvement at all - see link #1. I >> think most will concede that generics would help development of algorithms, >> libraries, and frameworks. So in the spirit of friendly rivalry, here is a >> list of algorithms developed for Swift: >> >> https://github.com/raywenderlich/swift-algorithm-club >> >> As you might guess, it is chock-full of generics. Yeah, I'm a little >> envious. :-) enjoy... >> >> >> >> #1 https://blog.golang.org/survey2016-results >> >> -- >> 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. >> > > -- 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.
Re: [go-nuts] Algorithm Club
Type-based generally is all that I ever seem to want...making a macro-like LLRB heap concrete to handle objects of my own type and with my own comparison function. I believe this is what Rob speaks of. I've personally never needed to sort or order a bunch of unknown "things" On Fri, Mar 24, 2017 at 12:16 PM Rob Pikewrote: > Algorithms are not helped by generic types as much as by polymorphism, a > related but distinct subject. > > -rob > > > On Fri, Mar 24, 2017 at 12:10 PM, Mandolyte wrote: > > The recent survey reveled that generics was thing that would improve Go > the most. But at 16%, the responses were rather spread out and only 1/3 > seemed to think that Go needed any improvement at all - see link #1. I > think most will concede that generics would help development of algorithms, > libraries, and frameworks. So in the spirit of friendly rivalry, here is a > list of algorithms developed for Swift: > > https://github.com/raywenderlich/swift-algorithm-club > > As you might guess, it is chock-full of generics. Yeah, I'm a little > envious. :-) enjoy... > > > > #1 https://blog.golang.org/survey2016-results > > -- > 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. > -- Michael T. Jones michael.jo...@gmail.com -- 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.
Re: [go-nuts] Algorithm Club
Algorithms are not helped by generic types as much as by polymorphism, a related but distinct subject. -rob On Fri, Mar 24, 2017 at 12:10 PM, Mandolytewrote: > The recent survey reveled that generics was thing that would improve Go > the most. But at 16%, the responses were rather spread out and only 1/3 > seemed to think that Go needed any improvement at all - see link #1. I > think most will concede that generics would help development of algorithms, > libraries, and frameworks. So in the spirit of friendly rivalry, here is a > list of algorithms developed for Swift: > > https://github.com/raywenderlich/swift-algorithm-club > > As you might guess, it is chock-full of generics. Yeah, I'm a little > envious. :-) enjoy... > > > > #1 https://blog.golang.org/survey2016-results > > -- > 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.