headers
David Jemmi | 1 Oct 1999 13:54
Picon

OCaml et l'évaluation paresseuse

Haskell supporte l'évaluation paresseuse pour tous les appels de fonctions
et pas OCaml.
D'après un article que je viens de lire "Why Functional Programming Matters"
(http://www.md.chalmers.se/~rjmh/Papers/whyfp.html), l'auteur explique que
les fonctions d'ordre supérieur et l'évaluation paresseuse font partie des
évolutions majeures apportées par les langages fonctionnelles.
Les auteurs d'Haskell on l'air d'insister sur ce point.

Pourquoi OCaml (ou caml) n'utilise pas l'évaluation paresseuse par défaut ??

(pour les problèmes de performances, je pense qu'un bon optimiseur suffit).

Merci.

Stéphane Baubillier
baubillier <at> hotmail.com
Permalink | Reply | 3 comments |
headers
David Gross | 1 Oct 1999 09:17
Picon

Re: A propos de monad


> Ayant déjà poser la question sur les news comp.lang.functionnal,
> Quelqu'un aurait-il une traduction de 'monad' et des info sur les causes (et
> raisons) de son existance.

Je ne suis pas du tout un specialiste, mais je crois que les monades
servent a realiser simplement dans un langage fonctionnel la notion de
changement d'etat d'un programme.

Un petit lien : http://www.dcs.gla.ac.uk/~nww/Monad.html (c'est de
l'haskell)

David Gross
http://www.lri.fr/~dgross
Permalink | Reply | 0 comments |
headers
Peter Bruhn | 1 Oct 1999 15:01
Picon

Newbies question

The following function does not compile, since the compiler thinks it has
the wrong return type: 

    let read_res file : ('a * 'b) list =
      let final_result = ref [] in
      let fd = open_in file in
      try 
        let lexbuf = Lexing.from_channel fd in
        while true do
          let result = Parseres.main Lexres.token lexbuf in
          final_result := result :: !final_result 
        done  (* <---- nothing returned here, but we cannot get here anyway
                       the loop is exited by an exception only *) 
      with             
        Lexres.Eof ->  
          close_in fd; !final_result (* !final_result is of type ('a * 'b) list *)
      | Parsing.Parse_error ->          
          close_in fd; printf "ERROR: Ressourcen Datei fehlerhaft\n"; exit (-1);

But when I use an empty list after the endless-loop, it works alright. Do I
really have to fake the compiler? Or am I doing something wrong? This works:

    let read_res file : ('a * 'b) list =
      let final_result = ref [] in
      let fd = open_in file in
      try 
        let lexbuf = Lexing.from_channel fd in
        while true do
          let result = Parseres.main Lexres.token lexbuf in
          final_result := result :: !final_result
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Mentr'e | 1 Oct 1999 11:26
Picon
Favicon

Re: A propos de monad/About monads

[ English (executive summary ;) ]

Monads are a way to encapsulate side-effects in functionnal
languages. Does anyboody have a more detailed explaination about how
monads really work ? What is the difference between the usual let and
the monad binding ?

[ Français ]
"Stéphane Baubillier" <stephane.baubillier <at> pactenovation.fr> writes:

> Quelqu'un aurait-il une traduction de 'monad'

? monade ? (c'est au moins dans le dico)

> et des info sur les causes (et raisons) de son existance.

C'est un mécansime pour encapsuler les effets de bord dans un formalisme
fonctionnel. Pour résumer très grossièrement, une fonction ne doit
dépendre que de ses entrées. Donc pour que les effets de bord puissent
être pris en compte, on passe en argument de la fonction un « monde »,
qu'elle rend modifié. Ce monde comprend le résultat de la fonction, plus
tous les effets de bords potentiels (exception, ...). 

Donc les monades sont un type abstrait de donné. De plus, ce type
abstrait doit avoir certaines caractéristiques : un opérateur de liage
(/binding/) et un élément neutre (/unit/) et des lois sur la composition
de ces éléments. Il se trouve que ces lois correspondent aux
caractéristiques des monades en mathématiques, d'où le nom.

Un dernier point, il semble que l'opérateur de liage/binding permet de
(Continue reading)

Permalink | Reply | 6 comments |
headers
Xavier Leroy | 1 Oct 1999 17:39
Picon
Picon
Favicon

Re: Problèmes avec lib UNIX sur Windows

> je souhaite utiliser la librairie Unix sous Windows98 
> pour réaliser un petit programme utilisant les 'SOCKET'
> mais mes nombreuses tentatives restent sans succès.
> (voir extraits si dessous)

> ***********************************************
> Dans l'interpréteur
> ***********************************************
> D:\ocaml\lib> ocaml
>         Objective Caml version 2.02
> 
> # #load"unix.cma";;
> The external function `unix_error_message' is not available

Le "runtime system" standard d'OCaml ne contient pas préchargées les
fonctions C nécessaires à la bibliothèque Unix.  Il faut en effet
construire un "runtime system" spécial contenant ces fonctions C.
Votre tentative suivante est exactement ce qu'il faut faire:

> ***********************************************
> Tentative de creation d'un nouveau interpréteur
> (tel que décris dans la doc)
> ***********************************************
> D:\ocaml\lib> ocamlmktop -custom -o mytop unix.cma -cclib -lunix
> Bad command or file name
> I/O error: mytop.exe: No such file or directory

... mais ocamlmktop -custom a besoin d'appeler le compilateur MSVC++
version 6 pour construire son "runtime system", et apparemment il
n'est pas installé sur votre machine (le "Bad command or file name").
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brown | 2 Oct 1999 20:10

Re: A propos de monad/About monads

David Mentr'e writes:

 > Monads are a way to encapsulate side-effects in functionnal
 > languages. Does anyboody have a more detailed explaination about how
 > monads really work ? What is the difference between the usual let and
 > the monad binding ?

Monads are primarily to encourage a lasy language (such as haskell) to 
evaluate side-effecting operations in a specific order.

In caml,

   let a = foo x y z in
   let b = bar g h i in
   blort a b

foo will be called before bar, and both will be called before blort.
So, if there are side effects in foo, and bar, and blort, we know what 
order these will happen in.

In a lazy language, foo will not be evaluated until blort needs to use 
its first argument.  Things could happen in blort before that.
Consequentially, some mechanism is needed to ensure an order.  Instead 
of "hiding" side-effecting operations wherever convenient, they are
encapsulated into a monad.  Other messages have given good references
to explanations.

Basically, instead of a function performing an operation, it returns a 
function that will perform that operation.  Monads provide a
convenient way to sequence these.  Also, the main program will return
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gerd Stolpmann | 2 Oct 1999 20:04
Picon
Picon

Re: Newbies question

>    let read_res file : ('a * 'b) list =
>      let final_result = ref [] in
>      let fd = open_in file in
>      try 
>        let lexbuf = Lexing.from_channel fd in
>        while true do
>          let result = Parseres.main Lexres.token lexbuf in
>          final_result := result :: !final_result 
>        done  (* <---- nothing returned here, but we cannot get here anyway
>                       the loop is exited by an exception only *) 

No, this is not true. "()", the only element of the "unit" type would be
returned if the loop could be finished; every "while" loop returns "()" by
definition. The compiler does not detect the infinite loop, so the typing
constraint applies that the code within "try"  must be compatible with the
"unit" type. 

>      with             
>        Lexres.Eof ->  
>          close_in fd; !final_result (* !final_result is of type ('a * 'b) list *)
>      | Parsing.Parse_error ->          
>          close_in fd; printf "ERROR: Ressourcen Datei fehlerhaft\n"; exit (-1);

The whole "try ... with ..." construct enforces the typing constraint that the
type of the "try" expression and all types of the "with" expressions must be
compatible. As already pointed out, the "try" expression has unit type; the
"Lexres.Eof" branch has the mentioned list type; and the "Parsing.Parse_error"
branch has arbitrary type (because the "exit" function has type int -> 'a).
The unit type and the list type cannot be unified, so a typing error occurs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erwan David | 3 Oct 1999 10:07
Picon

Re: monad

Le Thu 30/09/1999, Philippe Esperet disait
> 	``monad'' est le mot anglais correspondant à << monade >>, entité
> complexe intervenant dans le système philosophique de Leibniz (Monade
> en allemand). 
> 
> 	Cela aide-t-il ?

	Il y a aussi une notion de monades en théorie des
catégories. Mais mes souvenirs sont très flous sur ce que c'est
exactement.

--

-- 
Erwan DAVID
Permalink | Reply | 0 comments |
headers
Markus Mottl | 3 Oct 1999 12:58
Picon

Re: Newbies question

>     let read_res file : ('a * 'b) list =
>       let final_result = ref [] in
>       let fd = open_in file in
>       try 
>         let lexbuf = Lexing.from_channel fd in
>         while true do
>           let result = Parseres.main Lexres.token lexbuf in
>           final_result := result :: !final_result 
>         done  (* <---- nothing returned here, but we cannot get here anyway
>                        the loop is exited by an exception only *) 
>       with             
>         Lexres.Eof ->  
>           close_in fd; !final_result (* !final_result is of type ('a * 'b) list *)
>       | Parsing.Parse_error ->          
>           close_in fd; printf "ERROR: Ressourcen Datei fehlerhaft\n"; exit (-1);

>From the type checker's point of view there are three possible ways out
of your program, but just two can really happen at runtime:

The two exception cases: the first one returns a list of tuples, the second
one exits the program - as you see in the pervasives, "exit" has return
type 'a, so it unifies with any other type (e.g. your tuple list).

Then there is this loop: because there is no return value after it,
it has type "unit" as loops generally do. But "unit" does not unify with a
tuple list.

> But when I use an empty list after the endless-loop, it works alright. Do I
> really have to fake the compiler? Or am I doing something wrong? This works:
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Chesters | 2 Oct 1999 21:38
Picon
Picon

OCaml et l'évaluation paresseuse

David Jemmi writes:
 > Pourquoi OCaml (ou caml) n'utilise pas l'évaluation paresseuse par défaut ??

Two problems.  Firstly,

 > (pour les problèmes de performances, je pense qu'un bon optimiseur suffit).

is unfortunately not true.  For instance Clean, which supports both
strict and lazy evaluation, does so in entirely different ways, and
you are warned that the latter is much slower.

   The basic point is that a strict language like ocaml is just a
fancy version of assembler or C---a function call really is a CALL
instruction (and a higher order call is a "call *%ecx").  Since the
computational model presented to the programmer is essentially just
that of the underlying CPU, it's easy to write fast code.  The only
concession made to "abstraction" is the garbage collector.

   If instead you present the programmer with a different
computational model, however elegant, you make it impossible for her
to "talk the CPU's language", so she is relying on the compiler to
make the necessary transformations; and that turns out to be very,
very difficult, like proving theorems.

   Another point is that although lazy evaluation is very exciting and
fun to start with, you do quickly come to realise that for nearly all
purposes, the imperative idioms into which (you hope) the compiler is
going to compile your lazy code are in fact just as convenient, nearly
as flexible and often easier to understand.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane