[OSR] OCaml Standard Recommandation Process

[OSR] OCaml Standard Recommandation Process

[David Teller]

    Dear list,

 As I have mentioned in my previous message, during the OCaml Developer
Days, the INRIA team has made clear that, among other things, the
community is essentially in charge of recommending best practices,
standards, etc. A candidate name has been suggested: "OSR", for "OCaml
Standard Recommandations."

While we already have a few tools for this kind of discussions, (I'm
thinking about the current mailing-list and the Cocan Wiki), at the
moment, we are lacking organisation and a way of committing to a
decision.

Let me suggest the following process:
* anyone on this mailing-list may ask for or suggest best practises --
to do so, please put [OSR] in the header of your e-mail
* after some debate, if one or more solutions have emerged, we put these
solutions on the appropriate page of the Cocan Wiki, with summaries of
pros and cons and an official space for voting and suggesting future
improvements
* if the vote proves conclusive, we move the chosen solution from the
voting stage to some page on that Wiki, say "recommended practises."

Does this seem an acceptable method ?

Regards,
 David
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

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

[Paolo Donadeo]

> Does this seem an acceptable method ?

It's ok for me.


-- 
                                            Paolo
~
~
:wq

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

[Yaron Minsky]

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

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

On Jan 27, 2008 8:23 AM, David Teller <David.Teller@univ-orleans.fr> wrote:

>    Dear list,
>
>  As I have mentioned in my previous message, during the OCaml Developer
> Days, the INRIA team has made clear that, among other things, the
> community is essentially in charge of recommending best practices,
> standards, etc. A candidate name has been suggested: "OSR", for "OCaml
> Standard Recommandations."
>
> While we already have a few tools for this kind of discussions, (I'm
> thinking about the current mailing-list and the Cocan Wiki), at the
> moment, we are lacking organisation and a way of committing to a
> decision.
>
> Let me suggest the following process:
> * anyone on this mailing-list may ask for or suggest best practises --
> to do so, please put [OSR] in the header of your e-mail
> * after some debate, if one or more solutions have emerged, we put these
> solutions on the appropriate page of the Cocan Wiki, with summaries of
> pros and cons and an official space for voting and suggesting future
> improvements
> * if the vote proves conclusive, we move the chosen solution from the
> voting stage to some page on that Wiki, say "recommended practises."
>
> Does this seem an acceptable method ?
>
> Regards,
>  David
> --
> David Teller
>  Security of Distributed Systems
>  http://www.univ-orleans.fr/lifo/Members/David.Teller
>  Angry researcher: French Universities need reforms, but the LRU act
> brings liquidations.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

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

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

[David Teller]

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

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

[Jon Harrop]

On Sunday 27 January 2008 19:07:01 David Teller wrote:
> 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.

Would it not be much easier and much more productive to simply fork the OCaml 
distribution and address these issues at source? You could then address many 
other issues like improving the stdlib, adding a "try..finally" construct to 
the language, adding features to help with the brittle binding problem and 
opening the compiler's internal representations to the outside world.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Yaron Minsky]

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

On Jan 27, 2008 4:07 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

> On Sunday 27 January 2008 19:07:01 David Teller wrote:
> > 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.
>
> Would it not be much easier and much more productive to simply fork the
> OCaml
> distribution and address these issues at source? You could then address
> many
> other issues like improving the stdlib, adding a "try..finally" construct
> to
> the language, adding features to help with the brittle binding problem and
> opening the compiler's internal representations to the outside world.


That seems like a fairly awful idea to me.  Trying to develop the core
language away from the confines of INRIA seems expensive and unlikely to go
well.  The INRIA team understands the core of the language like no one else,
after all, and it will be hard to replace that expertise.

I do think there is value in outside companies thinking carefully about a
limited set of improvements that (a) can only be fixed in the core language
and (b) would make it easier for outsiders to add necessary features.

One role I would like to see the caml team take upon itself is that of
blessing standardization efforts.  If INRIA had a link on its site to a
recommended batteries-included distribution, that would help the community
coalesce around that distribution.  Obviously trying to choose winners in
this way is tricky and not to be done lightly, but I do think there's a good
chance that it will become important.

y

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

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

[David Teller]

Yaron wrote:
> One role I would like to see the caml team take upon itself is that of blessing standardization efforts.  If INRIA had a link on its site to a recommended batteries-included distribution, that would help the community coalesce around that distribution.  Obviously trying to choose winners in this way is tricky and not to be done lightly, but I do think there's a good chance that it will become important.

Just to be clear: we already have the verbal blessing of Xavier Leroy on
this. I can only assume that, once the process has been bootstrapped,
this will be materialized by a link on the site and/or in the manual.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

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

[Jon Harrop]

On Sunday 27 January 2008 21:47:47 Yaron Minsky wrote:
> On Jan 27, 2008 4:07 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Would it not be much easier and much more productive to simply fork the
> > OCaml
> > distribution and address these issues at source? You could then address
> > many
> > other issues like improving the stdlib, adding a "try..finally" construct
> > to
> > the language, adding features to help with the brittle binding problem
> > and opening the compiler's internal representations to the outside world.
>
> That seems like a fairly awful idea to me.

Agreed but I see no other way to keep OCaml alive and moving in a direction 
that is beneficial to its community.

> Trying to develop the core language away from the confines of INRIA seems
> expensive and unlikely to go well.

Sophisticated renovations of the type system might not succeed but we're 
talking about much more mundane features here. Just looking at text, we might 
want:

. Folds in the String module.
. Functions to read whole files as a string or list of lines.
. Either "try..finally" or "use" bindings or combinators to automate closing.
. Immutable strings.
. Ropes.
. Unicode.
. More efficient pattern matching.

These have all been available for years in the form of many incompatible 
extensions and will continue to be under-used until they are integrated into 
OCaml itself.

There are also many features that I would like to steal from other languages:

. The IDisposable interface from .NET and F#'s "use" bindings.
. F#'s computation expressions: a syntax for monadic style in ML.
. Integrated OpenGL-based graphics.

and some more involved ones like operator overloading.

> The INRIA team understands the core of the language like no one 
> else, after all, and it will be hard to replace that expertise.

OCaml's researchers at INRIA are unquestionably talented but they have made it 
quite clear that polishing the public OCaml distribution is not their job. 
Moreover, they are grossly over-qualified for most of this work. We don't 
need a world expert in type theory to write String.fold_right for us: it 
would be a waste of their time and constantly working around its absence is a 
waste of ours. So we have different goals and (IMHO) have reached the point 
where their developments are arguably doing more harm than good for many us.

If we want a more robust and feature complete OCaml then we must develop it 
ourselves. Luckily the community has already done most of the hard work and 
we just need to integrate this work into a new standardized OCaml 
distribution and get the package maintainers to migrate to it.

With so many trivial changes to make this seems like a no-brainer to me. 
Indeed, we've had many interesting threads here over the past few years and 
this is our chance to put them into action. Look at all of the great 
suggestions for optimizations that came out of the thread about MLton's 
performance, for example. We can implement some of them. Look at the 
outstanding bugs that were cited recently. We could fix many of them.

