[Yhc] Some suggested changes to Yhc.Core

[Thomas Shackell]

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