3 ms·

Of course, anyone can make a Map function for any particular type combination, but Tim Bray has a point. The generic, functional map function cannot be written,

Of course, anyone can make a Map function for any particular type combination, but Tim Bray has a point. The generic, functional map function cannot be written, and never will. There is an issue of elegance. If generics were to be added, lists and maps would need to have similar syntax, because they feel and behave like generics. However, they cannot. Their syntax is… not generic enough. Oddly enough, elegance through consistency was never reached when designing built-in functions like make(): those can be applied on any type, but user-defined functions don't have this freedom. Essentially, there is a Java-like divide between built-in types (which, for instance, you cannot create methods on) and user types. Their rules of elegance don't apply to the built-ins, which is quite odd. I doubt that this impedes on programming efficiency compared to C. However, some of the duplicated code out there cannot be factored into a library, and map is an example of that.

deleted 13y ago
[deleted]
pdeuchler 13y ago
I took a couple minutes to whip up a quick map function, to be honest I didn't quite believe you. This may be my naivete, but is there any way it's not sufficiently generic for types? I realize it's not suitable for maps, but it satisfies the OP's request for a map that can convert arrays of type Foo to type Bar http://play.golang.org/p/jxMFq5UYs1 http://play.golang.org/p/jxMFq5UYs1
- burntsushi 13y ago
  Here is something that is less onerous on the caller, but probably slower. [1] Here's the source. [2] [1] - https://github.com/BurntSushi/ty#examples https://github.com/BurntSushi/ty#examples [2] - https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17 https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17
- drewolson 13y ago
  I think the point is, if you write map like this you might as well be using a dynamically typed language in the first place because you're deriving no benefit from the type checker. In fact, you're just using casting to completely circumvent it.
  - pdeuchler 13y ago
    Of course. If the main cornerstone of your project is map it's probably not the greatest idea to use Go, but if you're using Go for other reasons and happen to need a quick map function there's no reason to change languages just because Go doesn't have a standard library implementation
    - bad_user 13y ago
      But then it's pretty odd to use Go because you like the language, while not being able to design a proper map(). And map() btw is only the tip of the iceberg in functional programming. But then again, Go is not a functional programming language.
- pcwalton 13y ago
  "I doubt that this impedes on programming efficiency compared to C." will not hold true if you're using reflection.
dragonwriter 13y ago
> The generic, functional map function cannot be written, and never will. https://github.com/droundy/gotgo/blob/master/example/slice.got https://github.com/droundy/gotgo/blob/master/example/slice.g...

deleted 13y ago

[deleted]

pdeuchler 13y ago

I took a couple minutes to whip up a quick map function, to be honest I didn't quite believe you. This may be my naivete, but is there any way it's not sufficiently generic for types? I realize it's not suitable for maps, but it satisfies the OP's request for a map that can convert arrays of type Foo to type Bar http://play.golang.org/p/jxMFq5UYs1 http://play.golang.org/p/jxMFq5UYs1

burntsushi 13y ago
Here is something that is less onerous on the caller, but probably slower. [1] Here's the source. [2] [1] - https://github.com/BurntSushi/ty#examples https://github.com/BurntSushi/ty#examples [2] - https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17 https://github.com/BurntSushi/ty/blob/master/fun/list.go#L17
drewolson 13y ago
I think the point is, if you write map like this you might as well be using a dynamically typed language in the first place because you're deriving no benefit from the type checker. In fact, you're just using casting to completely circumvent it.
- pdeuchler 13y ago
  Of course. If the main cornerstone of your project is map it's probably not the greatest idea to use Go, but if you're using Go for other reasons and happen to need a quick map function there's no reason to change languages just because Go doesn't have a standard library implementation
  - bad_user 13y ago
    But then it's pretty odd to use Go because you like the language, while not being able to design a proper map(). And map() btw is only the tip of the iceberg in functional programming. But then again, Go is not a functional programming language.
pcwalton 13y ago
"I doubt that this impedes on programming efficiency compared to C." will not hold true if you're using reflection.

dragonwriter 13y ago

> The generic, functional map function cannot be written, and never will. https://github.com/droundy/gotgo/blob/master/example/slice.got https://github.com/droundy/gotgo/blob/master/example/slice.g...