"Alastair Reid" <reid@cs.utah.edu> wrote,
ps Just as a general remark on language design...
User defined defaults are really tempting to add (my component programming language had them briefly and I am under constant pressure to add them back in) but they are kinda messy because:
1) You have to resolve (or forbid) use of multiple defaults.
2) You need a way to override the default. Do you override the whole default (includes, libraries, etc.) at once or only the bits you don't specify.
The latter seems to be slightly better than the former because defaults are sorta invisible - the programmer forgets that they're there and so they forget that overriding the default will zap all the default not just the part (libraries say) that they're thinking about at that moment.
3) A small change to code in one place can have unexpected results (and it is hard to detect the consequences using typechecking or from a failed link or whatever).
4) Cutting and pasting some code from one context to another context results in very different behaviour because the defaults don't carry over.
[I think every form of default behaviour in the Haskell spec has caused problems like this way out of proportion to the apparent difficulty of specifying the meaning of defaults and the difficulty of implementing it.]
In fact, I am tend to agree with you on that point by now. Any handling of defaults will either require some significant machinery (Marcin's proposal) or be a compromise with rough edges (all the other proposals). 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"...". This is simple and largely backwards-compatible. Implementations will support the specification of a library name (in a second string) for some more time, but its use is deprecated. (See the previous emails for why no library spec and why add the include spec to the function name.) Cheers, Manuel