3 ms·

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpru

by zaphar 12y ago

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... https://github.com/clipperhouse/gen https://github.com/clipperhouse/gen I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

ufo 12y ago
TBH, neither of those solve the same problem generics / parametric polymorphism were created to solve: being able to abstract over types when writing a function or data structure. The first link deals with automatically generating things like printers or comparison functions. Its orthogonal to type abstraction - for example, in Haskell you would use "deriving" or TemplateHaskell macros to do the same thing. This kind of code generation is useful for creating monomorphic functions that depend on the structure of a type (for example, a comparison function for that type) but it won't help you latter create polymorphic functions that work on any type (for example, a sorting function that receives that comparison function as a parameter). The second link suffers from a similar problem. The only types that can be used generically are the ones defined together with a "//gen" comment and you also can't define your own generic functions (for example, a SumOfDistinct function that composes Sum and Distinct) You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem.
- pjmlp 12y ago
  > You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem. Go community lives in 1993, back when C++ compilers shipped with code generation tools (mostly macro based) and templates only existed in CFront.
haberman 12y ago
> I'll just leave these here Are these links in relation to generics? Generics weren't the issue I had been posting about. > Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language. For what it's worth, if the people responding to me had said "yes, what you say is a potential downside of our approach, but we think that the advantages of our approach outweigh the disadvantages," that would have been fine. There would have been no need to debate anything further. The reason the argument went on is because the Go advocates were dismissing the possibility that my concern had any validity whatsoever.
p0nce 12y ago
> https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... Everything in there listed as impractical in Go is possible in D without external tool, with just regular meta-programming: - generating parsers from grammar https://github.com/PhilippeSigaud/Pegged https://github.com/PhilippeSigaud/Pegged - embedding files as array of bytes: ubyte[] = import("file.jpeg"); - protobuf files at compile-time: https://github.com/msoucy/dproto https://github.com/msoucy/dproto - generating tables at compile-time with CTFE Instead of copying what works the Go leaders pretend it doesn't work.

by zaphar 12y ago

ufo 12y ago

TBH, neither of those solve the same problem generics / parametric polymorphism were created to solve: being able to abstract over types when writing a function or data structure. The first link deals with automatically generating things like printers or comparison functions. Its orthogonal to type abstraction - for example, in Haskell you would use "deriving" or TemplateHaskell macros to do the same thing. This kind of code generation is useful for creating monomorphic functions that depend on the structure of a type (for example, a comparison function for that type) but it won't help you latter create polymorphic functions that work on any type (for example, a sorting function that receives that comparison function as a parameter). The second link suffers from a similar problem. The only types that can be used generically are the ones defined together with a "//gen" comment and you also can't define your own generic functions (for example, a SumOfDistinct function that composes Sum and Distinct) You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem.

pjmlp 12y ago
> You are giving me the impression that people are trying to solve Go's generics problem with tooling when its actually a language design and type system problem. Go community lives in 1993, back when C++ compilers shipped with code generation tools (mostly macro based) and templates only existed in CFront.

haberman 12y ago

> I'll just leave these here Are these links in relation to generics? Generics weren't the issue I had been posting about. > Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language. For what it's worth, if the people responding to me had said "yes, what you say is a potential downside of our approach, but we think that the advantages of our approach outweigh the disadvantages," that would have been fine. There would have been no need to debate anything further. The reason the argument went on is because the Go advocates were dismissing the possibility that my concern had any validity whatsoever.

p0nce 12y ago

> https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8/fgJ8a0tW1xcJ https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... Everything in there listed as impractical in Go is possible in D without external tool, with just regular meta-programming: - generating parsers from grammar https://github.com/PhilippeSigaud/Pegged https://github.com/PhilippeSigaud/Pegged - embedding files as array of bytes: ubyte[] = import("file.jpeg"); - protobuf files at compile-time: https://github.com/msoucy/dproto https://github.com/msoucy/dproto - generating tables at compile-time with CTFE Instead of copying what works the Go leaders pretend it doesn't work.