[m-dev.] Unicode support in Mercury

Peter Schachte schachte at csse.unimelb.edu.au
Tue May 10 10:16:28 AEST 2011

On 09/05/11 22:11, Matt Giuca wrote:
> Here he proposes three alternatives: #1 which is to leave the
> interface as-is and let users deal with surrogate pairs. This is the
> current position of Mercury (except in UTF-8 backends, Mercury lets
> users deal with individual bytes rather than surrogate pairs). #2, as
> I have been suggesting, which is to keen the UTF-16 backend but change
> the interface to deal in characters/codepoints -- as Guido says this
> is bad due to performance, and I'm backing down on this proposal now.
> #3 which is to change the implementation to UTF-32 and have a
> character/codepoint interface, which Guido calls "the ideal
> situation".

What about a fourth option:  make the string index type an abstract type
(stopping anyone from using +1 on it), and implement next_index to take a
string and an index, and return a new index, etc.?  Keep the efficient
implementation, but hide the index type.

Peter Schachte              Unlike other resources, time cannot be bought or
University of Melbourne     sold, borrowed or stolen, stocked up or saved,
schachte at unimelb.edu.au     manufactured, reproduced, or modified. All we
www.cs.mu.oz.au/~schachte/  can do is make use of it.
Phone: +61 3 8344 1338          -- Jean-Louis Servan-Schreiber
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au

More information about the developers mailing list