"Simon Peyton-Jones" <simonpj@microsoft.com> wrote,

| In case you aren't aware of this, Windows DLL's by default, (actually | always, as far as I know) use the stdcall (Pascal) calling convention. | | I personally hope that you won't drop anything which facilitates using | Haskell under Windows.

Dead right. I wasn't proposing removing the functionality, just changing how to get at it. More concretely, there are two alternatives

1. Treat C-via-stdcall and C-via-ccall as two different "languages". E.g. foreign import "C/stdcall" "gtk:foo" foo :: Int -> IO Int

2. Treat C as one language, but put the calling convention into the language specific string. E.g. foreign import "C" "stdcall/ gtk:foo" foo :: Int -> IO Int

I prefer (1) but it's not a big deal.

I think, it was Malcolm who earlier argued that we shouldn't have a language C, but rather name it ccall, because what we really are after is the calling convention and not the implementation language of an external function. I would regard this as an argument in favour of (1). BTW, We can't use "C/ccall" and "C/stdcall", as we decided to not use a string, but a pseudo identifier to select the language or rather calling convention. So, it would be foreign import ccall "gtk:foo" foo :: Int -> IO In this context, I actually find it the identifier `stdcall' strange. Why is it standard? I'd argue that ccall is the standard (in fact, it so far was the default, wasn't it?) Any suggestions for a better name? Technically, it should be `pascal' shouldn't it? Is it good for anything, but calling Win32? Are there maybe Pascal compilers that use it? If so, `pascal' would make sense. Otherwise, we might use `wincall'. That's not really nice, but better than `stdcall', I think. If nobody comes up with a serious reason why we shouldn't, I'll fix it to be foreign import ccall "gtk:foo" foo :: Int -> IO and foreign import XYZ "whatever:foo" foo :: Int -> IO where XYZ is `pascal' or `wincall' depending on what gets more support. Cheers, Manuel