> I do think there is value in outside companies thinking carefully about a
> limited set of improvements that (a) can only be fixed in the core language
> and (b) would make it easier for outsiders to add necessary features.

You need a reasonable and objective definition of "can only be fixed in the 
core language" because, of course, you can ad-hoc many things with camlp4 but 
the results are much harder to maintain and will never gain the traction they 
deserve. For example, I am not willing to have to change my compile lines, 
learn to interpret different compiler output and break my other tools just to 
get a "try..finally" construct but I would love to see it added to the OCaml 
language and implemented in the tools.

Improving the standard library is high on my list. Sources of stack overflows 
should be removed. The library should be filled out, e.g. so that all modules 
implementing containers adhere to a suitable signature and Set/Map-compatible 
modules are provided for all basic types (e.g. Int, Float).

As for making it easy for outsiders to add necessary features, perhaps there 
is something we can do to weaken these brittle bindings by automating the use 
of functors in a new intermediate representation and distribute that instead. 
As the package maintainers have already said, this would make their lives 
easier too!

> One role I would like to see the caml team take upon itself is that of
> blessing standardization efforts.  If INRIA had a link on its site to a
> recommended batteries-included distribution, that would help the community
> coalesce around that distribution.  Obviously trying to choose winners in
> this way is tricky and not to be done lightly, but I do think there's a
> good chance that it will become important.

If INRIA's blessing would help to persuade the package maintainers that we 
have consensus to move forward with a new upstream source for the OCaml 
distribution then I agree.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[David Teller]

On Mon, 2008-01-28 at 12:04 +0000, Jon Harrop wrote:
> Sophisticated renovations of the type system might not succeed but we're 
> talking about much more mundane features here. Just looking at text, we might 
> want:
> 
> . Folds in the String module.
> . Functions to read whole files as a string or list of lines.
> . Either "try..finally" or "use" bindings or combinators to automate closing.
> . Immutable strings.
> . Ropes.
> . Unicode.
> . More efficient pattern matching.
> 
> These have all been available for years in the form of many incompatible 
> extensions and will continue to be under-used until they are integrated into 
> OCaml itself.

I believe there's a problem of vocabulary rather than a philosophical
issue.

Almost everything you suggest in your post requires modifying *the
distribution* but not necessarily *the language*. INRIA is quite happy
to let the community handle a standard distribution.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

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

[Brian Hurt]

Jon Harrop wrote:

>There are also many features that I would like to steal from other languages:
>
>. The IDisposable interface from .NET and F#'s "use" bindings.
>  
>
Is there a reason that Gc.finalise doesn't work?

>and some more involved ones like operator overloading.
>
>  
>
I *hate* operator overloading.  My experience in C++ is for every time 
this feature is used legitimately (i.e. to implement complex numbers or 
whatever), it's abused 10 times- and that's ignoring C++'s use of the 
bit shift operators << and >> for I/O, and the use of + for string 
concatentation, both of which I'd argue really should be considered 
abuses, as far as I'm concerned.  And this is ignoring the difficulty of 
type inference in the presence of overloaded operators.

The best way to handle this IMHO is Haskell-style type classes.  Which 
solves the whole type inference problem, and rules most of what I 
consider abuses of operator overloading (for example, if you have a '+' 
operator, you also have to have a '*' operator- and what is "foo" * 
"bar"?).  But this is a very non-trivial change to the language.

Just my $0.02.

Brian

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

[Loup Vaillant]

2008/1/28, Brian Hurt <bhurt@janestcapital.com>:
> I *hate* operator overloading.  My experience in C++ is for every time
> this feature is used legitimately (i.e. to implement complex numbers or
> whatever), it's abused 10 times- and that's ignoring C++'s use of the
> bit shift operators << and >> for I/O, and the use of + for string
> concatentation, both of which I'd argue really should be considered
> abuses, as far as I'm concerned.  And this is ignoring the difficulty of
> type inference in the presence of overloaded operators.
>
> The best way to handle this IMHO is Haskell-style type classes.  Which
> solves the whole type inference problem, and rules most of what I
> consider abuses of operator overloading (for example, if you have a '+'
> operator, you also have to have a '*' operator- and what is "foo" *
> "bar"?).  But this is a very non-trivial change to the language.

Err, are you really suggesting type classes to be added in Ocaml?
Doing that properly would require to change the whole standard
library, breaking havoc in every single Ocaml program, even the
simplest
print_string "Hello World";;

I also heard that the current type checker is "quite" complicated
(labels, variants, objects...).  Type classes fits well with a naked
Hindley-Milner type system, but how would it interact with the extra
Ocaml features?

Finally, it may make some type annotations mandatory, which may be
viewed a unacceptable. (I'm not sure of this one, though.)

Maybe type classes should be added, but I'm afraid they can't. :-(

Loup

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

[Brian Hurt]

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

Loup Vaillant wrote:

>2008/1/28, Brian Hurt <bhurt@janestcapital.com>:
>  
>
>>I *hate* operator overloading.  My experience in C++ is for every time
>>this feature is used legitimately (i.e. to implement complex numbers or
>>whatever), it's abused 10 times- and that's ignoring C++'s use of the
>>bit shift operators << and >> for I/O, and the use of + for string
>>concatentation, both of which I'd argue really should be considered
>>abuses, as far as I'm concerned.  And this is ignoring the difficulty of
>>type inference in the presence of overloaded operators.
>>
>>The best way to handle this IMHO is Haskell-style type classes.  Which
>>solves the whole type inference problem, and rules most of what I
>>consider abuses of operator overloading (for example, if you have a '+'
>>operator, you also have to have a '*' operator- and what is "foo" *
>>"bar"?).  But this is a very non-trivial change to the language.
>>    
>>
>
>Err, are you really suggesting type classes to be added in Ocaml?
>  
>

No.  I was using that to try and kill the idea of operator overloading.

Brian


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

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

[Jon Harrop]

On Monday 28 January 2008 15:40:56 Brian Hurt wrote:
> No.  I was using that to try and kill the idea of operator overloading.

Pointing out that different ideas are not feasible doesn't kill the original 
idea.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Jon Harrop]

On Monday 28 January 2008 14:23:01 you wrote:
> Jon Harrop wrote:
> >There are also many features that I would like to steal from other
> > languages:
> >
> >. The IDisposable interface from .NET and F#'s "use" bindings.
>
> Is there a reason that Gc.finalise doesn't work?

Absolutely: Gc.finalise is only probabilistic whereas IDisposable is 
deterministic. IDisposable guarantees deallocation of resources by a certain 
point. (This is why you should never use Gc.finalise alone to manage the 
collection of external resources!)

So you write a "use" binding:

  let read_first_line file =
    use ch = open_in file in
    input_line ch

and it gets translated into:

  let read_first_line file =
    let ch = open_in file in
    try input_line ch finally
    ch#dispose

where the "dispose" method that was automatically inserted at the end of the 
scope of the "use" binding calls "close_in" in this case to deallocate the 
external resource (a file handle in this case but it could be anything with a 
dispose method).

This is easy to implement and will remove a world of pain when doing IO in 
OCaml.

> >and some more involved ones like operator overloading.
>
> I *hate* operator overloading.  My experience in C++ is for every time
> this feature is used legitimately (i.e. to implement complex numbers or
> whatever), it's abused 10 times- and that's ignoring C++'s use of the
> bit shift operators << and >> for I/O, and the use of + for string
> concatentation, both of which I'd argue really should be considered
> abuses, as far as I'm concerned. And this is ignoring the difficulty of type
> inference in the presence of overloaded operators.

You're looking in the wrong direction.

Look at F# to see how OCaml + overloading done right can be hugely beneficial. 
OCaml has fallen far too far behind to catch up completely but we could take 
some baby steps in this direction, just like SML's ad-hoc polymorphic 
approach but with a wider range of types (complexes, vectors, matrices).

This is fairly easy to implement and, again, will remove a world of pain when 
doing arithmetic in OCaml.

> The best way to handle this IMHO is Haskell-style type classes.  Which
> solves the whole type inference problem, and rules most of what I
> consider abuses of operator overloading (for example, if you have a '+'
> operator, you also have to have a '*' operator- and what is "foo" *
> "bar"?).  But this is a very non-trivial change to the language.

Type classes are more powerful but they also make performance less predictable 
(the dictionary may or may not be optimized away). They are also 
unachievable, as you say.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Christophe TROESTLER]

