ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[David T. <Dav...@un...>]

On Mon, 2008-05-19 at 08:59 +0200, blue storm wrote:
> > 2) For [Option.enum], it's not a big deal, just a matter of
> > uniformisation wrt other containers. I consider also adding [iter] and
> > [filter].
> 
> Enum already have iter and filter. As it is supposed to provide a
> common layer for those kinds of operation, i'm not sure iter and
> filter are that useful. An of_enum would be useful, though (is it ok
> for those function not to be one to one mapping ?).

I'm willing to write [of_enum], if people consider it interesting.
What should it do if there is more than one element in the enumeration ?
Raise an error or just consume the first element ?

> >> What's the use case for Option.enum?
> 
> For example, if you have an enumeration of options, and you want to
> "flatten" it into an enumeration of the base type (you're not
> interested in the failure cases) :
>   Enum.concat (Enum.map Option.enum your_option_enum)

As usual, you have a point.

> Speaking of the Option module, I have a suggestion for a monadic
> "bind" function (a celebrity in the Haskell world, would imho be
> useful in OCaml too) :
[...]

If we have to write a bind, I'd keep it consistent with other
OCaml-based binds, i.e. in the same order as Haskell.

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. 

[Ocaml-lib-devel] Halle Berry bares it all again

[Klusek <rit...@3a...>]

Your lady will be dying to go to bed with you every night http://www.liaberan.com/

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[Amit D. <ad...@du...>]

Hi,

I think the original idea behind ExtLib is that functions are either
highly used and small or fairly commonly used and complicated.  I
think some people were using it for embedded applications, and are
worried about code bloat.

get_exn is fairly simple, and as Option.get already returns the fairly
general Not_found exception, my impression is that it won't be highly
used.

That said, there are cases where a new function with a different
exception might be handy.  E.g. Invalid_argument in array's returning
the index number which caused the problem...

-Amit

On Mon, May 19, 2008 at 10:43 AM, Richard Jones <ri...@an...> wrote:
> On Sun, May 18, 2008 at 11:28:08PM +0300, Janne Hellsten wrote:
>> What kind of example uses did you have in mind for the Option additions?
>>
>> Not sure if I agree that get_exn is too useful an addition.
>
> I disagree: I think that as long as additional functions maintain a
> consistent style with the rest of the library, are working, documented
> and useful to someone, and don't consume any more "module namespace",
> then there shouldn't be any barrier to adding them.
>
> In this case I have no problem with David's additional functions, the
> patches are fine[1], and I would be inclined to add them.
>
> Rich.
>
> [1] David: please always post unified diffs as in your second email,
> not tarballs as in the first.
>
> --
> Richard Jones
> Red Hat
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
>

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[Richard J. <ri...@an...>]

On Sun, May 18, 2008 at 11:28:08PM +0300, Janne Hellsten wrote:
> What kind of example uses did you have in mind for the Option additions?
> 
> Not sure if I agree that get_exn is too useful an addition.

I disagree: I think that as long as additional functions maintain a
consistent style with the rest of the library, are working, documented
and useful to someone, and don't consume any more "module namespace",
then there shouldn't be any barrier to adding them.

In this case I have no problem with David's additional functions, the
patches are fine[1], and I would be inclined to add them.

Rich.

[1] David: please always post unified diffs as in your second email,
not tarballs as in the first.

-- 
Richard Jones
Red Hat

[Ocaml-lib-devel] Give her a climax every night

[baris <unw...@GO...>]

Find out the secret that porn stars use to make themselves humongous. http://www.stimirks.com/

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[blue s. <blu...@gm...>]

Sorry, silly mistake :
   fun b' -> Some (a' + b')

