[Yhc] Some suggested changes to Yhc.Core

Tom Shackell shackell at cs.york.ac.uk
Tue Aug 7 04:30:10 EDT 2007


Hi Dimitry,

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

    foreign import javascript "new Data.getTime" getTime :: ....

Well the parser would need to be modified to understand 'javascript', 
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 ;-)

Cheers


Tom


Dimitry Golubovsky wrote:
> Hi,
> 
> 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
> like to have ability to pass "javascript" into this field, even though
> 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
> being able to wrap calls to methods of Javascript objects such as "new
> Date.getTime()":
> 
> foreign import javascript "new Date.getTime" getTime :: ...
> 
> 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".
> 
> Thanks.
> 
> PS Hopefully, it is not too late to add suggestions...
> 


More information about the Yhc mailing list