lilypond-user-fr
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]