CTPL 0.1.1 et l’avenir

Oui vous avez bien lu, CTPL 0.1.1 vient de sortir. Comme le numéro de version le laisse supposer, c’est une version mineure faisant suite à la 0.1. Au menu : corrections de bugs, dont deux majeurs : stack overflow lors de la destruction d’un très grand arbre de tokens ; et accélération fulgurante de la création de grands arbres.

Quel futur pour CTPL ?

J’ai en ce moment plusieurs idées de ce qui pourrait peupler l’avenir de CTPL, c’est-à-dire de quoi y ajouter ou qu’y changer. Voici quelques unes de ces idées ; je vous invite bien entendu à faire part de vos avis sur le sujet.

Utilisation GIO comme I/O layer

Je penses sérieusement laisser tomber LibMB au profit de GIO, qui dispose d’un module d’I/O en mémoire, GMemoryInputStream et GMemoryOutputStream. Pourquoi ? Hé bien principalement car ceci permettrai de gérer implicitement toutes les sources de données que GIO gère à travers les flux d’entée et de sortie, et ce directement, c’est-à-dire sans forcement charger les données en mémoire (donc utilisation mémoire plus faible pour l’analyse − mais ne rêvons pas : les tokens sont de toutes façons chargés en mémoire).

Pros

• Analyse possible en streaming depuis un fichier (local, distant, tout ce que GIO supporte) ;
• Plus de dépendance sur LibMB, mais sur GIO qui est quand-même plus courant.

Cons

• Nécessite de réécrire une partie de la bibliothèque, en fait tout ce qui interagit directement avec les données d’entrée et de sortie (la sortie devrait être triviale à changer, l’entrée beaucoup moins) plus ce dont j’ai besoin mais qui n’est pas dans l’API GIO (manipulation plus aisée qu’à uniques coups de read()) ;
• Peut-être plus lent (rapport à toute l’abstraction et à GObject) ?

Ajout du support de l’assignation

Haha. Bon, ça j’y penses à moitié, et à moitié pas, particulièrement à cause de ses rares pros et nombreux cons.

Pros

• Ça serait cool.

Cons

• Ça ne sert sans doutes à rien en fait ;
• Il serait sans doutes bien d’avoir un vrai support des scopes avec ;
• Ça nécessite l’un des points suivants :
  1. Que toute assignation soit aussi ajoutée à la sortie ({a = b} ajoute b à la sortie, cool) ;
  2. Faire en sorte qu’un opérateur puisse ne rien retourner (ce qui n’est ni prévu actuellement, ni n’a de sens pour un autre opérateur) ;
  3. Ajouter un moyen pour qu’une partie des substitutions ne se retrouvent pas dans la sortie.

  La première solution est facile à implémenter, mais forcement j’ai un penchant pour la troisième puisque non seulement ça permet de ne pas écrire le résultat d’une assignation dans la sortie, mais aussi de le faire, au choix. Oui, mais comment faire ? Ajouter un nouveau type de bloc ? Ajouter une sorte d’opérateur unaire « ne pas afficher » ? Bof bof…

Ajout des chaînes littérales

Ceci permettrai l’une ou l’autre petite fantaisie comme la comparaison avec des variables de l’environnement ({if foo == "some text"}...) ou de s’amuser à remplir la sortie de « lol » très facilement ({"lol" * 10000}). Pas besoin de longue dissertation sur cette idée-là : ça ne serait sans-doutes pas très utile, et sans doutes pas très complexe à implémenter (BTW, il y a déjà une branche pour ça, même si je ne me souviens plus de son statut exact).

Conclusion

C’est gentil les fonctionnalités, mais il faut peut-être aussi se demander si ça vaut le coup : utiliser GIO me semble assez intéressant, mais les autres idées plus discutables. Qu’en pensez-vous, qu’est-ce qu’il vous serait agréable ou utile de voir venir ?