Subject: flux et filtrage de flux
To: caml-redistribution@margaux
Date: Tue, 16 Mar 1993 18:56:59 +0100 (MET)
To: caml-list@margaux
Subject: Stream pattern matching
Return-Receipt-To: murthy@margaux
Date: Tue, 16 Mar 93 17:43:02 N
Hum ... OK ... si le debat est ouvert, je dirai qqchose pour une
implementation destructive.
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.
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".
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.
Bien, c'est toujours faisable. Aussi faisable qu'utiliser des
arguments supplementaires plutot qu'utiliser un champs mutable. Et
aussi inefficace en termes de temps de programmation et d'exe'cution.
Et, encore pire, on peut dire qu'un programme ecrit comme ca, c'est
plus propre - mais, en fait, c'est simplement ecrit dans la "monade"
des flux, sauf que c'est sans l'aide des "definitions" de monades.
C'est-a-dire, il n'y a qu'un programme source. 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.
Si on l'ecrit dans un langage avec flux destructifs, le compilo le
fait.
En tout cas, c'est le meme programme. Et ce sera aussi difficile de
verifier, une fois traduit dans le langage purement fonctionnel, que
ce l'etait dans le langage imperatif - la difference est une simple
expansion des definitions.
Je trouverai difficile la tache de programmer dans un langage sans
flux destructifs - aussi difficile que dans un langage purement
fonctionnel.
Et, pour revenir a` l'argument premier, j'attends toujours un systeme
lazy/purement fonctionnel qui est assez efficace pour qu'on puisse l'utiliser
pour la programmation systeme. Les langages stricts comme ML sont a`
peine assez efficace.
Ah, oui - aussi, dire que les langages purement fonctionnels sont
assez efficace - a peu pres un facteur de 2 (ou 4 ou 10 ou whatever)
(up to a factor of 2 or whatever) n'est pas une reponse - le meilleur
espoir de tous les optimiseurs du monde, c'est de couper des facteurs
constants.
--chet--
[ Note du mode'rateur:
La politique de l'e'quipe d'imple'mentation Caml sur le sujet a
toujours e'te' pragmatique: on ne peut pas raisonnablement se passer
de traits impe'ratifs, pour des raisons d'efficacite' (complexite'
des algorithmes) aussi bien que de lisibilite'. La se'mantique
de'notationnelle d'un programme qui passe explicitement une me'moire
en argument supple'mentaire a` toutes les fonctions, est purement
fonctionnelle et purement illisible.
Les arguments en faveur du ``purement fonctionnel'' ne peuvent e^tre
eux aussi que de pure lisibilite' et e'le'gance. Ce point est
particulie`rement e'vident dans l'arithme'tique de Caml V3.1. La
programmation purement fonctionnelle avec le type num est
incomparablement plus facile et lisible que la programmation
impe'rative avec le type nat. Il faut alors ne pas he'siter a`
l'employer: il faut impe'rativement programmer fonctionnel. Ce n'est
pas une raison pour l'e'riger en syste`me et se forcer a` ne jamais
employer d'effets de bords.
Les arguments de ``re'sultat e'quivalent'' sont des arguments de
matheux pas d'informaticien.
Finalement le proble`me vient de la connotation du mot ``pur''.
Supposons que l'usage soit d'employer le mot ``be^te'' a` la place,
personne ne viendrait re'clamer une version ``be^tement fonctionnelle''
des flux! (Je me sens me^me obliger d'ajouter imme'diatement que je
ne conside`re pas cette demande comme une be^tise, mais bien comme
une purise)
Pierre Weis
----------------------------------------------------------------------------
Formel Project
INRIA, BP 105, F-78153 Le Chesnay Cedex (France)
E-mail: Pierre.Weis@inria.fr
Telephone: +33 1 39 63 55 98
----------------------------------------------------------------------------
]