Écrire son propre langage !

Support de présentation pour l'Apéro PHP du 2/10/2018 à Lille organisé par l'AFUP Hauts-de-France.

Code source du langage réalisé: https://gitlab.com/iamluc/reduc-lang

Transcript

1. écrire son propre langage !
2. Mais qui suis-je ? @schtroumpf_luc Développeur chez Blackfire.io Luc Vieillescazes
3. Pourquoi ? • Exprimer un domaine d’application particulier (DSL*) ◦ Ex. décrire les réductions applicables à un panier d’achat • Apporter de la flexibilité tout en définissant des limites ◦ Laissez les commerciaux gérer les réductions... ◦ .... mais empêchez les de faire n’importe quoi ! *DSL = Domain specific language
4. Pourquoi ? “Si le panier est supérieur à 100 €, alors réduire le prix de 10 €” → Expression d’un domaine d’application
5. Pourquoi ? “Si le panier est supérieur à 100 €, alors réduire le prix de 10 €” → Contrôle de l'exécution
6. Pourquoi ? “Si le panier est supérieur à 100 €, alors réduire le prix de 10 €”
7. Pourquoi ? “Si le panier est supérieur à 100 €, alors réduire le prix de 10 €” → S’adapter à un autre système
8. Quelques exemples Symfony Expression Language
9. Quelques exemples Doctrine (DQL = Doctrine Query Language)
10. Quelques exemples Twig
11. Quelques exemples Blackfire Player
12. Comment ? → Lexer (Analyse lexicale) → Parser (Analyse syntaxique) → Interpreter (Interpréteur)
13. Lexer (Analyse lexicale) Découper une chaîne de caractères en morceaux: des tokens. Exemple: • Token::Public • Token::Variable (name = “toto”) • Token::Equal • Token::String (value = “hello”)
14. Lexer (Analyse lexicale) Attention de ne pas chercher à être plus précis que nécessaire. • “public” peut-il aussi être un nom de constante ? Token::Public Token::Identifier (value = “public”) NON OUI Ne marche pas en PHP !
15. Lexer (Analyse lexicale) Attention de ne pas chercher à “comprendre” le langage ici ! Un token peut avoir plusieurs sens en fonction de son contexte. Token::Import Token::Inherit Token::Use
16. Lexer (Analyse lexicale) Lua Tokens (https://hackage.haskell.org/package/language-lua-0.10.0/docs/Language-Lua-Token.html)
17. Lexer (Analyse lexicale) Le code peut être lexicalement correct mais syntaxiquement incorrect Lexer content Parser pas content
18. Lexer (Analyse lexicale) Démo !
19. Lexer (Analyse lexicale) Pro tips: - Aimez vos utilisateurs, aidez les à débugger
20. Parser (Analyse syntaxique) Le travail du Parser: 1. Lire les Tokens dans l’ordre 2. Vérifier la grammaire 3. Retourner une représentation exploitable (par exemple un AST)
21. Parser (Analyse syntaxique) La grammaire définit les règles syntaxiques => c’est à dire les enchaînements de tokens valides Exemple: - Un “if” doit être suivi par: - une parenthèse ouvrante - une “expression” - une parenthèse fermante - Une “expression” commence par une “variable” ou un “chiffre”, suivi optionnellement d’un “opérateur binaire” lui-même suivi d’une “expression” - ...
22. Parser (Analyse syntaxique) The Complete Syntax of Lua (https://www.lua.org/manual/5.3/manual.html#9)
23. Parser (Analyse syntaxique) Les cas particuliers - Précédence 2 + 3 * 4 ⇒ (2 + 3) * 4 vs 2 + (3 * 4) - Association (gauche / droite) 2 ^ 3 ^ 2 ⇒ (2 ^ 3) ^ 2 vs 2 ^ (3 ^ 2)
24. Parser (Analyse syntaxique) Les cas particuliers - Opérateur unaire https://ruslanspivak.com/lsbasi-part8/
25. Abstract Syntax Tree (Arbre syntaxique abstrait) L’AST est une représentation du code sous la forme des noeuds d’un arbre. Exemple: Un “if / else” sera représenté par un noeud “ConditionalNode” (ou “TernaryNode”) qui stockera lui-même 3 autres noeuds: • La condition à évaluer (“AbstractNode”) • Le noeud à exécuter si la condition est vraie (“BlockNode”) • Le noeud à exécuter si la condition est fausse (“BlockNode”)
26. Abstract Syntax Tree (Arbre syntaxique abstrait)
27. Parser (Analyse syntaxique) Démo !
28. Interpréteur Il va évaluer nos noeuds à partir de la racine, en se déplaçant dans l’arbre
29. Interpréteur Les pièges: - Gestion du “flux de code”: - break / return / goto - La gestion des variables - portée des variables / scopes
30. Interpréteur Démo !
31. Gagner du temps ;-) hoa/compiler => compilateur de compilateur → Remplace le Lexer et le Parser par un fichier de définition de la grammaire.
32. Gagner du temps ;-) Démo !
33. Aller plus loin ? Optimiser l’AST - Suppression du code mort - Résolution des expressions statiques - 5*60 => 300 - Suppression des variables inutiles - echo ‘salut’;
34. Aller plus loin ? Ne pas parser plusieurs fois le même code: • Serialization de l’AST • Compilation dans un autre langage (ex. générer du code PHP) • Générer un bytecode exploitable par une machine virtuelle ◦ PHP / Opcache ◦ Java ◦ ...
35. Aller plus loin ? http://php.net/manual/en/internals2.opcodes.php
36. Aller plus loin ? Prévoir un système d’extension: - Nouveau mots clés (ou tag) - ex. Balises Twig - Nouvelles fonctions - ex. Fonctions ExpressionLanguage - Outils de debug ou profiling - ex. XDebug / Blackfire
37. Quelques parsers en PHP https://github.com/iamluc/script Interpréteur Lua-like (fait maison !) https://github.com/nikic/PHP-Parser Parser PHP https://github.com/symfony/expression-language Interpréteur simple et extensible, qualité Symfony https://github.com/hoaproject/Compiler Compilateur de compilateur
38. Questions ?