Version française
Home     About     Download     Resources     Contact us    
Browse thread
Correct way of programming a CGI script
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: tab@s...
Subject: Re: [Caml-list] Re: Rope is the new string
On Tue, Oct 09, 2007 at 11:06:59PM +0200, Loup Vaillant wrote:
> Err, I would prefer this:
> 
> type ustring (* the type should be abstract, I think *)
> of_string_utf8: string -> ustring (* raise if not utf8 compliant *)
> to_string_utf8: ustring -> string
> of_string_utf16: string -> ustring (* raise if not utf16 compliant *)
> to_string_utf16: ustring -> string
> of_string_latin1: string -> ustring (* raise if not latin1 compliant *)
> to_string_latin1: ustring -> string (* raise if characters not encoded
> in Latin1 (the exeption should contain a usefull result) *)
> (* etc for each encoding *)
> scan_utf8 (* raise if not utf8 compliant (but do not lose a possible
> partial result) *)
> print_utf8
> (* etc for each encoding *)

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 ;)

> append: ustring -> ustring -> ustring
> (* etc *) (* I agree on these ones *)
> 
> So I can mix-up different encodings:

yes it would be ideal.

> 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 ;)

> > 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.

-- 
Vincent Hanquez