Done, pushed a patch so that now

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

is correctly parsed and returned as core with corePrimName = "getTime" corePrimConv = "javascript" corePrimExternal = "new Date.getTime" corePrimImport = True Cheers Tom 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

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...

_______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc

Tom Shackell wrote:

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.

Yes, the FFI spec explicitly allows you to name any calling convention you care to think of, but states that if you use "ccall" or "stdcall", then the contents of the literal string must conform to the FFI spec for ccall/stdcall, and of course do the right thing. So you are free to develop any new calling convention, like "javascript", and to define what is permitted in the literal string for that convention. Ideally, if defined fully, this could later be added to the FFI spec to ensure that any other Haskell implementation that chooses to allow "javascript" would follow the same convention. nhc98/yhc already has the extra non-standard calling conventions "cast" and "noproto", whilst Hat has "haskell"(!) as an FFI convention.

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.

Actually, I think it would be better just to add the single new name "javascript". It's pretty easy, and allows us to represent the convention using an enumerated type internally, rather than just a String. Types are one of the reasons we like Haskell, aren't they?

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.

Indeed. Regards, Malcolm