On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> 
> So you write a "use" binding:
> 
>   let read_first_line file =
>     use ch = open_in file in
>     input_line ch
> 
> and it gets translated into:
> 
>   let read_first_line file =
>     let ch = open_in file in
>     try input_line ch finally
>     ch#dispose
> 
> where the "dispose" method that was automatically inserted at the end of the 
> scope of the "use" binding calls "close_in" in this case to deallocate the 
> external resource (a file handle in this case but it could be anything with a 
> dispose method).

What is wrong with

   let read_first_line file =
     with_open_in file begin fun ch ->
       input_line ch
     end

?

Cheers,
ChriS

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

[Nicolas Pouillard]

Excerpts from christophe.troestler+ocaml's message of Mon Jan 28 17:06:10 +0100 2008:
> On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > 
> > So you write a "use" binding:
> > 
> >   let read_first_line file =
> >     use ch = open_in file in
> >     input_line ch
> > 
> > and it gets translated into:
> > 
> >   let read_first_line file =
> >     let ch = open_in file in
> >     try input_line ch finally
> >     ch#dispose
> > 
> > where the "dispose" method that was automatically inserted at the end of the 
> > scope of the "use" binding calls "close_in" in this case to deallocate the 
> > external resource (a file handle in this case but it could be anything with a 
> > dispose method).
> 
> What is wrong with
> 
>    let read_first_line file =
>      with_open_in file begin fun ch ->
>        input_line ch
>      end

