Aluminium95 a écrit 223 commentaires

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 6.

    Pourquoi y réponds-tu alors?

    Je ne réponds pas, je produis des remarques inintéressantes, cela avait pour vocation de mettre un peu de distance entre les propos tenus par la suite et ma personne, et non pas de faire une attaque ad hominem.

    Je constate en effet que la règle de proximité, au même titre que les déclinaisons, les positions plus ou moins variables des mots dans une phrase ainsi que les construction syntaxiques qui alourdissent le langage ont fini par disparaitre du Français. Je n'ai pas lu le livre auquel tu fais référence, mais en lisant la page wikipédia citée, on trouve

    Au xviiie siècle, la primauté du masculin sur le féminin et celle du pluriel sur le singulier finissent par s'imposer, du moins concernant l'accord entre un sujet pluriel et son attribut.

    Qui est suivie d'une phrase pour le moins amusante : « Pour justifier la primauté du masculin, le motif … ». Je comprends peut-être mal la phrase, mais j'ai l'impression que la pratique s'est démocratisée, et que seulement par la suite les gens ont voulu l'institutionnaliser et ont trouvé des justifications plus ou moins douteuses (la noblesse du genre etc). Vu que tu as plus de connaissances que moi sur ce sujet, pourrais-tu éclaircir le passage entre les deux règles ?

    Un avantage? Quand on voit la merde que c’est

    Je ne vois pas le rapport … Franchement, le problème c'est que tout est mélangé ! On parle simplement d'offre et de demande à caractère discriminatoire. On ne va pas dire que tel truc n'est « pas sexiste » parce que bon, je sors de mon chapeau un critère complètement arbitraire qui va bien.

    ça serait un truc rempli de stéréotypes de mecs

    Mais je suis certain que cela existe ! Franchement, la recherche de la beauté, les articles hétérocentrés, et tout le tintouin c'est aussi le cas pour les hommes.

    Est-ce qu’une seule personne pouvait se vanter de l’être? Plus intéressant que de se poser la question de l’objectivité, se demander quel est mon but et ma perspective.

    Je suis parfaitement d'accord avec toi sur ce point. Mais le problème c'est que dans tes argumentations, j'ai l'impression d'avoir du mal à cerner le moment où tu parles de sexisme dans la société, le moment où tu fais des jugements d'ordre moral, le moment où tu invoques un critère de préférence personnelle … C'est plutôt cette difficulté que j'ai tenté d'exprimer en disant que certains points n'étaient « pas objectifs ».

    Je pense que l’écrasante majorité des différences sociales entre hommes et femmes sont dues au conditionnement social.

    Ça encore c'est une tautologie ou presque : la société façonne le comportement social. La vraie question c'est : veut-on imposer un changement social ? À partir de quel moment cesse-t-on d'encadrer les rapports humains et commençons nous à les dicter ?

    Mon objectif est donc de lutter contre les injonctions, stéréotypes et inégalités entre hommes et femmes.

    C'est là que les opinions sont un peu divergentes (enfin, au moins entre nous deux). Je pense qu'il faut lutter contre les discriminations abusives, volontaires, ou qui ont un impact sur le niveau de vie, et il y en a un énorme paquet. Par contre, passer du temps pour forcer une association dont l'intention est louable à changer son point de vue parce que tu imagines que cela impose une vision sexiste qui discrimine les femmes du jeu vidéo, je trouve que c'est une perte de temps, et cela cause plus de mal que de bien : c'est parfois fait de manière agressive (voir le premier commentaire du fil), non constructive, et du coup cela ternit l'image du combat que tu voudrais mener.

    Par exemple proposer de réformer une langue vivante qui malgré les formalisations continue d'évoluer, c'est à mon avis une perte de temps. Je suis conscient que le langage tel qu'il est actuellement peut introduire et introduit certainement des biais, et des manières de pensées. Seulement je pense qu'il est plus intéressant de faire évoluer les mentalités plutôt que les outils qui les expriment.

    De plus, quand une personne utilise le masculin, je suis persuadé que 99% du temps il ne veut pas par là assoir la domination du monde par les hommes dont le sexe serait plus noble ou je-ne-sais-quoi. J'irais même jusqu'à dire que le cerveau finit par faire abstraction de ce bruit et que seul le message qu'on veut faire passer importe, ensuite l'inconscient, les réflexes acquis durant l'apprentissage de la langue construisent naturellement des phrases valides (enfin, souvent).

    J'écris beaucoup et je me rends compte que cela dessert sûrement mon argumentation. Je m'en excuse d'avance, autant pour toi que pour la « pollution » engendrée dans le fil de discussion qui continue à grossir. Peut-être pouvons-nous continuer sur un autre canal de discussion ?

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.

    Je crois comprendre ce que tu veux dire, mais je pense encore une fois que tu sur-interprètes la portée de vouloir inciter une population à s'intéresser au travail d'une association. Je ne veux pas dire de bêtises, mais il me semblait avoir vu qu'il y avait certaines conférences / certains salons réservés aux informaticiennes. Si on suit ta logique, cette démarche serait sexiste envers les femmes ? (dans le sens négatif du terme).

    Par la suite, quelques remarques inintéressantes

    Les hommes ont aussi inscrit ce principe dans la grammaire en forçant la règle selon laquelle «le masculin l’emporte sur le féminin»

    Je crois que c'est plus une volonté de simplification des règles de grammaires qu'une réelle volonté d'imposer une hiérarchie homme/femme. Non pas que cette décision ne se soit pas inscrite pas dans un contexte où il y avait effectivement une hiérarchisation des relations entres les hommes et les femmes, mais je pense simplement que c'est une règle pratique. De la même manière, on a cessé d'avoir des déclinaisons pour les différentes fonctions, un genre neutre, modification de l'orthographe pour suivre les changements de prononciation etc, afin de se rapprocher d'un langage oral plus simple et aussi expressif : si on veut vraiment préciser, on peut toujours le faire, quand c'est important.

    Enfin, tout ça pour dire que les langues ont attendu pas mal de temps avant d'arriver à une forme stable, ou simplement une forme bien documentée, et donc imputer aux « hommes » un « choix » qui s'est vraisemblablement fait sur des dizaines voir des centaines d'années est quand même un peu étrange.

    Les magazines féminins sont un genre à part entière mais il n’y a pas de «magazine masculin»

    Et au contraire, je trouve ça discriminant : pourquoi est-ce qu'il existerait un magazine spécifique aux femmes quand il n'en existe aucun spécifique aux hommes ? (si on admet que ce que tu dis est vrai). À priori, un magazine « normal » n'est pas destiné à un genre particulier, ce qui donne en quelque sorte un « avantage » aux femmes … Tout est une question de point de vue, et la vision que tu as n'est pas objective.

    Après, je dirais que certains magazines se destinent quand même beaucoup plus aux hommes, ne serait-ce que par les articles proposés et le style d'écriture, mais mes connaissances sont trop minces pour que je me risque à en trouver.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.

    Ah, en effet, je ne connaissait pas, mais du coup, wikipédia a répondu à ma question : dans le cadre d'un phénotype masculin avec deux chromosomes X, une partie des séquences ADN du chromosome Y a subi une translocation vers l'un des deux chromosomes X, ce qui explique qu'il puisse en exprimer les caractéristiques.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 3.

    ça donne l’impression que les jeux vidéo s’adressent en premier lieu à des garçons

    C'est une interprétation comme une autre, ce n'est pas tellement parce qu'il y a un CD fille que tu peux déduire cela, mais plutôt du contexte, qu'il soit réel ou bien simplement par la perception que tu/nous en avons.

    Imaginons qu'un fabriquant de PC fournisse une gamme « spécial gamer », serait-ce parce que les « gamers » ne sont pas des vrais utilisateurs de PC, et que l'ordinateur ne s'adresse à priori pas à eux ? Non, tu vas dire : il leur faut des choses spécifiques parce qu'il sont chiants sur le matos. Je dirais même que les gens sont plutôt content, parce qu'ils savent qu'à priori, la configuration sera plus proche de ce qu'ils recherchent … (bien que cela puisse être faux).

    Imaginons maintenant qu'on fasse une poupée barbie « spécial garçon » (pour reprendre la discrimination sur le genre), là on peut imaginer retomber dans la construction que tu évoques : les barbies ne sont en général pas pour les garçon, donc là on va faire un truc spécial pour eux. Mais même dans ce cadre, est-ce que ce serait sexiste ? Pas tellement, cela pourrait juste provenir d'une étude de marché qui montre que les barbies sont principalement utilisées par des filles, et pour diversifier le marché (potentiellement doubler les ventes !) il faut attaquer la version « garçon » …

    On peut même arriver à une interprétation totalement différente du sujet initial : on constate par exemple que la part de jeux joués par des filles n'est pas assez représentée (de manière réelle ou perçue une fois de plus), on voudrait les sensibiliser aux jeux libres pour les intégrer à une communauté, et favoriser leur insertion … Ce qui est d'autant plus vrai car le « CD filles » ne contient pas de jeu spécifique pour les filles (on peut les récupérer ailleurs, il n'y a pas de version fille/garçon de ces jeux).

    Enfin, tout cela pour dire que ça donne l'impression est une formulation très vague qui permet de dire n'importe quoi ensuite. Je ne porte pas de jugement sur le contenu, juste sur l'argumentation : Bref c’est plutôt bof.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 4. Dernière modification le 17 août 2016 à 23:30.

    y a plein de mecs XX

    Je suis curieux, d'un point de vue strictement biologique, cela veut dire que les séquences qui permettent d'exprimer le phénotype « male » ne seraient pas dans le chromosome Y ? Ou plutôt, qu'on puisse quasiment toutes les retrouver en dehors de ce chromosome spécifique ? Mes cours de biologie montraient surtout que dès qu'on touche un peu trop ça commence à casser : Syndrome de Klinefelter, Trisomie, et autres …

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.

    'tu prends tes conges paternite ? hah bah c'est l'autre qui aura la promotion hein'

    C'est un autre problème, qui n'est pas de l'ordre du comportement de société mais de celui du chantage : pour cela il est utile de faire des lois pour protéger les salariés qui décident de prendre leurs congés. Après, il y a tout un facteur qui dépend de l'évolution de la société et des mentalités qui je pense (ou plutôt j'espère), ne se règle pas simplement en édictant une loi.

    Ce que tu appelles "liberte" c'est la liberte du patron de baiser ses salaries.

    C'est un autre débat, et je ne crois pas que des commentaires aussi courts puissent résoudre cette question définitivement (ou même partiellement) …

    La servitude volontaire a decidemment encore toujours autant d'avenir….

    De la part d'une personne prônant des lois imposant un comportement aux citoyens … c'est amusant. Des deux côtés il y a de la « servitude », ce n'est simplement pas la même forme, et je ne vois pas en quoi servir un État (sans spécification) serait théoriquement mieux que servir les lois du marché, les deux étant en quelque sorte arbitrairement fixés par des êtres humains.

    Encore une fois, il faut relativiser les propos et chercher un équilibre entre liberté individuelle et comportement collectif.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.

    la seule solution est que ce soit identique pour les 2 parents sinon ca reste comme c'est, que ca te plaise ou pas

    Je crois que la divergence d'opinion n'est pas sur ça, mais sur le fait que certains veulent une égalité en droit, et d'autres en actes. Ainsi, il a été proposé d'imposer aux gens de poser leurs congés d'une certaine manière, alors que d'autres font remarquer qu'il existe déjà des lois en place pour favoriser la prise de congés par le conjoint.

    c'est juste pas sympa pour ta femme

    Je ne crois pas avoir lu que laisser l'intégralité du taf à sa femme était un acte de sympathie …

    et certaines contraintes sont nécessaires pour assurer une liberté réelle.

    C'est à peu près le seul argument valide dans ton commentaire, seulement il n'est pas développé ! D'un côté oui, il faut imposer des choses si on veut pouvoir exercer des libertés individuelles, personne ne dit le contraire, mais le problème ici c'est essayer de régler une situation de société en imposant par la législation un comportement nouveau. Il faut systématiquement trouver un juste milieu, et c'est justement ce qui fait débat ici. Si on parlait par exemple d'une loi pour imposer un uniforme unisexe dans la fonction publique pour des raisons d'égalité, la question serait à peu de choses près la même, mais le « juste milieu » serait quand même bien différent à priori. (je précise que c'est un exemple volontairement exagéré à vocation illustrative).

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 1.

    Ça permet de résoudre ce problème, oui, mais c'est en « diminuant la productivité » globale des sociétés, et les gens vont râler. Ensuite, on dira que c'est pour cela que les délocalisations sont inévitables.

    Si on garde cette idée, ce qui serait bien c'est de faire en sorte que les congés des deux parents ne se chevauchent pas trop, ou alors faire un mois sur deux, enfin, quelque chose comme ça.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 2.

    Tu n'as pas cité ma phrase en entier et notamment la partie la plus importante : du fait de leur sexe.

    Je ne comprends pas cette réponse, en quoi le sexe des individus devrait influencer ton comportement vis-à-vis d'un sondage (supposé fait dans les règles de l'art) ? Si on remplace « fille » par « 10-12 ans » aurais-tu la même réaction ?

    Je rappelle quand même que ces questions ne sont pas directement en rapport avec le sujet du journal, ce pourquoi j'ai omis la question du sexe (qui à priori ne devait pas influencer l'interprétation d'un sondage) dans mon premier commentaire.

  • [^] # Re: Tiptop le sexisme

    Posté par  . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 9.

    aucune raison objective que les filles prises dans leur ensemble préfèrent

    Les préférences sont rarement objectives.
    Mais admettons … Si jamais un sondage fait proprement dit qu'un certain groupe possède une préférence (et ce de manière significative) mais que tu n'expliques pas de manière « objective », tu vas simplement nier son existence ? Je ne dis pas que c'est le cas ici puisque le sondage lui-même est contestable, mais dans l'absolu je trouve ta position est bancale.

  • [^] # Re: migre

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 1.

    Je répondais à

    mon expérience est qu'un algo en O(N log N) peut gagner en temps parce qu'il stocke plus d'état que son équivalent O(N).

    Du coup c'était sous entendu qu'il utilisait des « petites valeurs de N » ?

    Enfin, dans les arguments je pense qu'il faut différencier les particularités du jeu de données (pire cas VS cas moyen VS meilleur cas) des optimisations faites par la machine (qui peuvent réellement fausser l'étude de complexité moyenne par exemple) comme l'utilisation de caches, prédictions de branches et autres.

  • [^] # Re: migre

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 1.

    Je suis peut-être fatigué, mais O(N log N) c'est plus lent (asymptotiquement) que O(N) … Du coup je ne vois pas comment il peut « gagner du temps ».

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 6.

    qu'on a inventé un tas de trucs pour se débarasser de ses inconvénients

    Je suis curieux, quelles sont les alternatives dont tu parles ? L'analyse statique du code ?

    qu'il apporte plus d'inconvénients que d'avantages dans beaucoup de cas

    Là encore je suis curieux, est-ce une question de verbosité, de puissance d'expression, de flemme (ne pas avoir à se demander ce qu'on manipule) ?

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 5.

    Avoir un système de type permet aussi de renforcer certains invariants du programme quand même.

    Un exemple pas forcément pertinent : en python, quand je voulais faire des arbres rapidement, j'utilisais des dictionnaires. La raison principale était qu'il n'y avait pas besoin de définir de classes, que je pouvais ajouter des attributs très facilement aux noeuds (puisqu'ils étaient des dictionnaires) et la sérialisation/dé-sérialisation était facile.

    Le problème, c'est qu'en regardant le code, il n'y a aucun moyen de savoir quels champs étaient obligatoires, quelle était la structure générale, ou tout simplement si les informations ajoutées sur les noeuds étaient préservées par les fonctions qui traitaient les arbres (par chance c'était le cas). C'était génial pour faire du développement rapide, mais par la suite cela ne faisait pas « propre » (et c'était très dur de relire le code pour ajouter une fonctionnalité).

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 6.

    Tout dépend du système de type, mais un système statique peut se permettre d'oublier les types à la compilation (pas de checks à runtime) alors qu'un système dynamique doit conserver et vérifier les types durant l'exécution du programme. Cela apporte potentiellement une meilleure performance du programme.

    L'argument principal en faveur du typage statique étant toutefois qu'un système de type permet de détecter des classes d'erreurs à la compilation en rendant les mauvais programmes impossibles à écrire.

    A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute
    Benjamin Pierce, Types and Programming Languages

    C'est l'expressivité du système de type qui détermine sa capacité à capturer des mauvais comportements. Toutefois il faut limiter cette expressivité pour être capable d'assigner un type à une expression en un temps raisonnable.

    Un système de type dynamique n'assure rien à la compilation, donc par construction on remplace la notion d'état non représentable en erreur (spécifique) à l'exécution. Cela permet de ne pas se soucier des types avant de lancer le programme, mais en contrepartie, il faut se convaincre que tout marche comme on s'y attend (ce qui devient dur sur de gros programmes).

    Une petite remarque : les garanties d'un système de types sont à modérer, car on peut faire des conversions non-sûres dans la majorité des langages. C'est le cas de C avec les casts, mais aussi d'ocaml avec Obj.magic.

    Pour moi un système de type statique fort est un avantage certain.

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 2.

    Par curiosité, quel est le reproche fait à la généricité de Java ? Je crois comprendre que cela permet d'ajouter du polymorphisme au niveau des types, ce qui est à priori une bonne chose.

    Une rapide recherche peut mener sur un article qui explique que les « generics » ne sont pas nécessaires en Go, mais ses arguments sont peu convaincants. La première solution proposée est assez amusante

    Okay, what if I wanted an operation that works with multiple types—perhaps on all numeric types, e.g. int32, int64, uint16, etc. Now we've got a problem. But actually we don't. We just need a few intermediate alias types which implement an interface.

    Qui revient exactement à utiliser des fonctions non-polymorphes, et faire ensuite à chaque appel un dispatch pour savoir quelle implémentation utiliser.

  • [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    Merci ! Ça répond exactement à ma question. J'aurais du regarder directement là

    Dynamic languages, such as Scheme, Smalltalk or Javascript, are easy to compile to and have reasonably fast implementations. However, when running statically typed functional programs, time is wasted on runtime type checks.

    C'est l'argument clef qui met Lambda devant Scheme, en particulier il dit après

    it assumes its input to already have been proven safe
    by a high-level type checker. This makes it an ideal
    target for statically-typed languages with advanced
    type systems, since the safety of programs need not be
    explained to the backend.

    Cependant on peut quand même se poser quelques questions parce que ce n'est pas vraiment rassurant de lire ensuite :

    So, I conjecture that OCaml will not miscompile any Malfunction program, or at least that when it does, it will also miscompile a sufficiently contrived OCaml program.

  • [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    En effet, je me suis mal exprimé.

    Je voulais savoir pourquoi ocaml était un choix rationnel, ou plutôt, pourquoi malfunction produit du Lambda plutôt que du Scheme par exemple. À priori, je n'avais pas vu la grosse différence entre les deux langages. Pour moi on y trouvait

    1. Un langage avec des S-expressions
    2. Un garbage collector
    3. Une compilation efficace

    Mais il est vrai que la gestion des types sommes peut être pénible. L'argument qui consistait à préférer un scheme était celui de dire que contrairement à Lambda, il serait spécifié (un souci de moins).

    Lambda lui-même n'est pas proposé comme cible directe pour les autres langages et

    Oui mais il est utilisé, enfin, c'est le backend.

    Une question plus pertinente (puisque visiblement les types sommes en Scheme c'est vraiment peu performant) serait : pourquoi ne pas compiler vers GHC Core. Ici, on a encore un truc interne et pas forcément stable, mais la définition à le mérite d'être assez simple (au moins en surface). Par contre, il faudrait écrire Malfunction en haskell (pour générer l'AST reconnu par GHC Core).

  • [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 0. Dernière modification le 26 juin 2016 à 21:42.

    Je crois qu'il y a incompréhension mutuelle.

    La question était : pourquoi ocaml ? Pas pourquoi malfunction, pas pourquoi un mec voudrait écrire un compilateur rapidement, pas pourquoi est-ce que mettre dans le pointeur l'information d'un type somme c'est cool. Juste pourquoi le mec qui fait malfunction utilise ocaml. C'est tout. À partir de là, encore une fois, tes réponses sont à côté de la question, parce que la majorité de ce que tu dis concerne un mec qui veut utiliser malfunction.

    Encore une fois, la syntaxe importe peu. Malfunction permet d'utiliser le back-end d'OCaml (

    Oui, c'est justement la question.

    Bah euh, c'est justement le point. Malfunction offre juste un langage intermédiaire.

    Mais j'en ai rien à faire ! Je te demande pourquoi utiliser ocaml quand tu pouvais par exemple utiliser des macros scheme. C'est le mec qui code malfunction qui se fait chier, pas l'utilisateur final (qui de toute manière, cherche au départ à coder un compilateur, rappelons le).

    J'en conclus donc

    Donc je vois pas trop ce que tu essayes de dénoter ici.

    Idem. Je ne vois pas en quoi tes arguments sont pertinents.

    C'est là où on voit que tu as une méconnaissance de l'objectif réel de Malfunction. Bien entendu que tu peux faire toi même un back-end vers ASM x86 ayant une représentation optimisé des types sommes mais la véritable question est: est ce que tu veux réellement produire toi même de l'ASM x86 ?

    Je n'ai JAMAIS dit que je voulais complier directement du malfunction vers de l'ASM x86, c'était juste une petite pique pour préciser que l'argument avancé n'avait aucune valeur. C'était pourtant assez clair (il me semble).

    Pour revenir sur la stabilité

    une abstraction d'une représentation intermédiaire (le Lambda)

    Oui, j'ai même dit que malfunction offrait une interface stable, la question c'est pourquoi ne pas avoir choisi un langage stable pour faire le reste du boulot. C'est peut-être pour des raisons techniques intéressantes, comme par exemple la performance de la gestion des types sommes, comme tu l'as laissé entendre, et ça c'est un argument pertinent.

    pour finir

    et c'est bien la raison de Malfunction.

    Oui … on est bien d'accord, on ne parle juste pas de la même chose.

    Pour reprendre. Malfunction compile vers Lambda, qui est un langage basé sur des S-expressions qui n'est pas standardisé, mais qui est une représentation intermédiaire du langage ocaml, ce qui permet d'être compilé efficacement. Je demande si on ne pourrait pas imaginer utiliser un scheme à la place de lambda : basé sur des s-expressions, standardisé, qui bénéficie d'un compilateur efficace. Je ne dis pas que c'est une idée géniale, juste que pour l'instant je n'ai pas été convaincu par tes arguments.

    EDIT: je me suis trompé de destinataire, j'ai mal cliqué pour la réponse :-.

  • [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    C'est un langage intermédiaire, pas un langage de surface pour les utilisateurs.

    Oui, donc il faut encore plus une syntaxe spécifiée, c'est à dire, avec une spécification. Parce que bon, dépendre d'un truc qui peut casser à tout moment je trouve que c'est pas super. Ou alors il faut que ocaml puisse garantir une certaine stabilité de cette représentation intermédiaire, ce qui apparement n'est pas à l'ordre du jour.

    C'est en fait le point clef d'utiliser un scheme plutôt qu'une représentation qui de l'avis même de l'auteur, n'aurait jamais du être exposée en dehors du compilateur.

    De plus, j'ai l'impression que du confonds la syntaxe de malfunction et la syntaxe de Lambda. Qui sont apparemment deux langages différents, par exemple quand tu parles de

    Du moment que la syntaxe est non-ambiguë, clairement définie et facile à produire et à lire, ça pourrait être du XML ça n'aurait aucune importance.

    C'est à propos de Malfunction, et non pas de Lambda. Or, la question porte justement sur le fait de remplacer Lambda par un scheme … donc cette remarque n'a strictement aucun intérêt (elle ne porte pas sur le bon objet).

    Ensuite, j'ai l'impression que l'objectif n'est pas bien défini. Parce que d'un côté tu dis

    Beuh, encore une fois le but c'est d'obtenir facilement un compilateur décent pour un langage expérimental à moindre coût,

    Et ensuite

    Imagine que j'ai un programme OCaml qui veut appeler une fonction Links

    Ce qui veut dire que même une fois que ton langage devient « mûr » tu veux continuer à utiliser cette architecture ? Même si de ton propre avis

    si pour cela il faut piper dans un fichier texte au milieu, je ne vois pas vraiment le soucis

    Ce qui (pour moi) sous-entends que c'est une phase « alpha », prototype, enfin, quelque chose de pas propre. Et quand on voudra le faire proprement, voilà ce qu'il va se passer :

    manipuler directement la compilation (mais encore une fois elle n'est pas stable)

    Ah, bah, on repose sur un truc instable, génial.

    Lambda a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation intermédiaire du compilateur OCaml, qui en a)

    Je veux bien te croire sur parole (étant donné qu'il n'existe pas de spécification du langage), mais cet argument est quand même bien foireux, je te le refais

    ASM x86 a bien une représentation des valeurs qui permet de manipuler les types sommes (puisque c'est la représentation du compilateur OCaml, qui en a)

    Hophophop, voilà ! Bon, j'ai retiré « intermédiaire » et changé le nom … Soit ce que tu dis est qu'il est possible de le faire simplement, ce qui est le cas dans à peu près n'importe quel langage (même x86) soit tu dis qu'il existe une syntaxe spéciale, et alors l'argument n'a aucune valeur.

    Je ne vois pas vraiment l'intérêt.

    C'est minime, c'est juste que bon, tu n'as pas à construire :

    1. Un lexer
    2. Un parser
    3. Un programme qui va compiler un AST vers un autre langage

    En plus, le fait que tout soit « au même niveau » permet aux gens d'ajouter si besoin des syntaxes à ton langage de macros, ou d'en changer le sens plutôt facilement, en restant dans un même langage, plutôt que de devoir utiliser du ocaml pour changer le fonctionnement d'un langage (malfunction) et la manière dont il se compile vers un troisième (Lambda).

    Après c'est vrai que c'est beau en théorie, mais qu'en pratique c'est peut être pas idéal du tout. Il faudrait en parler avec l'auteur pour savoir quelles étaient les raisons de son choix.

    Imagine que j'ai un programme OCaml qui veut appeler une fonction Links (ou Eff ou Idris) ou l'inverse. Je peux vérifier que les types sont à peu près cohérents (les deux langages n'ont pas les mêmes types mais il y a sous-ensemble commun qui garantissent à peu près les mêmes comportements), compiler les deux vers Lambda et les lier ensemble.

    On ne peut pas le faire en utilisant un programme C intermédiaire ? Ça revient presque au même (parce que la glue et l'analyse de type tu la feras quand même). C'est plus complexe techniquement, certes.

  • [^] # Re: Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    La question se pose aussi dans l'autre sens: pourquoi choisir Lisp plutôt que OCaml ?

    Quand je dis lisp, c'est un lisp ou un scheme. Par exemple chicken scheme. Les avantages sont :

    1. La syntaxe est spécifiée pour le scheme : si le code n'utilise pas d'extensions c'est même très basique
    2. Le compilateur est fait pour être intégré dans une application (dans le cas de chicken scheme), ce qui n'est pas le cas d'ocaml
    3. Malfunction pourrait être une collections de macros qui génèrent le code adéquat pour les fonctions « haut niveau » comme le pattern matching

    Après, les points négatifs sont bien sûr

    1. À priori pas de types sommes (mais dans malfunction non plus si, puisque Lambda n'en a pas … ?)
    2. Pas d'interaction avec l'écosystème ocaml
    3. On peut payer le coût du runtime, être confronté aux limitations du compilateur, du garbage collector … mais c'est pareil avec ocaml (à moins qu'il ne soit techniquement meilleur)

    Je ne suis pas certain de tout maîtriser, mais il me semble que Lambda ne possède pas

    1. de système de type : l'argument de l'interaction typée avec les autres programmes tombe
    2. de type somme : donc c'est malfunction qui fait cette traduction, et elle pourrait aussi bien se faire avec un lisp/scheme

    Mais je peux me tromper.

  • [^] # Re: model

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    Après lecture du README, l'entrée attendue par son programme est une sorte de lisp non typé, et visiblement il y a un effort fait sur la facilité de produire du code de manière algorithmique, par exemple les noms de variables commencent tous par un symbole spécial pour ne pas avoir de problème avec des mots réservés du langage.

  • # Représentations intermédiaires du compilateur OCaml

    Posté par  . En réponse au journal Malfunction: réutiliser la représentation intermédiaire du compilateur OCaml. Évalué à 1.

    J'ai une question, est-ce que c'est une partie qui est standardisée (qui n'évolue pas ou presque malgré les changements dans le langage à plus haut niveau) ?

    Ce que j'ai trouvé dans real world ocaml dit explicitement :

    It's not important to understand every detail of this internal form, and it is explicitly undocumented since it can change across compiler revisions.

    Mais pour rejoindre les autres commentaires, c'est d'autant plus étrange que cela semble être assez proche d'un LISP au final, quand on regarde l'exemple donné dans la page :

    type t = | Alice | Bob | Charlie | David
    
    let test v =
      match v with
      | Alice   -> 100
      | Bob     -> 101
      | Charlie -> 102
      | David   -> 103

    Compilé vers le langage intermédiaire avec ocamlc -dlambda -c pattern_monomorphic_large.ml

    (setglobal Pattern_monomorphic_large!
      (let
        (test/1013
           (function v/1014
             (switch* v/1014
              case int 0: 100
              case int 1: 101
              case int 2: 102
              case int 3: 103)))
        (makeblock 0 test/1013)))

    Mais peut-être que ce n'est pas de cette représentation dont parle le journal (je n'ai pas eu le courage de regarder le code source), quoique le README puisse le laisser penser :

    The syntax is based on s-expressions, and is designed to be easy to correctly generate, rather than to be particularly beautiful.

    La question est donc : pourquoi utiliser le compilateur OCaml ? Les performances sont-elles vraiment meilleures qu'un lisp compilé ? L'écosystème OCaml est-il facilement accessible ?

  • [^] # Re: Dans l'art voluptueuse de ne rien comprendre

    Posté par  . En réponse au journal EDSL et F-algèbres. Évalué à 1.

    L'idée est que le fold retourne une liste complexe d'éléments qui sont analysé ensuite.

    Exactement ! C'est ce que je voulais dire par « enrichir la sortie ».

    De rien :-).

  • [^] # Re: Dans l'art voluptueuse de ne rien comprendre

    Posté par  . En réponse au journal EDSL et F-algèbres. Évalué à 1.

    Visiblement on est pas très fort pour communiquer :-).

    Je vais faire du pas à pas sur un exemple :-p.

    typedef toto int;
    int a = 1;
    toto b = 2;

    L'arbre pourrait ressembler à ça :

    expr = SEQ (TYPEDEF ("toto", "int"), (SEQ (VARDEF ("int", "a", INT 1), VARDEF ("toto", "b", INT 2))))

    Mon algorithme fait son petit fold et accumule les contraintes. Alors, comme on parle d'un langage assez compliqué, on admet qu'on ne peut pas mettre d'expressions à droite d'une égalité (c'est vraiment nul, mais sinon il faut plus de travail pour déterminer le type, c'est pénible, et cela n'est que « local » à l'expression).

    On peut donc écrire un bout de code dans ce genre là dans une disjonction de cas
    ocaml
    VARDEF (le_type, le_nom, (INT x)) -> { references = construire_un_singleton le_nom ; contraintes = construire_un_singleton (EQ "int" le_nom) ; declarations = empty_set }

    On peut aussi écrire un truc qui dit : ah bah oui, c'est bien défini

    TYPEDEF (a,b) -> { references = construire_un_singleton b ; contraintes = construire_un_singleton (EQ a b) ; declarations = construire_un_singleton a }

    On doit aussi écrire le cas où on tombe sur un SEQ, pour cela, on se contente de fusionner les contraintes et les références avec union_set.

    SEQ (a,b) -> { references = union_set a.references b.references ; contraintes = union_set a.contraintes b.contraintes }

    Je n'écris pas la fonction en entier, mais voilà comment ça tourne :

    evalue_type expr (* entre dans la fonction *)
    SEQ (x,y) (* fait l'appel récursif droit *)
    TYPEDEF ("toto","int") (* c'est un truc « final » : on applique la fonction de calcul *)
    { references = { "int" }; contraintes = { EQ ("int", "toto") }; declarations = { "toto" } }
    (* on a terminé l'appel récursif droit, on fait l'appel récursif gauche *)
    SEQ (z,t) (* fait l'appel récursif droit *)
    VARDEF ("int", "a", INT 1) (* c'est un truc « final » : on applique la fonction de calcul *)
    { references = { "int" }; contraintes = { EQ ("int", "int") }; declarations = {} }
    (* on a terminé l'appel récursif droit, on fait l'appel récursif gauche *)
    VARDEF ("toto", "b", INT 2) (* c'est un truc « final » : on applique la fonction de calcul *)
    { references = { "toto" }; contraintes = { EQ ("toto", "int") }; declarations = {} } 
    (* on a terminé gauche et droite, on fusionne les deux résultats car c'est ce qu'il faut faire avec un SEQ *)
    { references = { "toto", "int" }; contraintes = { EQ ("toto", "int") ; EQ ("int", "int") }; declaration {} }
    (* on a terminé gauche et droite pour la grosse expression, on fusionne les deux résultats car c'est encore un SEQ *)
    { references = { "toto", "int" }; contraintes = { EQ ("int", "toto") ; EQ ("toto", "int") ; EQ ("int", "int") }; declarations = {"toto"} }

    Alors j'ai très mal choisi la notation EQ qui correspond à ta flèche -> … Mais après, une fois qu'on a ce résultat, on peut regarder si tout ce qui est référencé est déclaré : ici ce n'est pas le cas, car on devrait dire que « int » est toujours déclaré. Ensuite, on peut éventuellement regarder si le graphe est bien fait au niveau des contraintes.