Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2016-06-25T23:53:25+02:00Les derniers messages parus sur le forum de Zeste de Savoir.Acid, le lisp-like de la communauté !, message #1157222016-06-25T23:53:25+02:00Dinosaure/@Dinosaurehttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115722<p>Je laisse ça là entre les contradictions et inepties de certains si vous vous posez toujours la question du <em>back-end</em>: <a href="http://linuxfr.org/users/bluestorm/journaux/malfunction-reutiliser-la-representation-intermediaire-du-compilateur-ocaml">Malfunction</a></p>Acid, le lisp-like de la communauté !, message #1157172016-06-25T22:55:01+02:00Eusèbe/@Eus%C3%A8behttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115717<blockquote>
<blockquote>
<p>La sémantique habituelle de ML, qui est la source d'inspiration directe, est de lui donner un sens existentiel</p>
</blockquote>
<p>Alors c’est justement là que tu te trompes : la source d’inspiration directe, c’est Haskell. Plus précisément, Haskell sans les classes de types, que je réserve pour plus tard, si besoin. </p>
</blockquote>
<p>Et sans un tas d'autres choses, mais Haskell <em>est</em> un ML (qui est plus une famille de langages et de systèmes de types qu'un dialecte précis - d'ailleurs, même dans les langages qui s'appellent « ML », il y a plusieurs implémentations différentes). Désolé si ce n'était pas clair.</p>
<blockquote>
<p>Donc les contraintes sont de type <code>forall</code> : une fonction sur des listes qui utiliserait dans son traitement une fonction qui ne porte que sur les entiers ne pourrait avoir le type <code>(lambda (List a) (List a))</code>. <img alt=":)" src="/static/smileys/smile.png"></p>
</blockquote>
<p>Ce n'est écrit nulle part dans ta spécification, et c'est <em>très</em> important. En fait, ta spécification ne parle même nulle part des variables de types, il y a seulement une vague ligne « les types peuvent prendre des paramètres » : sans connaître à l'avance un langage fonctionnel typé (ce qui n'est le cas d'à peu près personne dans cet atelier), aucune chance de comprendre comment ça marche (et même en ayant l'habitude, comme tu peux le constater, ce n'est pas suffisamment bien défini).</p>
<p>Ceci étant dit, forcer un typage explicite des fonctions du top-level ne te permettra pas de faire l'économie d'un typeur qui fasse un minimum d'inférence (en fait, ça ne changera même pas grand chose). Tu n'y arriveras pas avec une vérification « à la C » qui se contente de s'assurer que « les types sont compatibles » là où c'est pertinent de se poser la question.</p>
<blockquote>
<blockquote>
<p>Si vous voulez des types […] prenez un système déjà spécifié, sans essayer de faire des modifications au petit bonheur la chance pour le simplifier.</p>
</blockquote>
<p>C’est largement le cas. Comme dit plus haut, j’ai repris le système de types de Haskell, en remplaçant une manière de surcharger des fonctions (les classes de types) par une autre (les modules homonymes des types), <em>a priori</em> plus aisée à mettre en place, car plus explicite. <img alt=";-)" src="/static/smileys/clin.png"></p>
</blockquote>
<p>Le système de namespaces n'a rien à voir avec les typeclasses (parce que, précisément, il n'y a aucune surcharge). Mais indépendamment de ça, ce n'est pas à moi qu'il faut le dire ici, c'est dans tes spécifications qu'il faut l'écrire (et l'écrire explicitement : tu ne peux pas compter sur le lecteur pour deviner où tu penses que les quantifications se font, et pour le coup ce n'est pas quelque chose que tu peux laisser au choix de l'implémentation).</p>
<blockquote>
<blockquote>
<p>Il y a aussi quelques défauts de moindre importance, ou qui dans l'absolu n'en sont pas vraiment mais se trouvent être des mauvaises idées dans le cadre actuel : les trouzmille types d'entier, l'ajout inutile des flottants et des caractères, les tuples qui n'apportent rien… en fait, des points qui vont dans une tendance à laquelle il faut faire attention qui consiste à insister beaucoup sur une surspécification des détails (vous vous rappelez de « est-ce qu'on écrit <code>-></code> ou <code>lambda</code> ? » ?) en négligeant les fondations (du bikeshedding, en somme.)</p>
</blockquote>
<p>Bon, c’est dommage, tu retombes dans le travers de « laissez tomber, c’est trop compliqué pour vous »… </p>
</blockquote>
<p>Où est-ce que j'ai écrit dans le message que tu cites la moindre phrase qui te fasse penser ça ?</p>
<blockquote>
<p>En toute sincérité, qu’est-ce que cela change ? Y a-t-il une différence fondamentale de fonctionnement entre l’utilisation d’entiers signés sur 16 bits et d’entiers non signés sur 32 bits, sachant que toutes les machines modernes gèrent les uns et les autres nativement, et que <em>a fortiori</em>, la plupart des langages d’implémentation sauront les gérer aussi sans qu’on ait rien à faire ?</p>
</blockquote>
<p>Ce que ça change, c'est des complications complètement inutiles à développer et à maintenir alors qu'il y a déjà largement assez à côté. Honnêtement, qu'est-ce que ça change que le langage soit capable de faire la différence entre des entiers signés ou non-signés sur 32 ou 64 bits ?</p>
<blockquote>
<p>Je répète, y a-t-il quoi que ce soit de réellement plus <em>difficile</em> à gérer 8 types d’entiers bornés plutôt qu’un seul ? Ou est-ce que ce sera juste un chouïa plus long à taper le code ? Idem pour les tuples, ce ne sont jamais que des plages de mémoire adjacentes / tuples / structures de langage impératif : où se trouve la difficulté supplémentaire ?</p>
</blockquote>
<p>Il y a quoi de réellement plus limitant à se restreindre à un seul type d'entiers ? Encore une fois, vous ne codez pas un langage pour qu'il soit utilisable, mais pour apprendre. Dans ce cadre, une fonctionnalité qui complique votre tâche sans apport pédagogique concret est à jeter à la poubelle. C'est le cas ici.</p>
<blockquote>
<p>Il y a effectivement deux difficultés dans ces types natifs. Les entiers non bornés, tout d’abord. Ceux-là ont été explicitement demandés un peu plus haut dans la discussion. Et la solution sera très certainement de faire appel à une bibliothèque tierce, comme la plupart des langages qui en ont.</p>
</blockquote>
<p>Mais alors ça n'a aucun intérêt : ça devient une fonctionnalité « pour l'utilisation » au lieu d'être une fonctionnalité « pour l'apprentissage ». Soit vous voulez comprendre comment on implémente des entiers à taille variable, et il faut le faire vous-mêmes, soit vous considérez (mon avis personnel est que c'est le bon choix) que c'est quelque chose d'indépendant à l'implémentation d'un langage et qu'il vaudrait mieux faire ça sous forme de lib dans un autre projet, et vous pouvez oublier. </p>
<blockquote>
<p>Les caractères Unicode, ensuite. Là, de fait, rien à dire, ça risque d’être un peu plus compliqué qu’un simple <code>char</code> de C. Encore une fois, la solution viendra certainement d’une bibliothèque tierce ou d’un langage d’implémentation qui gère nativement ce genre de caractères (comme Rust ou Haskell, par exemple).</p>
</blockquote>
<p>Pareil que pour les entiers non bornés, sauf que pour le coup, vous n'avez <em>vraiment</em> pas envie d'implémenter ça vous-mêmes. Soit votre langage le gère nativement (coup de bol, Python le fait) et vous n'avez pas besoin de vous en préoccuper, soit vous ne devriez pas vous en préoccuper parce que c'est totalement orthogonal aux problématiques d'interprétation et de compilation.</p>
<p>Maintenant, si vraiment vous y tenez, je le redis : je n'empêche personne de le faire. Vous avez un avis et des conseils qui cherchent à vous faire avancer le plus possible dans la direction « apprendre à implémenter un langage », libre à vous de les suivre ou pas.</p>Acid, le lisp-like de la communauté !, message #1155822016-06-25T11:29:17+02:00felko/@felkohttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115582<p>J'ai essayé d'imaginer un ensemble d'instruction. En gros on aurai ça:</p>
<ul>
<li><code>PUSH_INT <value></code>: Ajoute un entier au haut de la pile</li>
<li><code>LOAD_GLOBAL <id></code>: Ajoute la valeur de <code>id</code> en haut de la pile</li>
<li><code>LOAD_LOCAL <n></code>: Ajoute le <code>n</code>-ième argument en haut de la pile</li>
<li><code>POP</code>: Enlève l'élément en haut de la pile</li>
<li><code>APPLY <n></code>: Applique à l'élément en haut de pile les <code>n</code> éléments précédents</li>
<li><code>PROC [<instructions> ...]</code>: Ajoute en haut de la pile une procédure avec les instructions données</li>
<li><code>STORE <id></code>: Assigne à <code>id</code> l'élément en haut de pile</li>
</ul>
<p>Avec ça on peut traduire du Acid facilement. Si on prend l'exemple suivant:</p>
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
4
5
6
7</pre></div></td><td class="code"><div class="codehilite"><pre><span></span><span class="p">(</span><span class="nv">define</span> <span class="nv">foo</span> <span class="p">(</span><span class="k">lambda</span> <span class="p">(</span><span class="nv">x</span> <span class="nv">y</span><span class="p">)</span>
<span class="p">(</span><span class="nb">*</span> <span class="nv">x</span> <span class="p">(</span><span class="nb">+</span> <span class="nv">y</span> <span class="mi">2</span><span class="p">))</span>
<span class="p">))</span>
<span class="p">(</span><span class="nv">define</span> <span class="nv">main</span> <span class="p">(</span><span class="k">lambda</span> <span class="p">()</span>
<span class="p">(</span><span class="nb">print</span> <span class="p">((</span><span class="nv">foo</span> <span class="mi">1</span> <span class="mi">2</span><span class="p">)))</span>
<span class="p">))</span>
</pre></div>
</td></tr></table>
<p>… on obtiendrait le bytecode suivant:</p>
<table class="codehilitetable"><tr><td class="linenos"><div class="linenodiv"><pre> 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25</pre></div></td><td class="code"><div class="codehilite"><pre><span></span>INSTRUCTION STACK LOCAL ENVIRONMENT
[] [] {}
PROC [
LOAD_LOCAL 1 [x] [x, y] {}
LOAD_LOCAL 2 [x, y] [x, y] {}
PUSH_INT 2 [x, y, 2] [x, y] {}
LOAD_GLOBAL + [x, y, 2, +] [x, y] {}
APPLY 2 [x, (+ y 2)] [x, y] {}
LOAD_GLOBAL * [x, (+ y 2), *] [x, y] {}
APPLY 2 [(* x (+ y 2))] [x, y] {}
] [<proc>] {}
STORE foo [<proc>] {foo: <proc>}
POP [] {foo: <proc>}
PROC [
PUSH_INT 1 [1] [] {foo: <proc>}
PUSH_INT 2 [1, 2] [] {foo: <proc>}
LOAD_GLOBAL foo [1, 2, foo] [] {foo: <proc>}
APPLY 2 [(foo 1 2)] [] {foo: <proc>}
LOAD_GLOBAL print [(foo 1 2), print] [] {foo: <proc>}
APPLY 1 [(print (foo 1 2))] [] {foo: <proc>}
] [<proc>] {foo: <proc>}
STORE main [<proc>] {foo: <proc>, main: <proc>}
APPLY 0 [None] {foo: <proc>, main: <proc>}
POP [] {foo: <proc>, main: <proc>}
</pre></div>
</td></tr></table>
<p>L'instruction <code>PROC</code> ressemble à la définition d'une fonction mais en fait c'est juste un <code>PUSH</code> de bytecode ordinaire (donc le code reste "linéaire").</p>Acid, le lisp-like de la communauté !, message #1155792016-06-25T11:19:46+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115579<p><a href="https://zestedesavoir.com/forums/sujet/6401/pulp-un-environnement-dexecution-zestueux/">https://zestedesavoir.com/forums/sujet/6401/pulp-un-environnement-dexecution-zestueux/</a></p>Acid, le lisp-like de la communauté !, message #1155762016-06-25T11:18:00+02:00SuperFola/@SuperFolahttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115576<p>Autant faire un sujet généraliste, le concept est sûrement reproductible dans une grande majorité de langages <img alt="^^" src="/static/smileys/hihi.png"></p>Acid, le lisp-like de la communauté !, message #1155752016-06-25T11:12:20+02:00mehdidou99/@mehdidou99https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115575<p>Comme tu veux, je ne veux rien t'imposer. J'ai encore de quoi m'occuper avec mon implémentation du langage impératif, donc si tu veux le faire en rust, vas-y. <img alt=":)" src="/static/smileys/smile.png"></p>Acid, le lisp-like de la communauté !, message #1155742016-06-25T11:09:43+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115574<figure><blockquote>
<figure><blockquote>
<p>Je le vois plus comme un projet independant vers lequel vous pourriez compiler n'importe quel petit langage en fait. En réalité c'est <strong>facile</strong> à faire, en une soirée tu peux avoir un truc qui marche. Mais ça m'intéresse de toucher a des features rigolotes comme la possibilité de faire nativement des appels système, celle de threader vs. Un GIL, pourquoi pas un JIT…</p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115543">nohar</a></p></figcaption></figure><p>Ça me plairait de te donner un coup de main, ça me ferait la main avec Python. <img alt=":)" src="/static/smileys/smile.png"></p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115571">mehdidou99</a></p></figcaption></figure><p>OK, je comptais partir dessus en Rust à la base, mais va pour ça, lançons un sujet pour écrire une VM avec Python. <img alt=":)" src="/static/smileys/smile.png"></p>Acid, le lisp-like de la communauté !, message #1155722016-06-25T10:57:17+02:00the_new_sky/@the_new_skyhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115572<figure><blockquote>
<p>Je le vois plus comme un projet independant vers lequel vous pourriez compiler n'importe quel petit langage en fait. En réalité c'est <strong>facile</strong> à faire, en une soirée tu peux avoir un truc qui marche.</p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115543">nohar</a></p></figcaption></figure><p>Peut-être un point de convergence avec Seventh ?</p>
<p>Si on peut avoir rapidement un truc fonctionnel je vais essayer de dev quelques chose ce soir si possible.</p>Acid, le lisp-like de la communauté !, message #1155712016-06-25T10:50:02+02:00mehdidou99/@mehdidou99https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115571<figure><blockquote>
<p>Je le vois plus comme un projet independant vers lequel vous pourriez compiler n'importe quel petit langage en fait. En réalité c'est <strong>facile</strong> à faire, en une soirée tu peux avoir un truc qui marche. Mais ça m'intéresse de toucher a des features rigolotes comme la possibilité de faire nativement des appels système, celle de threader vs. Un GIL, pourquoi pas un JIT…</p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115543">nohar</a></p></figcaption></figure><p>Ça me plairait de te donner un coup de main, ça me ferait la main avec Python. <img alt=":)" src="/static/smileys/smile.png"></p>Acid, le lisp-like de la communauté !, message #1155642016-06-25T08:37:04+02:00Dominus Carnufex/@Dominus%20Carnufexhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115564<blockquote>
<p>La sémantique habituelle de ML, qui est la source d'inspiration directe, est de lui donner un sens existentiel</p>
</blockquote>
<p>Alors c’est justement là que tu te trompes : la source d’inspiration directe, c’est Haskell. Plus précisément, Haskell sans les classes de types, que je réserve pour plus tard, si besoin. Donc les contraintes sont de type <code>forall</code> : une fonction sur des listes qui utiliserait dans son traitement une fonction qui ne porte que sur les entiers ne pourrait avoir le type <code>(lambda (List a) (List a))</code>. <img alt=":)" src="/static/smileys/smile.png"></p>
<blockquote>
<p>Si vous voulez des types […] prenez un système déjà spécifié, sans essayer de faire des modifications au petit bonheur la chance pour le simplifier.</p>
</blockquote>
<p>C’est largement le cas. Comme dit plus haut, j’ai repris le système de types de Haskell, en remplaçant une manière de surcharger des fonctions (les classes de types) par une autre (les modules homonymes des types), <em>a priori</em> plus aisée à mettre en place, car plus explicite. <img alt=";-)" src="/static/smileys/clin.png"></p>
<blockquote>
<p>Il y a aussi quelques défauts de moindre importance, ou qui dans l'absolu n'en sont pas vraiment mais se trouvent être des mauvaises idées dans le cadre actuel : les trouzmille types d'entier, l'ajout inutile des flottants et des caractères, les tuples qui n'apportent rien… en fait, des points qui vont dans une tendance à laquelle il faut faire attention qui consiste à insister beaucoup sur une surspécification des détails (vous vous rappelez de « est-ce qu'on écrit <code>-></code> ou <code>lambda</code> ? » ?) en négligeant les fondations (du bikeshedding, en somme.)</p>
</blockquote>
<p>Bon, c’est dommage, tu retombes dans le travers de « laissez tomber, c’est trop compliqué pour vous »… En toute sincérité, qu’est-ce que cela change ? Y a-t-il une différence fondamentale de fonctionnement entre l’utilisation d’entiers signés sur 16 bits et d’entiers non signés sur 32 bits, sachant que toutes les machines modernes gèrent les uns et les autres nativement, et que <em>a fortiori</em>, la plupart des langages d’implémentation sauront les gérer aussi sans qu’on ait rien à faire ?</p>
<p>Je répète, y a-t-il quoi que ce soit de réellement plus <em>difficile</em> à gérer 8 types d’entiers bornés plutôt qu’un seul ? Ou est-ce que ce sera juste un chouïa plus long à taper le code ? Idem pour les tuples, ce ne sont jamais que des plages de mémoire adjacentes / tuples / structures de langage impératif : où se trouve la difficulté supplémentaire ?</p>
<p>Il y a effectivement deux difficultés dans ces types natifs. Les entiers non bornés, tout d’abord. Ceux-là ont été explicitement demandés un peu plus haut dans la discussion. Et la solution sera très certainement de faire appel à une bibliothèque tierce, comme la plupart des langages qui en ont. Les caractères Unicode, ensuite. Là, de fait, rien à dire, ça risque d’être un peu plus compliqué qu’un simple <code>char</code> de C. Encore une fois, la solution viendra certainement d’une bibliothèque tierce ou d’un langage d’implémentation qui gère nativement ce genre de caractères (comme Rust ou Haskell, par exemple).</p>Acid, le lisp-like de la communauté !, message #1155512016-06-24T23:52:28+02:00Eusèbe/@Eus%C3%A8behttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=18#p115551<figure><blockquote>
<p>Du coup Eusèbe, tu critique la spec en disant, entre autre, que le système de typage est bancale. Pourrais tu pointer ce qui est bancale ? (Je t'ai pas vue le justifier et ça m'intéresse car à la lire j'ai pas repéré, ton avis m'intéresse). De plus, du coup, tu partirai sur quoi comme "spec" pour ce type de langage ?
</p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115528">Kje</a></p></figcaption></figure><p>Principalement, un décalage entre les objectifs et les propriétés concrètes du système, en plus d'une formalisation hâtive de parties importantes qui laisse des questions en suspens. Par exemple, pour éviter d'avoir à écrire une inférence de types, on décide de typer explicitement toutes les fonctions du toplevel. Mais la sémantique de ces contraintes n'est pas claire : si j'écris <code>(hastype (lambda (List a) (List a)) ma_fonction)</code>, quelle est la signification de la variable de type <code>a</code> ? La sémantique habituelle de ML, qui est la source d'inspiration directe, est de lui donner un sens existentiel : pour simplifier un peu, « il existe un type <code>a</code> tel que ma_fonction est de type <code>list a -> list a</code> ». Mais on peut aussi décider que c'est une quantification universelle : « pour tout type <code>a</code>, ma fonction est de type <code>list a -> list a</code> ». </p>
<p>Maintenant, imaginons que je donne cette contrainte de type à une fonction de type <code>list int -> list int</code>. Selon le sens de la variable <code>a</code>, le comportement attendu diffère radicalement : dans le premier cas, le typeur accepte, mais doit quand même retenir que le type de ma fonction est <code>list int -> list int</code> pour les appels suivants. Pour cela, il a besoin de calculer le type de la fonction puis de vérifier que la contrainte est effectivement plus générale (puis il oublie la contrainte dans la suite).</p>
<p>Dans le deuxième cas, le typeur doit refuser la contrainte : elle n'est pas une généralisation d'un type de la fonction. Ça ne demande pas forcément d'écrire un calcul complet du type le plus général de la fonction, mais il faut quand même quelque chose de plus compliqué que juste vérifier que les types sont corrects à chaque opération du programme. De toute façon, pour des raisons un peu compliquées, ce n'est pas le bon choix : on a besoin des variables existentielles si on veut faire du ML (par exemple, <code>let f : 'a. 'a list -> 'a list = List.map (fun x -> x)</code> ne type pas dans OCaml).</p>
<p>Dans tous les cas, s'aventurer dans ce genre de systèmes de types en faisant de l'à-peu-près est une garantie à peu près certaine de se casser la figure. Si vous voulez des types (je pense vraiment qu'il vaut mieux commencer par s'en passer, <em>surtout</em> si vous n'avez pas l'habitude de manipuler ce genre de choses dans vos propres programmes), prenez un système déjà spécifié, sans essayer de faire des modifications au petit bonheur la chance pour le simplifier. </p>
<p>Qu'on ne me fasse pas dire ce que je n'ai pas dit : c'est un domaine passionnant, et je serais ravi qu'on parle un peu plus de typage et un peu moins de C++/Python/Javascript sur ZdS <img alt=":-°" src="/static/smileys/siffle.png"> Pour autant, il ne faut pas mettre la charrue avant les boeufs : avant d'implémenter un typeur, il faut déjà avoir une idée de comment implémenter un langage non typé, et il faut avoir une idée de comment le système de types fonctionne (ce qui, en l'occurrence, se fait très bien en pratiquant un peu avec OCaml ou Haskell). Et avant de formaliser son propre système, il faut avoir les idées bien claires sur la théorie sous-jacente.</p>
<p>Il y a aussi quelques défauts de moindre importance, ou qui dans l'absolu n'en sont pas vraiment mais se trouvent être des mauvaises idées dans le cadre actuel : les trouzmille types d'entier, l'ajout inutile des flottants et des caractères, les tuples qui n'apportent rien… en fait, des points qui vont dans une tendance à laquelle il faut faire attention qui consiste à insister beaucoup sur une surspécification des détails (vous vous rappelez de « est-ce qu'on écrit <code>-></code> ou <code>lambda</code> ? » ?) en négligeant les fondations (du bikeshedding, en somme.)</p>
<p>Nohar : go for it !</p>Acid, le lisp-like de la communauté !, message #1155432016-06-24T22:51:32+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115543<figure><blockquote>
<p>C'est vrai, ça doit être super intéressant. Si tu veux t'y attaquer sur l'autre projet (impératif), je suis en train d'écrire le front-end, il me manque le back-end. <img alt="^^" src="/static/smileys/hihi.png"></p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115500">mehdidou99</a></p></figcaption></figure><p>Je le vois plus comme un projet independant vers lequel vous pourriez compiler n'importe quel petit langage en fait. En réalité c'est <strong>facile</strong> à faire, en une soirée tu peux avoir un truc qui marche. Mais ça m'intéresse de toucher a des features rigolotes comme la possibilité de faire nativement des appels système, celle de threader vs. Un GIL, pourquoi pas un JIT…</p>Acid, le lisp-like de la communauté !, message #1155282016-06-24T21:04:56+02:00Kje/@Kjehttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115528<p>Du coup Eusèbe, tu critique la spec en disant, entre autre, que le système de typage est bancale. Pourrais tu pointer ce qui est bancale ? (Je t'ai pas vue le justifier et ça m'intéresse car à la lire j'ai pas repéré, ton avis m'intéresse). De plus, du coup, tu partirai sur quoi comme "spec" pour ce type de langage ?</p>Acid, le lisp-like de la communauté !, message #1155132016-06-24T19:31:40+02:00the_new_sky/@the_new_skyhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115513<p>Sincèrement, je suis pour <img alt=":p" src="/static/smileys/langue.png"></p>Acid, le lisp-like de la communauté !, message #1155012016-06-24T18:26:18+02:00SuperFola/@SuperFolahttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115501<p>Et ben pourquoi pas alors <img alt=":)" src="/static/smileys/smile.png"> on va se planter et ça va être galère, mais on a 2 mois à trucider non <img alt=":p" src="/static/smileys/langue.png"> ?</p>Acid, le lisp-like de la communauté !, message #1155002016-06-24T18:25:51+02:00mehdidou99/@mehdidou99https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115500<p>C'est vrai, ça doit être super intéressant. Si tu veux t'y attaquer sur l'autre projet (impératif), je suis en train d'écrire le front-end, il me manque le back-end. <img alt="^^" src="/static/smileys/hihi.png"></p>Acid, le lisp-like de la communauté !, message #1154982016-06-24T18:23:49+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115498<p>Perso ce qui m'intéresse, plus que d'implémenter un langage, ce serait d'implémenter une VM avec le bytecode associé et pourquoi pas une IR pour aller avec (un code à trois adresses…). C'est pour ça que je pose la question. Ça fait une paye que le sujet me démange.</p>Acid, le lisp-like de la communauté !, message #1154932016-06-24T17:50:36+02:00felko/@felkohttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115493<figure><blockquote>
<p>Grosso-modo, quelles sont les différences entre une simple VM à pile et une VM fonctionnelle ?
</p>
</blockquote>
<figcaption><p><a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115488">nohar</a></p></figcaption></figure><p>Je suis débutant, mais de ce que j'ai compris, la différence est surtout sur la méthode d'évaluation. Dans les deux cas (paresseuse ou stricte), tu peux réduire ça de toute façon à une pile, mais dans le cas où ta VM gère l'évaluation paresseuse, tu auras quelques instructions en plus (comme <code>UNWIND</code> dans la G-Machine) qui s'occuperont de réarranger la pile pour que les <em>thunks</em> ne bloquent pas l'évaluation.</p>
<p>Je précise que j'ai pas non plus tout compris sur cette partie du livre de Simon P-J, cette réponse est aussi un moyen pour voir si j'ai bien compris, n'hésitez pas à me corriger si j'ai dit une bêtise <img alt=":)" src="/static/smileys/smile.png"></p>Acid, le lisp-like de la communauté !, message #1154922016-06-24T17:49:46+02:00Eusèbe/@Eus%C3%A8behttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115492<p>Je ne connais pas tellement la VM de Python, mais je ne pense pas qu'il y ait une opposition fondamentale entre « VM à pile » et « VM fonctionnelle ». Par exemple, la <a href="http://cadmium.x9c.fr/distrib/caml-instructions.pdf">VM de Caml</a> (je ne sais pas à quel point c'est à jour par rapport à l'implémentation actuelle, mais ça ne change pas grand chose) <em>est</em> une VM à pile.</p>
<p>J'imagine que ce qui change, c'est le type des valeurs que tu peux mettre sur la pile (objets, fermetures, juste des entiers…) A priori, je pense que la VM de Python pourrait parfaitement servir pour un langage fonctionnel. Il manque peut-être une instruction pour effectuer un appel terminal, mais je doute que ce soit très compliqué à rajouter.</p>
<p>Les slides de Xavier Leroy que j'ai données plus haut t'éclaireront peut-être un peu plus sur le sujet : dans celles qui parlent de machines virtuelles, il décrit plusieurs VM fonctionnelles à pile.</p>Acid, le lisp-like de la communauté !, message #1154882016-06-24T17:32:23+02:00nohar/@noharhttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115488<p>Pour en revenir à cette histoire de VM, je me pose une question de béotien : est-ce qu'une VM à pile (comme celle de Python) est capable de supporter un langage fonctionnel ?</p>
<p>Grosso-modo, quelles sont les différences entre une simple VM à pile et une VM fonctionnelle ? J'ai vraiment l'impression qu'il y a deux univers séparés entre les deux façons d'aborder la compilation, et je n'ai jamais réussi à trouver un point de convergence, alors que celui-ci doit nécessairement exister…</p>Acid, le lisp-like de la communauté !, message #1154862016-06-24T17:26:30+02:00Eusèbe/@Eus%C3%A8behttps://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=17#p115486<blockquote>
<p>Ôte-moi d’un doute… Quand tu parles de la spec, et que tu la critiques, tu ne parles pas de <a href="https://zestedesavoir.com/forums/sujet/6129/acid-le-lisp-like-de-la-communaute/?page=1#p111509">ça</a>, j’espère ? Parce qu’elle a <a href="https://github.com/Acid-ZdS/Acid/blob/master/sp%C3%A9cifications.md">bien changé</a> depuis… De même que le <a href="https://github.com/Acid-ZdS/Acid/tree/master/exemples/code_spec">code d’exemple</a>.</p>
</blockquote>
<p>Si, je parlais effectivement de celle-là. Merci du lien. Cela dit, elle a beau avoir « bien changé », les points noirs restent exactement les mêmes.</p>
<blockquote>
<p>Il va falloir te faire à l’idée : Acid est un langage fonctionnel, aussi « pur » que possible, avec des types algébriques. C’était le <em>deal</em> dès le départ, et à partir de là, on essaye d’arriver à ce résultat avec un système aussi simple que possible. Point barre. </p>
</blockquote>
<p>« C'était le deal », donc toute volonté personnelle de faire autrement doit se heurter à un refus parce que « c'est pas dans la spec, point barre » ? Pourquoi cherches-tu à tout prix à imposer à tout le monde ce genre de contraintes ?</p>
<blockquote>
<p>Tu peux continuer à ânonner inlassablement qu’on est trop nuls/ignorants/ce-que-tu-veux pour y arriver, cela n’y changera rien : c’est l’objectif fixé et les participants motivés iront aussi loin que nécessaire pour l’atteindre.
</p>
</blockquote>
<p>La question n'est pas d'être trop nuls ou ignorants pour y arriver, la question est de faire les choses dans le bon ordre. Tu veux faire implémenter par des gens qui n'ont jamais touché de fonctionnel de leur vie à part les <code>lambda</code> de Python un langage fonctionnel typé spécifié par quelqu'un qui ne maîtrise pas les outils nécessaires à une spécification correcte. Comment veux-tu que vous ayiez la moindre chance d'y arriver tel que c'est parti ? Ce n'est pas une question d'être « nul », tout le monde débute un jour. Mais normalement, quand on débute, on accepte les conseils au lieu de se braquer. </p>
<p>Contrairement à ce que tu sembles croire, mon but n'est ni de vous critiquer, ni de faire échouer le projet. Au contraire, je cherche à vous guider pour que vous ne tombiez pas dans des erreurs qui me semblent évidentes mais que vous ne voyez manifestement pas. Maintenant, je ne force personne à suivre mes conseils : si vous voulez que je vous « laisse avancer comme on veut, quitte à se planter parce qu'on ne sait pas où on va », allez-y ! Mais ça ne semble pas être le cas de tout le monde, donc tant que quelqu'un pose des questions, j'y répondrai. Si ça te déplaît, tu n'es absolument pas obligé de considérer que ça s'adresse à toi, et tu es parfaitement libre d'implémenter le langage que tu veux de ton côté. Aie au moins la courtoisie de laisser ceux qui veulent discuter le faire tranquillement au lieu de hurler dès qu'on envisage de faire quelque chose différemment de ta spécification.</p>
<blockquote>
<p>Alors s’il-te-plaît, épargne ton clavier et nos nerfs par la même occasion, et restreins-toi aux messages constructifs. Tu en as écris, et c’est très bien, c’est bien la preuve que tu en es capable. Mais tout ce qui revient, quelle que soit la formulation effectivement employée, à dire « Ne faites pas ça, vous êtes trop mauvais. », garde-toi-le bien au fond de la poche. Merci. <img alt=":)" src="/static/smileys/smile.png"></p>
</blockquote>
<p>Si tes nerfs ne peuvent pas supporter que je donne mon avis, je t'invite à prendre quelques jours de pause. Tu es depuis un certain temps le seul à réagir de façon aussi agressive ici quand j'écris, peut-être qu'à un moment il faut te remettre un peu en question.</p>
<p>Ensuite, si tu lis « ne faites pas ça, vous êtes trop mauvais », je t'invite aussi à souffler un peu et à relire mes messages quand tu seras un peu plus calmé. Ils disent à peu près tous le contraire, à savoir « commencez par cette étape avant d'attaquer bille en tête le problème originel sans organisation, c'est le meilleur moyen d'y arriver ». </p>