[Caml-list] Caml Development Kit

[Caml-list] Caml Development Kit

[Fabrice Le Fessant]

A few weeks ago, we started a project called "Caml Development Kit" or
CDK, which would gather in one big tarball or RPM several tools and
libraries, useful for Ocaml programming. 

For example, the CDK will include Ocaml, Camlp4, ledit, and many
user-contributed libraries. A new CDK will be released at each Ocaml
release (and probably more often from CVS sources), removing the need
to update, compile and install many different packages everytime to
have a coherent development envirronment.

If you are interested in contributing to this project, you can either
send me your code, or an URL where we can download your contribution.

We are particularly interested in general modules, providing useful
data structures, network(urlget,http_server,etc)/ crypto(des)/
multimedia(images) functions, or bindings to C libraries. 

The package includes a simple tool to generate HTML from .mli files.
Thus, contributions must provide .mli files for all interesting
modules, and these .mli files must be correctly documented.

Have a look at the just created web site:

http://pauillac.inria.fr/cdk

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Patrick M Doane]

This is excellent news! I'm looking forward to helping with this effort.

I have quite a bit of code lying around on my machine for working with
e-mail protocols (such as POP, SMTP, NNTP, IMAP, etc) and associated data. 
I recently created a Sourceforge project to try to organize an effort to
making high-quality Ocaml modules for these types of modules.  For those
interested, it is located at: 

  http://sourceforge.net/projects/ocamlnet/

I have placed a project goals document but not much source code yet for a
reason that this CDK project might be able to resolve: 

As much as I love Caml as a language, I have to admit that I've been less
than pleased with the standard infrastructure for string manipulation. 
First a summary of approaches that I'm aware of: 

  1) Manipulate the string manually with functions like String.index and
maintain position variables.  I find this to be pretty error-prone and
hard to read.

  2) Use the stream parsers.  I hesitate to use them because of their
status as "experimental" and that be removed at any time. I also have
heard claims that their performance is not too good compared with other
techniques.  Does anyone know if this true? 

  3) Use ocamllex.  This would be the most natural approach to me but
their utility is hampered by not being able to pass additional parameters
to the rules.  I understand that there is patch available that adds this
functionality, but it's part of the standard distribution.

  4) Use a regular expression matching library.  The builtin Str is
not thread-safe which is problematic. PCRE and xstr provide good
alternatives. Too many choices here though.

  5) Write another custom module for string manipulation!

Since I wasn't happy with the builtin functions and didn't want to rely on
a third party distribution, I opted for option 5 while writing a good bit
of the code.  But then I think, does the world really need another string
manipulation library? 

If we can converge on a small set of good workable solutions, then it'll
make it much easier to produce a large set of modules for protocols and
parsing.

Any thoughts?
Patrick

On Mon, 26 Mar 2001, Fabrice Le Fessant wrote:

> 
> A few weeks ago, we started a project called "Caml Development Kit" or
> CDK, which would gather in one big tarball or RPM several tools and
> libraries, useful for Ocaml programming. 
> 
> For example, the CDK will include Ocaml, Camlp4, ledit, and many
> user-contributed libraries. A new CDK will be released at each Ocaml
> release (and probably more often from CVS sources), removing the need
> to update, compile and install many different packages everytime to
> have a coherent development envirronment.
> 
> If you are interested in contributing to this project, you can either
> send me your code, or an URL where we can download your contribution.
> 
> We are particularly interested in general modules, providing useful
> data structures, network(urlget,http_server,etc)/ crypto(des)/
> multimedia(images) functions, or bindings to C libraries. 
> 
> The package includes a simple tool to generate HTML from .mli files.
> Thus, contributions must provide .mli files for all interesting
> modules, and these .mli files must be correctly documented.
> 
> Have a look at the just created web site:
> 
> http://pauillac.inria.fr/cdk
> 
> - Fabrice
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Brian Rogoff]

