From: cr@dcs.ed.ac.uk
Date: Wed, 17 Mar 93 18:10:54 GMT
Message-Id: <6263.9303171810@campay.dcs.ed.ac.uk>
To: caml-list@margaux
Subject: Encore du pattern matching et des streams
Ok, les arguments de Michel Mauny, pour la factorisation m'ont a peu pres
convaincu.
Quand au patterne matching destructif, je repond a Chet Murphy :
> C'est vrai qu'on garde "les bonnes proprietes" en utilisant un
> langage purement fonctionnel. Mais ... en tant que programmeur qui
> n'est meme pas satisfait avec Lucid CommonLisp, ne parlons pas de
> SML/CAML/gnagna, je trouve qu'on a des anne'es-lumie`res a` traverser avant
> qu'on puisse dire que nos langages sont assez efficaces pour qu'on puisse
> garder des choses comme les flux (streams) fonctionnels.
Les flux (streams) fonctionnels, ne sont rien de plus que des listes
eventuellement infinies. De toutes facons, les streams actuels de
camllight (avec correction du bug, j'ai la chance d'avoir le patch pour le
corriger) sont bien des listes infinies fonctionnelles. La fonction
"stream_get" existe !
Donc un patterne matching non destructif ne changera rien a la representation
des streams.
> C'est aussi vrai qu'un jour, le GC pourrait recuperer les donne'es
> utilise'es efficacement. Ce jour-la, ce n'est pas aujourd'hui. Et
> caml-light, c'est cense' etre un langage d'aujourd'hui _et_ demain.
> Pas simplement demain. Comme disait qqun: "la verification formelle,
> c'est l'avenir de l'informatique - ca l'a ete toujours, et ca le sera
> toujours".
Le GC actuel doit bien recuperer le debut des streams quand il ne sont plus
utilises ! ou du moins je l'espere, sinon les programmes que j'ecris vont
s'ecrouler.
> Mais, plus se'rieusement, j'ai des objections a` un langage dans lequel
> on e'crit des programmes manipulant des flux fonctionnels. C'est
> tre`s bien quand on ecrit simplement des flux et des motifs de flux.
> Mais quand on les me'lange avec d'autres fonctions, il me
> faudrait passer comme argument, et recuperer comme resultat, tous les
> flux que j'utilise.
Manipuler des flux fonctionnels (que sont actuellement les streams de caml)
n'empeche pas d'avoir des pointeurs (references) globaux qui pointent sur des
streams pour simuler le pattern matching destructif. Cela n'est pas trop
couteux.
> ....
> Si on l'ecrit dans un
> langage sans flux destructifs, il reste au PROGAMMEUR a` traduire
> ce programme dans le langage pauvre et purement fonctionnel.
Je ne parle pas de programmes dans un langage purement fonctionnelle, mais
simplement de changer le comportement du patterne matching sur les streams,
qui si l'on oublie la fonction stream_next semblent purement fonctionnels.
> .......
Donc en resume :
- Pour moi, si l'on excepte le patterne matching et la fonction
stream_next, et que l'on a le patch pour corriger le bug, les streams sont
purement fonctionnels.
- Alors pourquoi ne pas changer le comportement du patterne matching ?
- L'utilisation des streams avec "stream_get" au lieu de "stream_next"
fait-elle notablement baisser les performances ?
- Pour moi dans un langage fonctionnelle il doit y avoir des
manipulations physiques, etc ..... Mais les fonctions de bases tel que le
patterne matching devrait rester purement fonctionnelles.
Christophe