On 5/19/08, blue storm <blu...@gm...> wrote:
>> 2) For [Option.enum], it's not a big deal, just a matter of
>> uniformisation wrt other containers. I consider also adding [iter] and
>> [filter].
>
> Enum already have iter and filter. As it is supposed to provide a
> common layer for those kinds of operation, i'm not sure iter and
> filter are that useful. An of_enum would be useful, though (is it ok
> for those function not to be one to one mapping ?).
>
>>> What's the use case for Option.enum?
>
> For example, if you have an enumeration of options, and you want to
> "flatten" it into an enumeration of the base type (you're not
> interested in the failure cases) :
>   Enum.concat (Enum.map Option.enum your_option_enum)
>
>
>
> Speaking of the Option module, I have a suggestion for a monadic
> "bind" function (a celebrity in the Haskell world, would imho be
> useful in OCaml too) :
>
>   let bind f = function
>           | None -> None
>           | Some v -> f v
> (patches against .ml and .mli attached)
>
> It looks very much like map, except that the given function decides
> wether the result is a failure or a success.
>
> A typical use case would be the evaluation of an arithmetic AST (eg. a
> Sum data type), with an "eval" function that can fail, and thus
> returns an int option :
>
> let rec eval : ast -> int option = function
> | Num n -> Some n
> | ...
> | Sum (a, b) -> Option.bind (fun a' -> Option.bind (fun b' -> a' + b')
> (eval b)) (eval a)
>
> Option.bind allows one to compose possibly-failing operations.
>
> The parameters order (first the function, then the option) was choosen
> to be coherent with the other functions of the Option module.
> Haskellers are more used to the reverse order of the >>= operator (an
> infix version of bind), with the option first, allowing for a more
> natural style :
> eval a >>= fun a' -> eval b >>= fun b' -> a' + b'
>
> I think keeping the old order is a good compromise for now (moreover,
> the type is more elegant with the function first). If you're
> interested in the >>= syntaxic sugar too, i'd be happy to provide such
> an infix operator with reversed parameters.
>

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[blue s. <blu...@gm...>]

> 2) For [Option.enum], it's not a big deal, just a matter of
> uniformisation wrt other containers. I consider also adding [iter] and
> [filter].

Enum already have iter and filter. As it is supposed to provide a
common layer for those kinds of operation, i'm not sure iter and
filter are that useful. An of_enum would be useful, though (is it ok
for those function not to be one to one mapping ?).

>> What's the use case for Option.enum?

For example, if you have an enumeration of options, and you want to
"flatten" it into an enumeration of the base type (you're not
interested in the failure cases) :
  Enum.concat (Enum.map Option.enum your_option_enum)



Speaking of the Option module, I have a suggestion for a monadic
"bind" function (a celebrity in the Haskell world, would imho be
useful in OCaml too) :

  let bind f = function
          | None -> None
          | Some v -> f v
(patches against .ml and .mli attached)

It looks very much like map, except that the given function decides
wether the result is a failure or a success.

A typical use case would be the evaluation of an arithmetic AST (eg. a
Sum data type), with an "eval" function that can fail, and thus
returns an int option :

let rec eval : ast -> int option = function
| Num n -> Some n
| ...
| Sum (a, b) -> Option.bind (fun a' -> Option.bind (fun b' -> a' + b')
(eval b)) (eval a)

Option.bind allows one to compose possibly-failing operations.

The parameters order (first the function, then the option) was choosen
to be coherent with the other functions of the Option module.
Haskellers are more used to the reverse order of the >>= operator (an
infix version of bind), with the option first, allowing for a more
natural style :
eval a >>= fun a' -> eval b >>= fun b' -> a' + b'

I think keeping the old order is a good compromise for now (moreover,
the type is more elegant with the function first). If you're
interested in the >>= syntaxic sugar too, i'd be happy to provide such
an infix operator with reversed parameters.

Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[David T. <Dav...@un...>]

   Hi,

1) For [get_exn], I reason that, with ExtLib's conventions, when writing
a module for a new data structure, one often has to write two functions:
* some_kind_of_get : 'a t -> 'a option
* some_kind_of_get': 'a t -> 'a (**raises [ThisModule.NotFound] *)

Having [Option.get_exn] makes it possible to write the second function
from the first one as a (real) one-liner.

2) For [Option.enum], it's not a big deal, just a matter of
uniformisation wrt other containers. I consider also adding [iter] and
[filter].

Cheers,
 David


On Sun, 2008-05-18 at 23:28 +0300, Janne Hellsten wrote:
> Hi David,
> 
> What kind of example uses did you have in mind for the Option
> additions?
> 
> Not sure if I agree that get_exn is too useful an addition.  If
> Not_found for the (often erroneous) case of (Option.get None) is not
> generic enough, couldn't you just match the option and throw the
> exception yourself:
> 
> match o with None -> raise your_exception | Some f -> f
> 
> What's the use case for Option.enum?
> 
> Janne

