Bonjour El Papounet,
j'apprécie cet échange qui, en toute lucidité débute quand même après plusieurs années !
Je suis mitigé pour les macros. Au moins jusqu'à la version 5.50, elles sont légèrement discriminées quand se présente un bug au sein de l'une d'entre elles. Et je n'ai jamais fait la remarque. Pourtant, Fred a tâché d'avoir une certaine écoute le long des années.
J'ai vu des bugs 3D être totalement balayés. Demande honorée.
J'ai vu du code source devenir modifiable à la volée. Demande honorée.
J'ai vu des copies de mémoire s'accélérer. Demande honorée.
J'ai vu un champ totalement libre de toute syntaxe devenir accessible et éditable de manière transparente pour l'éditeur comme pour le compilateur. Demande honorée.
Les macros évoluent peu d'une version à l'autre. Mais quand elles évoluent, c'est pour régresser. Et ce n'est pourtant pas du tout une mauvaise nouvelle, car la dernière demande honorée décrite plus haut, couvre très largement les fonctionnalités des macros, rendant ces dernières obsolètes.
Je vous invite, avec un oeil prudent, à observer
ce code source récemment posté.
Il est en deux parties séparées par une directive de compilation. Il se présente sous la forme suivante :
La partie 2 est classique et exécutée immédiatement. Pour recréer ce code soi-même, il faut copier/coller
l'exemple de RunProgram dans la doc.
Cet exemple démarre le compilateur en mode "help". En virant l'option "help", le compilateur démarre alors en mode compilation et il n'attend qu'une chose : un nom de fichier PureBasic à compiler puis exécuter.
Or en lui fournissant la partie 1 étriée des caractères incompatibles, le compilateur compile et exécute cette partie 1.
Dans mon exemple, la partie 1 est le
code d'exemple CanvasGadget de la doc, code source traduit en français.
Si vous (toi, Micoute et bien d'autres) lisez cette partie 1, ça facilite grandement de disposer d'un code source dans sa langue natale.
La partie 2 travaille comme un gestionnaire de macros qui traite un fichier texte : la partie 1. C'est du pré-process pas optimisé, mais optimisable à des niveaux bien peu à plaindre.
Alors, je ne crie pas victoire, car, en l'état, il n'y a qu'une traduction :
traduction français -> charabia exécutable.
Il manque un traducteur français -> anglais exécutable
et un traducteur anglais exécutable -> français
Ce n'est qu'en ajoutant ces deux traducteurs que ce code sera vertueux : la langue anglaise reste le centre exécutable et tout autre langue locale, pouvant gérer un lexique de traduction verra sa compilation/exécution possible, comme ce code source, quelque soit la langue.
Les traducteurs en question restent de simples détecteurs/remplaceur. C'est une "simple" traduction de vocabulaire, pas grammatical (beaucoup plus lourd et inutile ici).
Il y a une règle à respecter dans l'ordre des expressions dans les noms traduisibles :
Général_ ... _Local
Exemple : Fenêtre_Obtenir_Largeur()
Le piège : Obtenir_Largeur_Fenêtre()
L'exemple sera toujours compris, par ce focus naturel de gauche à droite, de l'objet général à l'objet local, tandis que le piège, les francophones le comprendront très bien. Mais moins sûr qu'un non francophone comprenne efficacement (sans risquer une confusion dans un gros projet) la grammaire française dans sa langue natale.
Le "MacroExpandedCount" ne devient qu'une simple variable de la partie 2. Autrement dit, on ne se contraint pas à une syntaxe de macro à apprendre et comprendre : on crée la transformation qui ressemble à une gestion de macro, transformation adaptée à la syntaxe de la partie 1.
Ici, une macro contraint à n'avoir que des labels numérotés à partir de 1 :
Test1
Test2
Test3
etc...
Là, la partie 2 a un fonctionnement infiniment plus vaste que les macros. On peut créer des noms tels que :
TestASub3
TestBSub6
TestCSub9
TestAAdd12
TestBAdd15
TestCAdd18
etc...
.... et absolument toute autre combinaison. On peut aussi compiler la partie 2 et l'ajouter au pré-processing dans l'éditeur natif pour ne conserver visible dans le scope de l'éditeur que la partie 1 en langue natale.
Je pense donc, sans grandement me vanter, vu le non-accompli qui n'offre que de disposer de sa langue natale, sans lien traducteur vers la grande croisée des chemins de la langue anglaise, que bien que pas fini, ce type de code source rend les macros vraiment non nécessaires.
Cela n'empêche pas un résumé des fonctionnalités des macros :
- compteur (MacroExpandedCount)
- arguments facultatifs (comme avec les arguments des procédures)
- concaténation avec # (souder une expression à un argument)
Autrement dit, tu as fait le tour des macros. Libre à toi (comme à quiconque) d'aller bien plus loin en les détournant par cette autre pratique. Je ne peux malheureusement pas assurer d'établir ce projet, surtout quand il est bien plus vaste que la notion de langage humain. J'ai, sur papier, quelques algos qui seront plus facilement concrétisables et partageables dans le même domaine, avant de réussir à collecter le minimum nécessaire de vocabulaire anglais, allemand, polonais, russe, chinois, japonais, arabes et bien d'autres. Il y a 2000 fonctions natives. On peut estimer à un max de 2500 termes la quantité de vocabulaire techniques à collecter et vérifier pour chaque langue.
En tout cas, un grand merci pour ton appréciation.
