_ a écrit 73 commentaires

En OCaml par exemple tu as un GC générationnel, avec un tas mineur (petit et rapide à collecter, pas de problème de pause) et un tas majeur pour les vieux objets, plus gros, et collecté incrémentalement. Il n'y a une pause (tas majeur complet et compaction) que dans les situations critiques où il n'y plus assez de mémoire pour continuer à allouer. Le critère de "trop de mémoire" (ou trop de fragmentation) est configurable, tu peux dire "je veux une pause quand j'arrive aux 3/4 de ma mémoire occupée".

C'est le cas en java aussi en passant (i.e. une grande partie des programmes côté serveur en profite aujourd'hui déjà).

Il me semble que les primitimes offertes au programmeur sont des fonctions d'ordre supérieur builtin. Et sans cela, c'est fonctionnel au sens "pas d'état", qui est pour moi l'essence du fonctionnel: les langages de dataflow proposent de remplacer l'état mutable par de la transformation de données.

Si je me rappelle bien, le langage fournit une interface programmatique pas trop effrayante pour le programmeur non fonctionnel mais il s'agit seulement de sucre syntaxique pour (encore une fois) du FRP.

Le typage statique de SBCL reste assez limité malheureusement. Mais bon c'est quasi impossible de typer un langage à macros si le langage de macro n'est pas limité d'une manière ou d'une autre. Meta OCaml (et Scala Virtualized) proposent de la metaprogrammation typesafe mais c'est beaucoup plus limité que LISP. C'est plutôt dans une optique de multi staged programming que d'extensibilité du langage.

Oui, j'avais inféré le contournement, mais dans mon modèle mental (érroné) selon lequel les entiers étaient capturés par référence et passé aux fonctions par valeur ça s'expliquait bien :)

Je suppose que tu évoques LISP à cause de la partie sur les structures de contrôle et les arguments passés par nom ? En fait, pour ce que Mildred demande la puissance des macros n'est même pas nécessaire j'ai l'impression, de simples fermetures suffisent (c'est ce que fait smalltalk justement pour le if, et le branchement builtin est caché dans la liaison dynamique).

La partie vraiment pas évidente c'est le typage optionnel. Il y a eu pas mal de littérature sur le gradual typing (ou soft typing) et les blame tracking type systems, mais à l'exceptions de langages comme Racket (évoqué par gasche) il n'y a pas encore d'implémentation sérieuse de ces systèmes à ma connaissance. Dart est un des premiers environnements "grand public" à proposer ça mais la partie typée n'est pas sûre (typesafe)...

Maintenant, je ne sais pas si Mildred a connaissance de l'existence l'inférence de type si par "typage optionel" elle entendait "annotations de typage optionnelles". Les programmeurs font parfois cet amalgame. Dans le dernier cas, son langage ressemblerait beaucoup à haskell (ou à un ML qui aurait un bon support pour la concurrence, JoCaml peut-être ?). Les deux seuls points que haskell ne remplit pas sont:

• langage objet: mais les existentiels + typeclasses fournissent une fonctionnalité similaire;
• une VM généraliste: là-dessus j'ai été récemment assez convaincu par les auteurs de Dart qu'une telle chose n'existe pas. (Je ne leur fais pas super confiance pour le design du langage - quoique Bracha a rejoint la troupe, mais il a aussi un peu déraillé sur son blog récemment - mais pour son implémentation si : ce sont les gens qui ont bossé sur V8, Hotspot avant et self encore avant, ils savent en général de quoi ils parlent.)

Quand à Lustre, c'est pas un langage fonctionnel.

Vraiment ? Je ne connais pas bien Lustre (j'ai juste vu un exposé de Marc Pouzet une fois puis je l'ai vu cité dans des papiers de FRP) mais il me semblait bien qu'il s'agissait d'un langage fonctionnel au sens ou je l'ai "défini" au-dessus.

D'après la wikipedia c'est un language de dataflow et d'après la même wikipedia:

Dataflow programming languages share some features of functional languages, and were generally developed in order to bring some functional concepts to a language more suitable for numeric processing.

et plus loin:

Dataflow programming focuses on how things connect, unlike imperative programming, which focuses on how things happen.

Donc il doit bien y avoir un rapport quelque part.

