Dimitry Golubovsky wrote:
Perhaps there could be an intermediate solution: keep the calling convention field as a string, but add a command-line option, something like --allow-cconv=<comma-separated list> with default being whatever is in the Addendum plus those non-standard nhc98 convention names. For Javascript backend, I'll use --allow-cconv=javascript, etc.
--allow-cconv=ANY would turn this check off (thus ANY in capitals being reserved word)
It's an idea, but I think Malcolm was more thinking about the internal CallConv datatype (that calling conventions are parsed into). Arguing that it is better to add new calling conventions as additional enumerations in this datatype rather than using a string an allowing any identifier to be used as a calling convention. In any case the bytecode backend refuses to compile any foreign call to a calling convention it doesn't know so the user is told if they mistype a name already. We may thus need to add a --no-bytecode flag for you to say that the compiler shouldn't generate any bytecode (i.e. core only), but this is probably a useful addition in any case. I think the solution I have in place is fine. Any identifier as a calling convention, and it's placed in the (Other string) item in CallConv. Cheers Tom