Summary of current change suggestions

[Manuel M. T. Chakravarty]

"Alastair Reid" <reid at 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