Let's get this finished

Marcin 'Qrczak' Kowalczyk mk167280 at students.mimuw.edu.pl
Tue Jan 9 09:17:04 EST 2001

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

Marcin 'Qrczak' Kowalczyk

More information about the FFI mailing list