This  code  has  nothing  wrong but with_open_in (even if it's very useful) is
not resource safe. This is because the in_channel can escape it's scope.

| let ch = with_open_in file (fun x -> x) in
| input_line ch

This program is obviously wrong but still show that with_open_in is not safe.

Cheers,

-- 
Nicolas Pouillard aka Ertai

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

[Christophe TROESTLER]

On Mon, 28 Jan 2008 17:20:16 +0100, Nicolas Pouillard wrote:
> 
> Excerpts from christophe.troestler+ocaml's message of Mon Jan 28 17:06:10 +0100 2008:
> > On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > > 
> > > So you write a "use" binding:
> > > 
> > >   let read_first_line file =
> > >     use ch = open_in file in
> > >     input_line ch
> > > 
> > > and it gets translated into:
> > > 
> > >   let read_first_line file =
> > >     let ch = open_in file in
> > >     try input_line ch finally
> > >     ch#dispose
> > > 
> > > where the "dispose" method that was automatically inserted at
> > > the end of the scope of the "use" binding calls "close_in" in
> > > this case to deallocate the external resource (a file handle in
> > > this case but it could be anything with a dispose method).
> > 
> > What is wrong with
> > 
> >    let read_first_line file =
> >      with_open_in file begin fun ch ->
> >        input_line ch
> >      end
> 
> This  code  has  nothing  wrong but with_open_in (even if it's very useful) is
> not resource safe. This is because the in_channel can escape it's scope.
> 
> | let ch = with_open_in file (fun x -> x) in
> | input_line ch
> 
> This program is obviously wrong but still show that with_open_in is not safe.

Right but how is it different with "use" ?

ChriS

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

[Olivier Andrieu]

On Jan 28, 2008 5:45 PM, Christophe TROESTLER
<Christophe.Troestler+ocaml@umh.ac.be> wrote:
>
> On Mon, 28 Jan 2008 17:20:16 +0100, Nicolas Pouillard wrote:
> >
> > Excerpts from christophe.troestler+ocaml's message of Mon Jan 28 17:06:10 +0100 2008:
> > > On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > > >
> > > > So you write a "use" binding:
> > > >
> > > >   let read_first_line file =
> > > >     use ch = open_in file in
> > > >     input_line ch
> > > >
> > > > and it gets translated into:
> > > >
> > > >   let read_first_line file =
> > > >     let ch = open_in file in
> > > >     try input_line ch finally
> > > >     ch#dispose
> > > >
> > > > where the "dispose" method that was automatically inserted at
> > > > the end of the scope of the "use" binding calls "close_in" in
> > > > this case to deallocate the external resource (a file handle in
> > > > this case but it could be anything with a dispose method).
> > >
> > > What is wrong with
> > >
> > >    let read_first_line file =
> > >      with_open_in file begin fun ch ->
> > >        input_line ch
> > >      end
> >
> > This  code  has  nothing  wrong but with_open_in (even if it's very useful) is
> > not resource safe. This is because the in_channel can escape it's scope.
> >
> > | let ch = with_open_in file (fun x -> x) in
> > | input_line ch
> >
> > This program is obviously wrong but still show that with_open_in is not safe.
>
> Right but how is it different with "use" ?

It's basically the same. But with "use" (or "using" in C#), you don't
have to write the "with_open_in" wrapper in the first place because
the finalizing function is implicit, it's the method called "Dispose".

Using this scheme with OCaml would mean that any resource-using
datatype has to be an object (not really the case right now).

-- 
  Olivier

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

[Jon Harrop]

On Monday 28 January 2008 16:51:17 Olivier Andrieu wrote:
> It's basically the same. But with "use" (or "using" in C#), you don't
> have to write the "with_open_in" wrapper in the first place because
> the finalizing function is implicit, it's the method called "Dispose".

Exactly.

> Using this scheme with OCaml would mean that any resource-using
> datatype has to be an object (not really the case right now).

Well, anything that wanted to exploit this would need to be an object. We 
could provide a completely new interface and also maintain backwards 
compatibility.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Gordon Henriksen]

On 2008-01-28, at 11:20, Nicolas Pouillard wrote:

> Excerpts from christophe.troestler+ocaml's message of Mon Jan 28  
> 17:06:10 +0100 2008:
>>
>
>> On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
>>
>>> So you write a "use" binding:
>>>
>>>  let read_first_line file =
>>>    use ch = open_in file in
>>>    input_line ch
>>>
>>> and it gets translated into:
>>>
>>>  let read_first_line file =
>>>    let ch = open_in file in
>>>    try input_line ch finally
>>>    ch#dispose
>>>
>>> where the "dispose" method that was automatically inserted at the  
>>> end of the
>>> scope of the "use" binding calls "close_in" in this case to  
>>> deallocate the
>>> external resource (a file handle in this case but it could be  
>>> anything with a
>>> dispose method).
>>
>> What is wrong with
>>
>>   let read_first_line file =
>>     with_open_in file begin fun ch ->
>>       input_line ch
>>     end
>
> This  code  has  nothing  wrong but with_open_in (even if it's very  
> useful) is
> not resource safe. This is because the in_channel can escape it's  
> scope.
>
> | let ch = with_open_in file (fun x -> x) in
> | input_line ch
>
> This program is obviously wrong but still show that with_open_in is  
> not safe.


This argument applies equally to Pervasives.close_in. Allowing the  
programmer to control the deallocation of external resources is much  
more important than attempting to prevent her from performing an  
invalid operation via a deallocated handle.

— Gordon

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

[Jon Harrop]

On Monday 28 January 2008 16:06:10 Christophe TROESTLER wrote:
> On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > So you write a "use" binding:
> >
> >   let read_first_line file =
> >     use ch = open_in file in
> >     input_line ch
> >
> > and it gets translated into:
> >
> >   let read_first_line file =
> >     let ch = open_in file in
> >     try input_line ch finally
> >     ch#dispose
> >
> > where the "dispose" method that was automatically inserted at the end of
> > the scope of the "use" binding calls "close_in" in this case to
> > deallocate the external resource (a file handle in this case but it could
> > be anything with a dispose method).
>
> What is wrong with
>
>    let read_first_line file =
>      with_open_in file begin fun ch ->
>        input_line ch
>      end

Sure. Here's the complete version using combinators as a workaround:

# let try_finally x f g =
    try
      let f_x = f x in
      g x;
      f_x
    with e ->
      (try g x with _ -> ());
      raise e;;
val try_finally : 'a -> ('a -> 'b) -> ('a -> unit) -> 'b = <fun>

# let with_open_in file k =
    try_finally (open_in file) k close_in;;
val with_open_in : string -> (in_channel -> 'a) -> 'a = <fun>

# let read_first_line file =
    with_open_in file begin fun ch ->
      input_line ch
    end;;
val read_first_line : string -> string = <fun>

This is almost exactly what I currently do.

The "use" binding is syntactic sugar to make it shorter, clearer, more generic 
and scale better.

I'd be more than happy to have anything at all added to improve this though. 
Combinators in the stdlib are certainly better than nothing and this is one 
of the most complained about noob problems (and lack of functions to read 
files)...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Till Varoquaux]

It is worth noting that OCaml is not F#. Objects in OCaml, unlike in
F#, are an advance feature, many users find them hard to grasp and
work with. They also come with a rather high runtime cost. Unless we
have a good reason to do so, I think we should avoid bolstering them
at the very core of the standard library.
Don't get me wrong, I think objects have a purpose; and so have
polymorphic variants and recursive modules but great care should be
taken before axing the core library around them.
Out of the so called "advanced" features of OCaml only the labelled
and optional arguments have made their way in the standard library. As
much as we all enjoy re-inventing the standard library around a nice
cold beer, we have to give credit to the INRIA's team for their
collective wit and the work that actually has been done.
We should keep complicated solutions for complicated problems.
Although is is tempting to propose a solution for IO using phantom
types, objects or whatnot, I still think the Common Lisp approach
(using unwind_protect) is an elaborate enough one to avoid most
problems whilst remaining simple enough to be viable.

A great solution in F# might not translate as well in OCaml, or it
might not translate at all.
Till

On Jan 28, 2008 8:49 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 28 January 2008 16:06:10 Christophe TROESTLER wrote:
> > On Mon, 28 Jan 2008 15:25:12 +0000, Jon Harrop wrote:
> > > So you write a "use" binding:
> > >
> > >   let read_first_line file =
> > >     use ch = open_in file in
> > >     input_line ch
> > >
> > > and it gets translated into:
> > >
> > >   let read_first_line file =
> > >     let ch = open_in file in
> > >     try input_line ch finally
> > >     ch#dispose
> > >
> > > where the "dispose" method that was automatically inserted at the end of
> > > the scope of the "use" binding calls "close_in" in this case to
> > > deallocate the external resource (a file handle in this case but it could
> > > be anything with a dispose method).
> >
> > What is wrong with
> >
> >    let read_first_line file =
> >      with_open_in file begin fun ch ->
> >        input_line ch
> >      end
>
> Sure. Here's the complete version using combinators as a workaround:
>
> # let try_finally x f g =
>     try
>       let f_x = f x in
>       g x;
>       f_x
>     with e ->
>       (try g x with _ -> ());
>       raise e;;
> val try_finally : 'a -> ('a -> 'b) -> ('a -> unit) -> 'b = <fun>
>
> # let with_open_in file k =
>     try_finally (open_in file) k close_in;;
> val with_open_in : string -> (in_channel -> 'a) -> 'a = <fun>
>
> # let read_first_line file =
>     with_open_in file begin fun ch ->
>       input_line ch
>     end;;
> val read_first_line : string -> string = <fun>
>
> This is almost exactly what I currently do.
>
> The "use" binding is syntactic sugar to make it shorter, clearer, more generic
> and scale better.
>
> I'd be more than happy to have anything at all added to improve this though.
> Combinators in the stdlib are certainly better than nothing and this is one
> of the most complained about noob problems (and lack of functions to read
> files)...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
>
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
http://till-varoquaux.blogspot.com/

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

[Jon Harrop]

On Monday 28 January 2008 22:05:30 Till Varoquaux wrote:
> It is worth noting that OCaml is not F#. Objects in OCaml, unlike in
> F#, are an advance feature, many users find them hard to grasp and
> work with. They also come with a rather high runtime cost. Unless we
> have a good reason to do so, I think we should avoid bolstering them
> at the very core of the standard library.

In this case, the user doesn't see anything at all of the objects.

> Don't get me wrong, I think objects have a purpose; and so have
> polymorphic variants and recursive modules but great care should be
> taken before axing the core library around them.

Absolutely. I couldn't agree more.

I would say exactly the same of working around the absence of a "try..finally" 
construct using combinators. The problem is that trivial tasks like reading 
lines from a file are made much more difficult for newbies because OCaml 
pulls in so many complicated concepts but this complexity is completely 
incidental, completely man-made. OCaml is better in the long-run, of course, 
but many languages solve these common problems much more elegantly than 
OCaml.

> We should keep complicated solutions for complicated problems.

Exactly but OCaml is moving in the opposite direction because it is a research 
project: it is getting more complicated.

The community would benefit enormously from lots of simple things like 
String.fold_right and a "try..finally" construct (I've no preference for 
those two, I'm just picking them out of hundreds of common ideas) but INRIA 
cannot afford to do such things themselves and are instead focussing on 
advanced research concepts like integrating generalized algebraic data types 
instead. That is great research, but it does not help people to use OCaml as 
a tool. Hence if the community wants this improved then they must improve it 
themselves. That means either forking OCaml or starting afresh.

> Although is is tempting to propose a solution for IO using phantom
> types, objects or whatnot, I still think the Common Lisp approach
> (using unwind_protect) is an elaborate enough one to avoid most
> problems whilst remaining simple enough to be viable.

Yes. The only difference is syntax and I think that is an important 
difference.

> A great solution in F# might not translate as well in OCaml, or it
> might not translate at all.

I was proposing that we learn from the advancements made in other languages 
rather than referring to porting F# code to OCaml code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Brian Hurt]

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

Jon Harrop wrote:

>On Monday 28 January 2008 14:23:01 you wrote:
>  
>
>>Jon Harrop wrote:
>>    
>>
>>>There are also many features that I would like to steal from other
>>>languages:
>>>
>>>. The IDisposable interface from .NET and F#'s "use" bindings.
>>>      
>>>
>>Is there a reason that Gc.finalise doesn't work?
>>    
>>
>
>Absolutely: Gc.finalise is only probabilistic whereas IDisposable is 
>deterministic. IDisposable guarantees deallocation of resources by a certain 
>point. (This is why you should never use Gc.finalise alone to manage the 
>collection of external resources!)
>
>So you write a "use" binding:
>
>  let read_first_line file =
>    use ch = open_in file in
>    input_line ch
>
>and it gets translated into:
>
>  let read_first_line file =
>    let ch = open_in file in
>    try input_line ch finally
>    ch#dispose
>  
>
What happens when I write:
    let broken file =
       use ch = open_in file in
       (fun () -> input_line ch)
?  Or some other tricky way to let ch escape the scope?

Monads strike me as being a better way to do this, but again, we're 
talking about deep changes to Ocaml.  The alternative- wait until the 
object is garbage collected, depends upon the form of the garbage collector.

Brian


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

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

[David Teller]

A few things here:
* we can provide two libraries, one with monads and one without, and let
users choose whichever they use
* it's quite easy to build a generic resource-disposal facility on par
with 'use' or 'try...finally...', even without resorting to Camlp4 -- I
leave that as an exercise to the reader or to the time when we decide to
start an OSR thread on that issue
* in any case, there's no need to change OCaml itself to do any of
these, or even to add a IDisposable interface and an object-oriented
hierarchy, only the distribution.

Let me remind you that the initial topic of the thread was to agree upon
a discussion process, not to debate on a specific issue.

So do we agree on the OSR process as I've described it or does anyone
believe we should first change it ?

Cheers,
 David

On Mon, 2008-01-28 at 11:37 -0500, Brian Hurt wrote:
> Monads strike me as being a better way to do this, but again, we're talking about deep changes to Ocaml.  The alternative- wait until the object is garbage collected, depends upon the form of the garbage collector.

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

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

[Jon Harrop]

On Monday 28 January 2008 17:30:40 David Teller wrote:
> A few things here:
> * we can provide two libraries, one with monads and one without, and let
> users choose whichever they use

Why not provide both? After all, people are suggesting pulling in lots of 
esoteric libraries like Extlib...

> * it's quite easy to build a generic resource-disposal facility on par
> with 'use' or 'try...finally...', even without resorting to Camlp4 -- I
> leave that as an exercise to the reader or to the time when we decide to
> start an OSR thread on that issue

Combinators are certainly better than nothing and easier to implement (because 
they don't touch the language) but they can't compete with syntactic sugar 
for brevity and clarity, of course.

> * in any case, there's no need to change OCaml itself to do any of
> these, or even to add a IDisposable interface and an object-oriented
> hierarchy, only the distribution.

This should be in the stdlib (I don't know if that counts as "changing 
OCaml").

> Let me remind you that the initial topic of the thread was to agree upon
> a discussion process, not to debate on a specific issue.

Agreed. We need a more appropriate forum. I think a Wiki would be a great 
breeding ground for proposals.

> So do we agree on the OSR process as I've described it or does anyone
> believe we should first change it ?

I believe it is a good idea, yes. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Gerd Stolpmann]

Am Montag, den 28.01.2008, 18:30 +0100 schrieb David Teller:
> So do we agree on the OSR process as I've described it or does anyone
> believe we should first change it ?

Well, the discussion has already taken a strange direction, and this
might have to do with ... hhmmm ... some missing guidance. We first
should make clear what we are talking about, and then there is the
question of how to come to an agreement.

First of all, I think OSR can only be about giving users more choice.
For example, there are several XML parsers, and all use a different
representation of XML. I think this is basically good, because every
representation has its pros and cons, and the users can choose among
several options. But it would be even better if all XML parsers agreed
on an _additional_ representation they share, so the user has the
additional option to use the common XML representation, which makes it
very easy to switch between several parsers (e.g. sometimes the fastest
parser is preferred, and sometimes the parser with the best error
messages). I think this is the area for a user-driven process, because
there are a lot of views on such practical problems, and the result will
profit from knowing all of them.

As it was mentioned, we cannot modify OCaml itself. We can ask here and
there for changes, e.g. when core APIs could be improved so user add-ons
have an easier life. But the OCaml language itself is only a matter of
INRIA. It is still a cathedral, not a bazaar (I don't see any change
here - except that the cathedral is now completely built). So any
discussions about changing the language (try finally) or the stdlib are
off-topic.

What we can do is to improve the infrastructure around the OCaml core.
The example of the XML parsers shows that there is a lot to do (although
these parsers might not be the most urgent question). I don't like it to
talk about things others would have to implement, so I think OSR is
mostly addressed at library/tool authors. Of course, it is important to
also hear opinions from the users of the libraries, but I think the
implementers should finally decide on what they recommend. We should
avoid to set standards that are ignored.

As an example of OSR, there is the I/O channels effort:
http://www.ocaml-programming.de/rec/IO-Classes.html

This is basically an agreement between library implementers. As there
were only 3 parties involved, it was a good and fruitful debate, and I
think the result is convincing. Most importantly, the recommendation was
implemented, and the users have finally more options. E.g. they can now
transform a Camomile channel by an OCamlnet channel filter.

Of course, OSR could also be about new libraries, but I think this is
less important. Everybody can create a new library anyway, so there
might be no point in discussing that.

What I don't like to discuss is everything in the "what is good style"
area. This is fruitless, because there are real reasons for preferring
different coding styles to solve different problems, and discussing that
will only lead to flame wars.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

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

[Jon Harrop]

On Monday 28 January 2008 21:12:08 Gerd Stolpmann wrote:
> As it was mentioned, we cannot modify OCaml itself. We can ask here and
> there for changes, e.g. when core APIs could be improved so user add-ons
> have an easier life. But the OCaml language itself is only a matter of
> INRIA. It is still a cathedral, not a bazaar (I don't see any change
> here - except that the cathedral is now completely built). So any
> discussions about changing the language (try finally) or the stdlib are
> off-topic.

Can we clear up once and for all whether or not we can improve the stdlib?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Edgar Friendly]

Jon Harrop wrote:
> On Monday 28 January 2008 21:12:08 Gerd Stolpmann wrote:
>> As it was mentioned, we cannot modify OCaml itself. We can ask here and
>> there for changes, e.g. when core APIs could be improved so user add-ons
>> have an easier life. But the OCaml language itself is only a matter of
>> INRIA. It is still a cathedral, not a bazaar (I don't see any change
>> here - except that the cathedral is now completely built). So any
>> discussions about changing the language (try finally) or the stdlib are
>> off-topic.
> 
> Can we clear up once and for all whether or not we can improve the stdlib?
> 

I wish I could answer your question authoritatively.  The best I can
tell from the situation comes to this:

1) The community now has some permission to make a distribution out of
the OCaml code created at INRIA.

2) This distribution should (Must?) not break backwards compatibility
with the currently official, INRIA-blessed distro.

