4 ms·

I wonder if they'd ever consider adding hygienic macros instead of templates/generics. To me, that solves the problem of needing to write the same code for flo

I wonder if they'd ever consider adding hygienic macros instead of templates/generics. To me, that solves the problem of needing to write the same code for float32+float64 and so on. And it doesn't require so much careful thought about the type system, accidentally creating an awkward metalanguage like happened in C++.

marcosdumay 7y ago
Rust people are very glad that Rust brought high-kinded types to replace the most common uses of hygienic macros. Using macros for everything is a nightmare. About using them as generics, how do you enforce constraints? Unconstrained generics won't lead you far (or better, will lead you far into JS's Wat territory).
- steveklabnik 7y ago
  Rust does not have higher kinded types.
- civility 7y ago
  IMO, Rust has a very nice macro system, and this is a good thing (although I'm not familiar with any changes they've made in the last year or two). It's a bad thing that sometimes one needs to resort to the macro system because other features in Rust don't play well together, but that's a long topic with no solution in sight. > About using them as generics, how do you enforce constraints? I'm really thinking about the case for numerical algorithms where the exact same code works for different types (say float32 and float64 in Go). It sucks to copy and paste hundreds of lines of code and it sucks to have a separate code generator write your file for you (essentially an external macro processor). Imagine something like the C preprocessor for Go, but without the well known flaws of the C preprocessor: #define IMPLEMENT_FOOBAR(NAME, TYPE) \ void NAME(TYPE* ptr, long len) { \ hundred lines of implementation here \ } IMPLEMENT_FOOBAR(foobar32, float32) IMPLEMENT_FOOBAR(foobar64, float64) That parametric polymorphic enough for a lot of use cases, and this could work with data structures too. As for constraints, you can pass function names as arguments too. For instance: IMPLEMENT_SORT(sort_baz, baz, bazcompare) Other proposed features in go, such as the "check" statement for error handling, are probably implementable as a nice macro if you had a good macro language. This means the core language wouldn't have to grow, and features like "check" could be imported from a library. Including features like this in a library means the core language isn't bound by backwards compatibility when a better idea comes along. Old code used the old library, new code uses the new one, and the language stays clean and compatible with both.
  - pjmlp 7y ago
    This is how Borland C++ provided support for generics before they got into the ongoing ANSI/ISO standardisation process. For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS. Finding out the release date is left as exercise for the reader.
  - iopq 7y ago
    I see you're reinventing C++
    - civility 7y ago
      I guess you missed the part above where I mentioned C++ templates as a cautionary tale about accidentally creating an awkward metalanguage. Besides, Go and Rust are both clearly responses to C++, so it makes sense they would try to provide (reinvent) similar capabilities while avoiding the flaws.

marcosdumay 7y ago

Rust people are very glad that Rust brought high-kinded types to replace the most common uses of hygienic macros. Using macros for everything is a nightmare. About using them as generics, how do you enforce constraints? Unconstrained generics won't lead you far (or better, will lead you far into JS's Wat territory).

steveklabnik 7y ago
Rust does not have higher kinded types.
civility 7y ago
IMO, Rust has a very nice macro system, and this is a good thing (although I'm not familiar with any changes they've made in the last year or two). It's a bad thing that sometimes one needs to resort to the macro system because other features in Rust don't play well together, but that's a long topic with no solution in sight. > About using them as generics, how do you enforce constraints? I'm really thinking about the case for numerical algorithms where the exact same code works for different types (say float32 and float64 in Go). It sucks to copy and paste hundreds of lines of code and it sucks to have a separate code generator write your file for you (essentially an external macro processor). Imagine something like the C preprocessor for Go, but without the well known flaws of the C preprocessor: #define IMPLEMENT_FOOBAR(NAME, TYPE) \ void NAME(TYPE* ptr, long len) { \ hundred lines of implementation here \ } IMPLEMENT_FOOBAR(foobar32, float32) IMPLEMENT_FOOBAR(foobar64, float64) That parametric polymorphic enough for a lot of use cases, and this could work with data structures too. As for constraints, you can pass function names as arguments too. For instance: IMPLEMENT_SORT(sort_baz, baz, bazcompare) Other proposed features in go, such as the "check" statement for error handling, are probably implementable as a nice macro if you had a good macro language. This means the core language wouldn't have to grow, and features like "check" could be imported from a library. Including features like this in a library means the core language isn't bound by backwards compatibility when a better idea comes along. Old code used the old library, new code uses the new one, and the language stays clean and compatible with both.
- pjmlp 7y ago
  This is how Borland C++ provided support for generics before they got into the ongoing ANSI/ISO standardisation process. For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS. Finding out the release date is left as exercise for the reader.
- iopq 7y ago
  I see you're reinventing C++
  - civility 7y ago
    I guess you missed the part above where I mentioned C++ templates as a cautionary tale about accidentally creating an awkward metalanguage. Besides, Go and Rust are both clearly responses to C++, so it makes sense they would try to provide (reinvent) similar capabilities while avoiding the flaws.