On Mon, 26 Mar 2001, Patrick M Doane wrote:
> As much as I love Caml as a language, I have to admit that I've been less
> than pleased with the standard infrastructure for string manipulation. 
> First a summary of approaches that I'm aware of: 
> 
>   1) Manipulate the string manually with functions like String.index and
> maintain position variables.  I find this to be pretty error-prone and
> hard to read.
> 
>   2) Use the stream parsers.  I hesitate to use them because of their
> status as "experimental" and that be removed at any time. I also have
> heard claims that their performance is not too good compared with other
> techniques.  Does anyone know if this true? 

This is like shooting squirrels with a sniper rifle. It's quite a bit more 
power than you need for most string processing tasks. I certainly wouldn't 
worry about the "experimental" label since it's been there for quite a
long time. 

Why not steal the substring library from the SML Basis? It's a variant on
your 1) and has the added advantage that we can lift much of the
documentation from the SML community. 

It might even be worthwhile to just steal as much of the Basis library as
possible from Mosml and SML/NJ. Stealing code is this way is good, and it
allows SML programmers to migrate more easily (and ultimately would allow 
Caml programmers easy migration too) which is a good thing. 

As far as regexp libraries go, I like Pcre, but I haven't tried xstr. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Chris Hecker]

> As much as I love Caml as a language, I have to admit that I've been less
>than pleased with the standard infrastructure for string manipulation.

Slightly off-topic, but anybody who's interested in string processing should read the bottom part of the interview with Ilya Zakharevich.  He talks about how Perl's text processing is really not all that great, and he has a lot of good things to say.  Here's a snippet.  It would be a coup for Caml to have a module that supports some of these features before other languages:

---------
http://www.perl.com/pub/2000/09/ilya.html
Let me also mention that classifying the text handling facilities of Perl as "extremely agile" gives me the willies. Perl's regular expressions are indeed more convenient than in other languages. However, the lack of a lot of key text-processing ingredients makes Perl solutions for many averagely complicated tasks either extremely slow, or not easier to maintain than solutions in other languages (and in some cases both). 
...
---------

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Jacques Garrigue]

Hello Fabrice,

> A few weeks ago, we started a project called "Caml Development Kit" or
> CDK, which would gather in one big tarball or RPM several tools and
> libraries, useful for Ocaml programming. 
>
> For example, the CDK will include Ocaml, Camlp4, ledit, and many
> user-contributed libraries. A new CDK will be released at each Ocaml
> release (and probably more often from CVS sources), removing the need
> to update, compile and install many different packages everytime to
> have a coherent development envirronment.

Nice idea, but how do you handle dependencies, and configuration.
Notice also that many OSs/distribution have their own notion
of package, which they may prefer over a monolythic build.

Moving everything to findlib might be a good idea.
 
> If you are interested in contributing to this project, you can either
> send me your code, or an URL where we can download your contribution.

Of course I'm interested. Get anything you like from
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/ocaml.html

Do you need to have all the code in your own CVS, or can we use a more
distributed approach ?

> The package includes a simple tool to generate HTML from .mli files.
> Thus, contributions must provide .mli files for all interesting
> modules, and these .mli files must be correctly documented.

OK, the format used seems to differ a bit from the main ocaml
distribution, but this should be doable.
By the way, are labels a sufficient documentation for most functions ?

Best Regards,

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Daniel de Rauglaudre]

Hi,

On Mon, Mar 26, 2001 at 09:12:42PM -0500, Patrick M Doane wrote:

>   2) Use the stream parsers.  I hesitate to use them because of their
> status as "experimental" and that be removed at any time. I also have
> heard claims that their performance is not too good compared with other
> techniques.  Does anyone know if this true? 

For optimal speed and tail recursion, code holding streams or streams
parsers have to be preprocessed by Camlp4. Do:
    ocamlc -pp camlp4o foo.ml
instead of:
    ocamlc foo.ml

It can make a big difference.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Streams

[Daniel de Rauglaudre]

Hello,

On Mon, Mar 26, 2001 at 07:15:54PM -0800, Brian Rogoff wrote:

> >   2) Use the stream parsers.  I hesitate to use them because of their
> > status as "experimental" and that be removed at any time. I also have
> > heard claims that their performance is not too good compared with other
> > techniques.  Does anyone know if this true? 
> 
> This is like shooting squirrels with a sniper rifle. It's quite a bit more 
> power than you need for most string processing tasks. I certainly wouldn't 
> worry about the "experimental" label since it's been there for quite a
> long time. 