The way I interpret these two gives me/us limited ability to improve the
stdlib.  One question for the community involves both directions of
migration.  #2 insists that INRIA-OCaml programs have the same semantics
(including triggering the same warts of the language) under
Community-OCaml.  i.e. taking a program compiled under INRIA-OCaml and
compiling it under Community-OCaml should "just work".  The reverse --
going from Community-OCaml to INRIA-OCaml -- isn't guaranteed to work in
the same way, *but* the question comes: how much work must the user
spend to translate from Community-OCaml to INRIA-OCaml.

Messing with the type system has many pitfalls, but not least of which
comes a (likely) very difficult conversion to INRIA-OCaml involving
probably complex source-code transformation.

Many people seem to put forward improvement ideas for OCaml that stay
within the realm of including more libraries in the Community-OCaml
distribution, and having efforts to standardize interfaces of these
libraries.  This kind of change seems to have minimal conversion
difficulty to INRIA-OCaml (just install the needed libraries).

In between these extremes sits things like changes to the stdlib and
extensions to the language.  I hope that we can make changes to both of
these.  stdlib changes should only extend the current library (in my
mind this includes changing implementations of existing functions, as
long as the semantics stay identical), but to ease compatibility with
the INRIA-OCaml system, (some of) these changes could get implemented in
such a way that with a small amount of additional work (opening a
"Community.Pervasives" module that includes the new changes).

