Il y a cet axiome (relativement) bien connu de Perl, "Seul Perl peut analyser Perl." Je me demande, cela restera-t-il vrai pour Perl6?
Edit: Élargir la discussion ... J'ai pensé à cette question étant donné la récente mise à jour de PyPy. La parseabilité unique de Perl l'empêche-t-elle de faire des efforts similaires? Y a-t-il beaucoup de valeur dans une vue statique restreinte du code Perl (PPI?)? Perl6 peut-il avoir un compilateur JIT? *
* Je ne sais pas si ces concepts sont liés. Sont-ils?
Il n'y a pas de perl6, et il y a beaucoup de Perl 6 compilateurs. Perl 6 a une grammaire, même si il est écrit en Perl 6, donc tant que vous pouvez comprendre cela, il vous dit tout ce que vous devez savoir.
J'ai juste demandé à Larry pose cette question, car je suis assis en face de lui à déjeuner à l' São Paulo Perl Atelier. Il dit que c'est maintenant "Seulement Perl 6 peut analyser Perl 6", avec des majuscules sur les deux Perls, ce qui signifie quelque chose de différent de l'original de la déclaration.
Vous n'avez pas besoin d'un programme spécifique pour le faire, bien que depuis Perl 6 objectif est un standard et de nombreuses implémentations. Il n'y a pas de "perl6", bien que Larry avait qu'un alias de son Rakudo d'aujourd'hui, même si il a utilisé un peu différentes implémentations pour les exemples.
Pour la dernière fois, Perl 6 hérite du caractère / de Perl 5, ce qui peut signifier "début de l'expression régulière" lorsqu'un terme est attendu, ou "diviser" lorsqu'un opérateur est attendu. Compte tenu de cela, et des prototypes, et Perl 6 est au moins dans le même camp que Perl 5 pour la tokenisation statique. La seule façon de symboliser un programme Perl 6 est d'avoir un interpréteur Perl 6 en cours d'exécution dans le compilateur Perl 6. Encore des tortues.
L'axiome "Seulement perl peut analyser Perl" où "perl" est l'interprète binaire et "Perl" la langue est en grande partie provient du fait que les règles d'analyse peut changer pendant que le fichier est analysé. En Perl 5, cela vient de produire un prototype de sous-routine déclarations, à partir de diverses pragmas, et de la source des filtres.
À mon avis, ce n'est que va devenir de plus d'un problème de Perl 6. En Perl 5, le nombre d'endroits où l'analyseur de règles pourrait changer sont limitées, alors qu'en Perl 6, ils sont nombreux et variés. En plus de tout ce que Perl 5, Perl 6 vous permet de définir vos propres opérateurs, et depuis cette définition se fait dans le code Perl, un interpréteur Perl est nécessaire pour en comprendre le sens.
Autant que je sache, la mise en œuvre prend en charge encore, mais le Perl 6 spécification inclut également vrai niveau de langue des macros, qui peut se restructurer Perl 6 code soit sous forme de texte ou par la manipulation de l'AST. Ces deux requièrent l'existence d'un interpréteur Perl pour effectuer leur magie.
Donc, en conclusion, j'ai le sentiment que Perl 6 fera l'axiome plus forte qu'elle ne l'est pour le Perl 5. (Et le sera encore plus à un cauchemar pour les auteurs de la syntaxe surligneur :) ) bien sûr, cela est tout à augmenter la puissance expressive de la langue, donc je suis ok avec la concession.
Un corollaire est que, contrairement à Perl 5, Perl 6 est officiellement spec, donc l'axiome pourrait avoir à changer de "l'interprète de mise en œuvre de Perl 6 spec peut analyser Perl 6", mais c'est un peu pédant.
Par la mise à jour:
Je ne pense pas que le ci-dessus s'oppose à l'idée d'un compilateur JIT pour Perl 6, puisque, par définition, un tel compilateur devra également contenir un interpréteur Perl 6. Aussi loin que la compilation statique va, il POURRAIT être possible, mais il serait de restreindre fortement la langue d'exécution du pouvoir, puisque toute construction impliquant eval ne fonctionnerait pas.
PPI est utile en Perl 5 terre parce que l'interpréteur perl ne fournit pas beaucoup de riches et facile à utiliser des interfaces à son AST. En Perl 6, le niveau de l'introspection est BEAUCOUP plus grande, de sorte que l'interprète lui-même peut fournir tous les outils nécessaires.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
