Re: Again: FFI syntax
On 01-Jun-2001, Manuel M. T. Chakravarty [EMAIL PROTECTED] wrote: Fergus Henderson [EMAIL PROTECTED] wrote, I would be fine to say that some other name, e.g. `c', means that. But `ccall' already has an existing meaning, and it would be terribly confusing if e.g. MSVC and GNU C used `ccall' to mean one thing, while Haskell used it to mean something different. Are you sure that ccall has a fixed meaning outside of the Haskell community? Oh, sorry, I was mistaken. The name that MSVC and the Windows versions of GNU C use is `cdecl'. Using `ccall' for Haskell should be fine. Sorry for the confusion. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Michael Weber [EMAIL PROTECTED] wrote, On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote: So, it all boils down to the question of whether this (probably rare) case justifies the (not very large) extra complexity of allowing header file names enclosed in . I am happy either way, but slightly tend to the simpler solution (not allowing ). Would everybody who prefers to have please say so and briefly say why? Sorry for dropping into the discussion, but... You are always welcome, Michael :-) Using instead of once caused me some problems (can't recall what it was in particular). However, since then my standard was to always use and handle the case by adding -I. parameters... That would also have the benefit of being somewhat less dependant on the behaviour of a implementation (as somebody quoted from the standard). If you put -I. in front, it will always get searched before include dirs given by subsequent -I options, right? This is not guaranteed by the standard. The ISO C99 standard (as quoted by Fergus earlier) says for [..] searches a sequence of implementation-defined places [..] How the places are specified [..] is implementation-defined. However, the standard does guarantees for that The named source file is searched for in an implementation-defined manner. If [..] the search fails, the directive is reprocessed as if it read # include h-char-sequence new-line So, it seems that using is more portable than using in conjunction with -I. I will leave it with as the only option, then. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Fergus Henderson [EMAIL PROTECTED] wrote, On 31-May-2001, Manuel M. T. Chakravarty [EMAIL PROTECTED] wrote: Fergus Henderson [EMAIL PROTECTED] wrote, Making the semantics of a particular construct implementation-dependent is a good thing if the semantics that you want are implementation-dependent. Doing this allows the code to work correctly on different implementations without modifying the code. That is the case here, I believe. In particular, ccall is not abstract enough to use as a default. The default calling convention -- the one that you normally want -- is whatever the corresponding C implementation uses. But on x86, ccall means a *particular* calling convention (args passed on stack, caller pops, return value in EAX, etc.) which may not match the one that your C implementation uses. If you have a C implementation which always passes args in registers, as is certainly allowed by the C standard, then you want to the default calling convention to be passing args in registers, otherwise nothing that uses the default will work. How about saying that `ccall' means whatever the corresponding C implementation uses on any platform? I would be fine to say that some other name, e.g. `c', means that. But `ccall' already has an existing meaning, and it would be terribly confusing if e.g. MSVC and GNU C used `ccall' to mean one thing, while Haskell used it to mean something different. Are you sure that ccall has a fixed meaning outside of the Haskell community? A google search for `ccall' comes (wrt to programming languages) mainly up with Haskell references. If `ccall' is really fixed, then I would prefer to introduce a new calling convention (eg, `c') rather than using an unspecified calling convention. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Again: FFI syntax
| Just to restate my position: I'm against *always* wrapping | the header | file name in double quotes, unless | | #include foo/bar.h | | implies | | #include foo/bar.h | | if the first form is not found. | | It does, but having and (ab)using it to mean would be | bad - if the current directory happens to contain a file with | such name then confusion begins. I've not been following this discussion in detail, but I note that * IN GENERAL one might like to include multiple header files (#include foo.h; #include bax.h) to incude files from other directories (#include foo/bar.h) to #define things (#define DEBUG; #include foo.h) to change the search path (#include foo.h) * But all of these things can be done in a C header file. So all we *need* is the ability to include a single header file, gotten from the current directory foo.h So why not keep it simple? Just one header file, no directories, no search path, no brackets. Any of that stuff can be done in the file you #include Meta comment: this point is not large enough to justify a great deal of effort or delay. Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Sven Panne [EMAIL PROTECTED] wrote, Fergus Henderson wrote: The calling convention should not necessarily default to 'ccall'. That would not be appropriate for all implementations. Granted. Instead, I think the default calling convention should be implementation-dependent. Hmmm, this would make the semantics of the sources compiler-/interpreter- dependent, which is never a good thing. That's what I think, too. In addition, I can't see that it would buy us anything. So let's simply make callconv mandatory, ccall isn't that long after all. If this is generally preferred, ok. (I won't change it, though, unless I hear more people asking for it.) Also, implementations should be allowed to provide calling conventions not on that list. IIRC the intention for enumerating some calling conventions here is to make future implementations agree on the name of callconv when they implement e.g. a C++ or Java FFI, not to rule out other possibilities. Exactly. But this should be made clear from the FFI spec. The spec said, Generally, the set of calling conventions is open, as it is infeasible to cover all useful calling conventions in this report. I have changed this now to Generally, the set of calling conventions is open, i.e., individual implementations may elect to support additional calling conventions. Alternative wordings are welcome. Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Manuel M. T. Chakravarty wrote: Now that we require the include file to have the suffix `.h', the declaration should be unambigious without '!'. Or do I overlook anything? To be exact, we don't require a `.h' suffix, we just don't add `.h' stealthily. And if I read the ISO C spec correctly, this suffix is not required by it, so things are still ambiguous. But again, other people on this list would probably say: You have to write your own header file anyway, so you can give it a name including the `.h' suffix. :-P Just to restate my position: I'm against *always* wrapping the header file name in double quotes, unless #include foo/bar.h implies #include foo/bar.h if the first form is not found. I'm not sure about this, although it's guaranteed the other way round IIRC. It's a little bit awkward being forced to write a custom header when a system supplied one is the only thing one wants. But this is not a topic of paramount importance, so I'll probably surrender if there's no support for my position... :´-(;-) Cheers, Sven -- Sven PanneFon: +49/89/99567000Fax: +49/89/99567461 BetaResearch GmbH,Betastr. 1,D-85774 Unterfoehring mailto:[EMAIL PROTECTED]http://www.betaresearch.de ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
On 29-May-2001, Manuel M. T. Chakravarty [EMAIL PROTECTED] wrote: Sven Panne [EMAIL PROTECTED] wrote, Fergus Henderson wrote: The calling convention should not necessarily default to 'ccall'. That would not be appropriate for all implementations. Granted. Instead, I think the default calling convention should be implementation-dependent. Hmmm, this would make the semantics of the sources compiler-/interpreter- dependent, which is never a good thing. Making the semantics of a particular construct implementation-dependent is a good thing if the semantics that you want are implementation-dependent. Doing this allows the code to work correctly on different implementations without modifying the code. That is the case here, I believe. In particular, ccall is not abstract enough to use as a default. The default calling convention -- the one that you normally want -- is whatever the corresponding C implementation uses. But on x86, ccall means a *particular* calling convention (args passed on stack, caller pops, return value in EAX, etc.) which may not match the one that your C implementation uses. If you have a C implementation which always passes args in registers, as is certainly allowed by the C standard, then you want to the default calling convention to be passing args in registers, otherwise nothing that uses the default will work. Also, implementations should be allowed to provide calling conventions not on that list. IIRC the intention for enumerating some calling conventions here is to make future implementations agree on the name of callconv when they implement e.g. a C++ or Java FFI, not to rule out other possibilities. Exactly. But this should be made clear from the FFI spec. The spec said, Generally, the set of calling conventions is open, as it is infeasible to cover all useful calling conventions in this report. I have changed this now to Generally, the set of calling conventions is open, i.e., individual implementations may elect to support additional calling conventions. The words are clear, but IIRC they contradict the grammar. It would be nicer to make this explicit in the grammar. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
On 29-May-2001, Sven Panne [EMAIL PROTECTED] wrote: I'm against *always* wrapping the header file name in double quotes, unless #include foo/bar.h implies #include foo/bar.h if the first form is not found. It does. I'm not sure about this, although it's guaranteed the other way round IIRC. You recall incorrectly. For ..., the search is entirely implementation-defined [ISO C99 6.10.2#2]. For ..., the initial search is implementation-defined, but it if fails, then the search is retried as if for ... [ISO C99 6.10.2#3]: Cheers, Fergus. ISO C99 6.10.2#2: |[#2] A preprocessing directive of the form | | # include h-char-sequence new-line | |searches a sequence of implementation-defined places for a |header identified uniquely by the specified sequence between |theand delimiters, and causes the replacement of that |directive by the entire contents of the header. How the |places are specified or the header identified is |implementation-defined. ISO C99 6.10.2#3: |[#3] A preprocessing directive of the form | | # include q-char-sequence new-line | |causes the replacement of that directive by the entire |contents of the source file identified by the specified |sequence between the delimiters. The named source file is |searched for in an implementation-defined manner. If this |search is not supported, or if the search fails, the |directive is reprocessed as if it read | | # include h-char-sequence new-line | |with the identical contained sequence (including |characters, if any) from the original directive. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Fergus Henderson [EMAIL PROTECTED] wrote, On 29-May-2001, Sven Panne [EMAIL PROTECTED] wrote: I'm against *always* wrapping the header file name in double quotes, unless #include foo/bar.h implies #include foo/bar.h if the first form is not found. It does. I'm not sure about this, although it's guaranteed the other way round IIRC. You recall incorrectly. For ..., the search is entirely implementation-defined [ISO C99 6.10.2#2]. For ..., the initial search is implementation-defined, but it if fails, then the search is retried as if for ... [ISO C99 6.10.2#3]: Oh, great - I should have read this message before replying to Sven's. Then, this issue should be settled. Thanks, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Tue, 29 May 2001 10:37:54 +0200, Sven Panne [EMAIL PROTECTED] pisze: Just to restate my position: I'm against *always* wrapping the header file name in double quotes, unless #include foo/bar.h implies #include foo/bar.h if the first form is not found. It does, but having and (ab)using it to mean would be bad - if the current directory happens to contain a file with such name then confusion begins. I propose adding implicit if are not given explicitly. As -#include in ghc does (it looks for or and adds if neither is found; it might even not be necessary to allow explicit at all, only explicit or implicit ). -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Again: FFI syntax
| Comments? We should really come to an agreement on the syntax soon... Generally, I like it. | An open point is the last case of the include production: | Should we implicitly wrap double quotes around it or not? I | don't really like such implicit things, but | | foreign import ccall static !myproc \myinclude.h\ | myProc :: ... | | could look a little bit funny because of the backslashes. | Again, I don't really mind about that topic. But I'm against | implicitly suffixing with '.h' in any case. I'd go for automatically adding quotes. Acutally, I'd automatically add a '.h' too. Reason: you are really specifying the assembly or package where the function comes from, and that might be useful for linking as well as includes. If the package was called P, the compiler can #include P.h, and in addition say -lP on its link command. That's less convenient if there's a .h to strip off. Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Again: FFI syntax
* Silly combinations like an unsafe label or a dynamic import with a given C-name don't exist. But now we have all new silly combinations, like foreign export dynexp foo :: ... and foreign export dynimp foo :: and foreign export foo foo :: ... the extent field needs to be separated into import-extent and export-extent, I think. Can we make the static optional? It wouldn't introduce any ambiguity, and it would save characters in the common case. I like '', but I'm less sure about '!' - this feels like we're getting a little too cryptic. Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI Syntax
Simon Peyton-Jones wrote: [...] I'd go for automatically adding quotes. Acutally, I'd automatically add a '.h' too. Reason: you are really specifying the assembly or package where the function comes from, and that might be useful for linking as well as includes. If the package was called P, the compiler can #include P.h, and in addition say -lP on its link command. That's less convenient if there's a .h to strip off. Hmmm, this looks like mixing concepts again. I thought we agreed on the fact that the include part specifies an #include, and nothing else. For real stuff things aren't that easy anyway: Include files for larger libraries live in subdirectories (e.g. GL/gl.h, readline/readline.h), linking a single additional library is seldom enough (e.g. you normally need to link with termcap,too, when you link with (n)curses, linking an X app needs almost a dozen libs on some platforms, etc.), ... So let's simply say: The contents of the include part of extent are implictly wrapped into double quotes iff they don't start with '' or '', and no .h is appended. Easy rule, doesn't mix concepts, and is readable: foreign import ccall static !myproc myinclude.h myProc :: ... Cheers, Sven -- Sven PanneFon: +49/89/99567000Fax: +49/89/99567461 BetaResearch GmbH,Betastr. 1,D-85774 Unterfoehring mailto:[EMAIL PROTECTED]http://www.betaresearch.de ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
Simon Marlow wrote: But now we have all new silly combinations, like foreign export dynexp foo :: ... and foreign export dynimp foo :: and foreign export foo foo :: ... the extent field needs to be separated into import-extent and export-extent, I think. That's exactly what I had in mind. Can we make the static optional? It wouldn't introduce any ambiguity, and it would save characters in the common case. Well, it *would* introduce ambiguity (or we steal some names from C land): foreign import ccall dynimp dynimp :: ... I like '', but I'm less sure about '!' - this feels like we're getting a little too cryptic. The reason for the cryptic '!' is avoiding ambiguity. Let's assume we introduce a modifier which looks like a valid C identifier. What should the following mean then? foreign import ccall static foo bar baz :: ... Is it an import of the C entity foo with the #include file bar, or is it an import of the C entity bar with modifier foo? An alternative would be to make the include part somehow distinguishable from a C identifier, but I'm not sure if this would be less cryptical. And '!' is not that bad IMHO, the connotation DANGER should be obvious, and a single character doesn't clutter up the extent. *sigh* Syntax wars again...:-} Cheers, Sven -- Sven PanneFon: +49/89/99567000Fax: +49/89/99567461 BetaResearch GmbH,Betastr. 1,D-85774 Unterfoehring mailto:[EMAIL PROTECTED]http://www.betaresearch.de ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Again: FFI syntax
On 12-May-2001, Sven Panne [EMAIL PROTECTED] wrote: callconv : empty-- defaulting to 'ccall' | 'ccall' | 'stdcall' | 'cplusplus' | 'jvm' | 'dotnet' The calling convention should not necessarily default to 'ccall'. That would not be appropriate for all implementations. Instead, I think the default calling convention should be implementation-dependent. Also, implementations should be allowed to provide calling conventions not on that list. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Again: FFI syntax
It's weekend and so it's time for a new syntax proposal... :-) After the recent clarification of the role of import and export and a few other suggestions, here's my next shot: topdecl : 'foreign' impexp callconv extent var '::' type impexp : 'import' | 'export' callconv : empty-- defaulting to 'ccall' | 'ccall' | 'stdcall' | 'cplusplus' | 'jvm' | 'dotnet' extent : string -- Wake this optional? Which default then? Syntax for ccall/stdcall's import extent: extent : 'static' safety cid include -- former f.i. | 'dynimp' safety -- former f.i.d. | 'dynexp' -- former f.e.d. | '' cid include -- former f.l. safety : empty | '!' -- means never re-enters Haskell world include : empty | '' anything but ''* '' | anything but '' anything* Syntax for ccall/stdcall's export extent: extent : cid I don't have very strong feelings about other names for dynimp/dynexp, so I'll leave this to the native speakers. An open point is the last case of the include production: Should we implicitly wrap double quotes around it or not? I don't really like such implicit things, but foreign import ccall static !myproc \myinclude.h\ myProc :: ... could look a little bit funny because of the backslashes. Again, I don't really mind about that topic. But I'm against implicitly suffixing with '.h' in any case. The story above has a few advantages compared to the last proposal: * import/export explicitly tell you (= the compiler :-) if a new Haskell name is introduced or not, without inspecting extent. * Silly combinations like an unsafe label or a dynamic import with a given C-name don't exist. * It's (hopefully) more mnemonic, e.g. '' reminds one of the C address-of operator, and '!' suggests something inherently dangerous. Comments? We should really come to an agreement on the syntax soon... Cheers, Sven ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
