Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gen - a generics library for Go

clipperhouse.github.io

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Gen - a generics library for Go

#31

Post by stiff »

howeman wrote: post #30
stiff wrote: post #29

Earlier quoted context omitted.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

Packages aren't enough of a namespace differentiator for you?

I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single (language-level, not program-level) namespace, e.g if you have a struct type called Bytes, you can't call the instance Bytes etc. I end up having to use a lot of ugly variable names.

Re: Gen - a generics library for Go

#32

Post by a-nom-a-ly »

stiff wrote: post #29
mseepgood wrote: post #26

Earlier quoted context omitted.

> no multidimensional arrays That's not true, e.g. [4][4]byte is a multi-dimensional array. It's a contiguous block of 16 bytes of memory.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

(Can't reply to your post below)

> I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes

http://play.golang.org/p/98vt2YLslY

Re: Gen - a generics library for Go

#33

Post by stiff »

a-nom-a-ly wrote: post #32
stiff wrote: post #29

Earlier quoted context omitted.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

(Can't reply to your post below) > I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes http://play.golang.org/p/98vt2YLslY

I got confused about the details, but this does hit me, the example I had in mind is this:

  package main

  import (
  	"container/list"
	"fmt"
  )

  func main() {
  	list := list.New()
  	list.PushBack(10)
  	list2 := list.New()
  	list2.PushBack(10)
  	fmt.Println(list)
  	fmt.Println(list2)
  }
This does not compile, list variable shadows the list package. I would much prefer doing list::New() for package access like in C++, and being free to use obvious variable names (all the time the most obvious variable name is also the name of the package).

Re: Gen - a generics library for Go

#34

Post by banachtarski »

stiff wrote: post #29
mseepgood wrote: post #26

Earlier quoted context omitted.

> no multidimensional arrays That's not true, e.g. [4][4]byte is a multi-dimensional array. It's a contiguous block of 16 bytes of memory.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

To be fair, C++ doesn't have dynamic statically sized arrays yet either although you can get close with constexpr (but still done at compile time) yet.

Dynarray was slated for C++14 but has been pushed since it really isn't that useful and most people can get away with using vector.

Re: Gen - a generics library for Go

#35

Post by a-nom-a-ly »

stiff wrote: post #33
a-nom-a-ly wrote: post #32

Earlier quoted context omitted.

(Can't reply to your post below) > I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes http://play.golang.org/p/98vt2YLslY

I got confused about the details, but this does hit me, the example I had in mind is this: package main import ( "container/list" "fmt" ) func main() { list := list.New() list.PushBack(10) list2 := list.New() list2.PushBack(10) fmt.Println(list) fmt.Println(list2) } This does not compile, list variable shadows the list package. I would much prefer doing list::New() for package access like in C++, and being free to us…

Adding `::` just to separate package namespace adds nothing useful IMO; just more noise and one more needless concept.

If I decided to re-use the package name more than once it'd be `list1, list2`

I guess it's probably a programming culture thing, but I wouldn't use the word `list` to begin with. I'd use `l1`, `l2` etc. in the case where the name isn't important. It conveys no less information than `list` and short variable names AFAIK are already idiomatic so it's not even unconventional... But with all that said, `list2` wasn't a very good variable name to begin with. If you needed more than one list, then they clearly served different purposes and in that case it makes sense to name them as such: `apples`, `oranges`, `input`, `output`.

Re: Gen - a generics library for Go

#36

Post by stiff »

a-nom-a-ly wrote: post #35
stiff wrote: post #33

Earlier quoted context omitted.

I got confused about the details, but this does hit me, the example I had in mind is this: package main import ( "container/list" "fmt" ) func main() { list := list.New() list.PushBack(10) list2 := list.New() list2.PushBack(10) fmt.Println(list) fmt.Println(list2) } This does not compile, list variable shadows the list package. I would much prefer doing list::New() for package access like in C++, and being free to us…

Adding `::` just to separate package namespace adds nothing useful IMO; just more noise and one more needless concept. If I decided to re-use the package name more than once it'd be `list1, list2` I guess it's probably a programming culture thing, but I wouldn't use the word `list` to begin with. I'd use `l1`, `l2` etc. in the case where the name isn't important. It conveys no less information than `list` and short v…

It's an example, not a real program, I do like however to call my variables "file", "path", "buffer" instad of having "f", "p" and "b" or "buf", especially when there is a lot going on in the algorithm. I don't think there is a lot of baggage in having a separate namespace for packages and being able to say:

file = File:open("file")

Re: Gen - a generics library for Go

#37

Post by coldtea »

shurcooL wrote: post #2

Here is someone trying to come up with a good solution for generics, rather than simply complaining it don't exist. I am thankful for the effort.

>Here is someone trying to come up with a good solution for generics, rather than simply complaining it don't exist.

That's a hack. Complaining that they don't exist might eventually result in a better language.

Re: Gen - a generics library for Go

#38

Post by laumars »

stiff wrote: post #33
a-nom-a-ly wrote: post #32

Earlier quoted context omitted.

(Can't reply to your post below) > I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes http://play.golang.org/p/98vt2YLslY

I got confused about the details, but this does hit me, the example I had in mind is this: package main import ( "container/list" "fmt" ) func main() { list := list.New() list.PushBack(10) list2 := list.New() list2.PushBack(10) fmt.Println(list) fmt.Println(list2) } This does not compile, list variable shadows the list package. I would much prefer doing list::New() for package access like in C++, and being free to us…

You can alias imports, Eg

    import (
        cont_list "container/list"
    )

    func main() {
        list := cont_list.New()
    }

Re: Gen - a generics library for Go

#39

Post by atilaneves »

rybosome wrote: post #12
mseepgood wrote: post #8

These higher-order functions are a very inefficient way to write loops in Go. When you chain them you will end up with multiple sequential iterations instead of only one. Sort should not allocate and return a new slice, it's better to sort in-place, etc.

That's functional programming for you. It's definitely less efficient, but there are other major advantages. For one thing, given the propagation of immutable data, things can be parallelized effortlessly - look at 'pmap' in Clojure for example. Once you're familiar with the style, it's significantly more concise and readable. That being said, a systems programming language may not be the right place for FP concepts.

D is a systems programming language with FP concepts and they work quite well. Also, it has generics / templates / parametric polymorphism that are more powerful and easier to use than C++.

Re: Gen - a generics library for Go

#40

Post by microtonal »

a-nom-a-ly wrote: post #32
stiff wrote: post #29

Earlier quoted context omitted.

The size has to be known at compile time, though. One can do a slice of slices, but then it's not necessarily continuous in memory. So you are left with allocating a one dimensional array of size x*y and doing index calculations by hand like in the good old 70's or something.

(Can't reply to your post below) > I edited that part of the comment out because it was not really related to anything, but I meant that all identifiers go into a single namespace, e.g if you have a package called bytes you can't call a variable bytes, if you have a struct type called bytes, you can't call the instance bytes http://play.golang.org/p/98vt2YLslY

(Can't reply to your post below)

Hint: wait a few minutes, it's the cool-off period. Replying to the parent breaks threading and makes it annoying to read discussions ;).

Post reply on HN