Version française
Home     About     Download     Resources     Contact us    
Browse thread
flux et filtrage de flux Stream pattern matching
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: murthy@m...
Subject: flux et filtrage de flux Stream pattern matching

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