Gen - a generics library for Go(clipperhouse.github.io) |
Gen - a generics library for Go(clipperhouse.github.io) |
That's a hack. Complaining that they don't exist might eventually result in a better language.
There is a substantial set of changes happening out on this branch: https://github.com/clipperhouse/gen/tree/projection.
… for this reason: https://github.com/clipperhouse/gen/issues/8
- No min/max for integers (and Go doesn't have the ternary operator)
- No IsMember for checking if an object is in a collection
- Directly from the Gen page: Go’s sort package requires the fulfillment of three interface members, two of which are usually boilerplate. If you want to sort by different criteria, you need to implement multiple ‘alias’ types.
Also, unrelated to generics, but 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.
Edit: found it: https://github.com/droundy/gotgo
Fwiw, slices are inexpensive by design. The elements themselves are not copied. Allocating a new slice is really a small ‘struct’ which serves as a pointer to the underlying array: http://blog.golang.org/go-slices-usage-and-internals
(Gen’ing pointers is supported, which mitigates the potential for allocation.)
It is true that chained operations will be multiple iterations. Whether it will net out to more iterations than otherwise depends on the use.
I’d be interested to see if someone can come up with a pattern where the operations themselves are composed, with a ’.Results()’ method that can intelligently (lazily?) minimize iterations. That’d be impressive.
That being said, a systems programming language may not be the right place for FP concepts.
Uhm, what? No it's not.
Haskell has stream fusion, thereby generating assembler that looks a lot like the optimal imperative version.
If you're not using a language with Clojure's nifty datastructures, "effortlessly" probably isn't much better than OpenMP.
It's good enough for Rust.
https://existentialtype.wordpress.com/2011/03/16/languages-a...
[1] - https://ghc.haskell.org/trac/ghc/ticket/915
[2] - http://hackage.haskell.org/package/stream-fusionhttp://hackage.haskell.org/package/vector-0.9.1/docs/Data-Ve...
Except it's bloody everywhere in the libraries you use and you can design your own libraries around it.
A language powerful enough that things like this can be done in libraries instead of in the compiler is a good thing.
13 years, and only it's three features has made it into Java
I wish Sun found a way to transfer the Java trademark to Odersky before dying. Scala has so many nice features that companies prohibit because the language isn't called "Java".
> 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
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)
}
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`.
import (
cont_list "container/list"
)
func main() {
list := cont_list.New()
}Hint: wait a few minutes, it's the cool-off period. Replying to the parent breaks threading and makes it annoying to read discussions ;).
That's the whole point of an array in Go. So you meant slices, not arrays.
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.
file = File:open("file")