Macros type inference should support pointers

[phadej]

#define ADVANCE(ptr,n,m) ptr + n * m

In general, I think that HM-like inference is not the right approach for macros. That's C after all, where "foo" + 1 is a type correct expression, which actually does something reasonable.

#include <stdio.h>
#define VAL "foo" + 1

int main() {
	printf("%s\n", VAL);
}

prints oo. And for ADVANCE it's not right to infer Num a => a -> a -> a -> a type. It doesn't include all use cases.

[edsko]

"All use cases" is never the goal here. It is understood that we will carve out a subset of macros for which we can infer a reasonable type and produce reasonable code. It is certainly useful to open issues such as this so that we better delineate what we can and cannot do, but for now I'm with leaving this unsupported.

If it turns out we do need to support it, I'm not sure that the conclusion is that "HM type inference is not the right approach" immediately follows, however. Perhaps we just need to give the overloaded + a different type.

[phadej]

From https://en.cppreference.com/w/c/language/operator_arithmetic

lhs + rhs

1. addition: lhs and rhs must be one of the following

• both have arithmetic types, including complex and imaginary
• one is a pointer to complete object type, the other has integer type

Things like

#include <stdio.h>

int main() {
	printf("%f\n", 12.5f + 10L);
	return 0;
}

adding float and long are completely fine. And they just drive HM-trained people nuts, the implicit conversions are bizarre, but lhs and rhs of addition (and other operators) are unrelated. That's C, not Haskell.

---

It is understood that we will carve out a subset of macros for which we can infer a reasonable type and produce reasonable code.

I'd argue that both usages of addition (arithmetic types, and pointers) are valid and common. I we only support one, we should very loudly say that.

[edsko]

I'm certainly in favour of documenting clearly what we do and don't support. Note that "common" isn't necessarily the right thing to be concerned about; "are they common as part of a library's public API" is the more important question (the answer might still very well be "yes", of course).

@sheaf Do you think that there is any relatively low-hanging fruit here, ways in which we can generalize type inference to cover, or anticipate, some of these generalizations?

[phadej]

Another problem is that #define STRING const char * wont work; that's already issue in a parser.