Let's get this finished

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Mon Jan 8 21:59:10 EST 2001

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

> Mon, 8 Jan 2001 17:11:04 +0100 (CET), Marcin 'Qrczak' Kowalczyk <mk167280 at zodiac.mimuw.edu.pl> pisze:
> > A central database can be built around conversions available as values in
> > the program. But it would be a bad idea to take it as the basic
> > identification and require registering to use a conversion.
> An important reason is that one can never be sure that a particular
> encoding has been registered. 

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.  Given this, most normal users would never
have to touch the more complicated Conv type, but just use
the string handles to reference these standard encodings.
Just like in MIME.

> Unless it takes care to import its
> module ald call the registration function, but in this case he could
> as well take the conversion itself without the extra indirection.

Not necessarily.  Imagine a module StdEncodings, with a
function `initStdEncodings'.  Then, my program could look

  import StdEncodings


  main = do
	   <use encoding "iso-2022-jp">

This is simpler than using the fully fledged conversion
interface.  Moreover, we could require these standard
encodings already to be pre-registered.


More information about the FFI mailing list