Re: [go-nuts] Algorithm Club

[David Collier-Brown]

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

[gary . willoughby]

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

[Michael Jones]

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 Faught  wrote:

> 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

[Will Faught]

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

[Michael Jones]

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 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+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

[Rob Pike]

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.

[go-nuts] Algorithm Club

[Mandolyte]

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.