Changes to the compiler such as try..finally could get put in to the
community distro, but with a "close-enough" camlp4 filter to transform
programs using them into programs that would work under the current
system.  (maybe not as efficiently, maybe with horrible error messages)

E.

Re: [OSR] OCaml Standard Recommandation Process

[Sylvain Le Gall]

On 29-01-2008, Edgar Friendly <thelema314@gmail.com> wrote:
> Jon Harrop wrote:
>> On Monday 28 January 2008 21:12:08 Gerd Stolpmann wrote:
>>> As it was mentioned, we cannot modify OCaml itself. We can ask here and
>>> there for changes, e.g. when core APIs could be improved so user add-ons
>>> have an easier life. But the OCaml language itself is only a matter of
>>> INRIA. It is still a cathedral, not a bazaar (I don't see any change
>>> here - except that the cathedral is now completely built). So any
>>> discussions about changing the language (try finally) or the stdlib are
>>> off-topic.
>> 
>> Can we clear up once and for all whether or not we can improve the stdlib?
>> 
>
> I wish I could answer your question authoritatively.  The best I can
> tell from the situation comes to this:
>
> 1) The community now has some permission to make a distribution out of
> the OCaml code created at INRIA.
>
> 2) This distribution should (Must?) not break backwards compatibility
> with the currently official, INRIA-blessed distro.
>
> The way I interpret these two gives me/us limited ability to improve the
> stdlib.  One question for the community involves both directions of
> migration.  #2 insists that INRIA-OCaml programs have the same semantics
> (including triggering the same warts of the language) under
> Community-OCaml.  i.e. taking a program compiled under INRIA-OCaml and
> compiling it under Community-OCaml should "just work".  The reverse --
> going from Community-OCaml to INRIA-OCaml -- isn't guaranteed to work in
> the same way, *but* the question comes: how much work must the user
> spend to translate from Community-OCaml to INRIA-OCaml.

[...]

I am not sure that i understand you. "Community distribution" should
just be "INRIA-Ocaml" + some others libraries. I am really not sure that
anyone talk about anything else. In other word, what have been talked
about is that ocaml INRIA distribution will stay as is, but people can
take it to put it into the center of a larger distribution.

If i read you well, you are thinking that we can change things inside
ocaml INRIA distribution. That is not true. And anyway, if such a thing
should happen, you will see a change in INRIA license, that will permit
you to do so. For now, this is not the case.

Sorry if i didn't catch your point.

Regards,
Sylvain Le Gall

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

[Jon Harrop]

On Wednesday 30 January 2008 08:52:08 Sylvain Le Gall wrote:
> I am not sure that i understand you. "Community distribution" should
> just be "INRIA-Ocaml" + some others libraries.

That is the current situation.

> I am really not sure that anyone talk about anything else.

Several people (including me) have been talking about other ideas because we 
can't fix OCaml without leaving that model.

> In other word, what have been talked about is that ocaml INRIA distribution
> will stay as is, but people can take it to put it into the center of a
> larger distribution. 

That is the current situation. The problem is that INRIA's core OCaml 
distribution has many issues that we could address. To address them, we must 
create a new upstream that the community can maintain.

> If i read you well, you are thinking that we can change things inside
> ocaml INRIA distribution. That is not true.

Which is why forking is our only option.

> And anyway, if such a thing should happen, you will see a change in INRIA
> license, that will permit you to do so. For now, this is not the case.

INRIA cannot accept our contributions.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

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

[Vincent Hanquez]

On Wed, Jan 30, 2008 at 08:52:08AM +0000, Sylvain Le Gall wrote:
> I am not sure that i understand you. "Community distribution" should
> just be "INRIA-Ocaml" + some others libraries. I am really not sure that
> anyone talk about anything else. In other word, what have been talked
> about is that ocaml INRIA distribution will stay as is, but people can
> take it to put it into the center of a larger distribution.
> 
> If i read you well, you are thinking that we can change things inside
> ocaml INRIA distribution. That is not true. And anyway, if such a thing
> should happen, you will see a change in INRIA license, that will permit
> you to do so. For now, this is not the case.

to which license are you refering to here ?
most of the thing i've just look into ocaml-3.10 stdlib are LGPL.

-- 
Vincent Hanquez

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

[Dario Teixeira]

