[WIP] Implements Rfloat and Doubles using macros

[Ilia-Kosenkov]

Fixes #280.

This turned out to be a much larger contribution than I expected.
After implementing Doubles, I decided to introduce paste as a dependency (see #283) and then further improved code generation.

Major topics:

1. Rfloat as a thin NA-aware wrapper around f64. I generalized macros so that both Rint and Rfloat are generated using the same macros, and the only thin written by hand is TryFrom that also allows coercion (i.e., floats that can be represented as ints can be converted to Rint).
2. Doubles. Doubles is an almost exact copy of Integers, so, with the help of paste, both Doubles and Integers are generated using a single macros. I expect this approach will work as well for other primitive types. If not, at least in these cases we do not write the same code twice.
3. Moved tests from doc strings to test module. When members are generated using macros, it is even harder to generate meaningful tests. In this case, I took out test cases, and put them in a separate module (under crate::wrappers::{integers, doubles}::tests). These tests are guarded with #[cfg(test)] and are now executed in all build scenarios (see S4 doctests potentially fail on Windows #282).

Takeways:

• Prefer 'horizontal' development to 'vertical' (i.e., deal with one abstraction layer fully instead of implementing support of one type), which encourages macros usage instead of heavy copy-pasting
• Prefer meaningful tests in a separate module to reduce comment pollution around impl members
• Carefully address edge cases (marked with TODO)

TODO:

• Meaningful tests in extendr-api/tests
• Meaningful tests in tests/extendrtests
• Find a way to keep docs when generating members using macros

[clauswilke]

This is great!

One comment about doc strings: I understand the reasoning that they shouldn't be used to test the code, and I agree. However, I think 1-2 examples per function are super helpful and make the code more accessible for a new user. So I wouldn't just delete all these examples. Rather assess whether the example is actually helpful or not.

[Ilia-Kosenkov]

@clauswilke, I agree about examples. The challenge is -- when members are generated using macros, we have two options -- generate examples the same way we generate all these methods right now, which can be tricky, or add additional parameters to the macros, which are translated into docs.
This is challenging, and I will look into it (and encourage others with the knowledge of macros to do the same). I certainly do prefer macros with weaker documentation but no code repetition compared to a lot of code repetition but slightly better docs.

[clauswilke]

The challenge is -- when members are generated using macros, we have two options -- generate examples the same way we generate all these methods right now, which can be tricky, or add additional parameters to the macros, which are translated into docs.

I see. Maybe it's better to write documentation by hand and to just put all the relevant info and examples into a single documentation block for the entire type. In other words, put the documentation and examples for Doubles here:

extendr/extendr-api/src/wrapper/doubles.rs

Lines 4 to 7 in 6549281

	#[derive(Debug, PartialEq, Clone)]
	pub struct Doubles {
	pub(crate) robj: Robj,

[Ilia-Kosenkov]

@clauswilke,
Yeah, it is probably better to write the whole documentation block in one place.
However, we can provide some limited support for doctest (and examples) by generating docstrings within the macros.
The last commit 27c0858 demonstrates such an example. The generated test case also participates in the testing.

[andy-thomason]

Looking good!

I am usually cautious about using extra dependencies, but the problems with concat_ident! require this for now.
There is a PR to fix this in the language but don't forget to exhale.

It is worth thinking about Logicals/Rbool (aka Bool) but not in this PR.

This shares much with Integers.

We may need to implement more operators in the future (such as &, |, ^) for integer and bool.

[Ilia-Kosenkov]

I have identified several issues with Rfloat that I need to address.
The main problem is that NA checks and PartialEq do not work in the current (macros) implementation, because NA is represented with f64::NaN, and f64::NaN != f64::NaN (there are multiple NaNs, and NA uses one value AFAIK).

[Ilia-Kosenkov]

Rint was implementing PartialEq and Eq by default. This implementation is inconsistent with how R treats NAs. For R, NA != NA (it actually returns NA_logical_), so Eq should not be implemented. ParitalEq cannot be derived implicitly, because then it will generate equality such that Rint::na() == Rint::na() (ints can be compared directly), but Rfloat::na() != Rfloat::na() (NA_real_ is a NaN, and f64::NaN != f64::NaN).
Solution - manually implement PartialEq for (Rtype, Rtype) and return false if either of objects is NA. This can be done in a generic way, using macros.

Downside - can no longer compare NAs directly and in assertions, IsNA::is_na() should be used instead (as it is done in R and in f64 when working with NaNs).

I also generated some doctests using macros, to test simple behavior (like Rtype::default() == Rtype::default()).

Next stop: bounds check when using elt, doctesting this case, then some integration tests using R package. I will probably finalize it in a day or two and it will be ready for review.

[clauswilke]

Downside - can no longer compare NAs directly and in assertions,

I don't see this as a downside. As you say, it's exactly how R handles the same case.

[andy-thomason]

I agree that Rint::na() should not (partial) compare with another Rint::na()

This behavious makes it easy to compare floats.

[Ilia-Kosenkov]

These formatting changes were unintentional, I hooked cargo fmt to OnSave of my CLion, so once I edited this file, it automatically applied formatting and I did not notice it.

[yutannihilation]

Minor comments.

[clauswilke]

I feel this exceeds my level of technical understanding so please take my approval as nothing more than saying I'm very much in favor of this work and am glad you're taking the lead.

One minor comment: I always find it hard to read macro code and I would encourage you to be extra careful with documenting. It may seem all obvious to you today as you're writing this but a few more comments probably wouldn't hurt. At a minimum, I think it would be good for every chunk of macro code (i.e., every impl section) to provide in a comment a concrete example of what it implements. For example: "Implement binary mathematical operators such as + or -: a + b"