Ok donc ça signfie que dans ce cas la fermeture possède une référence vers la portée qui contient i plutôt que vers i directement ? Autrement dit, les environnements des closures de python sont mutables.

Sinon je ne suis pas un habitué de linuxfr mais pourquoi mon post du dessus est-il noté à -1 ? Est-ce que c'est le système qui l'assigne automatiquement ou est-ce que quelqu'un a "downvoté" ce que j'ai mis au-dessus ? Dans le dernier cas pourquoi ? Est-ce que j'ai dit quelque-chose d'offensif ou d'inutile ?

Dans ce cas pour moi c'est un problème lié, sinon à la portée lexicale, au mécanisme de closures (à moins que je loupe quelque chose): les types builtins sont capturés par référence alors qu'ils sont passés par valeur aux fonctions. Ce n'est pas seulement un problème d'implémentation de la boucle for (qui ne redéfinit pas un i à chaque pas) si ce dont tu parlais.

oui, dommage que ça incluse des langages aussi populaires que Coffeescript, ou les premières versions de Ruby

Et python aussi... je ne sais pas pourquoi il passe toujours à travers les gouttes dans ces discussions sur la portée lexicale.

>>> fs = []
>>> for i in range(3):
...   fs.append(lambda: i)
... 
>>> for f in fs:
...   print f()
... 
2
2
2

Ça ressemble aussi beaucoup à scala.react.

C'est une implémentation en scala du FRP avec un langage de dataflow impératif en surface grâce aux continuations délimitées.

Par exemple, tiré du papier:

val drags = Events.loop { self =>
  self next mouseDown
  val mu = self.loopUntil(mouseUp) {
    self emit Drag(self next mouseMove)
  }
  self emit Drop(mu)
}

Il y a à ce propos des excellents slides de François Pottier.

J'ai pas dit que ça marchait, j'ai juste dit que ça existait encore ! Je suis complètement d'accord avec ton commentaire selon lequel c'est encore expérimental.

Concernant FRP, je m'en fiche un peu de vexer les gens tant que l'appellation est correcte :) Et là aussi, je n'ai pas sous-entendu que c'était un langage généraliste.

Oui ça existe encore, JHC utilise la region inference à la place. Certains langages de FRP comme Lustre qui visent l'embarqué se passent aussi de GC si je me souviens bien (en contrepartie, on est limité à certaines primitives pour manipuler le flot d'évènement).

Le fait d'avoir des fonctions de première classe permet d'abstraire sur des valeurs fonctionnelles mais on peut faire déjà beaucoup de choses fonctionnelles sans ça.

Autrement dit, il n'y a pas besoin d'ordre supérieur pour dériver des équations du style

concat (xs ++ ys) = concat xs ++ concat ys

et en tirer parti.

Le fait d'avoir des fonctions de première classe permet d'abstraire sur des valeurs fonctionnelles mais on peut faire déjà beaucoup de choses fonctionnelles sans ça.

Ensuite si l'on considère que les fermetures et le GC sont nécessairement liés à la programmation fonctionnelle, alors oui, ça a du sens de dire que le langage supporte la programmation fonctionnelle, mais dans ce cas "closure" et "garbage collector" sont redondants dans la phrase "closure, programmation fonctionnelle, garbage collector". Donc j'ai supposé qu'il entendait par là autre chose.

Je crois qu'il va falloir inventer le Turing tar pit tar pit :)

Si j'avais dit: "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une chaîne de tests en retournant un booléen à chaque appel", je serais tombé dans le Turing tar pit parce que c'est une solution moins efficace qu'un support natif, et qui fournit moins de garanties statiques (checked exceptions par exemple).

Si j'avais dit "Ça n'a pas de sens de rajouter des exceptions dans X, parce que tu peux les simuler par une transformation CPS", je serais tombé dans le Turing tar pit parce que c'est une transformation non locale et non triviale.

Ce que je voulais dire ici c'est que justement, il n'y pas non seulement pas besoin de support du langage pour faire de la programmation fonctionnelle, mais un langage n'a que peu à offrir en la matière. Il s'agit plus d'une philosophie de programmation.

