RE: Summary of current change suggestions
I must say that I like Manuel's proposal below. I'm a bit alarmed about the proliferation of features in the FFI, but Manuel's story makes it seem more tractable. It's in the spirit of putting all the language-specific info needed for a particular foreign import into a single string. The FFI spec should have a section specifying the syntax of this string for a selection of languages. Incidentally, we should make the order of 'import/export' , 'dynamic', 'unsafe' keywords arbitrary. So you should be able to write foreign import unsafe dynamic ... or foreign import dynamic unsafe ... I'm not sure exactly which the unordered set should be, maybe the optional components. Simon | I am still against cpp, but maybe we can relegate defaults | to the tools domain in general (and whoever is fond of cpp, | can use cpp). Without defaults, it is still possible to use | all features of the FFI. If a user wants the convenience of | defaults, she has to use a tool (as with all the other | "features" that we considered too heavy for the core FFI). | | Then, we could use the following general form of foreign | imports: | | foreign import [callconv] [funname] ['unsafe'] varid :: prim_type | | where funname is calling-convention dependent and in the | case of ccall is either merely the name of the imported | symbol or an include specification followed by a colon and, | then, the imported symbol. So, we have | | foreign import ccall "gtk_window_new" | windowNew :: CInt -> IO (Ptr Window) | | or | | foreign import ccall "<gtk/gtk.h>:gtk_window_new" | windowNew :: CInt -> IO (Ptr Window) | | If the <.> are omitted in the include specification, it | corresponds to an #include"...".
On Thu, 22 Feb 2001, Simon Peyton-Jones wrote:
I must say that I like Manuel's proposal below.
Please don't force to put header names in *every* foreign declaration! For header names which are detected at configure time, we would have to write forwarding headers in separate files and install them with the package. When a header name changes from constant to not constant, every reference to it must change. Because nobody wants to have #ifdef around every foreign declaration. This scheme is not quite open for future defaults, because if every attribute has its own ad hoc syntax in the string, the way in which local definitions are overridden by defaults cannot be described language-independently. Here is a more backwards compatible variant of my proposal: foreign_decl ::= 'foreign' what foreign_name attributes varid '::' prim_type | 'foreign' 'default' attributes what ::= 'import' | 'export' | 'label' foreign_name ::= empty | string_literal attributes ::= empty | attribute attributes attribute ::= varid | varid string_literal Attribute names to be defined now: 'dynamic' 'ccall' 'stdall' 'unsafe' 'safe' 'include' In future: 'java' the blocking issues Uncertain what to do with: 'noproto' As a deprecated compatibility feature, calling conventions can also be specified before the foreign_name, in which case a string following them is not their argument but the foreign_name. What I find ugly is that 'dynamic' does not really fit here. It changes whether the name is created or exported (for foreign export), it does not make sense as a default, it makes the presence of foreign_name illegal. -- Marcin 'Qrczak' Kowalczyk
participants (2)
-
Marcin 'Qrczak' Kowalczyk -
Simon Peyton-Jones