Gotgo (generics) has been ported to Go1

[Issac Trotts]

This is a fork of the project by David Roundy:

https://github.com/ijt/gotgo

Have fun,

Issac

[Issac Trotts]

Pardon me. There is more breakage than I realized. I'll send another message once it's fixed.

[Sindre Myren]

I have seen a lot of discussions on this list on the all pro/against/how-to-implement generics stuff. After reading your README, I must say I like your approach. Especially the interface part, which was partially implemented in terms of type checking?

Good luck with your project!

-- Sindre

2012/5/1 Issac Trotts <issac....@gmail.com>

[Dorival Pedroso]

Nice non intrusive approach! It seems good also the idea of compiling only what's needed. Thanks!

[Issac Trotts]

Thanks, glad you like it. Thing is, the project was originally done by David Roundy and I only reversed some bit rot that had built up over two years. I understood it just well enough to get it working again, and I have some doubts about whether it's correct.

[Paulo Pinto]

It has a Modula-3 generics feel.
http://www.cs.purdue.edu/homes/hosking/m3/reference/generics.html

An interesting compiler project would be to fork Go and implement
Gotgo
facilities directly in the compiler, and see how it feels.

--
Paulo

[Ethan Burns]

On Sunday, May 6, 2012 4:50:47 AM UTC-4, Paulo Pinto wrote:

It has a Modula-3 generics feel.
http://www.cs.purdue.edu/homes/hosking/m3/reference/generics.html

An interesting compiler project would be to fork Go and implement
Gotgo
facilities directly in the compiler, and see how it feels.

I was wondering about a similar thing a while back.  The verdict seemed to be that package-level generics, like gotgo, has some annoying flaws.  See David Roundy's post here:

https://groups.google.com/d/msg/golang-nuts/auLWUqourlA/VkZ10YJ0rBoJ

Best,

Ethan

[Sindre Myren]

2012/5/6 Ethan Burns <burns...@gmail.com>

Yes, I read that. Coming from the package author, I guess this is a quite valid point.  However, package-level generics also have some good sides, like beeing compile-wise smart. That you have to create a package/sub-package for each group of generics, I don't see as a problem. The other problem mentioned, might be a valid issue:

type Foo struct { ... }

func (f *Foo) MyMethod() []Foo {
   [code that uses generic code on lists of Foo, but can't, since it
can't import a package that uses Foo]
}

My current view is that package level generics still seems like a good compromise between the C++ way of doing things (long compile times, among other issues), and the current Go solution (no generics). I'm not saying that gotgo necessarily is the way to go for Go mainline, but whatever experience gained from the use and development of it, could surly be usefull if generics is to some day be added to Go.

It is also a quite valid solution that gotgo stands as a non-standard alternative that users can choose to use. Also, a new and better project might spring from it's idea.

-- Sindre

[josvazg]

Gotgo sure has its limitations, but it is much better than letting the programer alone in the dark cutting and pasting code and replacíng int for string or for type X when she needs some code to work natively with different types who have the same or equivalent interface.

[Paulo Pinto]

Yes.

The only downside is that we are traveling the same road as the C++
compilers did in the
late 80's.

I still remember to have to use similar systems back then. Borland
even had a tool in Turbo
C++ that abused the preprocessor.

So it is sad that we, as a community, need to try to somehow reinvent
the wheel.

Please have in mind that generics in programming languages are much
more than
what C++, JVM or .NET have to offer. Many other languages have similar
mechanisms.

As I mentioned, Gotgo has a certain Modula-3 generics feel.

--
Paulo