Streams date from 1992. They have been implemented in Caml Light.

I added them in OCaml but actually it was an error: streams and
streams parsers are just syntactic sugar, it is work for Camlp4, but
Camlp4 did not exist at this time.  We plan to remove them from OCaml
but after having moved Camlp4 in OCaml contribution directory.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Sven LUTHER]

On Mon, Mar 26, 2001 at 03:03:22PM +0200, Fabrice Le Fessant wrote:
> 
> A few weeks ago, we started a project called "Caml Development Kit" or
> CDK, which would gather in one big tarball or RPM several tools and
> libraries, useful for Ocaml programming. 

Hello Fabrice, ...

I think this is a very nice idea.

Are you also aware of the debian-ocaml packaging effort, it is a plan to
integrate as much of the ocaml stuff in official debian packages. Upto now, we
have (at least) ocaml, ocaml-doc, lablgtk, lablgl, mlgtk, mldvi, ocamlp4,
ocamlweb, findlib, ocaml-tools (a collection of smaller thigns), hevea, and
more that i don't remember just yet.

We have both a mailing list (debian-ocaml-maint@lists.debian.org) with a
complete mailing list archive, and a web page :
http://www3.inrets.fr/Public/ESTAS/Mariano.Georges/OCamlDebian/html/

As well as a small group of people interested in working on this.

I would think that since the two effort share some common ideas, that it would
be nice to if not join, at least speak with each other about this issues, or
maybe cross post any mail discution on this ?

What do you think about it ?

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Streams

[Daniel de Rauglaudre]

Hi,

On Tue, Mar 27, 2001 at 10:25:41AM +0200, Christophe Raffalli wrote:

> I (and many others ?) have a lot of lines using stream parsers. I prefer to
> write stream parsers using their higher order power than camlyacc which does
> more thing automatically but is basically first order.
> 
> So if you remove them, keep some compatibility using a simple option calling
> camlp4 in the correct way ! Please !!

It will remain compatible. From now, you can absolutely add "-pp
camlp4o" in your Makefile for files containing streams and stream
parsers. If you don't do that now, you streams are slow.

Therefore, suppressing them from OCaml is to prevent people to have
slow streams without knowing it.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Caml Development Kit

[Matthieu Villeneuve]

Chris Hecker wrote:
> 
> > As much as I love Caml as a language, I have to admit that I've been less
> >than pleased with the standard infrastructure for string manipulation.
> 
> Slightly off-topic, but anybody who's interested in string processing should read the bottom part of the interview with Ilya Zakharevich.  He talks about how Perl's text processing is really not all that great, and he has a lot of good things to say.  Here's a snippet.  It would be a coup for Caml to have a module that supports some of these features before other languages:
> 
> ---------
> http://www.perl.com/pub/2000/09/ilya.html
> Let me also mention that classifying the text handling facilities of Perl as "extremely agile" gives me the willies. Perl's regular expressions are indeed more convenient than in other languages. However, the lack of a lot of key text-processing ingredients makes Perl solutions for many averagely complicated tasks either extremely slow, or not easier to maintain than solutions in other languages (and in some cases both).
> ...

Also, a Perl developer saying that Lisp is an "inherently unreadable
language" always makes you see life in a different way... ;-)


--Matthieu

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Streams

[Jon Harrop]

