[Yhc] Some suggested changes to Yhc.Core
shackell at cs.york.ac.uk
Tue Aug 7 04:30:10 EDT 2007
Well as far as the CorePrim datatype is concerned both of these are
possible now since both the corePrimConv and the corePrimExternal fields
are just strings, so you can put whatever you like in them.
As far as I know the FFI doesn't stipulate what you might have as a
calling convention but it suggests all implementations should support
"ccall" and "stdcall" where they make sense.
As for parsing imports like
perhaps the best way to do that is to say that any identifier is fine.
This is a good idea in general since people might want to support all
sorts of funny conventions ;-)
If I remember correctly the 'external name' is just treated as a quoted
string and can be anything you want so "new Data.getTime" should be
parsed fine at the moment.
I'll look at extending the parser to allow any identifier, shouldn't be
very difficult :-)
Thanks for the suggestions, it's definitely not too late ;-)
Dimitry Golubovsky wrote:
> I'd support the idea of extending the primitive definition. My
> addition is, to extend the meaning of the corePrimConv field, perhaps
> to carry the information about external language the Core interacts
> with (as much as it may be associated with calling convention). I'd
> this may break the existing FFI convention (or would it? - are we
> limited to only ccall and stdcall?). I'd also like to be able to have
> a free syntax form for foreign identifier (corePrimExternal) (thus
> This would help developers of backends to detect which primitives
> imported from standard libraries (where they would be "ccall") are OK,
> and which need to be substituted using Overlays, e. g. ycr2js could
> complain if it encounters any primitive that uses "ccall".
> PS Hopefully, it is not too late to add suggestions...
More information about the Yhc