Publicité
+ Répondre à la discussion
Page 2 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 21 à 40 sur 61
  1. #21
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    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.

  2. #22
    Membre expérimenté
    Inscrit en
    avril 2006
    Messages
    431
    Détails du profil
    Informations forums :
    Inscription : avril 2006
    Messages : 431
    Points : 530
    Points
    530

    Par défaut

    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.

  3. #23
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 567
    Points
    17 567

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  4. #24
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    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.

  5. #25
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 096
    Points : 4 160
    Points
    4 160

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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).

  6. #26
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 096
    Points : 4 160
    Points
    4 160

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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.

    Citation Envoyé par NokyDaOne Voir le message
    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.

  7. #27
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    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.

  8. #28
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 096
    Points : 4 160
    Points
    4 160

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    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.

    Citation Envoyé par bluestorm Voir le message
    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).

  9. #29
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    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).

  10. #30
    gl
    gl est déconnecté
    Rédacteur/Modérateur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 096
    Points : 4 160
    Points
    4 160

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    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.


    Citation Envoyé par bluestorm Voir le message
    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.

  11. #31
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    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 ?

  12. #32
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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 :
    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.

  13. #33
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par LLB Voir le message
    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.

    Citation Envoyé par LLB Voir le message
    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 :
    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.

  14. #34
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    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à ?

  15. #35
    Membre expérimenté
    Inscrit en
    avril 2006
    Messages
    431
    Détails du profil
    Informations forums :
    Inscription : avril 2006
    Messages : 431
    Points : 530
    Points
    530

    Par défaut

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

  16. #36
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par LLB Voir le message
    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.

  17. #37
    Membre émérite
    Inscrit en
    mars 2010
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 308
    Points : 888
    Points
    888

    Par défaut

    Citation Envoyé par NokyDaOne Voir le message
    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.

  18. #38
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

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


    Citation Envoyé par NokyDaOne
    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.

  19. #39
    Membre régulier
    Inscrit en
    septembre 2007
    Messages
    99
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 99
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par TropMDR Voir le message
    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.

  20. #40
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •