RE: FFI progress
"Simon Peyton-Jones" [EMAIL PROTECTED] wrote, Manuel | The FFI discussion seems to be completely stalled. Would | you, as our Tsar, like to summarise the state of play, and | re-invigorate it? There was a bit of discussion, which led, I think to a simplification of the library stuff. But we don't have a summary (even informal) of the current state of play, and that's beginning to be a problem here because we're about to implement the .NET FFI for GHC. I am at this now. Starting with the foreign import/export declarations to summarise what we discussed. There's one particular issue we havn't discussed. For Java and .NET we want to call static methods, dynamic methods, and constructors. We already have foreign import static foreign import dynamic but 'new' is different again. The obvious place for it is in the language-specific string foreign import static "new foo(int x)" foo :: Int - IO Foo It seems a bit odd to have static/dynamic *outside* but "new" inside the language-specific string. I suppose the justification is that 'new' is really a static method with a funny way to call it. Whereas the 'self' parameter on a dynamic call is treated specially. Basically, as you say, from the point of Haskell, `new' really is not that special, but there is a huge difference between `static' and `dynamic'. I think, this justifies pushing `new' into the language specific string. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
| 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. Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
"Simon Peyton-Jones" [EMAIL PROTECTED] 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 ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: FFI progress
Hi all. Sorry to butt in as an interloper who hasn't followed the entire strand of discussion. Is anyone actually specifying stdcall ccall calling conventions in a foreign import? hslibs/win32/Win32Dialogue.gc uses stdcall. I imagine there will also be a lot of stdcall stuff in HDirect generated wrappers for COM components. ps I think "stdcall" is also known as "pascal". Don't know if that helps the story on viewing C as two languages though - you're going to have a hard time persuading people to view COM methods as though they were written in Pascal :-) 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. Cheers Mike Thomas. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
One other thing. What did we decide about the 'calling convention' field. I reckon it should vanish into the language-specific string, or alternatively treat C as two languages that differ in their calling convention. No way C calling conventions deserve special treatment. Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
Is anyone actually specifying stdcall ccall calling conventions in a foreign import? hslibs/win32/Win32Dialogue.gc uses stdcall. cvs annotate says that this was written by Sigbjorn in October 1999. I'm not sure whether anyone depends on this. (The HGL definitely does not because it doesn't use dialogue boxes.) I imagine there will also be a lot of stdcall stuff in HDirect generated wrappers for COM components. Alastair ps I think "stdcall" is also known as "pascal". Don't know if that helps the story on viewing C as two languages though - you're going to have a hard time persuading people to view COM methods as though they were written in Pascal :-) ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: FFI progress
Fri, 6 Apr 2001 09:04:32 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
It seems a bit odd to have static/dynamic *outside* but "new"
inside the language-specific string. I suppose the justification
is that 'new' is really a static method with a funny way to call it.
Whereas the 'self' parameter on a dynamic call is treated specially.
So that's ok, but we should agree that's what we want.
Seems OK for me in the case of importing.
But what does foreign export mean in the context of Java or .NET?
Can whole classes be created? How does static/dynamic/new fit there?
In C functions are standalone, which is unlike Java.
In the C case there is no foreign name in dynamic imports and exports.
In Java there are: there is no distinguished function pointer type,
we are going to treat all classes as kind of function pointers with
multiple entry points. Looks ok?
I'm not familiar with Java's native methods. Can both static and
non-static methods be native? Can constructors be native? Shouldn't
foreign export dynamic generate a function which creates instances
of (an inner subclass of) some explicitly specified class?
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Re: FFI progress
"Simon Peyton-Jones" [EMAIL PROTECTED] wrote, Here's my contribution to re-invigoration: As I recall the main sticking point is whether we have a global 'foreign library' declaration in addition to foreign import etc. The main (only?) motivation for such a thing is C It's a powerful motivation because C is ubiquitous. I do have one suggestion to elaborate our earlier proposal. To remind you our simple-minded proposal was * no 'foreign library' decl * the c-language-specific string on a foreign import could say foreign import "gtk:foo" foo :: type with 'gtk' indicating which foreign package was indicated Main complaint was: the package-name = what-to-do mapping still isn't specified. In short, our simple-minded proposal is too simple-minded to be useful. OK so the new suggestion is this: the 'gtk' indicates 'please #include gtk.h'. It's up to you to have a 'gtk.h' lying around, in which you can put all the other #includes (including whether in brackets or "" quotes) to your heart's content. I bet this still doesn't solve the problem entirely, but maybe it solves enough of the problem. I remain reluctant to generate elaborate designs for a single language. I completely agree that we should have a simple solution and achieve more convenient interfaces via the existing FFI tools. I propose the following (basically my last proposal plus suggestions made by others): foreign import "gtk.h:foo" foo :: type corresponds to a `#include "gtk.h"' and foreign import "gtk.h:foo" foo :: type corresponds to a `#include gtk.h'. The former allows to have a custom `gtk.h' "lying around" as suggested above. The filename may of course be a path. As suggested by SimonM, we also allow multiple includes seperated by comma foreign import "sys/types.h,sys/sockets.h:socket" socket :: type (This could be solved by a custom header, too, but IMHO allowing a list of headers doesn't complicate the implementation much, but makes a common case more convenient.) foreign import/export modifiers like unsafe and dynamic can be in arbitrary order (proposed by SimonPJ). "foreign export dynamic" requires a result type of the form IO (FunPtr prim_type) (proposed by Sven). (Of course, concrete implemenatations - like the one in GHC and nhc - may support the old syntax for backward compatibility.) Rationale ~ This is easy to implement and as close as possible to the current syntax while still being better suited for multiple languages. It is not as flexible as the proposal from Marcin and Malcolm, but significantly simpler. More sophisticated interfaces can be realised on top of the basic FFI interface by tools. Proposed decision procedure ~~~ I propose that if nobody can come up with an important scenario that cannot be implemented with the above proposal, we adopt the proposal. (Here "cannot be implemented" means technically infeasable, not less convenient.) If we adopt the proposal, I will define it in detail. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
| I propose the following (basically my last proposal plus | suggestions made by others): | | foreign import "gtk.h:foo" foo :: type | | corresponds to a `#include "gtk.h"' and | | foreign import "gtk.h:foo" foo :: type | | corresponds to a `#include gtk.h'. The former allows to | have a custom `gtk.h' "lying around" as suggested above. | The filename may of course be a path. | | As suggested by SimonM, we also allow multiple includes | seperated by comma | | foreign import "sys/types.h,sys/sockets.h:socket" | socket :: type Do we really need this? Surely it's not so hard to have one header file per package living in a standard place that collects the headers needed for a particular package, including whether they are .. or "...", etc. Its easy to add features and nigh impossible to remove them. I suggest we have just "gtk:foo" (no ".h") meaning #include "gtk.h" Now we can sensibly interpret "gtk:foo" as meaning "foo from package gtk"; and in concrete terms import a suitable header file. But I could imagine a clever compiler could also use to add gtk.a to the link line etc (hence no .h). Let's see if simplicity is too painful. I can't imagine it will be. Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: FFI progress
I like this nice, simple design. I'm a little uncertain about the multiple header-file aspect but have no strong feelings either way. If most libraries could be ffi'd without the need for additional C files, the multiple header file notation would be an obvious win. As it is, many libraries I've dealt with need one or more .c files containing some support code and, in that case, it's not too big a deal to add another file. Some questions though. Suppose I have two ffi decls with differing orders of files: foreign import "foo.h,bar.h:f" f :: type foreign import "bar.h,foo.h:f" g :: type Should I report an error? Or, suppose I have: foreign import "foo.h:f" f :: type foreign import "bar.h:g" g :: type foreign import "foo.h:h" h :: type can I assume that foo.h will only be included once? can I assume that foo.h is included before bar.h? (When answering, remember that an optimising compiler might combine code from multiple modules (possibly with multiple maintainers) into a single C source file due to cross-module inlining.) -- Alastair ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: FFI progress
Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid [EMAIL PROTECTED] pisze:
If most libraries could be ffi'd without the need for additional C files, the
multiple header file notation would be an obvious win.
As it is, many libraries I've dealt with need one or more .c files containing
some support code and, in that case, it's not too big a deal to add another file.
I think that since usually there is a C header associated with the
module, it's not a problem to put original C headers there. I prefer
minimal header information at each foreign declaration, so it would
refer only to the custom module.
hsc2hs fits into this model. The user can let it choose the right form
for compilers supporting or not supporting the discussed feature, e.g.
foreign import #{fun "Foo", "f"} unsafe f :: Type
or better
#module "Foo"
foreign import #{fun "f"} unsafe f :: Type
foreign import "foo.h,bar.h:f" f :: type
foreign import "bar.h,foo.h:f" g :: type
Should I report an error?
No.
foreign import "foo.h:f" f :: type
foreign import "bar.h:g" g :: type
foreign import "foo.h:h" h :: type
can I assume that foo.h will only be included once?
can I assume that foo.h is included before bar.h?
No. Since headers from multiple declarations can be put into one
file, they may come in arbitrary order. You may get more headers
than requested, but not less. Particularly the compiler is allowed to
collect headers from all foreign declarations and attach them to the
module itself, and to arbitrarily combine headers from various modules
when C function calls are inlined across modules. The compiler is
not forced to detect duplicates, but I would expect it to do so at
least for declarations coming from a single module (so cpp doesn't
need to process the header a hundred times).
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Re: FFI progress
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid [EMAIL PROTECTED] pisze: If most libraries could be ffi'd without the need for additional C files, the multiple header file notation would be an obvious win. As it is, many libraries I've dealt with need one or more .c files containing some support code and, in that case, it's not too big a deal to add another file. I think that since usually there is a C header associated with the module, it's not a problem to put original C headers there. I prefer minimal header information at each foreign declaration, so it would refer only to the custom module. I have usually not needed an extra (custom) header file associated with Haskell modules, but maybe the libraries that bound where just exceptionally well behaved. "Alastair Reid" [EMAIL PROTECTED] wrote, foreign import "foo.h,bar.h:f" f :: type foreign import "bar.h,foo.h:f" g :: type Should I report an error? Or, suppose I have: foreign import "foo.h:f" f :: type foreign import "bar.h:g" g :: type foreign import "foo.h:h" h :: type can I assume that foo.h will only be included once? can I assume that foo.h is included before bar.h? (When answering, remember that an optimising compiler might combine code from multiple modules (possibly with multiple maintainers) into a single C source file due to cross-module inlining.) That's a very good argument in favour of SimonPJ's proposal, Its easy to add features and nigh impossible to remove them. I suggest we have just "gtk:foo" (no ".h") meaning #include "gtk.h" Now we can sensibly interpret "gtk:foo" as meaning "foo from package gtk"; and in concrete terms import a suitable header file. Ok. I think, this scheme is sufficient and Alastair has pointed out the semantic difficulties of a more complex scheme. Moreover, Marcin seems to favour it, too. Any objections? Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
