[Yhc] Some suggested changes to Yhc.Core
shackell at cs.york.ac.uk
Tue Aug 7 05:31:04 EDT 2007
Done, pushed a patch so that now
is correctly parsed and returned as core with
corePrimName = "getTime"
corePrimExternal = "new Date.getTime"
corePrimImport = True
Tom Shackell wrote:
> 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
> 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...
> Yhc mailing list
> Yhc at haskell.org
More information about the Yhc