[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inclusions automatiques en Scheme (was: Re: Bonjour)
From: |
Valentin Villenave |
Subject: |
Re: Inclusions automatiques en Scheme (was: Re: Bonjour) |
Date: |
Sun, 2 Dec 2007 16:58:00 +0100 |
Le 02/12/07, Nicolas Sceaux<address@hidden> a écrit :
> En fait j'avais passé "hors ligne" ces articles. Il y avait donc un
> "part 2", sur la façon de faire des dacapo et compagnie. Puis j'ai
> décidé de retirer les articles de ce genre, n'ayant pas trop l'énergie
> pour en faire davantage, ni maintenir les précédents. J'ai repassé
> "en ligne" l'article sur les inclusions juste avant d'envoyer mon post.
C'est fort dommage. Je comprends fort bien le problème vis-à-vis de
ton blog, fait avec soin et constamment mis à jour ; cependant tu
pourrais peut-être les poster sur cette mailinglist, ou encore les
mettre sur http://lilypondwiki.tuxfamily.org/ afin que ceux qui
cherchent un peu puissent tomber dessus.
> A une époque j'ai aussi regretté de ne pas avoir d'include relatif,
> puis je me suis débrouillé autrement, d'abord en ajoutant des
> répertoires pour la recherche des fichiers à inclure avec -I sur la
> ligne de commande, enfin avec les commandes que j'utilise maintenant.
Nous avions une discussion avec Han-Wen sur la légitimité des includes
relatifs ; je persiste à me sentir "choqué" quand je vois, par exemple
dans ton fichier common/common.ily, des lignes telles que
\include "common/include-commands.ily"
qui se rapportent pourtant à des fichiers se trouvant dans le *même* répertoire.
Je ne suis pas le seul à trouver ça bizarre, c'est aussi le cas de
Graham et quelques autres.
> (srfi srfi-39) sert à ajouter une fonctionnalité : des variables
> "spéciales", ce sont les variables entourées d'étoiles dans le reste
> du code, et qui ne fonctionne pas de la même façon que les autres
> variables en Scheme.
Très bien. Est-ce que, à ta connaissance, les prochaines versions de
Guile (avec notamment la R6RS) vont changer quelque chose ? Aura-t-on
toujours besoin d'inclure explicitement cette srfi ?
> Toute expression musicale située au "top-level" va être traitée
> de façon à générer une partition. Ici, ce n'est pas ce qu'on veut,
> puisque le fichier contenant la partition aura déjà été parsé.
> L'expression musicale returnée par cette fonction peut être ignorée,
> puisqu'elle ne sert à rien. C'est l'effet de bord créé par la
> fonction qui est intéressant, pas sa valeur de retour.
Je crains de n'avoir pas fait les études adéquates pour comprendre ces
explications :(
Je ne comprends pas en quoi l'expression serait parsée deux fois, et
même si je le comprenais, alors pourquoi utiliser un
"define-music-function (parser location quoiquecesoit)"
si c'est pour justement ne pas parser l'expression musicale ?
Pour poser ma question plus simplement : qu'est-ce qui différencie ton
code d'un truc tout bête tel que :
includeScore =
#(define-music-function (parser location name) (string?)
#{ \include " $name/score.ily" #})
(en dehors du fait que ce code ne marche pas ;)
Merci pour ces explications et pour ta patience.
Cordialement,
Valentin