feat(compiler): interpolation de chaînes "${expr}"#47
Open
NyalephTheCat wants to merge 1 commit into
Open
Conversation
…sur la concaténation)
Ajoute l'interpolation de chaînes en v4+ pour les chaînes à guillemets
doubles : `"a${expr}b"`. C'est du pur sucre syntaxique desugaré au niveau du
lexer en la suite de tokens d'une concaténation : `( "a" + (expr) + "b" )`.
Le parser et le générateur de code restent totalement inchangés. Le code Java
produit est strictement identique à une concaténation `+` écrite à la main,
donc le COÛT EN OPÉRATIONS est exactement le même que l'addition/concaténation
correspondante (vérifié : `"Hello ${name}!"` et `"Hello " + name + "!"`
coûtent tous deux 26 ops).
Détails :
- syntaxe `${expr}` ; n'importe quelle expression LeekScript est acceptée
(ex. `${a + b}`, `${count(arr)}`, interpolation imbriquée `${ "in ${x}" }`)
- le premier littéral est toujours émis (même vide) pour ancrer le type String,
de sorte que `"${42}"` produise la chaîne "42" et non l'entier
- les littéraux vides intermédiaires sont omis pour ne pas ajouter de
concaténation superflue
- `\$` échappe l'interpolation et produit un `$` littéral ; un `$` seul reste
littéral
- uniquement les guillemets doubles : `'${x}'` reste un littéral
- réservé à la v4+ : en v1-3 `${...}` reste du texte littéral, donc aucune IA
existante n'est impactée
Implémentation : extraction de la boucle de dispatch du lexer dans `step()`,
réutilisée pour lexer l'expression à l'intérieur d'un `${ … }` (suivi de la
profondeur d'accolades pour gérer maps/blocs/chaînes imbriqués).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ajoute l'interpolation de chaînes en v4+ pour les chaînes à guillemets doubles :
"a${expr}b". C'est du pur sucre syntaxique desugaré au niveau du lexer en la suite de tokens d'une concaténation :( "a" + (expr) + "b" ).Le parser et le générateur de code restent totalement inchangés. Le code Java produit est strictement identique à une concaténation
+écrite à la main, donc le cout est exactement le même que l'addition/concaténation correspondante (vérifié :"Hello ${name}!"et"Hello " + name + "!"coûtent tous deux 26 ops).Détails :
${expr}; n'importe quelle expression LeekScript est acceptée (ex.${a + b},${count(arr)}, interpolation imbriquée${ "in ${x}" })"${42}"produise la chaîne "42" et non l'entier\$échappe l'interpolation et produit un$littéral ; un$seul reste littéral'${x}'reste un littéral${...}reste du texte littéral, donc aucune IA existante n'est impactée (sauf en V4)Implémentation : extraction de la boucle de dispatch du lexer dans
step(), réutilisée pour lexer l'expression à l'intérieur d'un${ … }(suivi de la profondeur d'accolades pour gérer maps/blocs/chaînes imbriqués).