Discussion :

[NokyDaOne]

euh c'est extrêmement réducteur... tu en arrives presque à dire que C = assembleur en terme de fonctionnalités
je sais bien que les aficionados français des langages fonctionnels sont plus proches de la famille ML, mais il ne faudrait tout de même pas dire que la famille Algol (et son représentant le plus représenté aujourd'hui : C) est limitée à l'assembleur...

Franchement le C de base ne fait rien d'autres que cacher les registres, cacher les push et pop lors d'appel de fonctions et cacher le startpoint pour appeler la fonction main. C'est vraiment une couche minimale sur l'assembleur. Donc ce que le C sait faire, c'est ce que l'assembleur sait faire.

[Ubiquité]

Troll pas sur mon thread !
Le C permet par exemple la programmation structurée et probablement un peu plus de vérification statique que l'Assembleur, il est aussi plus portable.

[gorgonite]

Franchement le C de base ne fait rien d'autres que cacher les registres, cacher les push et pop lors d'appel de fonctions et cacher le startpoint pour appeler la fonction main. C'est vraiment une couche minimale sur l'assembleur. Donc ce que le C sait faire, c'est ce que l'assembleur sait faire.

le langage a un peu évolué depuis les années Ritchie
après il est clair qu'il a malgré tout conservé cette capacité à effectuer des opérations assez bas-niveau, et d'inliner de l'assembleur

là dire que C = asm, ça revient à dire que C++ = C avec des struct contenant des fonctions


petit exo: fais une SOS du C99, plus large que le sous-ensemble enseigné en école ( ça vole rarement haut en général , ou alors on voit des manipulations ultra bas-niveau pour les cryptographes), et notes ce qui ne peut pas être "trivialement" réécrit en ASM via un simple parseur

[NokyDaOne]

le langage a un peu évolué depuis les années Ritchie
après il est clair qu'il a malgré tout conservé cette capacité à effectuer des opérations assez bas-niveau, et d'inliner de l'assembleur

là dire que C = asm, ça revient à dire que C++ = C avec des struct contenant des fonctions


petit exo: fais une SOS du C99, plus large que le sous-ensemble enseigné en école ( ça vole rarement haut en général , ou alors on voit des manipulations ultra bas-niveau pour les cryptographes), et notes ce qui ne peut pas être "trivialement" réécrit en ASM via un simple parseur

Je ne sais pas ce qu'est le SOS du c99 et malheureusement mes recherches sur google furent infructueuses.
P.S : Je parie que ce n'est pas du C ANSI.

[gl]

Je ne sais pas ce qu'est le SOS du c99 et malheureusement mes recherches sur google furent infructueuses.
P.S : Je parie que ce n'est pas du C ANSI.

C99 est le nom "courant" (le nom formel étant ISO/CEI 9899:1999) de la dernière version de la norme C (aussi bien pour l'ISO que pour l'ANSI ou d'autres organismes internationaux).
Et pour être précis, c'est même actuellement la seule version normalisée du langage C puisqu'elle annule et remplace la précédente version.

Il s'agit donc bien de C normalisé par l'ANSI. Même si traditionnellement par C ANSI, on désigne plutôt la version précédente (également appelé C89 ou C90).

[gl]

Tous les langages savent manier les fonctions (sauf JAVA qui a décider de suivre la voie 100% objet) vu que l'assembleur sait le faire.

Mais tous ne gèrent pas les fonctions d'ordre supérieur ni les fermetures, ni ne traitent les fonctions comme des objets de première classe.

Ce qui fait réellement un langage fonctionnel, c'est l'application partielle.

Même si l'application partielle vient effectivement de la programmation fonctionnelle et est très présente dans les langages fonctionnels, ce n'est visiblement pas une condition nécessaire dans la plupart des définitions de ce qu'est la programmation fonctionnelle.

[gasche]

gl > si un langage ne supporte pas les fonctions de première classe, pour moi ce n'est pas un langage fonctionnel. Et pour faire cela il faut avoir des fermetures (sinon on ne peut pas créer des fonctions qui capturent une partie de leur environnement, comme le font les constructeurs de données classiques), et une fois que tu as ça tu as tout ce qu'il faut pour avoir ce qu'on appelle "application partielle" et qui consiste en fait simplement à écrire des fonctions qui renvoient des fermetures.

(On peut éventuellement discuter de la nécessité ou non des lambda-abstractions, ou fonctions anonymes; pour moi ce n'est pas inoubliable puisque les lambda-abstractions sont macro-expressibles avec des fonctions nommées)


NokyDaOne > ce que tu dis ne veut toujours pas dire grand chose à mon avis. D'abord tu dis que l'assembleur "gère les fonctions". Clairement, tu ne veux pas dire que l'assembleur est un langage qui a un concept sémantique de "fonction", car ce n'est pas vrai (en tout cas pour ceux que je connais). Tu veux donc dire que ce qu'on définit habituellement comme des "fonctions" dans un langage plus haut niveau peut être exprimé, par le biais d'une passe de compilation (automatique ou manuelle), en assembleur.
Certes, mais d'abord tu ne dis pas ce que veux dire "gérer les fonctions". De quelles fonctions parles-tu ? Celles de C ? Justement on est en train d'expliquer que le concept de "fonctions" en C n'est pas assez riche par rapport à d'autres langages.
"gérer les fonctions" ça veut dire permettre d'effectuer les opérations que l'on désire, qui mettent en œuvre des fonctions. Pour moi ce que tu appelles "les applications partielles" fait partie de ces opérations. Donc pour moi, "gérer les fonctions" ça veut aussi dire ça (ou alors il faut être plus précis).
Enfin, l'assembleur "gère" les "applications partielles", au même sens qu'il "gère" les fonctions : on peut compiler un code utilisant des "applications partielles" (en réalité des constructions de fermetures) vers de l'assembleur, c'est ce que font les compilateurs de langage fonctionnels.

Pour moi ta remarque n'a donc pas de sens. Pour tout langage compilé vers de l'assembleur tu peux dire "ce que **** sait faire, c'est ce que l'assembleur sait faire", autrement dit l'assembleur, avec cette conception, sait tout faire, et on ne peut pas différencier des fonctionnalités selon ce critère.

[gl]

gl > si un langage ne supporte pas les fonctions de première classe, pour moi ce n'est pas un langage fonctionnel. Et pour faire cela il faut avoir des fermetures (sinon on ne peut pas créer des fonctions qui capturent une partie de leur environnement, comme le font les constructeurs de données classiques),

Entièrement d'accord.
C'était d'ailleurs précisément le sens de ma remarque : ce n'est pas parce que la majorité des langages supportent la notion de fonction que ce sont des langages fonctionnels, pour cela il faut traiter les fonctions comme des objet de première classe, etc.

et une fois que tu as ça tu as tout ce qu'il faut pour avoir ce qu'on appelle "application partielle" et qui consiste en fait simplement à écrire des fonctions qui renvoient des fermetures.

Oui, mais :

• L'application partielle est la conséquence d'avoir un langage fonctionnel. Ce n'est pas une condition nécessaire pour dire qu'une langage est fonctionnel.
• J'ai considéré, peut être à tort, que NokyDaOne parlait d'application partielle "automatique" (i.e. le développeur ne se préoccupe que de la fonction "principale", et le compilateur se charge de tout ce qui est nécessaire pour gérer les applications partielles. Le développeur n'ayant justement pas à écrire les n fonctions qui renvoient les fermetures qu'il faut). Ce qui me semble encore moins être indispensable pour qualifier un langage de fonctionnel. Effectivement, s'il parlait simplement de la capacité à pouvoir écrire soi-même ces fonctions, ma remarque perd de son sens (mais il n'en reste pas moins que même dans ce cas, c'est plus une conséquence du paradigme fonctionnel qu'une cause).

[gasche]

Qu'est-ce qu'une application partielle "automatique" ?

Dans les langages typés que je connais, la curryfication n'est pas "automatique" mais bien spécifiée par le programmeur. Autrement dit, on décrit (bien que la syntaxe soit concise et agréable à utiliser) exactement la construction des fermetures etc. (indépendamment des potentielles optimisations du compilateur; en particulier l'"arity-raising" est très utile ici).

Par exemple en OCaml quand tu écris :
let f x y z = foo
C'est syntaxiquement équivalent à :
let f = fun x y z -> foo
Lui-même équivalent à
let f = fun x -> fun y -> fun z -> foo
qui est une forme explicitement curryfiée; il n'y a rien d'automatique, juste un sucre syntaxique.

Je peux imaginer des langages où la curryfication est "implicite", dans le sens où si on donne seulement une partie des paramètres à une fonction n-aire, le typeur insère lui-même une abstraction qui attend les arguments suivants. Ça doit être possible en Scala¹, avec des cœrcions explicites, en Coq, ou avec une extension Haskell bizarre (surcharger l'application), mais à ma connaissance les gens ne le font pas.

¹ : il me semble que le style idiomatique en Scala est plutôt d'écrire des fonctions non curryfiées f(x,y), et d'utiliser leur sucre syntaxique d'abstraction quand nécessaire : f(foo,_) pour abstraire selon le second argument.


Bref, je ne suis pas sûr de bien comprendre ce que voudrait dire "l'application partielle est nécessaire pour avoir un langage fonctionnel". Pour moi, l'application partielle n'existe pas vraiment, c'est plutôt un nom qu'on donne à une combinaisons de fonctionnalités (elles indispensables) qui permet de formuler élégamment certaines choses (mais qui a aussi des défauts).

[gl]

Par exemple en OCaml quand tu écris :
let f x y z = foo
C'est syntaxiquement équivalent à :
let f = fun x y z -> foo
Lui-même équivalent à
let f = fun x -> fun y -> fun z -> foo
qui est une forme explicitement curryfiée; il n'y a rien d'automatique, juste un sucre syntaxique.

Je peux imaginer des langages où la curryfication est "implicite", dans le sens où si on donne seulement une partie des paramètres à une fonction n-aire, le typeur insère lui-même une abstraction qui attend les arguments suivants. Ça doit être possible en Scala¹, avec des cœrcions explicites, en Coq, ou avec une extension Haskell bizarre (surcharger l'application), mais à ma connaissance les gens ne le font pas.

¹ : il me semble que le style idiomatique en Scala est plutôt d'écrire des fonctions non curryfiées f(x,y), et d'utiliser leur sucre syntaxique d'abstraction quand nécessaire : f(foo,_) pour abstraire selon le second argument.

C'est bien à ce type de mécanisme (sucre syntaxique par dessus la forme curryfié, curryfication implicite, etc.) auquel je faisais allusion par "automatique" : tout mécanisme permettant de ne pas avoir à explicitement écrire à la fois les formes curryfiées et non curryfiée de ladite fonction (comme on pourrait être amené à le faire pour émuler un comportement proche dans des langages non-fonctionnels).
Ça peut être aussi simple que de tout implémenter sous forme currifyée et d'avoir une syntaxe d'appel de fonction assez simple pour enchaîner les appels des fermetures retournées de manière "transparente" (que cette syntaxe soit "f a b", "f(a)(b)", ou quoique ce soit d'autre).

Le terme "automatique" n'est probablement pas le bon, mais je n'en trouve pas de meilleur pour désigner les différentes méthodes qui pourraient exister.

Bref, je ne suis pas sûr de bien comprendre ce que voudrait dire "l'application partielle est nécessaire pour avoir un langage fonctionnel". Pour moi, l'application partielle n'existe pas vraiment, c'est plutôt un nom qu'on donne à une combinaisons de fonctionnalités (elles indispensables) qui permet de formuler élégamment certaines choses (mais qui a aussi des défauts).

Là encore, je suis 100% d'accord avec toi.

[NokyDaOne]

Le mieux serait que l'on liste les langages fonctionnel et pas fonctionnels. De là on pourrait faire le tour des propriétés de ces langages et trancher sur ce qui fait d'un langage un langage fonctionnel (150 sur application partielle ? Qui veut parier )

Et sinon je ne vois pas pourquoi certains sont gênés par le fait que je dise que l'assembleur gère les fonctions (pointeurs) mais pas l'application partielle. J'ai connu des langages qui ne faisaient même pas ce que faisait l'assembleur, donc oui l'assembleur gère les fonctions, dire le contraire, c'est juste prouver que l'on a pas travailler avec un langage qui ne gère réellement pas les fonctions sinon la différence sauteraient aux yeux.

gl t'as un exemple de choses en C qui sont difficilement portable en assembleur ?

[LLB]

Le mieux serait que l'on liste les langages fonctionnel et pas fonctionnels. De là on pourrait faire le tour des propriétés de ces langages et trancher sur ce qui fait d'un langage un langage fonctionnel (150 sur application partielle ? Qui veut parier )

Comment faire les listes de langages si l'on n'a pas les critères ? Est-ce que tu classes Lisp, Ruby, Python, Perl, C#, C++0x dans les langages fonctionnels ?

Pour moi (comme ça a été dit), il suffit d'avoir des fonctions de premier ordre pour avoir un langage fonctionnel. Beaucoup de langages supportent ça sans avoir d'application partielle.

gl t'as un exemple de choses en C qui sont difficilement portable en assembleur ?

Le C fait du typage et de la vérification statique. Un bon compilo C fait aussi des optimisations non triviales. GCC optimise l'exemple suivant et n'utilise pas la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int factorial(int x) {
   if (x > 1) return x * factorial(x-1);
   else return 1;
}

Mais je ne comprends toujours pas pourquoi tu persistes à vouloir parler d'assembleur dans ce sujet.

[NokyDaOne]

Comment faire les listes de langages si l'on n'a pas les critères ? Est-ce que tu classes Lisp, Ruby, Python, Perl, C#, C++0x dans les langages fonctionnels ?

Lisp bien évidemment.
Perl que dalle
Python je ne sais pas
Ruby je crois que c'en est un.

L'idée est que l'on se mette d'accord sur la liste des langages fonctionnels et de là on verra quels sont vraiment les critères.

Le C fait du typage et de la vérification statique. Un bon compilo C fait aussi des optimisations non triviales. GCC optimise l'exemple suivant et n'utilise pas la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int factorial(int x) {
   if (x > 1) return x * factorial(x-1);
   else return 1;
}

Mais je ne comprends toujours pas pourquoi tu persistes à vouloir parler d'assembleur dans ce sujet.

Ton exemple là ne prouve strictement rien. On parle de langage pas de compilateur (ça vaut le coup de voir si gcc sait compiler ça aujourd’hui sans faire de la ***). Ton exemple je le code sans problème en assembleur, et je te l'iline même si tu veux ( ). gl avait l'air de parler d'autre chose et c'est ça qui m’intéresse.

[LLB]

On parle de langage pas de compilateur

Le C permet aux compilateurs de faire des réécritures complexes, alors que ça ne se fait pas pour l'assembleur (lequel d'ailleurs ?). Le standard C n'impose rien à ce niveau, mais ça reste un avantage en pratique. Encore une fois, n'oublie pas non plus tout ce qui concerne la vérification statique.

L'idée est que l'on se mette d'accord sur la liste des langages fonctionnels et de là on verra quels sont vraiment les critères.

Comment se mettre d'accord sur les langages, si l'on n'est pas d'accord sur les critères ? Je mettrai dans ma liste tous les langages qui permettent les fonctions de premier ordre... et l'on verra que c'est vraiment un critère. Je ne porterai pas d'attention à l'application partielle... et l'on verra que ce n'est pas vraiment un critère ? J'ai l'impression de tourner en rond.

Mais déjà, Lisp ne fait pas de base (dans le sens de gl) d'application partielle. On s'arrête là ?

[Ubiquité]

LLB, on dit pas objet de première classe plutôt que fonction de premier ordre ?

[NokyDaOne]

Mais déjà, Lisp ne fait pas de base (dans le sens de gl) d'application partielle. On s'arrête là ?

Lisp ne fait pas d'application partielle (dans le sens de gl) ?
Et alors c'est le sens selon une personne. Lisp fait des applications partielles, c'est même son but premier (vu que lisp est une pseudo implémentation du lambda calcul) et ne me dites pas non, j'en ai déjà faites. Je l'ai vu de mes propre yeux.

[TropMDR]

Le mieux serait que l'on liste les langages fonctionnel et pas fonctionnels.

Il faudrait détailler un peu plus quand même...

Python a des fermetures et des fonctions de première classe, et même des listes non mutables. Ca n'en fait pas un "langage fonctionnel", parce qu'il ne te pousse pas du tout à utiliser cette approche, qu'elle est peu exploité dans la librairie standard, et que ce n'est pas du tout dans la culture de sa communauté.

Et puis un programmeur Haskel pourra avec un minimum de mauvaise foi (<troll>et tout bon programmeur Haskel a ça en sock :p</>) justifier que caml n'est pas un langage fonctionnel parce qu'ils attachent aussi la persistance à la notion de "fonctionnel" (on parle souvent de "structure fonctionnelle" alors qu'il n'y a pas une seule fonction dans la structure, juste parce qu'elle n'est pas mutable)

Et je trouve que la présence de sucre syntaxique pour définir dans quelle catégorie se trouve un langage est un peu absurde (je parle ici de l'histoire de l'application partielle).

Bref, Lisp, Haskell, OCaml sont des langages fonctionnels
Python, C + Block, C++0x sont des langages ayant incorporés des traits fonctionnels
C et java ne sont *pas* des langages fonctionnels.

[gasche]

Comme j'avais pris soin de le dire en début de topic :

Il n'y pas de définition stricte et formelle de ce qu'est un "langage fonctionnel". Il y a des outils utiles pour faire de la programmation fonctionnelle, mais souvent c'est aussi une convention "sociale", les langages dans lequel le style fonctionnel est encouragé.

Ça ne sert à rien de débattre pendant des heures d'une définition qui est, de toute façon et par essence, subjective. Il vaut mieux se rattacher à certains points objectifs qui sont la disponibilité de tel ou tel fonctionnalité sémantique dans un langage (fonctions de premier ordre, fermetures, typage statique, filtrage de motif...), ou propriétés de la sémantique (différence expression/instruction, présence de lvalues, transparence référentielle, garbage collection) ou de son implémentation (optimisation des appels tail-rec ou tail-call, performance des appels indirects, ...).

Après chacun est libre de juger que tel ou tel aspect est nécessaire ou incompatible avec le label rouge "langage fonctionnel", mais je pense que c'est un débat stérile. Par contre dire qu'on a besoin d'un de ces aspect parce qu'il permet ceci ou cela qui est désirable, c'est une bonne idée (même si ça reste souvent difficile à mesurer objectivement).


En plus de la difficulté d'isoler un concept de "langage fontionnel", il y a des critères sociaux qui font que deux langages même avec les mêmes fonctionnalités peuvent être utilisés très différemment. Par exemple dans la famille des Lisp il y a des langages très proches, mais dont certains mettent en avant un style fonctionnel (Scheme par exemple), la limitation des effets de bords et l'utilisation généreuse de la récursivité, alors que d'autres Lisp favorisent au contraire un style impératif et procédural, avec des variables modifiables et des boucles.

À ce compte là, un langage est fonctionnel à partir du moment où la majorité de ses utilisateurs le décrivent comme un langage fonctionnel...

Et sinon je ne vois pas pourquoi certains sont gênés par le fait que je dise que l'assembleur gère les fonctions (pointeurs) mais pas l'application partielle. J'ai connu des langages qui ne faisaient même pas ce que faisait l'assembleur, donc oui l'assembleur gère les fonctions, dire le contraire, c'est juste prouver que l'on a pas travailler avec un langage qui ne gère réellement pas les fonctions sinon la différence sauteraient aux yeux.

Je suis gêné parce que ce que tu dis est faux. Je n'ai regardé en profondeur que l'assembleur MIPS, mais j'ai vu aussi et peu de x86 et de PowerPC, et dans aucun de ces assembleurs il n'y a de concept de fonction. Les fonctions n'existent pas en assembleur. Il y a des branchements (directs ou indirects) pour le flôt de contrôle, avec une facilité pour stocker une adresse de retour, souvent un support d'une pile (c'est à dire simplement un registre qui s'appelle "stack pointer" et parfois certaines instructions pour le manipuler) qui permet d'empiler des données, mais il n'y a pas de fonctions¹, à fortiori pas de pointeur de fonctions (par contre il y a des adresses vers des segments de code), pas de convention d'appel, etc.

¹ : puisqu'on en arrive là, je pense à des fonctions au sens du lambda-calcul : quand on leur donne un argument (ou plusieurs), elles s'évaluent en un résultat. Je me contenterais de procédure à qui on donne un argument et qui ne renvoient rien, mais ça n'existe pas non plus.

On peut bien sûr organiser ses programmes assembleurs de la même façon qu'on le ferait dans un langage avec des fonctions : on passe des valeurs sur la pile ou en registre, quand on fait des appels on sauvegarde les registres caller-save, etc. C'est d'ailleurs ce que font les compilateurs qui traduisent un langage avec fonctions vers de l'assembleur. Mais ça ne donne pas pour autant de sens à l'affirmation "l'assembleur gère les fonctions", puisqu'à ce compte-là l'assembleur gère tout.

NokyDaOne, ça fait plusieurs messages dans ce thread que j'ai l'impression que tu ne comprends pas ce dont tu parles. Si tu pouvais étayer un peu tes dires au lieu d'ignorer soigneusement mes remarques, je serais plus content quand je viens lire ce thread. Et j'aime bien être content.


TropMDR > Haskell n'est pas un langage fonctionnel, il a programmes qui ne terminent pas.

[NokyDaOne]

Il faudrait détailler un peu plus quand même...

Python a des fermetures et des fonctions de première classe, et même des listes non mutables. Ca n'en fait pas un "langage fonctionnel", parce qu'il ne te pousse pas du tout à utiliser cette approche, qu'elle est peu exploité dans la librairie standard, et que ce n'est pas du tout dans la culture de sa communauté.

Et puis un programmeur Haskel pourra avec un minimum de mauvaise foi (<troll>et tout bon programmeur Haskel a ça en sock :p</>) justifier que caml n'est pas un langage fonctionnel parce qu'ils attachent aussi la persistance à la notion de "fonctionnel" (on parle souvent de "structure fonctionnelle" alors qu'il n'y a pas une seule fonction dans la structure, juste parce qu'elle n'est pas mutable)

Et je trouve que la présence de sucre syntaxique pour définir dans quelle catégorie se trouve un langage est un peu absurde (je parle ici de l'histoire de l'application partielle).

Bref, Lisp, Haskell, OCaml sont des langages fonctionnels
Python, C + Block, C++0x sont des langages ayant incorporés des traits fonctionnels
C et java ne sont *pas* des langages fonctionnels.

Je crois que plus on va discuter plus on va se rendre compte que l'on a tous le même critère mais que chacun lui donne un nom personnel. Tu parles de sucre syntaxique pour l'application partielle. Vu la notion que je mets derrière je te jure que ce n'est pas un sucre syntaxique.

Au global il y a un seul et unique critère : est-ce que je peux facilement créer une fonction qui ajoute 3 à partir d'une fonction qui additionne deux entiers. Si oui alors on est en fonctionnel (caml, c#, vb.net, js, lisp, python, haskell). Si non alors on est pas en fonctionnel (c, asm, java, php (sauf s'il a muté depuis le temps)).

P.S : on ne peut pas prendre en compte les habitudes de la communauté pour classifier un langage, c'est pas recevable. Un langage existe en dehors de son utilisation.

[gasche]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
camlTest__add_3_58:
.L100:
        movl    %eax, %ecx
        movl    %ebx, %eax
        movl    $7, %ebx
        jmp     caml_apply2