-- 
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: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[Janne H. <jjh...@gm...>]

Hi David,

What kind of example uses did you have in mind for the Option additions?

Not sure if I agree that get_exn is too useful an addition.  If Not_found
for the (often erroneous) case of (Option.get None) is not generic enough,
couldn't you just match the option and throw the exception yourself:

match o with None -> raise your_exception | Some f -> f

What's the use case for Option.enum?

Janne

On Sun, May 18, 2008 at 9:29 PM, David Teller <Dav...@un...>
wrote:

>     Hi,
>
>  I've tried to send a patch a few weeks ago but, for some reason, it
> seems that this patch never reached the mailing-list.
>
>  I'm trying again to send a first patch. This patch involves
> * addition of two functions to module [Option]: [enum] (which allows
> enumerating the contents of an [Option.t]) and [get_exn] (a
> generalisation of [get])
> * two new modules, [LazyList] and [LazyListLabels], for Haskell-style
> lazy lists.
>
> I hope that the patch will reach you, this time. I'm waiting for
> feedback before contributing an improved [Enum] and a number of other
> modules.
>
> 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.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
>
>

[Ocaml-lib-devel] [Batteries] Fixed patch

[David T. <Dav...@un...>]

   Oops,

 Got the wrong files for module option. While my previous post remains
correct, two files were full sources where they should have been unified
diffs. I attach the correct files.

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. 

[Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[David T. <Dav...@un...>]

     Hi,

 I've tried to send a patch a few weeks ago but, for some reason, it
seems that this patch never reached the mailing-list.

 I'm trying again to send a first patch. This patch involves
* addition of two functions to module [Option]: [enum] (which allows
enumerating the contents of an [Option.t]) and [get_exn] (a
generalisation of [get])
* two new modules, [LazyList] and [LazyListLabels], for Haskell-style
lazy lists.

I hope that the patch will reach you, this time. I'm waiting for
feedback before contributing an improved [Enum] and a number of other
modules.

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. 

[Ocaml-lib-devel] Studies have shown that herbal express work 90%

[Borna <Bor...@Si...>]

Show her the true man that you are with herbal express medications http://www.makebiggs.com/

Re: [Ocaml-lib-devel] [ExtLib] Getting ready for a second contribution

[Erik de C. L. <mle...@me...>]

David Teller wrote:

> Let me rephrase: I'm waiting for some feedback on either my planned list
> of contributions or my previous submission. I have no clue if my plans
> are acceptable, if the size of my module is convenient, or the
> formatting of comments, or anything else, for that matter.

Having submitted hundreds of things to dozens of projects my advice
is to start small. Small submissions are the easiest for the receiver
to digest and comment on. A couple of small submissions that go into
the code base will ease the way for larger and more complex subissions
often leading to eventual CVS/SVN/whatever commit rights.

Large submissions that from untrusted sources (ie you haven't contributed
something of worth before) are rarely accepted by any open source
project.

HTH,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Religious moderation, insofar as it represents an attempt to hold on to
what is still serviceable in orthodox religion, closes the door to more
sophisticated approaches to spirituality, ethics, and the building of
strong communities.
Religious moderates seem to believe that what we need is not radical
insight and innovation in these areas but a mere dilution of Iron Age
philosophy." -- Sam Harris

[Ocaml-lib-devel] The shock in her eyes

[Ismail <ala...@19...>]

We go to great lengths to show you the best in male nutrition http://www.niroaoop.com/

Re: [Ocaml-lib-devel] [ExtLib] Getting ready for a second contribution

[David T. <Dav...@un...>]

Let me rephrase: I'm waiting for some feedback on either my planned list
of contributions or my previous submission. I have no clue if my plans
are acceptable, if the size of my module is convenient, or the
formatting of comments, or anything else, for that matter.

Cheers,
 David

On Wed, 2008-05-14 at 20:44 +0100, Richard Jones wrote:
> On Wed, May 14, 2008 at 09:41:12PM +0200, David Teller wrote:
> >  I have a second contribution ready for submission. I'm waiting for a
> > greenlight from you.
> 
> [??]
> 
> Feel free to post patches whenever you want.
> 
> Rich.
> 
-- 
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: [Ocaml-lib-devel] [ExtLib] Getting ready for a second contribution

[Richard J. <ri...@an...>]

On Wed, May 14, 2008 at 09:41:12PM +0200, David Teller wrote:
>  I have a second contribution ready for submission. I'm waiting for a
> greenlight from you.

[??]

Feel free to post patches whenever you want.

Rich.

-- 
Richard Jones
Red Hat

[Ocaml-lib-devel] [ExtLib] Getting ready for a second contribution

[David T. <Dav...@un...>]

   Hi,

 I have a second contribution ready for submission. I'm waiting for a
greenlight from you. It's an improvement to Enum, and, if you're
curious, it's available as a preview release here [1]. 

Cheers,
 David

[1]
http://forge.ocamlcore.org/frs/download.php/17/enum_replacement_0_1_1.tgz 

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

[Ocaml-lib-devel] Waste no further time

[shalisha <rom...@4i...>]

Never understood why you have such bad luck with ladies, the secret is here http://www.pighebar.com/

Re: [Ocaml-lib-devel] ExtLib/Camomile UTF8

[Richard J. <ri...@an...>]

On Mon, May 05, 2008 at 11:55:08AM +0200, Berke Durak wrote:
> As it's actually a patch against Camomile, (at the time I didn't know at the
> time that UTF8 was taken from Camomile),
> Richard Jones suggested that this is where the patch should go.

