Let's get this finished

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Tue Jan 9 21:06:02 EST 2001

qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,

> Tue, 09 Jan 2001 13:59:10 +1100, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> pisze:
> > I was thinking of having the library itself by default
> > provide a set of standard encodings.  Like - as you say
> > later - we usually rely on a set of standard MIME encodings
> > to be available.
> If an encoding is added to the database at some point of time,
> a program uses it and is then recompiled on a system which does
> not provide this encoding, you get a runtime error.
> If conversions are referred to as plain imported values, you get
> a compile error.

But what would be the reason for an implementation not
providing this conversion?  That it can't do the conversion?
But in this case, you have a problem anyway.  Independent of
the mechanism used to reference the conversion, you won't
get it.  This not different from trying to print Cyrillic
text on a computer that doesn't have a Cyrillic font - you
just won't see much :-)

Other than that, your library could explicitly list a set of
standard conversions that any complying implementation has
to provide (at least if it is available on the system).

> A database is only useful if encodings are now known individually
> by the programmer and he wants his program to support everything
> the Haskell's library provides for some well known name scheme. It
> can be a convenience wrapper, but definitely not the basic reference
> for conversions.

I did mean it as a convenience wrapper.  There are certainly
users who want the full interface.  I am just thinking about
the average user writing an average program who happens to
write all error message in Mandarin.  This person wants an
easy way to access Big5 somehow, not more.


More information about the FFI mailing list