Re: Résolution de l'équation iScheme = infix (Scheme)

[Olivier Miakinen]

Bonjour,

Le 08/06/2022 18:41, Jacques Menu a écrit :
> 
> [...]
> 
> #(define (grow-in-up-direction beam)
>    (let* ((Y-positions (ly:grob-property beam 'positions))
>           (left-position (car Y-positions))
>           (right-position (cdr Y-positions)))
>      (cond
>        ((< left-position right-position)
>         RIGHT)
>        ((> left-position right-position)
>         LEFT)
>        (else
>         CENTER))))
> 
> \relative c' {
>   \override Beam.grow-direction = #grow-in-up-direction
>   c'16 d e f g f e d c g c g c e g c
> }
> 
> pourrait s’écrire avec iScheme:
> 
> @define grow-in-up-direction (beam) {
>   let* {
>     Y-positions    = ly:grob-property (beam, 'positions),
>     left-position  = car (Y-positions),
>     right-position = cdr (Y-positions);
> 
>     cond {
>       left-position < right-position:
>         RIGHT;
> 
>       left-position > right-position:
>         LEFT;
> 
>       else:
>         CENTER;
>     }
>   }
> }

J'avoue que je suis partagé.

D'un côté, c'est vrai que cette syntaxe infixée sera plus accessible à
ceux qui ont l'habitude de C, Java, PHP, JavaScript, Python, et beaucoup
d'autres langages. Je suppose d'ailleurs qu'elle doit permettre d'écrire
de façon procédurale, en masquant le fait que cela se traduira par un
« (progn ... ... ...) » implicite.

D'un autre côté, je suppose qu'il y aura toujours besoin dans certains cas
de revenir au vrai Scheme, ce qui veut dire apprendre deux langages au lieu
d'un (Scheme + iScheme) en plus de la syntaxe LilyPond.

Ajoutons à cela le fait qu'aux bugs que l'on peut trouver dans Scheme et
dans LilyPond il faudra tenir compte de bugs possibles dans la traduction
de iScheme en Scheme. Par exemple, dans le cas de if et cond imbriquées,
la traduction en Scheme pourrait ne pas imbriquer les instructions dans le
même ordre que ce que croit la personne qui code en iScheme. Pareil avec
les traitements de l'ordre des opérateurs tels que a * b + c * d, surtout
si a, b, c et d sont en fait des appels de fonctions.

Quoi qu'il en soit, je ne dis pas que c'est impossible ni que ce n'est
pas souhaitable. L'idée est même très séduisante.

> \relative c' {
>   \override Beam.grow-direction = @grow-in-up-direction
>   c'16 d e f g f e d c g c g c e g c
> }

Si la définition de grow-in-up-direction en iScheme se traduit par une
définition de même nom en Scheme, alors je pense qu'on pourrait tout aussi
bien continuer à écrire l'appel sous la forme #grow-in-up-direction au
lieu de @grow-in-up-direction. Cela dit, ça peut être une bonne idée
quand même d'introduire cette nouvelle syntaxe comme une sorte de rappel
de comment ça a été implémenté.

> [...]
> 
> Cerise sur le gâteux, [...]

Mais non, il ne faut pas croire que l'on est gâteux quand on a du mal avec
le Scheme ! :-)

-- 
Olivier Miakinen