On Thursday 10 August 2006 11:51, Error404 wrote:
> I'm looking for some streams related tutorial or any other info.
> By stream i mean something like this (I don't know exact definition):
>
> open Lazy;;
> type 'a stream = Nil | Cons of 'a Lazy.t * 'a stream Lazy.t;;
>
> (* For example stream of 'integers from x' would look like this: *)
>
> let rec intsfrom x =
>   Cons(lazy x,lazy (intsfrom (x+1)));;
>
> If you know any www/book or anything on this kind of streams please mail me
> (error92@tlen.pl). Many thanks.

I just posted a link to some stuff on streams in the context of parsing but 
you can write intsfrom as:

# #load "camlp4o.cma";;
        Camlp4 Parsing version 3.09.2

# let rec intsfrom n = [< 'n; intsfrom(n+1) >];;

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Streams

[Chris King]

On 8/10/06, Jonathan Roewen <jonathan.roewen@gmail.com> wrote:
> The Stream module provides exactly this functionality.

Don't forget about Fstream
(http://caml.inria.fr/pub/docs/manual-camlp4/manual008.html#toc30); it
does the same thing as Stream but in a functional manner (and with a
similar syntax, pa_fstream.cmo).

Re: [Caml-list] Streams

[Martin Jambon]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 975 bytes --]

On Thu, 10 Aug 2006, Error404 wrote:

> Hi,
>
> I'm looking for some streams related tutorial or any other info.
> By stream i mean something like this (I don't know exact definition):
>
> open Lazy;;
> type 'a stream = Nil | Cons of 'a Lazy.t * 'a stream Lazy.t;;
>
> (* For example stream of 'integers from x' would look like this: *)
>
> let rec intsfrom x =
>  Cons(lazy x,lazy (intsfrom (x+1)));;
>
> If you know any www/book or anything on this kind of streams please mail me (error92@tlen.pl).
> Many thanks.

I call this a lazy list. Anyway, I use the following definition:

   type 'a l = Empty | Cons of 'a * 'a t
   and 'a t = 'a l lazy_t   (* only one lazy object per cell *)

See attachment for the full implementation.

You can manipulate such lists like real lists, only the syntax is less 
comfortable. They are different from streams in the sense of the standard 
Stream module, which are mutable.


Martin

--
Martin Jambon, PhD
http://martin.jambon.free.fr

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2295 bytes --]

(* lazy lists *)

type 'a l = Empty | Cons of 'a * 'a t
and 'a t = 'a l lazy_t

let empty = lazy Empty
let is_empty l = Lazy.force l = Empty

let rec force l =
  match Lazy.force l with
      Empty -> ()
    | Cons (hd, tl) -> force tl

let hd l =
  match Lazy.force l with
      Empty -> invalid_arg "Lizt.hd"
    | Cons (x, _) -> x

let tl l =
  match Lazy.force l with
      Empty -> invalid_arg "Lizt.tl"
    | Cons (_, x) -> x

let peek1 l = 
  match Lazy.force l with
      Empty -> None
    | Cons (x, _) -> Some x

let peek2 l =
  match Lazy.force l with
      Empty -> None
    | Cons (x1, l) -> 
	match Lazy.force l with
	    Empty -> None
	  | Cons (x2, l) -> Some (x1, x2)

let peek3 l =
  match Lazy.force l with
      Empty -> None
    | Cons (x1, l) -> 
	match Lazy.force l with
	    Empty -> None
	  | Cons (x2, l) -> 
	      match Lazy.force l with
		  Empty -> None
		| Cons (x3, l) -> Some (x1, x2, x3)


let rec of_list l =
  lazy (match l with
	    [] -> Empty
	  | hd :: tl -> (Cons (hd, of_list tl)))

let rec to_list l =
  match Lazy.force l with
      Empty -> []
    | Cons (hd, tl) -> hd :: to_list tl

let from f =
  let rec make f i =
    lazy (match f i with
	      None -> Empty
	    | Some x -> Cons (x, make f (i+1))) in
  make f 0

let rec append l1 l2 =
  lazy (match Lazy.force l1 with
	    Cons (hd, tl) -> Cons (hd, (append tl l2))
	  | Empty -> Lazy.force l2)

let rec iter f l =
  match Lazy.force l with
      Empty -> ()
    | Cons (hd, tl) -> f hd; iter f tl

let rec map f l =
  lazy (match Lazy.force l with
	    Empty -> Empty
	  | Cons (hd, tl) -> Cons (f hd, map f tl))

let filter f l =
  let rec loop f l =
    match Lazy.force l with
	Empty -> lazy Empty
      | Cons (hd, tl) -> 
	  if f hd then lazy (Cons (hd, loop f tl))
	  else loop f tl in
  lazy (Lazy.force (loop f l))

let optmap f l =
  let rec loop f l =
    match Lazy.force l with
	Empty -> lazy Empty
      | Cons (hd, tl) -> 
	  match f hd with
	      Some y -> lazy (Cons (y, loop f tl))
	    | None -> loop f tl in
  lazy (Lazy.force (loop f l))

let rec fold_left f accu l =
  match Lazy.force l with
      Empty -> accu
    | Cons (hd, tl) -> fold_left f (f accu hd) tl

Re: [Caml-list] Streams

[Jonathan Roewen]

The Stream module provides exactly this functionality.

With camlp4o, you can use the old parser syntax too.

#load "camlp4o.cma";

let rec enum_from n = [< 'n; enum_from (n + 1) >];;

let first_10 = Stream.npeek 10 (enum_from 1);;

Streams are also lazily evaluated. More complex examples can be had
too, and there is the parser keyword to deconstruct streams as well.
You should be able to find more info in the camlp4 manual at the caml
site.

Jonathan

On 8/10/06, Error404 <error92@tlen.pl> wrote:
> Hi,
>
> I'm looking for some streams related tutorial or any other info.
> By stream i mean something like this (I don't know exact definition):
>
> open Lazy;;
> type 'a stream = Nil | Cons of 'a Lazy.t * 'a stream Lazy.t;;
>
> (* For example stream of 'integers from x' would look like this: *)
>
> let rec intsfrom x =
>  Cons(lazy x,lazy (intsfrom (x+1)));;
>
> If you know any www/book or anything on this kind of streams please mail me (error92@tlen.pl).
> Many thanks.
>
> _______________________________________________
> 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
>

Re: [Caml-list] Streams

[Diego Olivier Fernandez Pons]

    Alain,

> type
>   'a stream =
>      | Nil
>      | Patchable of 'a stream_patchable
> and 'a stream_patchable = { mutable data : 'a streamCell }
> and
>   'a streamCell =
>     | Cons of 'a * 'a stream
>     | Append of 'a stream * 'a stream
>     | Delayed of (unit -> 'a stream)
>     | Generator of int * (int -> int) * (int -> 'a)

Mes listes à évaluation retardées contrairement à celles de Rauglaudre
supportent (quasi) totalement les fonctions génératrices, en
particulier leur concaténation.

Quand Generator ou Delayed vont envoyer une exception [Empty] ou une
liste vide [Nil] respectivement, il faut que je mémorise la valeur, ce
qui empêche la construction que vous proposez à moins d'utiliser
Append (Nil, Nil) ou un nouveau constructeur NilBis dans StreamCell.

voici ma fonction force

let rec force = function stream ->
 (match stream.data with
   | Delayed f -> let x = f () in stream.data <- x.data
   | Generator (index, succ, gen) ->
      (try
         let next_index = succ index in
           stream.data <- Cons (gen next_index, 
              makeStream (Generator (next_index, succ, gen)))
        with Empty -> stream.data <- Nil)
   etc.
  ) ;
  stream 

En fait nous voudrions mimer le mieux possible le comportement des
listes de base, avec une unique représentation de la liste vide :
# []
- : 'a list = []
# let (_ :: tail) = [1] in tail
- : int list = []

# { data = Nil }
- : '_a stream = { data = Nil }

> Couln't you just abstract the generator outside the stream ?
> 
> let gen ini f =
>   let state = ref ini in
>   (fun () -> state := f !state),
>   (fun () -> !state);;
> 
> Do you really need to keep the current state visible ?

Cette représentation des générateurs a été choisie afin de pouvoir
implémenter (relativement) efficacement les fonctions take et drop.

J'ai gardé l'indexe courant visible car c'était fait ainsi dans
l'implémentation de Rauglaudre, en effet dans les streams de Caml
l'indexe compte simultanément le nombre d'états consommés : 

la fonction drop k applique simplement succ^k sur l'indexe,

la fonction take k remplace succ par la version suivante
  let count = ref k in
  let succ' = function index ->
    if !count = 0 then raise Empty
    else decr count ; succ index

L'idée est essentiellement que décaler d'un indice est plus rapide que
générer une valeur avec evenutellement une fonction triviale si ce
n'est pas le cas 'a * 'a -> 'a * 'a -> 'a

        Diego Olivier

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Streams

[Alain Frisch]

Hello Diego,

On Fri, 2 Aug 2002, Diego Olivier Fernandez Pons wrote:

> - serait-il possible de documenter un peu le module obj ? Peut-être
> est-ce une mauvaise idée, dans la mesure où cela pourrait permettre à
> des utilisateurs non avertis d'écrire du code dangereux

Using Obj safely requires to know a little bit about the runtime
representation of objects; and once you have this knowledge (after
reading the section on interfacing with C in the manual, or the OCaml
runtime source files), the module interface should be self-explanatory.

> L'inconvénient est que l'on perd le polymorphisme de la liste vide.
> N'y a t-il aucun moyen de s'en sortir en utilisant du Caml
> conventionnel ?

You have to explain to the typechecker that the Nil stream will
never be patched:

type
  'a stream =
     | Nil
     | Patchable of 'a stream_patchable
and 'a stream_patchable = { mutable data : 'a streamCell }
and
  'a streamCell =
    | Cons of 'a * 'a stream
    | Append of 'a stream * 'a stream
    | Delayed of (unit -> 'a stream)
    | Generator of int * (int -> int) * (int -> 'a)

Of course, this is less efficient (one would like to write
as in other ML dialects,

type
  'a stream =
     | Nil
     | Patchable of { mutable data : 'a streamCell }

[see http://pauillac.inria.fr/~lefessan/src/ for such a patch
to OCaml 2.02]
...
Any plan to introduce this syntax in OCaml ?
)

> ensuite je voudrais abstraire le type int du constreur Generator afin
> que l'utilisateur puisse indicer sa fonction génératrice par le type
> de son choix :
>
>    | Generator of 'k * (k' -> 'k) * ('k -> 'a)
>
> seulement si je déclare un type ('k, 'a) streamCell alors on ne peut
> plus utiliser des listes d'indexes de type différent alors qu'elles
> sont "logiquement" compatibles puisque le type 'k ne sert qu'a
> construire les nouvelles valeurs de type 'a
>
> comment limiter "l'étendue" du type 'k au seul constructeur
> [Generator] ?

Couln't you just abstract the generator outside the stream ?

let gen ini f =
  let state = ref ini in
  (fun () -> state := f !state),
  (fun () -> !state);;

Do you really need to keep the current state visible ?

> - la forme spéciale lazy ressemble très fortement à la fonction lazy_
> ci-dessous mis à part qu'elle n'évalue pas ses arguments
>
> (* OCaml 3.04 *)
> let lazy_ = function x -> ref (Lazy.Delayed (function () -> x))
>
> Quels seraient les inconvénients (théoriques ? pratiques ?) d'une
> forme spéciale [uneval_] qui serait équivalente à function () ->,
> autrement dit
>
>    uneval : 'a -> (unit -> 'a)
>    uneval_ x <=> function () -> x

What do you mean by "forme spéciale" ?  If you just want syntactic
sugar, you can implement it yourself with Camlp4.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Streams

[Diego Olivier Fernandez Pons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3297 bytes --]

    Bonjour,

Dans le cadre de la librairie de structures de données EDiSon
(Efficient Data Structures, Okasaki 2000) que je suis en train de
porter et d'adapter (pour l'instant 500k, prérelease prévue en
septembre), j'ai réalisé plusieurs types de listes à évaluation
retardée.

La première remarque est que j'ai eu beaucoup de mal à trouver de la
documentation à ce sujet :

- une implémentation très simple dans ML for the working programmer
(Paulson 1991, 1996)

- une implémentation par Pierre Weiss pour le problème des 8 dames sur
l'échiquer dans la librairie d'exemples d'Objective Caml

- l'implémentation de Daniel de Rauglaudre, cette dernière ayant
l'inconvénient de s'appuyer sur des fonctions non documentées de Caml,
mais il faut reconnaître que le code est parfaitement lisible et que
l'on devine à peu près ce qui se passe. C'est de surcroît la seule
implémentation à prendre en compte les fonctions génératrices et la
concaténation

- un article de Wadler (1997) sur l'implémentation de l'évaluation
retardée dans les langages stricts, qui a la particularité d'enfoncer
des portes ouvertes (ne considérant que les deux implémentations
traditionnelles) et de parler d'une implémentation particulièrement
efficace en SML/NJ qui serait en cours de développement, or la version
CVS de SML/NJ (110.41) ne comporte rien de tout cela, sinon le
traditionnel module Lazy

Enfin le rapport de recherche de Didier Remy et Daniel de
Rauglaudre (1992) n'est disponible que sous forme papier.


Voici donc mes questions :

- serait-il possible de documenter un peu le module obj ? Peut-être
est-ce une mauvaise idée, dans la mesure où cela pourrait permettre à
des utilisateurs non avertis d'écrire du code dangereux

j'ai écrit une version de listes à évaluation retardée qui simule le
fonctionnement des streams de Caml (fichier joint streamVI.ml)

type 
  'a stream = { mutable data : 'a streamCell } and
  'a streamCell =
    | Nil
    | Cons of 'a * 'a stream
    | Append of 'a stream * 'a stream
    | Delayed of (unit -> 'a stream)
    | Generator of int * (int -> int) * (int -> 'a)

L'inconvénient est que l'on perd le polymorphisme de la liste vide.
N'y a t-il aucun moyen de s'en sortir en utilisant du Caml
conventionnel ?

ensuite je voudrais abstraire le type int du constreur Generator afin
que l'utilisateur puisse indicer sa fonction génératrice par le type
de son choix :

   | Generator of 'k * (k' -> 'k) * ('k -> 'a)

seulement si je déclare un type ('k, 'a) streamCell alors on ne peut
plus utiliser des listes d'indexes de type différent alors qu'elles
sont "logiquement" compatibles puisque le type 'k ne sert qu'a
construire les nouvelles valeurs de type 'a

comment limiter "l'étendue" du type 'k au seul constructeur
[Generator] ?

- la forme spéciale lazy ressemble très fortement à la fonction lazy_
ci-dessous mis à part qu'elle n'évalue pas ses arguments

(* OCaml 3.04 *)
let lazy_ = function x -> ref (Lazy.Delayed (function () -> x))

Quels seraient les inconvénients (théoriques ? pratiques ?) d'une
forme spéciale [uneval_] qui serait équivalente à function () ->,
autrement dit

   uneval : 'a -> (unit -> 'a)
   uneval_ x <=> function () -> x  

        Diego Olivier

[-- Attachment #2: streams --]
[-- Type: APPLICATION/octet-stream, Size: 8911 bytes --]

Re: [Caml-list] Streams

[Wolfram Kahl]

Hi,

Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> pinpointed the problem:
 > 
 > It was an error that the OCaml version accepted the "??" for the first
 > element.

Thanks!

 > Your code is equivalent to:
 > 
 >   let pc0 c = parser n
 >     [< '  x
 >           when x == c
 >     >] -> ();;

However, there is nothing on
http://caml.inria.fr/camlp4/tutorial/tutorial002.html
that indicates that even this might be legal ---
``when'' is not mentioned on that page.
Would it perhaps make sense to include an adapted version
of the old OCaml Manual section on streams
that tries to give a general description instead of
just a few selected examples?

(Also I have found it useful to leave two blanks after '
 in parsers since in some instances I obtained very strange
 (lexical?) errors.
)


Best regards,

Wolfram Kahl

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Streams

[Daniel de Rauglaudre]

Hi,

> let pc0 c = parser n
>   [< '  x
>         when x == c
>         ?? (string_of_int n ^ ": pc '" ^ String.make 1 c ^ "'")
>   >] -> ();;

The "??" is unuseful for the first element of a stream pattern, because
when it fails, it raises Stream.Failure, not Stream.Error. The "??"
introduces a parameter for Stream.Error. Your code is equivalent to:

  let pc0 c = parser n
    [< '  x
          when x == c
    >] -> ();;

It was an error that the OCaml version accepted the "??" for the first
element.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners