Re: [Caml-list] [OSR] OCaml Standard Recommandation Process

[David Teller <David.Teller@univ-orleans.fr>]

You are correct, I should have been more specific. The idea is to
discuss
* libraries
* Camlp4 extensions
* language features that may be implemented as a combination of
libraires and Camlp4 extensions
* actual code.

Let me summarise a few good candidates for discussion. Please don't
start the actual debate in this thread, they will be posted again in
their own e-mail.

** The Unicode situation **

At the moment, at least four libraries (Camomile, ExtLib, ULex, LablGtk)
contain their own, incompatible, Unicode management modules, none of
which is compatible with OCamllex, or (I believe) OCamlDuce, Camlp4,
OCaml-Java, Spidercaml, the Str module, wxOCaml, Expat...

We need to
* decide on APIs we will consider "standard" for Unicode management --
preferably in the form of one already-existing library, possibly with
minor modifications, otherwise as things-that-need-to-be-implemented
* decide on whether/how to include these APIs in end-user distributions
(e.g. GODI, Debian packages, Fedora packages)
* add new implementations of Pervasives / standard library functions for
Unicode strings instead of the string type
* document the use of these APIs for the most common situations, both
for newbies and seasoned developers
* start patching our own applications to make use of these APIs, both as
a way to test them and as a way to have bring the OCaml world one step
further towards something that interacts more easily
* from the moment the debate is concluded, make it clear for new users
of OCaml that, unless they have very specific needs, this is the One
True Way of using Unicode.


** The mutable string situation **

Since the first version, OCaml has mutable strings. With time and the
hindsight provided by numerous languages with immutable strings, this
design decision has begun to be seen by many developers as wrong. As
pointed out by Xavier Leroy, however, it is now impossible to come back
on that decision and fully root out mutable strings from the language.
However, new data structures may be added, made comfortable for general
use and documented as being the new standard.

We need to
* decide if we actually want this to happen
* decide on the necessary APIs and performance requirements for these
new data structures (e.g. ropes)
* discuss and implement a nice Camlp4 syntax for these revised strings
* decide on whether/how to include these APIs in end-user distributions
(e.g. GODI, Debian packages, Fedora packages)
* add new implementations of Pervasives / standard library functions for
text strings instead of the string type
* document the use of these APIs for the most common situations, both
for newbies and seasoned developers
* start patching our own applications to make use of these APIs, both as
a way to test them and as a way to have bring the OCaml world one step
further towards something that interacts more easily
* from the moment the debate is concluded, make it clear for new users
of OCaml that, unless they have very specific needs, this is the One
True Way of using text.


---

Of course, these two debates will probably be closely linked, as they
both deal with the representation of text.

Other subjects would include ExtLib (anything we need to add ?), Lazy
lists, lazy pattern-matching (yes, this can be implemented in Camlp4),
pattern views, simple equation solving in patterns à la Haskell (match x
with y+1 -> ...), ...



Does this answer your questions ?

Cheers,
 David

On Sun, 2008-01-27 at 09:24 -0500, Yaron Minsky wrote:
> 
> What is it that is meant to be standardized by this process?  Is this
> meant to be parallel to the Java Community Process or Python's PEPs
> (Python Enhancement Proposals)?  Those are not just about "best
> practices", but are actually about code, language features, APIs, etc.
> I don't at first glance see any real use in agreeing on best practices
> for OCaml.  Can you give some examples of what would make a reasonable
> OSR?  That might clarify the purpose of them considerably.
> 
> y