errno again

[Manuel M. T. Chakravarty]

Simon Marlow <simonmar at microsoft.com> wrote,

> > Yes, I am persuaded that hard-coded datatypes tend to be bad in
> > this situation.  The way hsc2hs deals with constants is quite good,
> > and it is certainly a better, more flexible, approach.  However, I do
> > have some hesitation in relying on yet another pre-processing tool,
> > with yet another "little language" outside of Haskell itself.
> > 
> > Of course hsc2hs does more than just filling in constants, but for
> > just that one task, I wonder if we should be extending the primitive
> > FFI mechanism itself.  For instance, we already have "foreign label",
> > so what about perhaps "foreign value":
> > 
> >     foreign value "F_GETFL" fGetFL :: CInt
> > 
> > This is just off the top of my head, so I'm probably missing some
> > subtleties.  What do people think of this idea?  Are there some
> > real killer situations which would make it impossible?
> 
> Uh-oh!  The return of litlits!
> 
> But seriously, this approach pollutes the language-independence of the
> low level FFI, unless you add an extra language descriptor to the
> declaration.  It's also awkward to implement unless you compile via C -
> you couldn't implement this using a dumb preprocessor, for example.
> 
> The preprocessor approach seems to be the lesser of several evils.

I agree.  This is just beyond what can be done without
requiring that the Haskell compiler generates C code or
implements significant portions of a C compiler itself.
Constants in C can be quite tricky:

  enum {
    VALUE0 = -1,
    VALUE1,
    VALUE2
  };
  typedef struct {
    int   this;
    float that;
  } mystruct;
  #define EVIL_CONSTANT (VALUE1 + sizeof (mystruct))

C->Haskell implements part of a C compiler to get this right
and hsc2hs uses a vanilla C compiler for that.

Cheers,
Manuel