Poor error message: calling a method on its own

[justinpombrio]

If you call a method m on its own (as if it were a function), you get a confusing error message saying that is not a function:

> m()
Expected a function in the application expression at interactions1: line 1, column 0 but got:
<function>

Perhaps methods should print as <method> instead of <function>? They evidently already have different runtime representations.

[jpolitz]

Yeah, <method> should print. The IMO amusing issue is that the method value is stored on a data structure. When we use getField to access the method field, it automatically curries itself because that's what methods do. We need to use the internal getColonField to do so. Interestingly, this has real consequences for writing error renderers in Pyret, since we got rid of the surface syntax for field access without automatic currying.

[jpolitz]

A stupid workaround for now would be to change e.g. non-function-app to have a ref field for non-fun-val, and use ! to access it in the rendering, to avoid the automatic currying. This would work in general for the various errors that store arbitrary values.

[blerner]

This is worse now, with flatness -- before we even get to this error, the program crashes with an internal error that m##.app doesn't exist.

[jpolitz]

Sigh. This is not fun at all.

[jpolitz]

I realized a better fix – we should use some other, non-field container, like a raw-array, in the non-function-app error to avoid the currying.