Re: Version 2.23.80 : define vs ly:parser-defined

[Jean Abou Samra]

Le 27/10/2022 à 00:11, Gilles Thibault a écrit :
> Ok, j'avais bien compris pour la portée de ly:parser-define! mais je 
> ne savais pas que define était une macro
>   (macro? define)     => #t
>   (procedure? define) => #f


... en Guile 1. En Guile 2, c'est aussi une macro,
par contre cette manière de le vérifier ne marche
plus, justement parce que c'est une macro (à cause
de l'ajout de la fonctionnalité « identifier syntax »).


$ ~/lilies/2.23.80/bin/lilypond scheme-sandbox
GNU LilyPond 2.23.80 (running Guile 2.2)
Traitement de 
« /home/jean/lilies/2.23.80/share/lilypond/2.23.80/ly/scheme-sandbox.ly »
Analyse...
GNU Guile 2.2.7
Copyright (C) 1995-2019 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(#{ g101}#)> (macro? define)
While compiling expression:
Syntax error:
unknown location: source expression failed to match any pattern in form 
define
scheme@(#{ g101}#)> (procedure? define)
While compiling expression:
Syntax error:
unknown location: source expression failed to match any pattern in form 
define
scheme@(#{ g101}#)> (macro? (module-ref (current-module) 'define))
$1 = #t
scheme@(#{ g101}#)> (procedure? (module-ref (current-module) 'define))
$2 = #f




C'est mentionné sur cette page :

https://www.gnu.org/software/guile/manual/html_node/Internal-Macros.html



> > Pour finir, est-ce que je recommande personnellement d'utiliser ce
> > style de codage ? À vrai dire, non, pas vraiment,  pour deux raisons.
> > D'une part, en utilisant defined?, tu mets quand même les mains dans
> > le cambouis de Guile et de son interaction de bas niveau avec LilyPond.
>
>   Hum, pas pratique toutes ces fonctions de base dont on doit se méfier.
>   Un développeur avait aussi un jour mis des réserves sur la fonction 
> primitive-eval.



Pas idiot.

Par exemple, en Guile 2, les erreurs dans du code exécuté avec
primitive-eval peuvent être difficiles à comprendre. (Je précise
que LilyPond exécute tout le code Scheme avec primitive-eval par défaut,
mais on peut changer ça avec #(ly:set-option 'compile-scheme-code).)



>   Il faudrait des fonctions sûres, estampiées Lilypond pour remplacer 
> defined? et primitive-eval.



Ce n'est pas mon point de vue. La question de base qui se pose aux
développeurs LilyPond est : est-ce qu'il est possible de
créer une interface qui fait toujours ce à quoi l'utilisateur
s'attend ? En l'espèce, difficile de savoir ce à quoi l'utilisateur
s'attend. Est-ce que tu t'attendais à voir defined? renvoyer #t
dans un \layout lorsque la variable a été définie dans un autre
\layout dont le \layout où tu utilises defined? hérite ? Peut-être,
peut-être pas, mais que cela t'ait surpris ou non, je suis sûr
qu'il y en a pour qui c'est l'inverse. Même chose avec les
variables locales. Donc s'il faut se méfier de defined?, ce n'est
pas tant parce que son comportement risque de changer dans les
versions futures, même si c'est vrai dans une certaine mesure. C'est
surtout parce que c'est une fonction qui fait pénétrer dans les entrailles
de choix techniques complexes et que par conséquent elle pourrait te
piéger dans des cas un peu avancés si tu n'as pas parfaitement compris
ce qu'elle fait.



>   Pour primitive-eval, ce même développeur avait proposé : (module-ref 
> (current-module) sym)


Oui, ça sonne mieux que primitive-eval.


>   Pour defined?, il pourrait y avoir : (module-variable 
> (current-module) sym)
>   ... même si je ne vois pas en quoi ces fonctions "module" seraient 
> plus sûrs.



Pour le coup, c'est quasi-équivalent.


Cordialement,
Jean