On Wed, 2004-04-28 at 02:58, Yamagata Yoriyuki wrote:

> I'm interested in an emprical evidence, though.

You don't need it. It is clear that there are
common (99%) of all cases where UTF-8 representation
of ISO10646 is the same as ASCII, and 90% of the
rest using Latin-1 which converts very very fast.

In these common cases the overhead of non-inlined
function calls to convert characters could be very serious.

Perhaps it isn't and perhaps it is. Who knows?
Providing bulk conversions seems a prudent way to
hedge your bets. It makes the interface richer,
but there is a universal default for the bulk
operations, so no burden is imposed on the implementor.

To add to the argument in favour of bulk conversions:
in principle, doing *any* conversions on I/O is a bad
idea. The order of priority is:

	1. single point codecs
	2. string codecs
	3. IO codecs

Doesn't really make sense to have (1) and (3) and not (2).
	

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners