C++17, Genèse d’une version mineure

[^] # Re: Donc pour résumer…

Posté par groumly le 02 octobre 2016 à 20:14. Évalué à 10.

• [^] # Re: Donc pour résumer…

  Posté par freem le 03 octobre 2016 à 00:12. Évalué à 3.

  

  les temps de compilation sont long, tres long.

  Je ne le nie pas, les temps de compilation C++ peuvent être longs. Ceci étant dit, quelle est la part de lenteur due au langage, et quelle est la part due aux outils, make, par exemple?
  Parce que selon certains, pour une compilation incrémentale, make est inutilement très lent.

  Et aussi, je pense que comparer uniquement les temps de compilation est une erreur de nos jours. Après tout, si on prend Java ou C#, il me semble bien qu'une partie de la compilation est faite au lancement de l'exécutable.
  Du coup, ce qui serait objectif, c'est de comparer compilation + temps de première exécution, non?

  • [^] # Re: Donc pour résumer…

    Posté par lockidor le 03 octobre 2016 à 00:44. Évalué à 1.

    

    Du coup, ce qui serait objectif, c'est de comparer compilation + temps de première exécution, non?

    Si on compare à un langage à VM, effectivement. Mais dans ce cas, je faisais une comparaison implicite de mon expérience avec Rust (parce que c'est celui que j'utilise le plus en ce moment), qui est aussi compilé comme C++.

  • [^] # Re: Donc pour résumer…

    Posté par karchnu le 03 octobre 2016 à 00:52. Évalué à 1. Dernière modification le 03 octobre 2016 à 00:53.

    

    Je ne pense pas que ce soit pertinent : les langages qui compilent au lancement ne sont pas les plus adaptés à remplacer le C++. Deux catégories, deux outils peu comparables.

    Et si on avait un jour un langage orienté système (pas de GC, compilé…) avec une bonne gestion des dépendances et avec une programmation haut niveau façon langages de script (voire Java mais en moins verbeux), alors il est envisageable (selon moi) que nous ayons un remplaçant aux langages dynamiques. Seuls resteront ceux qui, à l’instar de Perl 5, ont été pensés pour un usage spécifique (par exemple la manipulation de texte pour Perl). Bien entendu, je n’exclus pas les hybridations, les attachements personnels ou financiers (investissement sur le long terme) ainsi que l’historique lié aux autres langages qui feront qu’on continuera à les utiliser pendant des décennies. Mais pour des nouveaux projets…

    Peut-être qu’il y a un usage extrêmement important et utile des langages dynamiques que je ne vois pas. Mais selon mon point de vue, ils arrivent presque tous à leur terme. Je ne connais pas Python, mais Perl 6 est bien moins pratique pour manipuler rapidement du texte que Perl 5 (surtout avec nos bonnes vieilles habitudes), Ruby glisse doucement vers le compilé avec Crystal… si on arrive facilement à faire de la cross-compilation, je ne vois pas l’intérêt d’un interpréteur.

    Bref, je m’égare, je rêve… il est temps de dormir. :)

    • [^] # Re: Donc pour résumer…

      Posté par anaseto le 03 octobre 2016 à 09:51. Évalué à 1.

      

      Perl 6 est bien moins pratique pour manipuler rapidement du texte que Perl 5 (surtout avec nos bonnes vieilles habitudes)

      Curieux, sur ce point j'ai pas remarqué de grandes différences : les regexp, substitutions, split, etc. c'est relativement similaire en dehors de détails cosmétiques, et le langage vient même de base avec quelques fonctions comme slurp et spurt, sans devoir charger de module supplémentaire. Après si dans le « rapidement » on inclut le temps d'exécution, alors oui, là je suis bien d'accord, ça rame encore beaucoup trop sur des trucs aussi simples qu'un split sur une chaîne de caractères avec une regexp simple (le langage a aussi le défaut d'être probablement trop gigantesque, mais ça, ça fait partie de la philosophie du langage, donc, bon).

    • [^] # Re: Donc pour résumer…

      Posté par Stibb le 04 octobre 2016 à 00:16. Évalué à 6.

      

      Ah, tu oublies Rust. Pas de GC, bas niveau, elegant,une gestion de la la memoire au petits oignons…

      • [^] # Re: Donc pour résumer…

        Posté par DerekSagan le 05 octobre 2016 à 00:47. Évalué à 3.

        

        … et une portabilité et un nombre de libs disponibles très en dessous de C++

        mais ça changera peut-être

      • [^] # Re: Donc pour résumer…

        Posté par karchnu le 05 octobre 2016 à 01:11. Évalué à 2.

        

        Je ne l’oublie pas. En fait, c’est sans doute le langage qui m’attire le plus (au moins sur le papier) pour faire de la programmation système bas niveau. Je me tâte à l’apprendre et à le proposer en projet à mes étudiants.

        Depuis quelque temps, je me demande quels sont les langages dont j’aurai vraiment besoin, et qu’il faudrait vraiment que j’apprenne, pour avoir des outils adaptés à (presque) toutes les situations. Je suis fan de Haskell, pour plein de raisons, mais pour de la programmation système c’est pas aussi intuitif que le C. Du coup, je me garderai bien du Haskell pour du haut niveau (des applications en général, un peu complexes, avec un petit paquet de fonctionnalités) et partir vers du Rust pour le système. Les deux ont une bonne communauté, des outils modernes pouvant gérer les dépendances, des compilateurs qui peuvent détecter facilement des erreurs à la compilation plutôt qu’à l’exécution (voir la gestion de la mémoire en Rust, et la prise en compte des « corner cases » en Haskell, plus un million d’autres trucs) et des concepts haut niveau pour simplifier la programmation (d’accord, les concepts d’Haskell sont très poussés, on est tous d’accord à dessus).

        • [^] # Re: Donc pour résumer…

          Posté par kantien le 05 octobre 2016 à 11:18. Évalué à 4.

          

          As-tu déjà envisagé d'étudier OCaml ? Il est de la même famille que Haskell : lambda-calcul fortement et statiquement typé, mais contrairement à lui il n'est pas pur : on peut y pratiquer les paradigmes impératif, fonctionnel et orienté objet.

          On peut y faire de la programmation système, et même faire des OS.

          MirageOS is a library operating system that constructs unikernels for secure, high-performance network applications across a variety of cloud computing and mobile platforms. Code can be developed on a normal OS such as Linux or MacOS X, and then compiled into a fully-standalone, specialised unikernel that runs under the Xen hypervisor.

          De ce que j'en ai compris, un des intérêts des unikernels est de faire de l'isolation de service et de réduire la surface d'attaque. À l'arrivée il n'y a pas à proprement parler de user-land, le noyau et l'unique application (serveur web, serveur mail, serveur de minage bitcoin…) sont fondus en un tout unique. D'où la notion de library operating system : selon l'application à la compilation on ne prend que les bibliothèques strictement nécessaire tant du noyau proprement dit que de l'application.

          d’accord, les concepts d’Haskell sont très poussés, on est tous d’accord à dessus

          Non, on n'est pas tous d'accord là-dessus. Bien souvent ce sont des concepts simples à expliquer mais les haskelleux sont pédants dans leur manière de s'exprimer et ont systématiquement recours au vocabulaire de la théorie des catégories au lieu de vulgariser leur propos.

          J'en avais fait un commentaire humoristique en illustrant les notions de catamorphisme, anamorphisme et hylomorphisme… sur l'algorithme de la multiplication tel qu'on l'enseigne à des enfants de 8 ans !

          Dans le même genre il y a ce journal (désolé Aluminium 95 ;-) où un docteur en physique, et ce n'est pas le seul, se plaignait de l'usage d'un jargon incompréhensible. Je m'y suis collé pour vulgariser le propos. En gros le problème était : comment encoder des arbres dans un langage fonctionnel dont le système de type ne dispose pas de types récursifs, et cela afin de faire un langage embarqué (EDSL) ?

          Pour ce qui est d'ailleurs du vocabulaire et des concepts utilisés en Haskell, l'abus qu'ils en font ne fait pas toujours plaisir aux spécialistes du sujet.

          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

          • [^] # Re: Donc pour résumer…

            Posté par karchnu le 05 octobre 2016 à 11:41. Évalué à 0.

            

            Haskell permet de faire lui aussi des unikernels, mais j’ai l’impression qu’il y a un problème derrière ça : on réutilise énormément de code pour produire un simple binaire. Je trouve que cela va à l’encontre de la simplicité, et je ne sais pas ce que ça pourrait donner sur des gros programmes. La philosophie Unix, moi j’aime bien, et ça la casse complètement, pour un gain pas très clair. Certes tu vas plus vite qu’en ayant toute une machine virtuelle qui tourne, m’enfin le problème ne viendrait-il pas d’ailleurs ? Il me semble concevable de juste produire un binaire et de le faire exécuter sur une machine distante sans avoir à gérer toute une VM pour ça. Le fait que nous utilisions des VM n’est qu’une question de simplicité de déploiement : on fait n’importe-quelle application, on aura du stockage, on aura du réseau. Je pense qu’il y a une autre façon de voir les choses, et je vous en parlerai bientôt.

            D’accord pour dire que la vulgarisation c’est compliqué. J’en ai bien conscience, et apprendre le Haskell ce n’est pas simple en partie à cause d’explications absconses. Je ne voulais dire que ça dans mon premier commentaire.

            • [^] # Re: Donc pour résumer…

              Posté par kantien le 05 octobre 2016 à 12:37. Évalué à 1. Dernière modification le 05 octobre 2016 à 12:40.

              

              Il me semble concevable de juste produire un binaire et de le faire exécuter sur une machine distante sans avoir à gérer toute une VM pour ça.

              De ce que j'ai compris, l'idée de la VM c'est pour l'isolation et la sécurité : si il y a une faille cela ne compromet pas l'hôte, là où une faille dans un binaire peut aller jusqu'à donner un accès root à la machine distante qui, comme elle aura un noyau complet et un user-land, offrirait des possibilités illimités à l'attaquant. Avec un unikernel, même s'il y a une faille l'attaquant ne pourra jamais en tirer partie ou très peu.

              D’accord pour dire que la vulgarisation c’est compliqué. J’en ai bien conscience, et apprendre le Haskell ce n’est pas simple en partie à cause d’explications absconses.

              Je suis bien d'accord avec toi sur la difficulté de la vulgarisation, je m'améliore avec les années mais j'ai encore de gros progrès à faire sur ce plan. Néanmoins, je maintiens que pour apprendre la programmation fonctionnelle il n'est pas nécessaire de passer par ces explications absconses. Cela peut s'avérer nécessaire si l'on veut faire des choses très poussées et évoluées¹ — comme avec le C++ de ce que j'ai compris de la discussion de ce fil ;-) — mais pour apprendre on n'en a pas besoin.

              ---

              1. Comme encoder des preuves dans le système de types pour garantir des invariants sur une structure. ↩

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

              • [^] # Re: Donc pour résumer…

                Posté par barmic le 05 octobre 2016 à 13:59. Évalué à 3.

                

                De ce que j'ai compris, l'idée de la VM c'est pour l'isolation et la sécurité : si il y a une faille cela ne compromet pas l'hôte, là où une faille dans un binaire peut aller jusqu'à donner un accès root à la machine distante qui, comme elle aura un noyau complet et un user-land, offrirait des possibilités illimités à l'attaquant. Avec un unikernel, même s'il y a une faille l'attaquant ne pourra jamais en tirer partie ou très peu.

                Techniquement, on a déjà vu des faille de sécurité d'hyperviseur et les OS commencent depuis quelques temps (oui parce que seccomp c'est pas vieux, hein ?) à avoir ce qu'il faut pour sandboxer un binaire. Pour les unikernel, je ne suis pas certain que l'idée soit vraiment la sécurité. Ou si mais pas pour des raison de cloisonnement, plutôt par réduction de la surface d'attaque. L'un des gros intérêt c'est d'avoir quelque chose de petit. Ça te permet de créer des VM dont la taille se compte en Mio. Du coup :

                • tu diminue la surface d'attaque
                • tu diminue la taille de ton image face à une image de VM
                • tu part sur un environnement maîtrisé comme avec un VM
                • tu peu envisager des optimisations profondes (pas de recopie de données userland/kernelland, moins de protection à avoir, inlining poussé, etc)

                Ça ne marche pas pour tout, mais c'est une technique qui peut avoir du sens je trouve.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Donc pour résumer…

                  Posté par kantien le 05 octobre 2016 à 14:31. Évalué à 0.

                  

                  Merci pour ces précisions. Comme je l'ai dit c'est ce que j'en avais compris, et ne connaissant pas vraiment le sujet et les problématiques c'était à prendre avec des pincettes. Mais l'idée reste bien de n'embarquer que le strict nécessaire au niveau des fonctionnalités du noyau et de l'application pour réduire la surface d'attaque ? Et cela avec la sécurité des systèmes de typage des langages fonctionnels, ce qui réduit également le risque de failles ?

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                  • [^] # Re: Donc pour résumer…

                    Posté par barmic le 05 octobre 2016 à 15:53. Évalué à 3.

                    

                    Mais l'idée reste bien de n'embarquer que le strict nécessaire au niveau des fonctionnalités du noyau et de l'application pour réduire la surface d'attaque ?

                    C'est aussi pour l'alléger pour un démarrage plus rapide par exemple.

                    Et cela avec la sécurité des systèmes de typage des langages fonctionnels, ce qui réduit également le risque de failles ?

                    Quand c'est dans un langage fonctionnel peut être, mais il en existe en C ou en C++ par exemple :)

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Donc pour résumer…

                      Posté par kantien le 05 octobre 2016 à 18:35. Évalué à 2.

                      

                      C'est aussi pour l'alléger pour un démarrage plus rapide par exemple.

                      J'avais lu un article de blog, que je n'ai pas retrouvé, où l'auteur avait poussé l'expérimentation jusqu'à servir un site web statique avec une VM par page. :-P

                      Quand c'est dans un langage fonctionnel peut être, mais il en existe en C ou en C++ par exemple :)

                      Oh, c'est dommage ! :-P

                      Dans le genre sécurité et fonctionnement dans la vie réel, il y a eu un conteste de sécurité avec une prime de 10 bitcoin pour qui casserait la pinãta. Personne n'a réussi, voilà le compte-rendu :

                      TL;DR: Nobody took our BTC. Random people from the Internet even donated into our BTC wallet. We showed the feasibility of a transparent self-service bounty. In the style of Dijkstra: security bounties can be a very effective way to show the presence of vulnerabilities, but they are hopelessly inadequate for showing their absence.

                      What are you talking about?

                      Earlier this year, we released a Bitcoin Piñata. The Piñata was a security bounty containing 10 BTC and it's been online since 10th February 2015. Upon successful mutual authentication, where the Piñata has only a single trust anchor, it sends the private key to the Bitcoin address.

                      It is open source, and exposes both the client and server side of ocaml-tls, running as an 8.2MB MirageOS unikernel. You can see the code manifest to find out which libraries are involved. We put this online and invited people to attack it.

                      Any approach was permitted in attacking the Piñata: the host system, the MirageOS TCP/IP stack, our TLS, X.509 and ASN.1 implementations, as well as the Piñata code. A successful attacker could do whatever they want with the BTC, no questions asked (though we would notice the transaction).

                      Lire la suite…

                      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                      • [^] # Re: Donc pour résumer…

                        Posté par Babelouest (site web personnel) le 11 octobre 2016 à 23:05. Évalué à 2.

                        

                        XKCD a déjà proposé une approche plus pragmatique de la résolution de ce genre de problème:

                        

            • [^] # Re: Donc pour résumer…

              Posté par barmic le 05 octobre 2016 à 14:06. Évalué à 3.

              

              La philosophie Unix, moi j’aime bien, et ça la casse complètement, pour un gain pas très clair.

              Pas vraiment non. Les gens qui utilisent des unikernel, le font pour avoir un OS qui fait une seule chose, mais qui le fait bien et découpe leur programme en une série de services chacun ayant une responsabilité propre et bien limité. Oui c'est fait pour du microservice.

              VM n’est qu’une question de simplicité de déploiement

              Pas que. Déjà la simplicité de déploiement sous linux, on est les dieux des déploiement complexes (on a juste un milliard de façon « simples » de faire des déploiements qui sont juste pas tous compatible avec la distribution que tu vise…). D'autre part le sandboxing est assez récent. SElinux est vieux, mais c'est rare de voir des softs qui ont leurs règles associés et seccomp c'est très récent.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Donc pour résumer…

                Posté par karchnu le 05 octobre 2016 à 16:04. Évalué à 0.

                

                Tu te retrouves avec des programmes qui ont des milliers de fonctionnalités, avant même d’avoir codé quoi que ce soit, ce n’est pas ce que j’appelle de la simplicité. Réduire une surface d’attaque, on sait déjà très bien faire : tu utilises un service simple, avec le moins de fonctionnalités possibles pour vérifier correctement les entrées. Sur un système, tu vas pas avoir des centaines de programmes qui vont écouter sur ton réseau et qui, par définition, seraient des failles potentielles.

                Bref, j’attends de voir ce que ça va donner dans la vraie vie.

                • [^] # Re: Donc pour résumer…

                  Posté par barmic le 05 octobre 2016 à 16:58. Évalué à 3.

                  

                  Ton programme en unikernel n'a aucune fonctionnalité tant qu'il ne les pas créé lui-même (tu ne paie que ce que tu utilise). Il est équivalent à un système totalement épuré comme tu le dis (mais en plus simple - pas d'init, pas de configuration particulière, etc). Mais la plupart des gens (et des images que tu trouve sur amazon/azure/google sont des systèmes complets comme des RedHat, des ubuntu ou des Debian).

                  Bref, j’attends de voir ce que ça va donner dans la vraie vie.

                  Ça n'est pas nouveau, hein ? Ça existe depuis pas mal de temps sur des archi ASMP ou NUMA où l'on pose un unikernel par CPU. Pour des services ça existe depuis quelques temps, même si c'est à la mode que depuis quelques années.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Donc pour résumer…

                    Posté par karchnu le 05 octobre 2016 à 19:19. Évalué à 0.

                    

                    Pour des applications assez spécifiques alors, non ? Parce que pour mes usages courants (DHCP, DNS, web…) je n’ai rien de tout ça sur mes ordinateurs.

[^] # Re: Donc pour résumer…

Posté par Guillaum (site web personnel) le 03 octobre 2016 à 12:17. Évalué à 1.

[^] # Re: Jai: Language for game programmming

Posté par kantien le 10 octobre 2016 à 15:01. Évalué à 4.

• [^] # Re: Jai: Language for game programmming

  Posté par DerekSagan le 10 octobre 2016 à 23:51. Évalué à 2. Dernière modification le 10 octobre 2016 à 23:52.

  

  Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ? Elles sont où les applications partielles, la curryfication, les fonctions comme citoyens de premières classes ?

  En fait dans les langages de programmation de ces dernières décennies le mot "lambda" correspond à une fonction anonyme, c'est loin d'être une spécificité de C++.
  https://en.wikipedia.org/wiki/Anonymous_function

  Et oui l'expression vient bien du lambda calcul.

  Et du coup les fonctions comme citoyens de première zones sont un cas plus général que les seuls opérateurs lambdas.
  Parce qu'une fonction comme citoyen de première classe c'est pas forcément un lambda, ça peut aussi être une méthode de classe ou une fonction C.

  Les trucs vraiment intéressant sont là, car en effet les lambdas c'est juste* une facilité d'écriture:
  http://en.cppreference.com/w/cpp/utility/functional/function
  http://en.cppreference.com/w/cpp/utility/functional/bind
  voire tout
  http://en.cppreference.com/w/cpp/utility/functional

  *: bon mais c'est bien pratique quand même hein :-)

  • [^] # Re: Jai: Language for game programmming

    Posté par kantien le 11 octobre 2016 à 02:59. Évalué à 2.

    

    En fait dans les langages de programmation de ces dernières décennies le mot "lambda" correspond à une fonction anonyme, c'est loin d'être une spécificité de C++.

    C'est gentil de me l'apprendre… mais je le savais déjà, hein. ;-)

    Mon message répondait à barmic dans une volonté trollesque clairement affichée, et donc empreinte de mauvaise foi. Cela étant je restais dans le sujet du commentaire initial de ce fil puisque Le Gab y parlait de théorie des langages, et que mon commentaire aborde le sujet à plus d'un titre.

    Je suis allé voir tes liens, et la syntaxe me semble bien lourde et difficile à appréhender pour un non initié. Pour comparer :

    let tab = Array.init 5 (fun i -> 2 * i);;
    val tab : int array = [|0; 2; 4; 6; 8|]
    
    Array.iteri (fun i v -> Printf.printf "%i -> %i\n" i v) tab;;
    0 -> 0
    1 -> 2
    2 -> 4                                                                          
    3 -> 6
    4 -> 8
    - : unit = ()
    
    (* ou mieux avec les applications partielles, merci Curry ! *)
    let tab = Array.init 5 (( * ) 2);;
    val tab : int array = [|0; 2; 4; 6; 8|]
    
    Array.iteri (Printf.printf "%i -> %i\n") tab;;
    0 -> 0
    1 -> 2
    2 -> 4                                                                          
    3 -> 6
    4 -> 8
    - : unit = ()

    Et quand on parle de fonctions comme citoyens de premier classe, on entend aussi par là qu'elles peuvent être utilisées dans un contexte polymorphe comme n'importe quel autre terme sans syntaxe particulière.

    let tab = Array.init 5 (fun i -> ( * ) i);;
    val tab : (int -> int) array = [|<fun>; <fun>; <fun>; <fun>; <fun>|]
    
    Array.iteri (fun i f ->  Printf.printf "%i * 2 -> %i\n" i (f 2)) tab;;
    0 * 2 -> 0
    1 * 2 -> 2
    2 * 2 -> 4
    3 * 2 -> 6
    4 * 2 -> 8
    - : unit = ()

    Mais je peux continuer le troll aussi : si tu veux essayer de me convaincre que la POO (oui ça ne touche pas que le C++ ;-) n'est pas une totale aberration logique et intellectuelle, il va falloir te lever de bonne heure. L'esprit humain est structurellement constitué selon des schèmes fonctionnels, et la POO est fondée sur une étrange analyse logique de la classification et du rapport de subordination des concepts en genres et espèces : à comparer avec les type classes de Haskell, par exemple, et la génération automatique de code dont Guillaum a donné des exemples dans ce commentaire.

    Que l'entendement humain soit fonctionnel par essence, ce n'est pas une découverte qui date d'aujourd'hui : je pourrais te renvoyer à la théorie du schématisme dans la Critique de la Raison Pure de Kant qui date de… 1781. ;-)

    Et au cas où la référence à un tel ouvrage, dans une question qui traite d'informatique et de théorie des langages, t'étonnerait, je m'auto-cite à partir d'un commentaire sur un autre journal :

    Dans son ouvrage Les Métamorphoses du calcul, le mathématicien et informaticien Gilles Dowek revient sur l'évolution du calcul de l'antiquité jusqu'à nos jours et ce qui a donné naissance à l'informatique et l'ordinateur. Un des moments de cette histoire est une polémique lorsque Gottlob Frege voulut s'attaquer à la thèse centrale de l'ouvrage de Kant sus-cité, à savoir que tous les jugements mathématiques sont synthétiques a priori. Il a échoué, et pour cause, Kant avait raison et Gödel le prouva via son théorème d'incomplétude (ce qui équivaut au problème de l'arrêt en informatique). M. Dowek le reconnaît dans son livre, mais en appendice il cite malheureusement le cogito cartésien comme exemple de jugement synthétique a priori : c'est une erreur, ce jugement est analytique et non synthétique.

    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

    • [^] # Re: Jai: Language for game programmming

      Posté par DerekSagan le 11 octobre 2016 à 08:58. Évalué à 3.

      

      Je suis allé voir tes liens,
      (…)
      Et quand on parle de fonctions comme citoyens de premier classe, on entend aussi par là qu'elles peuvent être utilisées dans un contexte polymorphe comme n'importe quel autre terme sans syntaxe particulière.

      Bah t'as pas dû tout lire alors.
      Voici comme définir une variable qui est une fonction:
      
auto ajouter = [](int x, int y) { return x+y; };
auto uneautre = &MaClasse:unemethode;
Et comment on capture une variable en passant une fonction en paramètre:
      
int total;
macollection.iterer([&total](int n) { total += n; });
Tu peux trouver la syntaxe difficile si tu veux, mais perso je trouve que séparer les paramètres capturés (crochets) des paramètres d'appel (parenthèses) clarifie beaucoup de choses (notamment en précisant si la capture est pas référence ou par copie).

      Mais je peux continuer le troll aussi : si tu veux essayer de me convaincre que la POO (oui ça ne touche pas que le C++ ;-) n'est pas une totale aberration logique et intellectuelle, il va falloir te lever de bonne heure

      Je n'essayerai pas de te convaincre. Mais en fait selon le problème que tu cherches à résoudre ce n'est pas toujours le même modèle de programmation (objet, fonctionnel, procédural) le plus efficace et avoir plusieurs outils ne nuit pas.

      D'ailleurs un des avantages de C++ est que tu peux faire un peu tout avec. Je ne dis pas qu'il faut tout faire avec juste que tu n'es pas obligé de faire du fonctionnel (contrairement à lisp/scheme qui te l'impose), que tu n'es pas obligé de faire de l'objet avec (contrairement à java qui te l'impose au moins dans la forme et les bibliothèques/frameworks existants), etc.

      • [^] # Re: Jai: Language for game programmming

        Posté par kantien le 11 octobre 2016 à 13:08. Évalué à 1.

        

        J'ai l'impression que l'on ne se comprend pas, ou que tu ne sais pas ce qu'est la programmation fonctionnelle.

        Premièrement, pour la curryfication et les applications partielles, un langage fonctionnel digne de ce nom (donc basé sur le lambda-calcul) n'a pas besoin d'artifice particulier à la std::bind pour faire cela.

        (* le principe de la curryfication se voit dans le type inféré :
         * c'est une fonction qui prend un int et renvoie une fonction
         * qui prend un int pour retourner un int *)
        let plus i j = i + j;;
        val plus : int -> int -> int = <fun>
        
        (* donc si je lui donne un int, j'obtiens une fonction des
         * int vers les int *)
        let plus_2 = plus 2;;
        val plus_2 : int -> int = <fun>
        
        plus_2 3;;
        - : int = 5
        
        (* la curryfication, ça se voit aussi comme cela : *)
        let plus = fun i -> fun j -> i + j;;
        val plus : int -> int -> int = <fun>
        
        let plus_2 = plus 2;;
        val plus_2 : int -> int = <fun>
        
        plus_2 3;;
        - : int = 5

        Ensuite ton exemple avec macollection.iterer, je ne vois pas où il illustre le statut de citoyen de première classe pour les fonctions. De ce que je comprends, iterer est une méthode d'un objet itérable qui prend une fonction en paramètre : mais cela fait partie du type même de la méthode d'attendre un tel paramètre. De ce que je comprends, c'est équivalent à ça :

        let (+=) x i = x := !x + i;;
        val ( += ) : int ref -> int -> unit = <fun>
        
        let sum a = fun x -> Array.iter ((+=) x) a;;
        val sum : int array -> int ref -> unit = <fun>
        
        let x = ref 3 in
        sum [|1; 2; 3|] x; !x;;
        - : int = 9

        Moi ce que je disais c'est que le type des tableaux 'a array est polymorphe et contient des éléments de n'importe quel type 'a qui peut être un type de fonction, comme dans l'exemple :

        let tab = Array.init 5 (fun i -> fun x -> x += i);;
        val tab : (int ref -> unit) array = [|<fun>; <fun>; <fun>; <fun>; <fun>|]

        Ici le type 'a est instancié à la valeur particulière int ref -> unit qui est celui des fonctions qui appliquent des effets de bords sur les pointeurs sur int. On peut en user ainsi :

        let a = Array.init 5 (fun i -> ref 1);;
        val a : int ref array =
          [|{contents = 1}; {contents = 1}; {contents = 1}; {contents = 1};{contents = 1}|]
        
        Array.iteri (fun i f -> f a.(i)) tab;;
        - : unit = ()
        
        a;;
        - : int ref array = 
          [|{contents = 1}; {contents = 2}; {contents = 3}; {contents = 4};{contents = 5}|]

        Mais en fait selon le problème que tu cherches à résoudre ce n'est pas toujours le même modèle de programmation (objet, fonctionnel, procédural) le plus efficace et avoir plusieurs outils ne nuit pas.

        Je n'ai jamais dit le contraire, d'ailleurs OCaml permet d'utiliser les paradigmes impératif, orienté objet et fonctionnel (mais vraiment du fonctionnel, pas l'ersatz que tu as illustré jusqu'à maintenant).

        En attendant, quand je ne trolles pas pour répondre à du troll, je fournis des réponses plus pertinentes et adaptées aux autres commentaires. Comme quand dans cette dépêche, freem se demandait à quoi pouvait servir les shared_ptr et que je lui ai proposé de s'en servir pour implémenter des tableaux immuables. D'ailleurs, j'attends toujours des adeptes du C++ qu'ils m'éclairent sur la pertinence de mon exemple.

        P.S: Bon, le lambda-calcul ça date de 1936, et on a du attendre C++11 pour en avoir un ersatz à lire tes exemples. Pour l'inférence de type et l'argorithme d'unification de Robinson qui en est la base, ça date de 1965. Il va falloir attendre combien de temps, pour celui-là ? L'algorithme en question est présenté sur le blog de la Société Informatique de France par Gilles Dowek.

        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Jai: Language for game programmming

          Posté par DerekSagan le 11 octobre 2016 à 15:06. Évalué à 0.

          

          un langage fonctionnel digne de ce nom (donc basé sur le lambda-calcul)

          Ensuite ton exemple avec macollection.iterer, je ne vois pas où il illustre le statut de citoyen de première classe pour les fonctions.

          Moi ce que je disais c'est que le type des tableaux 'a array est polymorphe et contient des éléments de n'importe quel type 'a qui peut être un type de fonction

          J'en déduis donc que selon toi un langage fonctionnel digne de ce nom doit être faiblement typé. Ou au moins doit avoir un type racine qui peut contenir n'importe quoi. C++ ne sera donc jamais un langage fonctionnel digne de ce nom.

          En attendant, quand je ne trolles pas pour répondre à du troll, je fournis des réponses plus pertinentes et adaptées aux autres commentaires.

          Bravo. Tu es donc quelqu'un de bien. Je suppose que c'était le message.

          Et du coup grâce à ta constructivité(1) sur certains sujets tu a acheté le droit de faire preuve de mauvaise foi en écrivant, ceci, comme si cette définition du lambda était propre à C++, y compris OCaml (le seul langage digne de ce nom):

          Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

          Pour ensuite répondre:

          En fait dans les langages de programmation de ces dernières décennies le mot "lambda" correspond à une fonction anonyme, c'est loin d'être une spécificité de C++.

          C'est gentil de me l'apprendre… mais je le savais déjà, hein. ;-)

          Après je considère le droit à troller (et donc à troller de mauvaise foi) comme une liberté fondamentale qui devrait être inscrite dans la déclaration des droits de l'homme.

          J'ai juste bien rigolé en lisant cette médaille que tu porte fièrement à la poitrine:

          En attendant, quand je ne trolles pas pour répondre à du troll, je fournis des réponses plus pertinentes et adaptées aux autres commentaires.

          (accompagné de deux liens où tu réinventes l'eau chaude en découvrant manifestement ce qu'est un smart pointer, je dis ça pour donner de la profondeur à l'adjectif "pertinentes")

          • [^] # Re: Jai: Language for game programmming

            Posté par lasher le 11 octobre 2016 à 16:58. Évalué à 4.

            

            J'en déduis donc que selon toi un langage fonctionnel digne de ce nom doit être faiblement typé. Ou au moins doit avoir un type racine qui peut contenir n'importe quoi. C++ ne sera donc jamais un langage fonctionnel digne de ce nom.

            Je pense que tu as tort. D'une part, il existe un lambda-calcul typé, dont se servent les langages fonctionnels (et LISP, par exemple, est fortement typé, mais le typage est dynamique). D'autre part, je ne vois pas ce qui te fait dire que l'exemple donné par Kantien est faiblement typé. Simplement l'application de l'opération (+=) sera adaptée au type contenu dans un élément spécifique du tableau, mais le typage est statique et fort en OCaml.

          • [^] # Re: Jai: Language for game programmming

            Posté par kantien le 11 octobre 2016 à 17:15. Évalué à 4.

            

            J'en déduis donc que selon toi un langage fonctionnel digne de ce nom doit être faiblement typé

            Gné ??? Haskell ou OCaml sont fortement et statiquement typé. Voici la page des publications de Jacques Garrigue qui est le responsable principal du système de types du langage OCaml.

            Par contre, je n'ai toujours pas vu comment tu illustrais le principe de la curryfication en C++ ni celui des fonctions comme citoyen de première classe. Au passage, Curry qui a donné le nom à ce principe était un mathématicien et logicien qui se prénommait… Haskell. ;-)

            Bravo. Tu es donc quelqu'un de bien. Je suppose que c'était le message.

            Que nenni ! Je pointais juste du doigt qu'un utilisateur de C++ (ce que je ne suis pas) posait une question sur l'utilité des shared_ptr et qu'aucun spécialiste de ce langage n'avait dénié lui répondre. C'est un peu dans le même ordre que ce commentaire de Benoît Sibaud :

            Déjà six commentaires pour dire à quel point c'est un mauvais choix. Et pas un capable d'expliquer et/ou de proposer une solution ou d'être constructif ou donner des références. Pauvre communauté.

            Pour ce passage, je ne comprends pas trop :

            Et du coup grâce à ta constructivité(1) sur certains sujets tu a acheté le droit de faire preuve de mauvaise foi en écrivant, ceci, comme si cette définition du lambda était propre à C++, y compris OCaml (le seul langage digne de ce nom):

            Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

            Pour ensuite répondre:

            En fait dans les langages de programmation de ces dernières décennies le mot "lambda" correspond à une fonction anonyme, c'est loin d'être une spécificité de C++.
            C'est gentil de me l'apprendre… mais je le savais déjà, hein. ;-)

            Premièrement, je n'ai jamais, mais alors jamais, affirmé que OCaml était le seul langage digne de ce nom. Je dis juste qu'un langage qui ne fournit pas nativementt les concepts et principes de la programmation fonctionelle (dont l'archétype est le lambda-calcul) ne mérite pas d'être qualifié de langage fonctionnel. J'allais dire que j'avais passé l'âge de jouer à qui a la plus grosse en comparant les langages, mais à dire vrai je ne l'ai jamais eu : c'est ridicule, je n'en ai jamais vu l'intérêt.

            Deuxièmement, oui il y a avait du troll et de la mauvaise foi dans mon message initial : mais c'était clairement affiché. ;-) Cela étant sur le site C++ référence à Lambda, on peut bien lire :

            Lambda functions (since C++11)
            Constructs a closure: an unnamed function object capable of capturing variables in scope.

            Le concept est donc bien apparu avec le C++11 et représente des fonctions anonymes qui capturent des variables d'environnement en construisant une fermeture. Comme cette notion de fermeture est apparue avec le langage scheme en 1975, et que tu raillais Java qui avait mis plus de temps à les implémenter, je me suis permis de railler également le C++. Sur la page wikipédia sur les fermetures, tu pourras en particulier y lire :

            En Haskell, grâce à la curryfication, toute fonction peut générer des fermetures lorsqu'on lui passe seulement une partie de ses arguments
            [..]
            En OCaml […] grâce à la curryfication, toute fonction peut générer une fermeture lorsqu'on lui passe seulement une partie de ses arguments.

            c'est ce que j'ai fait avec mon exemple de plus, en faisant une application partielle :

            let plus i j = i + j
            
            let plus_2 = plus 2

            Ici, on génère une fermeture en capturant 2 dans l'environnement d'évaluation de plus_2. Mais on peut aussi le faire anonymement :

            fun i -> plus 2 i

            Cela étant, je n'ai toujours pas d'exemples de curryfication et de leur usage pour générer des fermetures en C++.

            Au passage, cette notion est empruntée à la logique formelle et au calcul des prédicats : c'est la notion de variable libre et de variable liée (et date donc de la fin du XIXème siècle). Dans un énoncé comme celui-ci : Pour tout entier n, n + i = n, la variable n est liée par le quantificateur universel (on peut changer son alias par j sans changer le sens de l'énoncé) tandis que la variable i est libre (elle représente un entier indeterminé). Pour pouvoir interpréter un tel énoncé, qui est en fait paramétré par un entier indéterminé i, il faut l'évaluer dans un environnement qui attribue une valeur à cette entier i : voilà d'où vient ce concept de fermeture. En l'occurrence pour cet énoncé, il ne sera vrai que pour la valeur i = 0 si on l'interprète dans son environnement naturel qui est celui de l'ensemble des entiers naturels. C'est là la base de la théorie des modèles qui n'est pas sans intérêt pour l'étude de la sémantique des langages de programmation.

            accompagné de deux liens où tu réinventes l'eau chaude en découvrant manifestement ce qu'est un smart pointer, je dis ça pour donner de la profondeur à l'adjectif "pertinentes".

            Je vois que tu es prompte à répondre, mais que tu n'as rien compris au code que j'ai écrit. Il ne s'agissait pas de réinventer l'eau chaude ou de découvrir ce qu'était un smart pointer mais :

            • de montrer quel était l'équivalent de cette notion dans le langage OCaml;
            • et d'en faire usage pour implémenter des tableaux persistants.

            C'est la partie graissée qui est l'objectif principal du code : donner un exemple d'utilisation possible de ce concept sous la forme des shared_ptr (qui peut aussi existait sous la forme des unique_ptr), car telle était la question de freem. Le premier point était simplement là pour que le lecteur non familier avec les concepts de OCaml, mais familier avec ceux du C++, puisse comprendre le fonctionnement du code et traduise en C++.

            Pour reprendre ma question trollesque du premier message :

            ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

            Dis : tu t'y connais un peu en programmation fonctionnelle et en théorie des langages ou tu veux juste troller ?

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Jai: Language for game programmming

              Posté par whity le 11 octobre 2016 à 18:14. Évalué à 0.

              

              Ton problème, c’est que soit tu trolles de mauvaise foi, soit tu ne sais pas lire:

              Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

              Il n’est pas marqué ça sur le site. Il est marqué que les lambdas sont apparues dans le langage C++ depuis la version C++11. C’est pour ça que je dis que tu es de mauvaise foi, ou que tu ne sais pas lire.

              Il existait déjà bien auparavant boost::function.

              ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

              Si tu connaissais un peu le C++, tu verrais qu’il y a beaucoup de choses qui relèvent de la programmation fonctionnelle dès qu’on fait de la métaprogrammation. Il y a même une syntaxe presque aussi horrible que celle d’Haskell :) (dans un style différent, certes).

              Mais plus généralement, tu juges de la compétences des concepteurs d’un langage (ne me dis pas que tu poses seulement une question, la tournure est loin d’être innocente et tu le sais très bien) que tu ne connais pas sur une mauvaise lecture que tu fais (probablement volontairement) de documentations sur un site web qui n’est pas en lien avec le comité en charge de l’évolution du langage.  Il y a des limites à ce qui acceptable comme troll :).

              À part ça, pour shared_ptr, j’ai déjà répondu (avec des exemples). C’est un partage de responsabilité de la durée de vie. Ton idée de liste chaînée ou de tableaux persistants est (de ce que j’en ai compris) un peu à côté de la plaque de ce point de vue.

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

              • [^] # Re: Jai: Language for game programmming

                Posté par lasher le 11 octobre 2016 à 18:27. Évalué à 7. Dernière modification le 11 octobre 2016 à 18:28.

                

                Ton problème, c’est que soit tu trolles de mauvaise foi, […]
                En même temps, par définition, un troll de mauvaise foi. Ceci étant dit, je suis d'accord avec ce que tu dis sur le côté troll de Kantien (mais comme il disait, il trolle ouvertement, du coup je lui pardonne à moitié :-)). Cependant :

                Si tu connaissais un peu le C++, tu verrais qu’il y a beaucoup de choses qui relèvent de la programmation fonctionnelle dès qu’on fait de la métaprogrammation. Il y a même une syntaxe presque aussi horrible que celle d’Haskell :) (dans un style différent, certes).

                Le langage de templates (qui est Turing complet, d'ailleurs), est un langage fonctionnel (affectation unique, etc.). C++ lui-même, en tant que langage n'est pas fonctionnel, mais offre quelques mécanismes permettant d'écrire des programmes dans un style fonctionnel. C'est quand même différent d'un langage fonctionnel par nature.

                Lorsque je dis que C++ est un langage orienté objet, c'est parce qu'il offre des mécanismes qui me permettent directement d'exprimer un programme selon les concepts de la POO : niveau d'encapsulation (privé, protégé, public, etc.), héritage, groupement des données et des messages (méthodes/fonctions) qui leur sont associés, etc.

                De même, lorsque je dis qu'un langage est fonctionnel, je m'attends à ce que les fonctions soient des objets de première classe, mais aussi que je puisse naturellement compter sur une expression de mes programmes en termes de valeurs (« immutable ») et pas de variables ( « mutables », et qui offrent donc des effets de bord), d'être capable d'exprimer des fonctions imbriquées dans d'autres fonctions si j'en ai le besoin, etc. La notion de récursivité (du code, des types, etc.) est inhérente au paradigme fonctionnel. Ce n'est pas le cas en C++. Oui, on peut jouer avec const, boost::function (et maintenant les lambdas), et même avec de la méta-programmation pour contraindre le système et forcer un style fonctionnel, mais ça ne fait pas de C++ un langage fonctionnel. De même que ce n'est pas parce qu'on peut programmer dans un style objet en C que ça en fait un langage orienté objet.

                • [^] # Re: Jai: Language for game programmming

                  Posté par whity le 11 octobre 2016 à 22:13. Évalué à 3.

                  

                  Lorsque je dis que C++ est un langage orienté objet

                  Tu commets une première erreur :).

                  ça ne fait pas de C++ un langage fonctionnel.

                  Ce n’est pas non plus ce que j’ai dit. Je répondais simplement à

                  ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

                  En faisant remarquer qu’un pan entier du langage suivait ces paradigmes…

                  Néanmoins, C++ est multiparadigme (et donc, C++ n’est pas un langage « orienté objet », il est un langage intégrant parmi d’autres le paradigme objet), et de plus en plus, les paradigmes fonctionnels trouvent leur place dans le langage. Je suis très surpris d’ailleurs que les tenants des langages fonctionnels y trouvent matière à critiquer, en fait, ils devraient au contraire s’en réjouir :).

                  Les langages fonctionnels purs n’existent de toute façon que pour faire de la preuve mathématique : dès que tu travailles sur un système, tu introduis à minima les problématiques d’aliasing et de mutabilité (même si ton langage l’interdit au niveau variable, tu peux l’avoir au niveau système de fichier par exemple, des ressources systèmes, de la console, etc.), ce qui casse toute la « pureté » de ton langage. C’est d’ailleurs je pense une des raisons de l’échec (relatif, bien entendu) des langages fonctionnels : leur niveau d’abstraction ne correspond finalement pas tant que ça à la réalité à laquelle est confronté le programmeur.

                  Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                  • [^] # Re: Jai: Language for game programmming

                    Posté par lasher le 11 octobre 2016 à 22:19. Évalué à 5. Dernière modification le 11 octobre 2016 à 22:21.

                    

                    Néanmoins, C++ est multiparadigme (et donc, C++ n’est pas un langage « orienté objet », il est un langage intégrant parmi d’autres le paradigme objet),

                    Bon, je me suis demandé s'il fallait que je pinaille, JUSTEMENT à cause de ça. :) J'ai raccourci, mais si tu veux, de même que OCaml est connu pour être un langage fonctionnel, il est lui aussi multi-paradigme. C'est juste que le paradigme impératif et objet me semble quand même plus secondaire quand on discute de ce langage. Même chose pour C++ : oui, il permet la prog générique, procédurale, objet, etc. Mais superficiellement, C++ est quand même largement associé à la programmation objet.

                    EDIT: Tiens d'ailleurs, lorsque je dis que C++ est un langage orienté objet, je ne dis pas qu'il n'est que cela, ET TOC.

                    (j'aime pas avoir tort, ça se voit ?)

              • [^] # Re: Jai: Language for game programmming

                Posté par kantien le 11 octobre 2016 à 22:25. Évalué à 2.

                

                Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture : ils ne savent pas ce qu'est le lambda-calcul les concepteurs et développeurs C++ ?

                Il n’est pas marqué ça sur le site. Il est marqué que les lambdas sont apparues dans le langage C++ depuis la version C++11. C’est pour ça que je dis que tu es de mauvaise foi, ou que tu ne sais pas lire.

                Euh, c'est exactement ce que j'ai écrit ! :-O Enfin, j'ai sous entendu que l'apparition était dans le langage C++; je ne voulais pas entendre par là qu'ils prétendait que C++11 avait inventé les lambda. Je le reconnais, cela pouvait prêter à confusion (enfin, si l'on ne fait pas beaucoup d'effort). ;)

                Qu'il y ait de la mauvaise foi dans mes propos précédents, c'est évident, je ne l'ai jamais nié, j'ai même annoncé la couleur. Par contre, je ne sais pas lequel de nous deux à des problèmes de compréhension sur ce qu'il lit.

                Mais plus généralement, tu juges de la compétences des concepteurs d’un langage (ne me dis pas que tu poses seulement une question, la tournure est loin d’être innocente et tu le sais très bien) que tu ne connais pas sur une mauvaise lecture que tu fais (probablement volontairement) de documentations sur un site web qui n’est pas en lien avec le comité en charge de l’évolution du langage. Il y a des limites à ce qui acceptable comme troll :).

                C'était clairement de la mauvaise foi en ce qui concerne les concepteurs du langage, je sais très bien qu'ils sont loin d'ignorer ce qu'est le lambda-calcul. Pour ce qui est des développeurs C++, cela dépend : DerekSagan ou toi ne semblent pas y connaître grand chose. ;-)

                C’est un partage de responsabilité de la durée de vie. Ton idée de liste chaînée ou de tableaux persistants est (de ce que j’en ai compris) un peu à côté de la plaque de ce point de vue.

                Alors tu n'as pas compris mon code, mais c'est peut être mon explication qui est défectueuse. En OCaml, en dehors des valeurs de type int et des constructeurs constants comme Nil on ne manipule que des pointeurs qui se comportent comme des smart pointer. Tous mes tableaux se partagent la responsabilité de la durée de vie du 'a array qui sert de mémoire partagée. Quand on a des types somme comme Cons of ... ce sont des smart pointer nommés en lecture seule, avec les ref ce sont des smart pointer en lecture-écriture. Les types somme cela sert à poser des étiquettes sur les branches du graphe des pointeurs, et ça s'implémente en C aussi : le runtime et le GC de OCaml sont codés en C.

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Jai: Language for game programmming

              Posté par DerekSagan le 13 octobre 2016 à 09:31. Évalué à -2.

              

              Gné

              Un beau concentré de ta pensée. Le reste est habillage pour donner de l'apparence à l'absence de contenu.

          • [^] # Re: Jai: Language for game programmming

            Posté par barmic le 11 octobre 2016 à 17:25. Évalué à 4.

            

            Moi ce que je disais c'est que le type des tableaux 'a array est polymorphe et contient des éléments de n'importe quel type 'a qui peut être un type de fonction

            J'en déduis donc que selon toi un langage fonctionnel digne de ce nom doit être faiblement typé. Ou au moins doit avoir un type racine qui peut contenir n'importe quoi. C++ ne sera donc jamais un langage fonctionnel digne de ce nom.

            L'inférence de type vérifie que le typage est correct. Quand tu touche à OCaml tu te rend vite compte qu'il a un typage fort.
            L'inférence de type (je vais essayer de l'expliquer mais je vais me casser les dents, on va me reprendre derrière ^^), c'est le compilateur qui va tenter de déduire les types non pas avec du transtypage et/ou de la conversion (PHP c'est toi qu'on regarde !), mais en propageant les types partout où c'est nécessaire.

            Si tu as une fonction qui peut retourner soit le type A soit le type B, tu doit faire attention à gérer chacun des 2 types partout ou utiliser des fonctions ou des opérateurs qui peuvent prendre ces 2 types en paramètre. C'est en ça qu'ils sont polymorphiques. Le polymorphisme dans le paradigme fonctionnel ne s'appuie pas sur une hiérarchie de classe, mais sur le fait de pouvoir prendre un type parmi d'autres. C'est ce qu'ils appellent les union type si je ne m'abuse (mais je crois que je m'abuse, c'est un autre nom).

            En tout cas ça permet de définir un type comme étant soit d'un type soit d'un autre (c'est pas limité à 2). Ça se rapproche du type union du C sauf que ça ne cache pas le type au compilateur, il va propager la liste des types partout où c'est nécessaire.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Jai: Language for game programmming

              Posté par whity le 11 octobre 2016 à 18:20. Évalué à 0.

              

              Si tu as une fonction qui peut retourner soit le type A soit le type B, tu doit faire attention à gérer chacun des 2 types partout ou utiliser des fonctions ou des opérateurs qui peuvent prendre ces 2 types en paramètre. C'est en ça qu'ils sont polymorphiques. Le polymorphisme dans le paradigme fonctionnel ne s'appuie pas sur une hiérarchie de classe, mais sur le fait de pouvoir prendre un type parmi d'autres. C'est ce qu'ils appellent les union type si je ne m'abuse (mais je crois que je m'abuse, c'est un autre nom).

              Si je comprends bien, c’est un l’équivalent d’un variant, mais implicite ? Le polymorphisme dans les langages fonctionnels repose sur le duck typing (c’est le cas en python, et aussi en go si je ne me plante pas, ce n’est pas lié au paradigme fonctionnel), mais ce que tu dis c’est que là le compilateur s’autorise à créer de nouveaux types ?

              Il me semble qu’ocaml fait du multiple dispatch (j’en suis sûr pour Haskell) en fonction du type réel des arguments. Est-ce à dire que si tu as une fonction f qui peut renvoyer soit un A, soit un B, et deux surcharges de g, l’une pour A, l’autre pour B, cela va fonctionner correctement de chaîner les appels g(f("toto")) ? Ce serait élégant.

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

              • [^] # Re: Jai: Language for game programmming

                Posté par barmic le 12 octobre 2016 à 00:39. Évalué à 3.

                

                le duck typing (c’est le cas en python, et aussi en go si je ne me plante pas

                Le duck typing c'est un typage fort mais dynamique. Go fais ça de manière statique et on appelle ça un typage structurel.

                Ce sont des typages où pour le premier on vérifie dynamiquement si les noms de méthodes correspondent. Imagine en python hors classe new style, tu peux ajouter manuellement toutes les méthodes nécessaires à n'importe quelle variables pour t'en servir comme d'un tableau par exemple, c'est le principe du dynamique et on ne peut donc pas trop se contenter de regarder le type d'un objet pour savoir si on peut ou non s'en servir comme ça.

                En go c'est un peu différent, une variable peu correspondre à une interface qu'elle ne connaît pas (lors de la création de l'objet, on a pas indiqué qu'il descendait de cette interface), mais si c'est le cas il peut être utilisé comme un objet de cette interface. Le compilateur vérifie que l'objet a bien une structure qui correspond à l'interface demandé.

                Dans le paradigme fonctionnel, une variable a un type qui lui est propre et qui reste inchangé de sa création à sa libération. Ce qu'il y a c'est que tu peut indiquer que tu es capable de manipuler plusieurs types différents (soit parce que tu le spécialise via du pattern matching, soit parce que tu te contente de faire des courses que tu peux faire avec les 2).

                ce que tu dis c’est que là le compilateur s’autorise à créer de nouveaux types ?

                Non non c'est toi qui les crée.

                Est-ce à dire que si tu as une fonction f qui peut renvoyer soit un A, soit un B, et deux surcharges de g, l’une pour A, l’autre pour B, cela va fonctionner correctement de chaîner les appels g(f("toto")) ? Ce serait élégant.

                Oui et ça peut même aller plus loin, tu peux spécialiser pour des valeurs donné (par exemple avoir une fonction pour un entier et une pour la valeur 0, c'est souvent comme ça que sont géré les cas terminaux des fonctions récursives). Soit ça se fait par création de multiples fonctions soit via le pattern matching (je crois que ocaml n'a pas de multimethode - on ne parle pas de surcharge en fonctionnel car les fonctions cohabitent-). En tout cas oui le typage est propagé à travers les méthodes (c'est là que réside la beauté du bousin).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Jai: Language for game programmming

              Posté par kantien le 11 octobre 2016 à 21:47. Évalué à 2.

              

              Pour la version longue : voir ce commentaire que j'avais fait l'an dernier sur les principes de base du lambda-calcul typé. J'y comparais le typage de OCaml (qui est décidable, sauf sur quelques corner cases, d'où l'inférence de types) et celui de Coq qui lui ne l'est pas et donc le programmeur doit le dériver lui même explicitement, ce qui s'appelle faire une démonstration au sens mathématique du terme.

              Pour la version courte : disons que le language des types c'est, grosso modo, celui de la logique propositionnelle du second ordre. C'est à dire que l'on a des variables propositionnelles : A, B, C..., l'implication logique A -> B (si A alors B), la conjonction A et B et la disjonction exclusive A ou B. L'implication : c'est le type des fonctions de A dans B; la conjonction : c'est les types produits, l'équivalent des struct du C; la disjonction : c'est les types sommes, les union du C mais en mieux.

              On appelle ces deux genres de types, types sommes et types produits à cause de cette relation : A et (B ou C) <-> (A et B) ou (A et C). Ce qui donne une des définitions du concept d'algèbre de Boole au sens où l'entendent les mathématiciens : c'est un corps dans lequel tout élément est sont propre carré ((A et A) <-> A). L'algèbre a deux éléments {vrai, faux} étant la plus simple et la plus triviale de telles algèbres.

              Par exemple, le type des listes : type 'a liste = Nil | Cons of 'a liste exprime une disjonction : c'est soit la constante propositionnelle Nil, soit une variable propositionnelle indexée par le type lui-même (ce qui fait que le type exprime une disjonction infinie, disjonction qui pour un type 'a donné est isomorphe à l'ensemble des entiers naturels 0 ou 1 ou 2 ou 3...). Pour les types produits, on peut prendre par exemple les points du plan : type point = {x:float; y:float}; c'est la donnée d'un int et d'un int, d'où la conjonction.

              Ce qui fait qu'à l'arrivée, on tombe bien sur la logique des stoïciens.

              Le principe d'application des fonctions, par exemple, c'est la régle de déduction logique dite du modus ponens : Si A alors B, or A, donc B. Règle que l'on écrit en logique propositionnelle : (A -> B) -> A -> B. À comparer avec le type inféré de la fonction suivante :

              let apply f x = f x;;
              val apply : ('a -> 'b) -> 'a -> 'b = <fun>

              L'inférence de type relève de la preuve automatique, Coq c'est de la preuve assistée par ordinateur, et les principes du typage du lambda-calcul proviennent tous de la théorie de la démonstration. Et donc coder en fonctionnel, c'est faire une preuve : le principe même de la correspondance de Curry¹-Howard, ou correspondance preuve-programme. Le compilateur gueule, au niveau du typage, quand il considère qu'il y a un vice de forme dans la preuve.

              ---

              1. le même Curry qui a donné son nom à la curryfication, et qui s'appelait Haskell Brooks Curry. ;-) ↩

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Jai: Language for game programmming

              Posté par DerekSagan le 13 octobre 2016 à 09:38. Évalué à -4. Dernière modification le 13 octobre 2016 à 09:42.

              

              Mouaih enfin OCaml est un exemple de langage à typage faible, mine de rien. Même un exemple souvent cité.

              https://fr.wikipedia.org/wiki/Typage_fort

              • [^] # Re: Jai: Language for game programmming

                Posté par barmic le 13 octobre 2016 à 10:26. Évalué à 7.

                

                Cette page raconte n'importe quoi… Si tu veux à la place de typage fort. Parlons de sûreté de type. OCaml est typé statiquement donc le compilateur vérifie le typage avant l'exécution et il n'est pas autorisé à faire des conversions ou des transtypages. Donc OCaml a un typage sûr. Il ne faut pas se laisser berner par l'inférence de type. Quand tu utilise le auto en C++, tu as de l'inférence de type, ça n'est pas du type erasure et ben là c'est pareil sauf que c'est plus poussé. De la même manière pour le type Somme qui décrit une variable comme l'un de ses types. Ça t'oblige à gérer chaque type.

                Quand tu commence à écrire de l'OCaml le système de type c'est le premier truc qui vient te foutre une baffe :)

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Jai: Language for game programmming

                Posté par Shuba le 13 octobre 2016 à 11:03. Évalué à 9.

                

                Apparemment tu n'interprètes pas correctement le paragraphe:

                Un langage est fortement typé si les conversions implicites de types sont formellement interdites. Si de telles conversions sont possibles, le langage est faiblement typé. Exemples répondant à ce critère : OCaml, Haskell.

                Il faut dire qu'il n'est pas mise en page de la façon la plus claire possible, mais pour rendre la chose plus claire tu peux garder la même sémantique en enlevant la phrase du mileu:

                Un langage est fortement typé si les conversions implicites de types sont formellement interdites. Exemples répondant à ce critère : OCaml, Haskell.

                Et là, il est tout de suite plus claire qu'OCaml et Haskell sont cités comme des langages à typage fort.

                • [^] # Re: Jai: Language for game programmming

                  Posté par kantien le 13 octobre 2016 à 21:42. Évalué à 2.

                  

                  Exemple de conversion de type qui doit être explicite sous peine de voir le type checker te foutre une baffe — pour reprendre l'expression de barmic.

                  (* l'opérateur infixe +. exige deux paramètres de types float *)
                  (+.);;
                  - : float -> float -> float = <fun>
                  
                  (* si on lui donne un int, il proteste ! *)
                  1 +. 2.3;;
                  Error: This expression has type int but an expression was expected of type float
                  
                  (* il faut faire une conversion explicite *)
                  float_of_int 1 +. 2.3;;
                  - : float = 3.3

                  Ce qui ne semble pas être le cas du C++, si j'en crois ce commentaire de Guillaum (développeur C++ expérimenté) :

                  Aller, j'en ajoute (C++ est mon outil de travail 8h par jour depuis plus de 10 ans) en me focalisant sur les problèmes qui m’embêtent vraiment au quotidien et pour lesquels il n'y a pas de solution simple. J'essaye de rester objectif ;)

                  • Les casts implicites. Plus particulièrement le fait que les flottants, les ints, les bools, les enums, et j'en passe, c'est la même chose. Le downcast implicite d'une classe vers une autre. Je sais que c'est la philosophie du langage. Combien de fois je me suis fais manger par un int négatif convertit en unsigned…

                  […]

                  C'est moi qui graisse. :-)

                  Et je le comprends : faire de la conversion de type sans l'accord explicite du développeur, ça ne devrait pas être permis ! C'est quoi ces compilateurs qui prennent des décisions qui affectent la sémantique du code dans le dos du programmeur ?

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                  • [^] # Re: Jai: Language for game programmming

                    Posté par Guillaum (site web personnel) le 13 octobre 2016 à 22:29. Évalué à 8.

                    

                    Yahoo, je suis enfin reconnu par mes pairs ;)

                    En effet, en C++ tous les types numériques sont implicitement castables en un autre type numérique, et comme les enums et les bools sont des types numériques, cela devient vite comique. Tu peux cependant activer des warnings quand ces conversions font de la perte d'information, mais c'est simplement un warning et surtout il dépend du compilateur :

                    void add(float, int, int){}
                    
                    int main()
                    {
                        if(3.5)
                        {
                            add(2, false, 3.5);
                        }
                    }

                    La compilation avec clang nous donne :

                    λ skyskolem ~ → clang++ test_conv.cpp -Wall -Wextra -Wall -Wconversion
                    test_conv.cpp:5:5: warning: implicit conversion from 'double' to 'bool' changes value from 3.5 to true
                          [-Wliteral-conversion]
                            if(3.5)
                            ~~ ^~~
                    test_conv.cpp:7:17: warning: implicit conversion from 'double' to 'int' changes value from 3.5 to 3
                          [-Wliteral-conversion]
                                    add(2, false, 3.5);
                                    ~~~           ^~~
                    2 warnings generated.
                    

                    (note: j'avoue que je n'ai pas cherché si il existe un ensemble de flags pour en trouver plus).

                    À cela j'ajoute un piège dans lequel beaucoup de développeurs C++ tombent facilement c'est que par définition en C++ un constructeur à un argument est un opérateur de cast implicite :

                    struct Test
                    {
                        Test();
                        Test(int);
                        Test(bool);
                    };
                    
                    void foo(Test, Test, Test);
                    
                    int main()
                    {
                        Test a;
                        foo(5, true, a);
                    }

                    Ce problème se règle en préfixant les constructeur du mot clé explicit, mais l'oubli est facile.

                    Pour finir ce message, je voudrais expliquer comment cela fonctionne dans Haskell. C'est la même situation qu'en OCaml au sens que les conversions implicites n'existent pas. Cependant en ce qui concerne les literaux numériques c'est un peu particulier, ceux-ci sont polymorphiques, ce qui veut dire que 2 est potentiellement un Float/Double/Int/Integer/Int32/Word16 et cela ne sera décidé que par le biais de l’inférence de type, en gros c'est la fonction qui prendra notre literal en paramètre qui décidera de son sort.

                    Notons cependant que ce choix est fait en fonction du literal. En gros, 3 peut être un Double, mais 3.2 ne peut pas être un Int, exemples, avec deux fonctions:

                    f :: Int -> Int
                    f x = 2 * x
                    
                    g :: Float -> Float
                    g x = 2 * x

                    Prelude> g 2
                    4.0
                    Prelude> f 2
                    4
                    Prelude> g 2.3
                    4.6
                    Prelude> f 2.3
                    
                    <interactive>:20:3: error:
                        • No instance for (Fractional Int) arising from the literal ‘2.3’
                        • In the first argument of ‘f’, namely ‘2.3’
                          In the expression: f 2.3
                          In an equation for ‘it’: it = f 2.3

                    C'est un beau compromis dans le sens où il n'est pas nécessaire de typer explicitement ses literaux, mais aucun cast implicite n'est effectué. En contrepartie il faut de temps à autre être explicite sur le type car l'inférence de type s'y perd.

                    C'est aussi pratique quand on commence à implémenter ses propres types numériques pour différents cas de figure (calcul vectoriel, auto differentiation, …) et où il est agréable de profiter de l'écriture de litéreaux. Exemple non complet, soit une fonction f :

                    f v = 2 * (v * v)

                    Le type inferé par Haskell est f :: Num a => a -> a. En gros, une fonction qui prend un Num et retourne un Num.

                    Cela fonctionne pour les littéraux "classiques" :

                    Prelude> f 2
                    8
                    Prelude> f 2.3
                    10.579999999999998

                    Mais j'ai aussi définis mon type numérique maison Expr Float qui représente un arbre d'expression et je peux utiliser f dessus :

                    > (f 5) :: Expr Float
                    Mul (Constant 2.0) (Mul (Constant 5.0) (Constant 5.0))

                    Bon, je me suis encore lâché et j'ai expliqué pleins de trucs au lieu de regarder le meilleur pâtissier ;) Bonne soirée.

                    • [^] # Re: Jai: Language for game programmming

                      Posté par kantien le 14 octobre 2016 à 11:21. Évalué à 5. Dernière modification le 14 octobre 2016 à 11:23.

                      

                      Pour les cas que tu décris en Haskell, c'est ce qui manque à l'heure actuelle en OCaml : le polymorphisme ad hoc (en), qu'il faut distinguer du polymorphisme paramétrique (en). Le second est le polymorphisme que l'on trouve en OCaml : une fonction peut prendre en entrée un type quelconque sans que cela change son code dans sa forme (l'algorithme est identique) comme c'est le cas avec des fonctions sur les 'a list ou 'a array, par exemple.

                      Le polymorphisme ad hoc, lui, est ce qui permet entre autre de faire de la surcharge d'opérateur : une multiplicité de code partage le même alias, et le code adapté sera choisi en fonction du type des entrées. C'est par exemple pour cela qu'en Haskell il y a un seul opérateur d'addition + alors qu'en OCaml il y en un pour chaque type de données : + pour les int et +. pour les float. Ce sont les type classes qui permettent cela en Haskell, dispositif qui ne possède pas encore d'équivalent en OCaml mais il y a des personnes qui y travaillent.

                      Leo White, Frédéric Bour et Jeremy Yallop ont proposé les modular implicts qui s'insprirent entre autre des type classes de Haskell et des implicits de Scala. Dans leur article, ils comparent leur approche avec celles faites dans d'autres langages, comme les concepts pour le C++, section qui renvoie à un article collaboratif dont un des auteurs est Bjarne Stroustrup : Concepts: linguistic support for generic programming in C++. Comme je ne suis pas abonné à l'ACM, je n'ai pas pu lire l'article, et je me demande si ce sont bien les concept que les développeurs C++ attendent et dont parle la dépêche.

                      L'idée de base pour ajouter cette possibilité dans le langage OCaml est de passer par le système des modules du langage et des fonctions sur les modules ou foncteurs. Une approches lourde et qui crée beaucoup d'indirection à base de pointeurs, dans l'exemple de l'addition, est de passer par un type somme :

                      type num = I of int | F of float
                      
                      let add i j = match i, j with
                        |I i, I j -> I (i + j)
                        |I i, F j -> F (float_of_int i +. j)
                        |F i, I j -> F (i +. float_of_int j)
                        |F i, F j -> F (i +. j)
                      
                      add (I 1) (F 2.3);;
                      - : num = F 3.3

                      C'est extrêmement lourd dans l'écriture à l'usage. Leur idée est donc de passer par le système de modules et les modules de première classe. On commence par définir une signature pour les objets numériques :

                      module type Num = sig
                        type t
                        val add: t -> t -> t
                        val mul: t -> t -> t
                      end

                      Puis, on définit deux fonctions¹add et mul qui prennent, en plus de leurs deux paramètres habituels, un module qui choisira l'implémentation adaptée.

                      let add (type a) (module M:Num with type t = a) (i:a) (j:a) = M.add i j;;
                      val add : (module Num with type t = 'a) -> 'a -> 'a -> 'a = <fun>
                      
                      let mul (type a) (module M:Num with type t = a) (i:a) (j:a) = M.mul i j;;
                      val mul : (module Num with type t = 'a) -> 'a -> 'a -> 'a = <fun>

                      Il reste à implémenter deux modules de la bonne signature pour nos deux types de base int et float.

                      module Int_num : (Num with type t = int) = struct
                        type t = int
                        let add = (+)
                        let mul = ( * )
                      end;;
                      module Int_num :
                        sig type t = int val add : t -> t -> t val mul : t -> t -> t end
                      
                      module Float_num : (Num with type t = float) = struct
                        type t = float
                        let add = (+.)
                        let mul = ( *. )
                      end;;
                      module Float_num :
                        sig type t = int val add : t -> t -> t val mul : t -> t -> t end

                      Pour l'usage cela se passe ainsi :

                      add (module Int_num) 1 2;;
                      - : int = 3
                      
                      add (module Float_num) 1.3 2.5;;
                      - : float = 3.8

                      Leur proposition consiste à ajouter quelques modifications légères au langage de base de telle façon que le module en argument soit implicite et inféré automatiquement par le compilateur en fonction du type des autres paramètres. Ce qui permettrait d'avoir la syntaxe (qui n'est pas acceptée à l'heure actuelle) suivante :

                      (* ajout du mot clé `implicit` en tête de la définition du module *)
                      implicit module Int_num : Num = struct
                        type t = int
                        let add = (+)
                        let mul = ( * )
                      end
                      
                      implicit module Float_num : Num = struct
                        type t = float
                        let add = (+.)
                        let mul = ( *. )
                      end
                      
                      (* le paramètre implicite est mis entre accolades {}
                       * et non entre parenthèse () *)
                      let add {M : Num} (i : M.t) (j : M.t) = M.add i j
                      
                      add 1 2;;
                      - : int = 3
                      
                      add 1.3 2.5;;
                      - : float = 3.8

                      Le compilateur se chargeant de regarder, dans le dictionnaire des modules implicites ayant la bonne signature, de trouver celui dont le type t correspond à celui des paramètres donnés à la fonction.

                      ---

                      1. en réalité ce n'est pas tout à fait ce choix qui est fait pour l'implémententation des fonctions add et mul, mais c'est pour simplifier, et ils justifient leur approche à la section 2.4 qui permet d'atteindre un plus haut niveau de polymorphisme. ↩

                      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                      • [^] # Re: Jai: Language for game programmming

                        Posté par Guillaum (site web personnel) le 14 octobre 2016 à 13:42. Évalué à 3.

                        

                        J'adore tes réponses ! Complètes, avec des liens, super. Déjà que je trouve que les réponses que j'écris sont souvent longue à écrire, tu dois y passer un temps non négligeable, merci.

                        Cependant j'ai maintenant une question. Tu dis qu'en OCaml, il faut changer d'opérateur entre les float et les int. Mais qu'en est-t-il entre les différentes représentations de ceux-ci. Genre si tu as des int16, des int32, des int64, des int de taille infinie ? C'est chaque fois un autre opérateur où il y a une solution intermédiaire ?

                        • [^] # Re: Jai: Language for game programmming

                          Posté par kantien le 14 octobre 2016 à 16:41. Évalué à 1. Dernière modification le 14 octobre 2016 à 16:42.

                          

                          Il n'y a pas de quoi pour mes réponses, on est là pour échanger et partager. Quand j'ai du temps, j'essaye d'être assez précis, d'illustrer le plus que je peux et de fournir des références si le lecteur veut prolonger sa réflexion de son côté.

                          Pour les différentes représentations, elles ont chacune leur module avec leurs opérateurs propres :

                          • module Int32 pour les entiers 32-bits signés;
                          • module Int64 pour les entiers 64-bits signés;
                          • module Num pour les opérations sur des rationnels en précision arbitraire.

                          (* exemple sur les Int32 *)
                          Int32.add 32l 64l;;
                          - : int32 = 96l
                          
                          (* mais on peut le renommer localement + si on préfère *)
                          let (+) = Int32.add in 32l + 54l;;
                          - : int32 = 86l
                          
                          (* idem avec les Int64 *)
                          Int64.add 32L 544L;;
                          - : int64 = 576L
                          
                          let (+) = Int64.add in 32L + 544L;;
                          - : int64 = 576L
                          
                          (* mais si on travaille dans un module où l'on ne manipule
                           * que des Int32, il suffit de l'ouvrir et de renommer *)
                          open Int32;;
                          
                          let (+) = add;;
                          val ( + ) : int32 -> int32 -> int32 = <fun>
                          
                          127l + 233l;;
                          - : int32 = 360l
                          
                          (* là comme j'étais dans la REPL j'ai perdu le + sur les int
                           * il me suffit de le renommer et c'est good ! :-) *)
                          let (+) = Pervasives.(+);;
                          val ( + ) : int -> int -> int = <fun>
                          
                          21 + 21;;
                          - : int = 42

                          Une fois qu'il y aura le polymorphisme ad hoc, on pourra avoir un opérateur + « unique » pour les différentes représentations. J'ai mis les guillemets car en réalité, cela correspond à un seul alias pour différents codes mais qui préserve tout de même l'essentiel : le typage fort du langage.

                          En attendant, on peut néanmoins déjà utiliser les principes du code avec les modules de première classe (et oui les modules aussi sont des citoyens de premières classe : c'est du lambda-calcul après tout ;-) mais avec paramètre explicite. Ils sont abordés au chapitre First-Class Modules (en) du livre Real World OCaml, et sont illustrés pour coder un query-handling framework.

                          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                        • [^] # Re: Jai: Language for game programmming

                          Posté par kantien le 14 octobre 2016 à 17:51. Évalué à 0.

                          

                          Petite précision pour illustrer qu'une fois le système des modular implicits définitivement mis au point et stabilisé, cela ne demandera pas de grands changements dans la base de code existante.

                          Pour rappel, on peut déjà écrire :

                          module type Num = sig
                            type t
                            val add: t -> t -> t
                            val mul: t -> t -> t
                          end;;
                          module type Num = sig type t val add : t -> t -> t val mul : t -> t -> t end
                          
                          let add (type a) (module M:Num with type t = a) i j = M.add i j;;
                          val add : (module Num with type t = 'a) -> 'a -> 'a -> 'a = <fun>

                          Avec les modules de première classe, on a déjà un polymorphisme élargi mais le module doit être donné explicitement. Les modules Int32 et Int64 correspondent à cette interface, même s'ils définissent plus de choses : il n'est pas nécessaire de se restreindre aux seuls éléments d'une interface pour la satisfaire, il suffit qu'ils y soient. D'où :

                          add (module Int32) 21l 21l;;
                          - : int32 = 42l
                          
                          add (module Int64) 21L 21L;;
                          - : int64 = 42L

                          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                        • [^] # Re: Jai: Language for game programmming

                          Posté par kantien le 24 octobre 2016 à 13:03. Évalué à 2.

                          

                          Dans la série liens intéressants et instructifs : Demystifying Type Classes sur le site de Oleg Kiselyov. D'une manière générale, son site est une véritable mine d'or ! :-)

                          Sur cette page, il y explique de manière didactique et complète le principe des type classes en étudiant trois implémentations possibles du système dans un langage : par passage de dictionnaire, par monomorphisation ou par analyse intentionnelle de type. La première étant la plus répandue et les deux secondes étant issues de l'article pionnier sur le sujet : Parametric overloading in polymorphic programming languages de Stephan Kaes en 1988 (un lien vers cet article est donné en bas de page).

                          On y trouve aussi une comparaison avec des techniques du C++, comme il le souligne en conclusion :

                          We have presented the intensional type analysis, the third way of compiling type classes. Whereas monomorphization is akin to C++ template instantiation and dictionary passing is similar to vtable, the intensional type analysis reminds one of resolving overloading by a large switch statement.

                          Traduction rapide :

                          Nous avons présenté l'analyse intentionnelle de type, la troisième façon de compiler les classes de type. Tandis que la monomorphisation est similaire à l'instantiation de template C++ et le passage de dictionnaire est similaire aux vtable, l'analyse intentionnelle de type fait penser à la résolution de surcharge comme à un grand switch.

                          La dernière technique m'a donné une idée un peu différente de la sienne, mais largement inspirée de son illustration en OCaml, en utilisant des types sommes ouverts et des GADT. Exemple avec la fonction show :

                          (* on définit un type somme ouvert dans lequel on peut rajouter des cas après coup *)
                          type 'a showable = ..
                          
                          (* on définit la fonction show pour ce type encore vide *)
                          let show : type a. a showable -> a -> string =
                            fun _ x -> failwith "failed overloading resolution";;
                          val show : 'a showable -> 'a -> string = <fun>
                          
                          (* on rajoute des cas dans le type avec leur instance pour show *)
                          type 'a showable += Int : int showable;;
                          type 'a showable += Int : int showable
                          
                          let show : type a. a showable -> a -> string = function
                            | Int -> string_of_int
                            | ty -> show ty;;
                          val show : 'a showable -> 'a -> string = <fun>
                          
                          type 'a showable += Bool : bool showable;;
                          type 'a showable += Bool : bool showable
                          
                          let show : type a. a showable -> a -> string = function
                            | Bool -> string_of_bool
                            | ty -> show ty;;
                          val show : 'a showable -> 'a -> string = <fun>
                          
                          type 'a showable += List : 'a showable -> 'a list showable;;
                          type 'a showable += List : 'a showable -> 'a list showable
                          
                          let show : type a. a showable -> a -> string = function
                            | List ty ->
                              fun l ->
                                let rec loop first = function
                                  | []   -> "]"
                                  | h::t ->  
                                      (if first then "" else ", ") ^ show ty h ^ loop false t
                                in "[" ^ loop true xs
                            | ty -> show ty;;
                          val show : 'a showable -> 'a -> string = <fun>
                          
                          (* quelques exemples *)
                          show Int 1;;
                          - : string = "1"
                          
                          show Bool true;;
                          - : string = "true"
                          
                          show (List Int) [1; 2; 3];;
                          - : string = "[1, 2, 3]"
                          
                          (* limitations du système *)
                          
                          (* on définit une fonction print sur les showable *)
                          let print ty x = print_endline (show ty x);;
                          val print : 'a showable -> 'a -> unit = <fun>
                          
                          (* cela marche bien... pour l'instant *)
                          print Int 1;;
                          1
                          - : unit = ()
                          
                          print (List Int) [1; 2; 3];;
                          [1, 2, 3]
                          - : unit = ()
                          
                          (* maintenant on rajoute les float mais sans implémentation pour show *)
                          type 'a showable += Float : float showable;;
                          type 'a showable += Float : float showable
                          
                          (* la c'est normal, dans le grand switch le cas Float n'est pas encore géré *)
                          print (Float) 1.2;;
                          Exception: Failure "failed overloading resolution".
                          
                          (* on rajoute le cas au switch *)
                          let show : type a. a showable -> a -> string = function
                            | Float -> string_of_float
                            | t -> show t;;
                          val show : 'a showable -> 'a -> string = <fun>
                          
                          show Float 1.2;;
                          - : string = "1.2"
                          
                          (* et là : pouf, ça marche pas pour print !!! *)
                          print (Float) 1.2;;
                          Exception: Failure "failed overloading resolution".
                          
                          (* la raison en est que en OCaml lorsque l'on définit un terme,
                           * sa définition ne doit dépendre que des termes déjà défini qui le précèdent
                           * et donc rajouter un cas à show après avoir défini print ne change rien à son code :
                           * il faut la redéfinir à chaque fois que l'on rajoute une instance :-/ *)
                          let print ty x = print_endline (show ty x);;
                          val print : 'a showable -> 'a -> unit = <fun>
                          
                          print Float 1.2;;
                          1.2
                          - : unit = ()
                          
                          (* au final cette implémentation n'est pas compatible avec la programmation
                           * modulaire et les avantages des compilations séparées. *)

                          Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                      • [^] # Re: Jai: Language for game programmming

                        Posté par Shuba le 14 octobre 2016 à 13:47. Évalué à 2. Dernière modification le 14 octobre 2016 à 13:47.

                        

                        Dans leur article, ils comparent leur approche avec celles faites dans d'autres langages, comme les concepts pour le C++, section qui renvoie à un article collaboratif dont un des auteurs est Bjarne Stroustrup : Concepts: linguistic support for generic programming in C++. Comme je ne suis pas abonné à l'ACM, je n'ai pas pu lire l'article, et je me demande si ce sont bien les concept que les développeurs C++ attendent et dont parle la dépêche.

                        J'ai accès à l'article, et je confirme qu'il parle bien des même concepts que la dépêche. Si quelqu'un veut lire l'article je peux le transférer, demandez-moi par mail: shuba<at>melix<dot>org

        • [^] # Re: Jai: Language for game programmming

          Posté par lasher le 11 octobre 2016 à 16:53. Évalué à 7.

          

          Premièrement je suis d'accord pour dire que malgré toutes ses améliorations, C++ ne prend pas réellement de fonctions comme objets de première classe. Les lambdas et autres types d'inférences limités sont extrêmement bienvenus, mais on reste dans le domaine d'un langage impératif (avec désormais plus d'opportunités pour avoir un style fonctionnel). Je renvoie à l'article de John Carmack pour une exploration de style fonctionnel en C++. Ceci étant dit :

          P.S: Bon, le lambda-calcul ça date de 1936, et on a du attendre C++11 pour en avoir un ersatz à lire tes exemples

          Histoire de troller un chouïa : étant donné que Church et son thésard, un inconnu du nom de Alan… Alan… Alan T-quelque chose, sont les deux piliers qui ont permis de créer les fondations de l'informatique théorique telle qu'on la connaît, j'ai envie de dire que crâner à propos du lambda calcul « créé en 1936 »¹, alors que les principes de la machine universelle de Turing, qui sont certes arrivés plus tard (ce qui est somme toute logique), ont eux été mis en œuvre dès les années 40, c'est quand même rigolo. :-)

          Ensuite, juste pour dire, le bouquin de B. Pierce sur les types montre qu'il est parfaitement possible d'implémenter un système de typage fort à base de lambda-calcul (il propose un mini-Java comme exemple, et un mini-ML aussi).

          Je pense que l'ajout de trucs types lambdas à Java et C++ vient surtout du fait que lorsque tu as un écosystème populaire, il faut d'abord composer avec ce que les utilisateurs veulent (et fabricants de compilateurs proposent). Jusqu'au début des années 90, les compilateurs de production étaient franchement médiocres en termes d'optimisation (à quelques exceptions près, en particulier pour les compilateurs Fortran à destination de machines vectorielles, genre les Cray-I, etc.). Du coup, avec un langage procédural genre C, on pouvait au moins donner une forme au code qui permettait d'optimiser l'utilisation des registres, et d'être proche de la machine. Pendant très longtemps, les langages de programmation fonctionnelle a été considérée comme inefficaces en termes de performances. Ça commencé à sérieusement changer lorsque les compilateurs ont commencé à proposer des optimisations très agressives, mais même ainsi, les algorithmes (géniaux) qui sont derrière l'inférence de type de ML, et ceux qui gèrent la curryfication par exemple, ont tendance à mener à de la compilation via continuation, ce qui peut être très bien ou terrible en fonction de l'implémentation (y'a un excellent bouquin d'A.Appel sur la compilation de ML avec continuations soit dit en passant). Bref.

          Jusqu'à il y a peu, la programmation fonctionnelle était considérée comme un truc d'académicien². L'un des rares langages procéduraux à avoir intégré des bouts de programmation fonctionnelle était Perl: il est possible de passer des blocs de code et de créer des lambdas, tout un tas de fonctions « built-in » (genre map, grep, etc.) sont directement tirées de CLISP et ses copines, … Mais c'était aussi parce que Perl était à la base optimisé pour le traitement de fichiers textuels, et que les entrées-sorties étaient ce qui était bloquant de toute manière. Donc niveau perf, l'utilisation de fonctions de haut-niveau avec un coût à l'exécution était OK.

          Quand OCaml, Scala, Haskell, etc., on enfin émergé et commencé à prouver qu'ils pouvaient, eux aussi, proposer des performances raisonnables (pas forcément comparé à C/C++, mais au moins par rapport à Java), tout en proposant une grande puissance d'expression, on a vu Java et C# (par exemple) commencer à se doter d'aspects fonctionnels. Encore une fois, c'est entre autres parce que les développeurs/utilisateurs du langage ont vu ce que pouvaient faire les voisins et ont réclamé ces fonctionnalités.

          ---

          1. D'ailleurs je pense que tu parles du lambda-calcul typé; si je me souviens bien, le lambda-calcul non-typé avait été proposé 5 ans auparavant mais ne « servait à rien », d'où le besoin de pousser plus loin. ↩

          2. Il faut aussi dire que c'est un peu la faute des profs. Genre en France quand OCaml était enseigné y'a ~15-20 ans, la façon d'enseigner le truc était très mathématique. On faisait en pratique des maths avec un langage de matheux. Si les profs avaient proposé de faire de la prog en OCaml mais avec un aspect pragmatique (mais en gardant l'aspect fonctionnel) je pense que ça aurait dégoûté beaucoup moins de gens de l'informatique en DEUG. ↩

• [^] # Re: Jai: Language for game programmming

  Posté par DerekSagan le 11 octobre 2016 à 00:00. Évalué à 1.

  

  Selon le site C++ référence, les lambda seraient apparues avec le C++11 et ne correspondent qu'à de vulgaires fonctions anonymes construisant une clôture

  Soit 3 ans avant qu'à peu près la même chose n'apparaisse en Java.
  Et je suis gentil parce que les lambdas Java sont moins riches fonctionnellement.

  • [^] # Re: Jai: Language for game programmming

    Posté par barmic le 11 octobre 2016 à 07:38. Évalué à 2.

    

    Mais nous on s'en sert ! Il n'y a pas un framework ou une bibliothèque qui ne ce soit adaptée pour être plus agréable avec des lambdas. Il y a eu une vraie évolution de la bibliothèque standard pour avoir des usages pratiques.

    Autant je déplore le manque de curryfication, autant je n'ai jamais ressenti le besoin d'avoir plus de choix dans ma façon de capturer. Ajouter des options pour ajouter des options ça ne m'intéresse pas plus que ça. Avoir une API fluent pour faire de la composition c'est déjà plus utile pour ce que je fais en tout cas.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Jai: Language for game programmming

      Posté par DerekSagan le 11 octobre 2016 à 09:12. Évalué à 0.

      

      Je ne sais pas de qui tu parles quand tu dis "nous" mais perso j'utilise pas mal les lambdas en C++ et je curryfie régulièrement avec std::bind.

      http://en.cppreference.com/w/cpp/utility/functional/bind

      Je sais pas comment on fait en Java mais au pire il suffit de refaire une closure à la main même si ça doit être un peu plus lourd en syntaxe (comme je trolle pas sur Java remarquerais pas que la lourdeur de syntaxe est un standard de fait).

      • [^] # Re: Jai: Language for game programmming

        Posté par barmic le 11 octobre 2016 à 10:24. Évalué à 3.

        

        […] comme je trolle pas sur Java […]

        lol ?

        Et je suis gentil parce que les lambdas Java sont moins riches fonctionnellement.

        Pour la curryfication :

        […] il suffit de refaire une closure à la main même si ça doit être un peu plus lourd en syntaxe […]

        Oui c'est tout à fait possible et comme tu peux utiliser des références de méthodes ça n'est pas forcément particulièrement lourd. Au niveau de la syntaxe une lambda c'est (params) -> { body } où les paramètres n'ont pas forcément de type explicite et où il n'est pas nécessaire de mettre le body dans un bloc s'il ne contient qu'une seule instruction. Je trouve ça assez concis.

        Pour ce qui est du fonctionnellement moins riches, le fait que ça se base sur des interfaces et que les interfaces peuvent avoir des méthodes permet des choses qui ne sont pas directement accessible en C++ comme le fait java.util.Function avec la composition par exemple (https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Jai: Language for game programmming

          Posté par DerekSagan le 11 octobre 2016 à 14:10. Évalué à 0.

          

          […] comme je trolle pas sur Java […]
          lol ?

          Tout à fait, un exemple typique de prétérition.

          […] il suffit de refaire une closure à la main même si ça doit être un peu plus lourd en syntaxe […]
          Oui c'est tout à fait possible et comme tu peux utiliser des références de méthodes ça n'est pas forcément particulièrement lourd. Au niveau de la syntaxe une lambda c'est (params) -> { body }

          Donc je dis "écrire une closure à la main par dessus le lambda pour pouvoir curryfier ça peut-être un peu lourd" et tu me réponds "la syntaxe de base du lambda n'est pas lourde", t'as pas l'impression qu'on parle pas de la même chose ?
          Cela dit mon propos n'était pas une critique, juste je disais que c'était possible de curryfier en Java.

          où les paramètres n'ont pas forcément de type explicite

          Oui, le compilateur C++ sait les déduire aussi.

          Et on peut même définir un lambda générique genre:
          
auto multiplier_par_deux = [](auto x) { return 2*x; }

          Sans être obliger de déclarer une interface avec un generic autour de java.util.Function. Suivez mon regard.

          Pour ce qui est du fonctionnellement moins riches, le fait que ça se base sur des interfaces et que les interfaces peuvent avoir des méthodes permet des choses qui ne sont pas directement accessible en C++ comme le fait java.util.Function avec la composition par exemple

          C'est pas un exemple c'est le seul argument.
          C'est un lot de consolation pour toutes les limitations de java.util.Function, notamment celui que je décris juste au-dessus.

          Mais ça ne doit pas interdire de faire du java ni d'en utiliser les lambdas !