Maintenant, certains langages (comme haskell) encouragent ce style de programmation en confinant par typage les effets de bords. Certains environnements (comme scala) encouragent ce style de programmation en fournissant des structures de données persistantes dans la bibliothèque standard. Dans les deux cas, il ne s'agit pas d'une simulation et ça n'a donc rien à voir avec le Turing tar pit.

Pour en revenir au sujet de départ, je pense que la personne qui a écrit le journal voulait parler de la capacité du langage à abstraire sur les fonctions, qu'on associe souvent aux langages fonctionnels parce qu'elle y est lié historiquement et, je suppose, parce qu'il y a "fonction" dans "fonctionnel". Ma remarque portait là-dessus.

Gentiement.

Autrement dit, on peut très bien faire de la programmation fonctionnelle en C par exemple. Il suffit de s'assurer que les fonctions sont pures. En contrepartie le debugging, le test, le raisonnement équationnel et la compositionalité s'en trouvent facilités.

Voir ce texte par exemple.

je ne mettrais aucun des trucs à la mode du genre [...] programmation fonctionnelle

Étant donné que "programmation fonctionnelle" désigne un style de programmation dans lequel on ne fait pas d'effets de bords (i.e. les fonctions sont des fonctions au sens mathématique), ça n'a pas beaucoup de sens de la "mettre" ou pas dans un langage.

Pardon, je me suis mal fait comprendre. Je citais une phrase plus haut et je montrais que c'était pas très convaincant.

Mais moi aussi je penses de plus en plus fonctionnel, ca n'empêche que je trouve que le travail intellectuel qu'il nécessite (à savoir un gros travail de synthèse et un haut niveau d'abstraction) est beaucoup plus contraignant qu'un "simple" code procédural.

x = f(a1 ... an);
y = g(x,b1 ..... bm);
return h(x,y,c1 ... cp);


let x = f a1 ... an in
let y = g x b1 ..... bm in
h x y c1 ... cp


j'ai relus le texte en cherchant les fautes, et n'en ai trouvé aucune :-)

Je ne connais pas en détail les licences utilisées par google dans ce projet, mais OpenMoko me semble bien plus libre

...

Je ne connais pas cette personne ni ce langage mais je ne comprends pas ce que "premier langage fonctionnel auto-prouvé (!), à la compilation" signifie.

Je ne comprends pas non plus ce que "jeter curry-howard à la poubelle" signifie. Est-ce que cela veut dire que le langage fonctionnel en question ne repose pas sur la théorie des types ?

Le rho-calcul est un lambda-calcul avec patterns, où l'on peut abstraire sur des patterns. Par exemple : (lambda P(x,y) . x P(a,b)) -> a.
L'idée au départ était de canaliser la réécriture au travers de stratégies exprimées dans ce calcul. On peut également le voir comme un calcul plus proche des langages usuels de programmation fonctionnelle que ne l'est le lambda-calcul.

Les originalités du langage sont la capacité à traiter les cas d'erreur (contrainte de filtrage non satisfaites) et la gestion du filtrage non unitaire (collection de résultats). Dans certaines de ses versions, il est muni d'un système de types (à la PTS) avec les meta-propriétés qui en découlent et il y a des versions qui typent les point fixes.

Pour plus d'infos : http://rho.loria.fr

C'est exactement le genre d'applications pour lesquelles Tom est fait. On fournit un moyen de s'interfacer facilement avec ANTLR (http://www.antlr.org) et on travaille sur une signature algébrique représentant de manière "naturelle" un programme Java. Ainsi, il sera possible de définir et tester rapidement des transformations, analyse statique de code, etc. de programmes Java.

Ce travail n'est pas complètement terminé car la grammaire complète de Java est un gros morceau, mais il est bien sûr déjà possible de prendre un parser Java existant et ne récupérer que la partie intéressante pour bosser dessus.

Un interfaçage encore plus transparent avec Antlr est prévu pour la prochaine version.

Oui bien sûr ça peut remplacer XSLT, on a même une syntaxe spéciale pour manier plus facilement les arbres XML, même si on peut utiliser la syntaxe algébrique aussi.

Le gros avantage par rapport à XSLT c'est qu'on contrôle explicitement la stratégie d'application des règles, qui d'habitude doit être gérée par un ensemble de règles artificielles mélangées aux règles qui ont du sens. Sur de gross projets, ça devient simplement impossible à maintenir.