[Caml-list] [ANN] ucorelib 0.1.0

[Caml-list] [ANN] ucorelib 0.1.0

[Yoriyuki Yamagata]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Dear list,

I am pleased to announce the release of ucorelib, a new Unicode library for
OCaml.  ucorelib provides Unicode character type, Unicode text type
(internally ropes), and decoder/encoder of UTF-8, UTF-16, UTF-32.

Main page: https://github.com/yoriyuki/ucorelib
Release page: https://github.com/yoriyuki/ucorelib/releases/tag/v0.1.0

ucorelib provides

1. An abstract data type for Unicode character.  This prevents you to
create illegal Unicode characters, so it is safer than just using integers
of Unicode characters.

2. An abstract text data type, internally implemented as ropes.  All
interface to Text module are purely functional.

3. Code converter from/to UTF-8, UTF-16, UTF-32

By the way, I am looking for someone who can collaborate with me.
 Specifically, I am looking for

1. OCaml build system guru
2. OCaml syntax extension guru, to propose a syntax extension for Unicode.
3. XML guru, to make a parser for LDML, Locale Data Markup Language.

Best,
-- 
Yoriyuki Yamagata
yoriyuki.y@gmail.com

[-- Attachment #2: Type: text/html, Size: 1550 bytes --]

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Peter Zotov]

On 2014-05-10 06:52, Yoriyuki Yamagata wrote:
> Dear list,
> 
> I am pleased to announce the release of ucorelib, a new Unicode
> library for OCaml.  ucorelib provides Unicode character type, Unicode
> text type (internally ropes), and decoder/encoder of UTF-8, UTF-16,
> UTF-32.

Hello,

Any properties of your library notwithstanding, what are the reasons for
development of yet another OCaml unicode library? There are:

   * Uutf+Uucd
   * Camomile
   * ocaml-text
   * ucslib[1]

I can believe that there are good reasons for doing so, I'm just curious
what they are.

[1]: https://github.com/pippijn/ucslib

-- 
Peter Zotov
sip:whitequark@sipnet.ru

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Daniel Bünzli]

Le samedi, 10 mai 2014 à 05:22, Peter Zotov a écrit :

> * Uutf+Uucd

Note, Uucd won't bring you efficient access to character properties, it just parses the Unicode XML character database [1] and presents its data to you as OCaml datatypes. I do have something in preparation for exposing efficient access to a selection of properties but it's not ready at the moment.

Best,

Daniel

[1] http://www.unicode.org/reports/tr42/

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Yoriyuki Yamagata]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Hi, thank you for a comment.

2014年5月10日土曜日、Peter Zotov<whitequark@whitequark.org>さんは書きました:
>
> Any properties of your library notwithstanding, what are the reasons for
> development of yet another OCaml unicode library?
>

ucorelib will (hopefully) be a succeser of Camomile.  Camomile has many
functionalities which are not always necessary.  ucorelib has only basic
functionalities and advanced features will be provided in separate
libraries.

For other libraries, my complaint is that they expose internal
representations of Unicode characters and texts.  This is convinient for
now, but unsafe and not conceptually clean.

Best,

-- 
Yoriyuki Yamagata
yoriyuki.y@gmail.com

[-- Attachment #2: Type: text/html, Size: 1078 bytes --]

Re: [Caml-list] [ANN] ucorelib 0.1.0

[malc]

On Sat, 10 May 2014, Yoriyuki Yamagata wrote:

> Dear list,
> 
> I am pleased to announce the release of ucorelib, a new Unicode library for
> OCaml.  ucorelib provides Unicode character type, Unicode text type
> (internally ropes), and decoder/encoder of UTF-8, UTF-16, UTF-32.
> 
> Main page: https://github.com/yoriyuki/ucorelib
> Release page: https://github.com/yoriyuki/ucorelib/releases/tag/v0.1.0
> 
> ucorelib provides
> 
> 1. An abstract data type for Unicode character.  This prevents you to
> create illegal Unicode characters, so it is safer than just using integers
> of Unicode characters.
> 
> 2. An abstract text data type, internally implemented as ropes.  All
> interface to Text module are purely functional.
> 
> 3. Code converter from/to UTF-8, UTF-16, UTF-32
> 
> By the way, I am looking for someone who can collaborate with me.
>  Specifically, I am looking for
> 
> 1. OCaml build system guru
> 2. OCaml syntax extension guru, to propose a syntax extension for Unicode.
> 3. XML guru, to make a parser for LDML, Locale Data Markup Language.
> 

Not a guru by any stretch but i do have a translation of Tor Anderssons'
XML parser into OCaml, if nothing else it's small and can be easily
embedded into any any code base, main/only benefit is that is small (it
lacks everything else).

http://repo.or.cz/w/llpp.git/blob/HEAD:/parser.ml

-- 
mailto:av1474@comtv.ru

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Andrew Herron]

On Saturday, 10 May 2014 at 9:19 pm, malc wrote:

> On Sat, 10 May 2014, Yoriyuki Yamagata wrote:
> > 3. XML guru, to make a parser for LDML, Locale Data Markup Language.
>  
>  
> Not a guru by any stretch but i do have a translation of Tor Anderssons'
> XML parser into OCaml, if nothing else it's small and can be easily
> embedded into any any code base, main/only benefit is that is small (it
> lacks everything else).
>  
> http://repo.or.cz/w/llpp.git/blob/HEAD:/parser.ml
It’s a bit old but I found xml-light to be a nice dead simple parser. It and some others are listed on the somewhat out of date camp hump page:
http://caml.inria.fr/cgi-bin/hump.en.cgi?sort=0&browse=49

Cheers,
Andy

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Daniel Bünzli]

Le dimanche, 11 mai 2014 à 23:58, Andrew Herron a écrit :
> It’s a bit old but I found xml-light to be a nice dead simple parser. It and some others are listed on the somewhat out of date camp hump page:
> http://caml.inria.fr/cgi-bin/hump.en.cgi?sort=0&browse=49

I highly suggest *not* to use xml-light if you don't have control over the xml you input. It's not standard compliant by any means and the day you get a file that cannot be parsed you (or the users of your tools) won't be happy. AFAIK pxp or xmlm are the only pure OCaml standard compliant alternatives that exist.

Best,

Daniel

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Andrew Herron]

On Monday, 12 May 2014 at 8:16 am, Daniel Bünzli wrote:

> I highly suggest *not* to use xml-light if you don't have control over the xml you input. It's not standard compliant by any means and the day you get a file that cannot be parsed you (or the users of your tools) won't be happy. AFAIK pxp or xmlm are the only pure OCaml standard compliant alternatives that exist.

huh. When I first looked into it, I thought xmlm wasn’t pure OCaml. Not sure where I got that idea.

Ignore my xml-light suggestion then :)

Cheers,
Andy

Re: [Caml-list] [ANN] ucorelib 0.1.0

[Daniel Bünzli]

Le lundi, 12 mai 2014 à 00:55, Andrew Herron a écrit :

> huh. When I first looked into it, I thought xmlm wasn’t pure OCaml.

God forbid.  

> Ignore my xml-light suggestion then :)
Note however that xmlm may not be the easiest interface to work with, it was designed so that if you need to efficiently extract data from that fundamentally inefficient format, you get a chance to, in bounded memory.  

It has always been my hope that someone else would devise higher-level xquery like combinators on top of it, but that never really materialized. That is until recently, it seems there is now ezxmlm [1] that tries to fill that void (never used it, but it's an opam install away).  

Best,

Daniel

[1] https://github.com/avsm/ezxmlm