Printing the type of a Chapel first class function should provide something useful

[bmcdonald3]

Summary

Running this code:

proc myFunc(a: int) {
  return a + 1;
}
var f = myFunc;
writeln(f.type: string);

prints shared chpl__fcf_type_int64_t_int64_t, which is very obfuscated and can't be used to declare a variable with that as the type (e.g., var f: chpl__fcf_type_int64_t_int64_t), which I would expect to be able to do with the type that is displayed to the user, similar to how when we print out the type of the class, we will see something like owned myClass.

David proposed something like proc(int): int, which I am in favor of.

Workarounds

To work around this issue when I needed to know the type of the FCF, I thought to do something like this:

proc dummyFunction(a: int): int {
  return a;
}
var f = dummyFunction;
var myFcf: f.type;

But that is not the ideal solution since it required me creating that dummy function for no reason besides getting the type I was looking for. I have been directed towards the func() function, but that doesn't seem intuitive to me either.

[bradcray]

For some context here, chpl__fcf_type_int64_t_int64_t is the type that we use in the generated C code to represent this first-class function, and you're right that it's not one that should be printed to the user (but the C identifier also can't be something that isn't a legal C identifier, such as a string with spaces, parens, etc.). There are a number of internal symbols like this that need to be de-sugared before displaying them to the user, and we've taken care of some of them, but not others like this one. In this case, it'd be nice to desugar it to func(int(64), int(64)) since that's the current way that a user has for expressing the type of a FCF.

Alternatively, I wonder whether, when we create the function symbol to begin with, we could create a pretty name like func(int(64), int(64)) as the Chapel identifier for the type (since it shouldn't appear in code after that point) and only put the chpl_fcf... string into the cname field (for context, all symbols in the compiler have a name field representing their Chapel name and a cname field representing their name in the C code. Typically name comes from the user's source code for things the user has created, but in a case like this where the compiler is creating the type, it could probably get away with being something that is not a legal Chapel identifier).