Yup, I think this should go into Camomile, and the UTF8 module should
be dropped from Extlib.

It's an unnecessary pain keeping two modules with the same name in
synch ... and if it is needed at all, then it is something which
should be done by the distributions.

Rich.

-- 
Richard Jones
Red Hat

[Ocaml-lib-devel] Grown your organ into a monster

[Jaron <Jar...@AR...>]

Get any chick you ever wanted with your brand new pecker http://www.mivaete.com/

[Ocaml-lib-devel] No side effects, express herbals do work

[Djura <roe...@BT...>]

Your long hard machine is set to become longer and harder http://www.nuruusie.com/

[Ocaml-lib-devel] [ExtLib] Design of Enum.init ?

[David T. <Dav...@un...>]

   Hi,

 I'm currently reviewing my code before sending in a second contribution
(this time, a patch to Enum) and I'm a bit puzzled by Enum.init . With
current implementation, creating a clone of an enumeration created with
[Enum.init n f] is the same thing as calling [Enum.init n f] again. In
particular, if one is to iter through both enumerations, [f 0] will be
invoked both by the original and by the clone, [f 1] will be invoked
both by the original and by the clone, etc.

For instance
(*start of example*)
let print e = Enum.iter (Printf.printf "%i; ") e;;
let f x = Printf.printf "\n\t(Evaluating %i)\n" x; x;;
let test_1 = Enum.init 5 f;;
let test_2 = Enum.clone test_1;;

# print test_1;;
        (Evaluating 0)
0; 
        (Evaluating 1)
1; 
        (Evaluating 2)
2; 
        (Evaluating 3)
3; 
        (Evaluating 4)
4; 

# print test_2;;
        (Evaluating 0)
0; 
        (Evaluating 1)
1; 
        (Evaluating 2)
2; 
        (Evaluating 3)
3; 
        (Evaluating 4)
4; 
(*end of example*)

I find this strange and inconsistent with the cloning of enumerations
created with [from] or forced. Now, it's rather easy to fix this but I'm
wondering if this behaviour is a bug or by design.

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. 

[Ocaml-lib-devel] Make her worship you

[Lakamsani <met...@Vi...>]

Double your girth and add more inches to your length easily with new herbal http://www.sverahe.com/

Re: [Ocaml-lib-devel] Batteries Included

[Richard J. <ri...@an...>]

On Tue, May 06, 2008 at 11:34:29PM +0200, David Teller wrote:
> By the way, what's the preferred way for submitting patches ?

To extlib?  As unified diffs sent to the mailing list.

If you can split it into reviewable chunks, that helps.

Rich.

-- 
Richard Jones
Red Hat

Re: [Ocaml-lib-devel] Batteries Included

[David T. <Dav...@un...>]

By the way, what's the preferred way for submitting patches ?

Cheers,
 David

On Fri, 2008-05-02 at 15:57 +0200, David Teller wrote:
> Ok, as you prefer.

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