> What we can do is to improve the infrastructure around the OCaml core.
> The example of the XML parsers shows that there is a lot to do (although
> these parsers might not be the most urgent question). I don't like it to
> talk about things others would have to implement, so I think OSR is
> mostly addressed at library/tool authors. Of course, it is important to
> also hear opinions from the users of the libraries, but I think the
> implementers should finally decide on what they recommend. We should
> avoid to set standards that are ignored.

Hi,

Another example that is probably so obvious that it almost doesn't need
mentioning is the incompatibility of the lexer interface between ulex
and Ocamlyacc/Menhir.  Either we define a common lexer interface that
everyone can migrate to, or at least Ocamlyacc and Menhir could adopt
Dypgen's solution and allow the user to specify the lexer's signature.
The current situation is just absurd.

Cheers,
Dario



      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

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

[Francois Pottier]

Hello,

On Mon, Jan 28, 2008 at 09:43:55PM +0000, Dario Teixeira wrote:
> Another example that is probably so obvious that it almost doesn't need
> mentioning is the incompatibility of the lexer interface between ulex
> and Ocamlyacc/Menhir.

It would be possible for menhir to follow dypgen and allow the parser to
be parameterized over a lexer signature. I'll add that to the todo list.

In the meantime, another possibility would be to write a stub function that
makes ulex (or whatever lexer you are using) artificially look like an
ocamllex lexer. If I am not mistaken, all that is needed is to provide a
function of type Lexing.lexbuf -> token, which must update the fields
lex_start_p and lex_curr_p as a side effect.

-- 
François Pottier
Francois.Pottier@inria.fr
http://cristal.inria.fr/~fpottier/

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

[Arnaud Spiwack]

>
> Monads strike me as being a better way to do this, but again, we're 
> talking about deep changes to Ocaml. 
Monads are no more than a pair of functions (there are four in Haskell 
presentation of these, but two of them can be defined automatically). 
They not only exist by essence, but there also is a camlp4 extension 
(rather short actually) which gives them a nice notation looking :
perform
  p <-- e;
  q <-- f;
  return a


You can specify a module name after the "perform" keyword when using 
several monads. This camlp4 extension is pa_monad (authored by Oleg 
Kiselyov, Lydia E. van Dijk, and Jacques Carette), it works both with 
camlp4 3.10 and previous version by the way (plus camlp5 I guess).

Actually, there are a couple of developpement that use monads : Jérôme 
Vouillon's Lwt (lightweight, monadic, cooperative threads) are a monad. 
On a more personnal note, my current developpement (somewhere deep 
inside the code of the proof assistant Coq) uses a monad as well.

The downside is that sometimes monad might be slower than other 
approaches (there are more closure built than necessary). At least in 
the current runtime and compiler.

But I guess we're going (again) off topic... We probably have to start 
having wiki discussions ;) .



Arnaud Spiwack

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

[Michaël Grünewald]

David Teller <David.Teller@univ-orleans.fr> writes:

>     Dear list,
>
>  As I have mentioned in my previous message, during the OCaml Developer
> Days, the INRIA team has made clear that, among other things, the
> community is essentially in charge of recommending best practices,
> standards, etc. A candidate name has been suggested: "OSR", for "OCaml
> Standard Recommandations."
>
> While we already have a few tools for this kind of discussions, (I'm
> thinking about the current mailing-list and the Cocan Wiki), at the
> moment, we are lacking organisation and a way of committing to a
> decision.
>
> Let me suggest the following process:
> * anyone on this mailing-list may ask for or suggest best practises --
> to do so, please put [OSR] in the header of your e-mail
> * after some debate, if one or more solutions have emerged, we put these
> solutions on the appropriate page of the Cocan Wiki, with summaries of
> pros and cons and an official space for voting and suggesting future
> improvements
> * if the vote proves conclusive, we move the chosen solution from the
> voting stage to some page on that Wiki, say "recommended practises."
>
> Does this seem an acceptable method ?

The method seems acceptable.

It could be very stimulating to arrange a weekly appointment on the
IRC (or anything else), perspectives and projects could born thanks to
the spontaneity of this communication medium.

It could also turn out useful to give volunteers to list themselves
somewhere, so that people having a project can look there to find a
helping hand.
-- 
Michaël

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

[Dario Teixeira]

Hallo,

>  As I have mentioned in my previous message, during the OCaml Developer
> Days, the INRIA team has made clear that, among other things, the
> community is essentially in charge of recommending best practices,
> standards, etc. A candidate name has been suggested: "OSR", for "OCaml
> Standard Recommandations."

I'm looking forward to hearing more about the results from yesterday's
meeting (are there minutes?).  In any case, the OSR seems like a very
reasonable process.

I'll start with one thorn: the Unicode situation.  Everyone plus their
mother defines some custom Unicode module.  ExtLib has one, Camomile
has obviously a few, Ocamlnet has its own thing, etc, etc.  It would make
sense to have instead a fairly simple "Unicode" package that defined the
basic data type, and then have all these libs use that one.  I bet this
was discussed yesterday -- what was the conclusion?

Cheers,
Dario Teixeira



      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

Re: [OSR] OCaml Standard Recommandation Process

[Sylvain Le Gall]

On 27-01-2008, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> Hallo,
>
>>  As I have mentioned in my previous message, during the OCaml Developer
>> Days, the INRIA team has made clear that, among other things, the
>> community is essentially in charge of recommending best practices,
>> standards, etc. A candidate name has been suggested: "OSR", for "OCaml
>> Standard Recommandations."
>
> I'm looking forward to hearing more about the results from yesterday's
> meeting (are there minutes?).  In any case, the OSR seems like a very
> reasonable process.
>
> I'll start with one thorn: the Unicode situation.  Everyone plus their
> mother defines some custom Unicode module.  ExtLib has one, Camomile
> has obviously a few, Ocamlnet has its own thing, etc, etc.  It would make
> sense to have instead a fairly simple "Unicode" package that defined the
> basic data type, and then have all these libs use that one.  I bet this
> was discussed yesterday -- what was the conclusion?
>

You can already read every presentations on the website (.pdf and .odp).
At one time in the future, i will also put the video of every talks
somewhere (YouTube?) and a link on the wiki page. 

http://wiki.cocan.org/events/europe/ocamlmeetingparis2008

Regards,
Sylvain Le Gall

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

[David Teller]

On Mon, 2008-01-28 at 13:38 +0000, Sylvain Le Gall wrote:
>   It would make
> > sense to have instead a fairly simple "Unicode" package that defined the
> > basic data type, and then have all these libs use that one.  I bet this
> > was discussed yesterday -- what was the conclusion?
> >

The conclusion was essentially "let's create an OCaml Standard
Recommendation Process and discuss Unicode as part of that process" :)

Cheers,
 David

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

[Oliver Bandel]

Hello,


Zitat von David Teller <David.Teller@univ-orleans.fr>:

>     Dear list,
>
>  As I have mentioned in my previous message, during the OCaml
> Developer
> Days, the INRIA team has made clear that, among other things, the
> community is essentially in charge of recommending best practices,
> standards, etc. A candidate name has been suggested: "OSR", for
> "OCaml
> Standard Recommandations."
[...]

