athas
commented
2 years ago Yes, this needs better examples. The rules do follow "naturally" from the basic concepts of parametric polymorphism and modules, but "naturally" in terms of logic does not imply it's intuitive at all. We probably need a mixture of more text in the book, and a bunch more examples on the web site.
Note that my experience is that open is usually a misfeature. Your module is better written like this:
module F (R:real) = { let f (x:R.t) (y:R.t): R.t = R.(x + y) }
As a scientific programmer coming C++/Python I scratched my head a bit on writing type-generic arithmetic in Futhark, since it doesn't work out-of-the-box like one might expect from C++, e.g.
template <class T> T f(T a, T b) {return x*y + x/y;}can't be written aslet f 't (x:t) (y:t): t = x*y + x/y. The latter needs to bemodule F (R:real) = { open R let f (x:t) (y:t): t = x + y }with an type-explicit instantiation prior to use. I wrote a gist to remind myself how to do it based on what I understand so far (https://gist.github.com/maedoc/cab49e0916c49ff1dd14aaacb8fd480b) also after reading the futhark-fft code.I think two concrete improvements in the documentation (for the new-ish scientific users) would be in the section 2.5 of the Futhark book,
(a) Follow up on the example of complex_add with an example of idiomatic polymorphic arithmetic, since the section on parametric modules doesn't address arithmetic per se, and the example of complex_add is never followed up on.
(b) The error message for
let f 't (x:t) : t = x+x(i.e. "Cannot apply "*" to "x" (invalid type).") reflects IIUC that Futhark type checks the declaration and not instantiation while C++ does the latter. It could be helpful to point this out also in section 2.5 of the book.