On Wed, 10 Jan 2001, Manuel M. T. Chakravarty wrote:
which, I think, is what you want, should suffice for the moment.
I am happy with that.
There is, however, one constraint that I would like to impose on the design of the conversion library. It must be possible to spot and optimise the application of cheap conversions like to/fromLatin1.
It is possible now, even witohut RULES (which would not catch cases which are not recognizable statically). Conv is an abstract type. Currently it has alternatives for a conversion implemented in Haskell (working on lists), a conversion implemented in C (working on pointers to C arrays and with a different chunking strategy), and a conversion implemented in both styles, to be chosen by code using it (perhaps it's unnecessary, I have to measure). For example direct application of a conversion to a user-supplied String uses the Haskell variant if available, otherwise does appropriate array marshalling for the C variant. OTOH newCStringConv uses the C variant directly on the returned buffer if available, otherwise runs the Haskell variant and uses newArray0. It would be no problem to add variants for Latin1 and let withCStringConv not call newCStringConv in this case but treat it specially. (Currently alloca is implemented in terms of malloc so it does not matter anyway.) -- Marcin 'Qrczak' Kowalczyk