What does that mean?
What means "best practices" here?
I think it will be more than just recommendation
of best code-indentation / coding rules-/Style.

Possibly things like how to do the best way in
e.g. paketizing things? (CPAN-like, I remember
perl -MCPAN ... which IMHO is one of Perl's plus's.)




>
> While we already have a few tools for this kind of discussions, (I'm
> thinking about the current mailing-list and the Cocan Wiki), at the
> moment, we are lacking organisation and a way of committing to a
> decision.


...hmhhh...
can please elaborate more on the above stuff?

Thanks,
    Oliver

Re: [OSR] OCaml Standard Recommandation Process

[Sylvain Le Gall]

On 27-01-2008, David Teller <David.Teller@univ-orleans.fr> wrote:
> Does this seem an acceptable method ?
>

Yes, but we should add some more rules:
* designate 1 person that will sync discussion and OSR on the wiki
(maybe the one who start the thread)
* limit the time of disscussion (1 month)
* limit the time of vote (1 week)

If the time limit is reached, the current text (as sync by the person in
charge on the wiki) is put on vote:
<mail that should be sent>
Subject: [OSR] XML processing --
Read the OSR: http://wiki.cocan.org/osr/XMLProcessing. 

Choice:
[ ] Accept the OSR
[ ] Further discussion

Please classify this choices (you should put 1 to the best choice). 
</mail that should be sent>

We should find a way to allow only one vote per person.

After one week of voting, choices are classified (Methode Condorcet) and
the best choice win.

If the choice is "Further discussion", the discussion should last
another month.

This way, you prevent endless discussion (non converging one) by a final
decision after one month.

Regards,
Sylvain Le Gall

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

[blue storm]

> Yes, but we should add some more rules:
> * designate 1 person that will sync discussion and OSR on the wiki
> (maybe the one who start the thread)
> * limit the time of disscussion (1 month)
> * limit the time of vote (1 week)
>
> If the time limit is reached, the current text (as sync by the person in
> charge on the wiki) is put on vote:
> <mail that should be sent>
> Subject: [OSR] XML processing --
> Read the OSR: http://wiki.cocan.org/osr/XMLProcessing.
>
> Choice:
> [ ] Accept the OSR
> [ ] Further discussion
>
> Please classify this choices (you should put 1 to the best choice).
> </mail that should be sent>
>
> We should find a way to allow only one vote per person.
>
> After one week of voting, choices are classified (Methode Condorcet) and
> the best choice win.
>
> If the choice is "Further discussion", the discussion should last
> another month.
>
> This way, you prevent endless discussion (non converging one) by a final
> decision after one month.
>
> Regards,
> Sylvain Le Gall

I'm sorry, but this seems far too complicated to me.
You jokingly admitted that Debian people tend to have "bureaucratic"
methods. Now i can see what you mean :)

I'm not fond of the "let's vote" idea. I think most discussions can be
sorted out by reaching a consensus, wich is a vaguely defined idea,
but works very well in practice.

1) We have seen no need for such a "political" structure for now. What
are you trying to fix with such a method ?
The only real thing we have now is the I/O specification (
http://www.ocaml-programming.de/rec/IO-Classes.html ), wich are real,
emerged from developpers discussion, and certainly didn't required a
"community" voting process.

2) I can see problems in your "constitution" draft. To fix them you'd
have to add even more bureaucratic definitions.

As an example : who vote ? Anybody ? "Registered members" ?
In the XML standardization effort, who would vote ? How could someone
who never use XML vote, and have the same "power" than a ocaml XML
library developper ? This is nonsense. You could restrict the voting
process to the XML developpers only, but then you'd have other
problems (and XML libs users ? etc.).

Do we really need to vote ? I don't think so. I even think that
putting such rigid rules too early could harm the process : a vote
that is perceived as meaningless by most (and each time you've got
more than two choices, there is a chance that the majority disagree
with the result) is worse than no vote at all : you've got a
meaningless "standard".

I suggest we keep to the simple principles that have worked well in
other projects, for a very long time :
- try to resolve problems by consensus, not vote (although vote in
specific situations is of course possible)
- generally, let those who do the work decide. If one disagrees, he
can works up a better solution, instead of starting an endless
"policital" debate.

As you said earlier :
> That is "keep it simple and stupide" (KISS)! That is great, easy and direct.
> I like it.

Re: [OSR] OCaml Standard Recommandation Process

[Sylvain Le Gall]

On 30-01-2008, blue storm <bluestorm.dylc@gmail.com> wrote:
>> Yes, but we should add some more rules:
>> * designate 1 person that will sync discussion and OSR on the wiki
>> (maybe the one who start the thread)
>> * limit the time of disscussion (1 month)
>> * limit the time of vote (1 week)
>>
>> If the time limit is reached, the current text (as sync by the person in
>> charge on the wiki) is put on vote:
>> <mail that should be sent>
>> Subject: [OSR] XML processing --
>> Read the OSR: http://wiki.cocan.org/osr/XMLProcessing.
>>
>> Choice:
>> [ ] Accept the OSR
>> [ ] Further discussion
>>
>> Please classify this choices (you should put 1 to the best choice).
>> </mail that should be sent>
>>
>> We should find a way to allow only one vote per person.
>>
>> After one week of voting, choices are classified (Methode Condorcet) and
>> the best choice win.
>>
>> If the choice is "Further discussion", the discussion should last
>> another month.
>>
>> This way, you prevent endless discussion (non converging one) by a final
>> decision after one month.
>>
>> Regards,
>> Sylvain Le Gall
>
> I'm sorry, but this seems far too complicated to me.
> You jokingly admitted that Debian people tend to have "bureaucratic"
> methods. Now i can see what you mean :)
>
> I'm not fond of the "let's vote" idea. I think most discussions can be
> sorted out by reaching a consensus, wich is a vaguely defined idea,
> but works very well in practice.
>

The draft (ideas) i send is almost a copy of the Debian way of doing...
I am caught ;-)

This is just a suggestion. I am only afraid that some point of view
never converge, and i don't like the idea of things being blocked by a
minority (in particular some people tends to post more than necessary --
just as me today, but they are not representative to the real
problem...)

Regards,
Sylvain Le Gall

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

[Eric Cooper]

On Wed, Jan 30, 2008 at 08:49:49PM +0000, Sylvain Le Gall wrote:
> On 30-01-2008, blue storm <bluestorm.dylc@gmail.com> wrote:
> > I'm not fond of the "let's vote" idea. I think most discussions can be
> > sorted out by reaching a consensus, wich is a vaguely defined idea,
> > but works very well in practice.
> [...] 
> This is just a suggestion. I am only afraid that some point of view
> never converge, and i don't like the idea of things being blocked by a
> minority (in particular some people tends to post more than necessary --
> just as me today, but they are not representative to the real
> problem...)

I like the old Internet Engineering Task Force motto:
    "We believe in rough consensus and working code".

-- 
Eric Cooper             e c c @ c m u . e d u