Re: [Caml-list] Re: Rope is the new string

["Loup Vaillant" <loup.vaillant@gmail.com>]

2007/10/10, Vincent Hanquez <tab@snarc.org>:
> On Tue, Oct 09, 2007 at 11:06:59PM +0200, Loup Vaillant wrote:
> > Err, I would prefer this:
> >
> >(* big snipet *)
>
> yes I agree, that what I had in mind, but didn't want to clutter my example.
> internally the ustring can hold the format. it should look something like:
>
> type unicode_type = UTF8 | UTF16 | UTF32 | Latin | .............
> type ustring = unicode_type * string
>
> of_string : string -> unicode_type -> ustring (* raise if not correct type *)
>
> which is the same as what you describe, except that you have one parsing
> function for every type ;)

That's even better.

> > print
> >   (append
> >     scan_Latin1
> >     (of_string text))
> > (* this is not Lisp *)
> >
> > Just that the sample code you wrote suggest you could have different
> > types of unicode strings. I want only one type, so I don't mind the
> > encoding, except when reading and printing (to files and native
> > strings). To mind even less, you could have a general scan and
> > from_string functions which guess which encoding is used (not very
> > safe, but cool)
>
> or have a autodetect format in the of_string format wanted along with
> the other encoding ;)

But of course.


> > > that way when I'm manipulating unicode string, i won't try to append a
> > > binary string to a unicode string. I can code safely with my unicode
> > > string (whatever the format utf-{8..32}), and certainly expect the type
> > > system to complain loudly when doing something that might break unicode.
> >
> > The exception system can do that, but how could the type system?
> > (Would be better if it could.)
>
> well it does now if you define ustring as an opaque type. you do your
> parsing at one place (from string to ustring), at this place it can
> raise exception if not a proper format. but once you're manipulating
> ustring, it's safe to do whatever you want with them.

OK.


So, it seem we agree more or less on the interface. Now what about the
implementation? Ropes? Flat? I like ropes, personally: catenation is
made fast, and look-up are still sub-linear. In general Ropes look
cool for functional strings. Last but not the least, they were almost
mandatory for saving Endo at the ICFP this year. ;-)

Loup Vaillant