Re: Choose paper size and layout with command line options?

[M Sun]

Thanks Knute. The problem is not only the paper size, but also this part:

  #(set-global-staff-size 18)
  \paper {
top-margin = 0
bottom-margin = 0
left-margin = 5
right-margin = 0
  }

I need to enable these with the "kobo" size, but not in us-letter.

On Sun, Aug 7, 2022 at 8:12 PM Knute Snortum  wrote:
>
> On Sun, Aug 7, 2022 at 4:03 PM M Sun  wrote:
> >
> > Hi all,
> >
> > I’m writing a sheet targeting two different paper sizes, with some
> > layout adjustments. My goal is to be able to specify (maybe
> > indirectly) the paper size in command line, without changing the
> > lilypond file itself. My initial set up was this:
> >
> >   \version "2.23.2"
> >   #(set! paper-alist
> > (cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
> >   #(set-global-staff-size 18)
> >   \paper {
> > top-margin = 0
> > bottom-margin = 0
> > left-margin = 5
> > right-margin = 0
> >   }
> >   #(set-default-paper-size "kobo")
> >   \score { \new Staff {a b c}}
> >
> > As you can see this is a cramped layout for a small paper size. Now I
> > also want a version with a normal layout on us-letter size, so I
> > removed the set-global-staff-size line, and the paper block, and
> > changed the paper size to “letter”. The file became this:
> >
> >   \version "2.23.2"
> >   #(set! paper-alist
> > (cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
> >   #(set-default-paper-size "letter")
> >   \score { \new Staff {a b c}}
> >
> > These worked. But like I mentioned my goal is to be able to switch
> > between these two setups in command line, without changing the file.
> > My idea was to set a variable in the command line using “-e”, and in
> > the file choose the layout and paper size based on the variable.
> > Here’s my code:
> >
> >   \version "2.23.2"
> >
> >   #(define (configOutput spec)
> > (cond
> >  ((eqv? spec 'letter) (set-default-paper-size "letter"))
> >  ((eqv? spec 'kobo)
> >   (set! paper-alist
> >(cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
> >   (set-global-staff-size 18)
> >   #{ \paper {
> >   top-margin = 0
> >   bottom-margin = 0
> >   left-margin = 5
> >   right-margin = 0 }
> >   #}
> >   (set-default-paper-size "kobo"))
> >  (default nil)))
> >
> >   #(use-modules (guile-user))
> >   #(configOutput output-spec)
> >
> >   \score { \new Staff {a b c}}
> >
> > Then in the shell I ran a command like this:
> >
> >   lilypond -e "(define-public output-spec 'kobo)" test.ly
> >
> > This produced the output with the “kobo” paper size. Or I could change
> > that “kobo” to “letter” and it’d produce with the “letter” paper size.
> >
> > This *almost* worked, except that the \paper block didn’t take effect.
> > This is where I’m lost. How should I make this work?
>
> I believe it's as easy as:
>
> lilypond -dpaper-size="kobo" test.ly
>
> --
> Knute Snortum



-- 
Fear  is  the  path  to  the  dark  side.
Fear  leads  to  anger,
Anger  leads  to  hate,
Hate  leads  to  suffering.

Re: Choose paper size and layout with command line options?

[Jean Abou Samra]

Le 07/08/2022 à 22:51, M Sun a écrit :

Hi all,

I’m writing a sheet targeting two different paper sizes, with some
layout adjustments. My goal is to be able to specify (maybe
indirectly) the paper size in command line, without changing the
lilypond file itself. My initial set up was this:

   \version "2.23.2"
   #(set! paper-alist
 (cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
   #(set-global-staff-size 18)
   \paper {
 top-margin = 0
 bottom-margin = 0
 left-margin = 5
 right-margin = 0
   }
   #(set-default-paper-size "kobo")
   \score { \new Staff {a b c}}

As you can see this is a cramped layout for a small paper size. Now I
also want a version with a normal layout on us-letter size, so I
removed the set-global-staff-size line, and the paper block, and
changed the paper size to “letter”. The file became this:

   \version "2.23.2"
   #(set! paper-alist
 (cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
   #(set-default-paper-size "letter")
   \score { \new Staff {a b c}}

These worked. But like I mentioned my goal is to be able to switch
between these two setups in command line, without changing the file.
My idea was to set a variable in the command line using “-e”, and in
the file choose the layout and paper size based on the variable.
Here’s my code:

   \version "2.23.2"

   #(define (configOutput spec)
 (cond
  ((eqv? spec 'letter) (set-default-paper-size "letter"))
  ((eqv? spec 'kobo)
   (set! paper-alist
(cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
   (set-global-staff-size 18)
   #{ \paper {
   top-margin = 0
   bottom-margin = 0
   left-margin = 5
   right-margin = 0 }
   #}
   (set-default-paper-size "kobo"))
  (default nil)))

   #(use-modules (guile-user))
   #(configOutput output-spec)

   \score { \new Staff {a b c}}

Then in the shell I ran a command like this:

   lilypond -e "(define-public output-spec 'kobo)" test.ly

This produced the output with the “kobo” paper size. Or I could change
that “kobo” to “letter” and it’d produce with the “letter” paper size.

This *almost* worked, except that the \paper block didn’t take effect.
This is where I’m lost. How should I make this work?




set!, set-global-staff-size and set-default-paper-size all act
through a side effect. On the other hand, \paper doesn't have
a side effect, it is a value that you should pass to LilyPond
to make its settings integrated into the default settings. Because
the principle of cond in Scheme is that the value of the last
expression the a cond clause is returned, your \paper is evaluated
and just thrown away. You need to put it last. Furthermore,
there is a subtlety here that forces to use $ instead of #;
see
https://lilypond.org/doc/v2.23/Documentation/extending/lilypond-scheme-syntax
and
https://extending-lilypond.readthedocs.io/en/latest/lily-and-scheme.html#hash-vs-dollar

Some minor comments on your code:
- eqv? is more general than needed for symbols, you can use the
  (theoretically) faster eq?
- case does the job too,
- there is no "default" in Scheme, it's "else",
- there is no "nil" (the empty list is '() and the boolean
  false is #f). You don't need it anyway, just leave that
  "default" clause out (it will return *unspecified*, a special
  Guile value that is ignored by LilyPond).

Giving:

\version "2.23.12"

#(use-modules (guile-user))

$(case output-spec
   ((letter)
    (set-default-paper-size "letter"))
   ((kobo)
    (set! paper-alist
 (cons '("kobo" . (cons (* 15.7 cm) (* 20.9 cm))) paper-alist))
    (set-global-staff-size 18)
    (set-default-paper-size "kobo")
    #{
  \paper {
    top-margin = 0
    bottom-margin = 0
    left-margin = 5
    right-margin = 0
  }
    #})))

\score { \new Staff {a b c}}


Best,
Jean

Re: polychords: what's the current state-of-the-art?

[Lukas-Fabian Moser]

Hi Kieren,


What's the current best snippet for rendering polychords? I know the GSoC chord stuff 
is still in air traffic control, but the snippet found 
at  
definitely doesn't work, and is likely far from optimal given the decade-plus of 
advances in the codebase.


I don't have much time at the moment, but as a first pointer:

The snippet worked as late as 2.18.2. What broke it after that is that 
the meaning of c1:5.9-.11.13- in chordmode has changed:


\version "2.18.2"

\chordmode {
  c1:5.9-.11.13-
}

yields

in 2.18.2, whereas in 2.19.83, it yields

The culprit seems to be the added support for power chords: In 2.18.2, 
c1:5 generated a c major chord; now it only generates a power chord 
fifth. My guess would be that Valentin V.'s chord name cleanup in 
78225bc1b386e12dc was the point when this changed.


Lukas

Re: polychords: what's the current state-of-the-art?

[David Kastrup]

Lukas-Fabian Moser  writes:

> Hi Kieren, 
>
>  What's the current best snippet for rendering polychords? I know the GSoC
>  chord stuff is still in air traffic control, but the snippet found at
>  
>  definitely doesn't work, and is likely far from optimal given the
>  decade-plus of advances in the codebase.
>
> I don't have much time at the moment, but as a first pointer:
>
> The snippet worked as late as 2.18.2. What broke it after that is that the 
> meaning of
> c1:5.9-.11.13- in chordmode has changed:
>
> \version "2.18.2"
>
> \chordmode {
>   c1:5.9-.11.13-
> }
>
> yields
>
> *
>
> in 2.18.2, whereas in 2.19.83, it yields
>
> *
>
> The culprit seems to be the added support for power chords: In 2.18.2, c1:5
> generated a c major chord; now it only generates a power chord fifth. My guess
> would be that Valentin V.'s chord name cleanup in 78225bc1b386e12dc was the
> point when this changed.

convert-ly exists.

Sounds more like issue 4614 to me.

-- 
David Kastrup

Re: polychords: what's the current state-of-the-art?

[Lukas-Fabian Moser]

The culprit seems to be the added support for power chords: In 2.18.2, c1:5
generated a c major chord; now it only generates a power chord fifth. My guess
would be that Valentin V.'s chord name cleanup in 78225bc1b386e12dc was the
point when this changed.

convert-ly exists.


I actually thought I had tried this. Obviously I was too stupid to do it 
correctly.



Sounds more like issue 4614 to me.


True, thanks.

Lukas

Re: polychords: what's the current state-of-the-art?

[Valentin Petzel]

Hi Lukas,

This snippet basically works by defining an Exception for each single Polychord 
structure you’re going to use. This is not even done in a systematic way, so 
you could easily add other Exceptions along the way. In my opinion the main 
issue here is that the chord naming strategy of first transforming theoretical 
respesentation of a chord into a bunch of notes to then have some function try 
to make sense of that and turn in again into a theoretical representation of a 
chord is absolute madness if we do actually already know how this chord should 
look.

Suppose we had a different way of specifying chords not as a bunch of notes, 
but in a representation that preserves the theoretical meaning of such a 
chord. Then ChordNames would simply have to take care of formatting. In the 
current design we have a huge function that is responsible for both 
interpreting the notes as well as formatting the chord. The other way we could 
have two functions, one that formats chords and another that interprets notes 
as chords.

This way we could have a transposable syntax to say e.g. des|c to specify Db 
major over C major or even g|dis:m|cis:m or something and would be able to 
quickly get the chord specification we actually want, instead of having to do 
something like c:3.5.9-.11.13- or even something like this 
cis,:m3.5.9.11.13.19-.21.23-.

Best,
Valentin

Am Dienstag, 9. August 2022, 12:28:25 CEST schrieb Lukas-Fabian Moser:
> Hi Kieren,
> 
> > What's the current best snippet for rendering polychords? I know the GSoC
> > chord stuff is still in air traffic control, but the snippet found
> > at > .txt>  definitely doesn't work, and is likely far from optimal given the
> > decade-plus of advances in the codebase.
> I don't have much time at the moment, but as a first pointer:
> 
> The snippet worked as late as 2.18.2. What broke it after that is that
> the meaning of c1:5.9-.11.13- in chordmode has changed:
> 
> \version "2.18.2"
> 
> \chordmode {
>c1:5.9-.11.13-
> }
> 
> yields
> 
> in 2.18.2, whereas in 2.19.83, it yields
> 
> The culprit seems to be the added support for power chords: In 2.18.2,
> c1:5 generated a c major chord; now it only generates a power chord
> fifth. My guess would be that Valentin V.'s chord name cleanup in
> 78225bc1b386e12dc was the point when this changed.
> 
> Lukas



signature.asc
Description: This is a digitally signed message part.

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi all,

>> convert-ly exists.
> I actually thought I had tried this. Obviously I was too stupid to do it 
> correctly.

Me, too, I guess…? At least in Frescobaldi, it didn't work at all [!!].
Kieren

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi Valentin,

> Suppose we had a different way of specifying chords not as a bunch of notes, 
> but in a representation that preserves the theoretical meaning of such a 
> chord.

The GSoC work was working towards exactly that.

> This way we could have a transposable syntax to say e.g. des|c to specify Db 
> major over C major or even g|dis:m|cis:m or something and would be able to 
> quickly get the chord specification we actually want, instead of having to do 
> something like c:3.5.9-.11.13- or even something like this 
> cis,:m3.5.9.11.13.19-.21.23-.

We really need something like this.
Kieren.

Re: polychords: what's the current state-of-the-art?

[David Kastrup]

Kieren MacMillan  writes:

> Hi all,
>
>>> convert-ly exists.
>> I actually thought I had tried this. Obviously I was too stupid to
>> do it correctly.
>
> Me, too, I guess…? At least in Frescobaldi, it didn't work at all [!!].

Running the given file through convert-ly changes the respective lines
in the example code (and bumps the version to 2.20.0 I think).

That's the entry part of this snippet.  Whether the analysis part would
also be affected, I have no clue.  If so, convert-ly would have no
chance of fixing it.  But convert-ly appears to deal with the samples
Lukas discussed.

-- 
David Kastrup

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi David,

>> Me, too, I guess…? At least in Frescobaldi, it didn't work at all [!!].
> Running the given file through convert-ly changes the respective lines
> in the example code (and bumps the version to 2.20.0 I think).

Indeed — no problem from the command line.
I'll file a bug-report with Frescobaldi.

Thanks!
Kieren.

Re: polychords: what's the current state-of-the-art?

[Lukas-Fabian Moser]

Hi Kieren,


What's the current best snippet for rendering polychords? I know the GSoC chord stuff 
is still in air traffic control, but the snippet found 
at  
definitely doesn't work, and is likely far from optimal given the decade-plus of 
advances in the codebase.


I don't have much time at the moment, but as a first pointer:

The snippet worked as late as 2.18.2. What broke it after that is that
the meaning of c1:5.9-.11.13- in chordmode has changed:

\version "2.18.2"

\chordmode {
  c1:5.9-.11.13-
}

yields

in 2.18.2, whereas in 2.19.83, it yields

The culprit seems to be the added support for power chords: In 2.18.2,
c1:5 generated a c major chord; now it only generates a power chord
fifth. My guess would be that Valentin V.'s chord name cleanup in
78225bc1b386e12dc was the point when this changed.

Lukas

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi Valentin,

> In my opinion the main issue here is that the chord naming strategy
> of first transforming theoretical respesentation of a chord into
> a bunch of notes to then have some function try to make sense
> of that and turn in again into a theoretical representation of a chord
> is absolute madness if we do actually already know how this chord should look.
> 
> Suppose we had a different way of specifying chords not as a bunch of notes, 
> but in a representation that preserves the theoretical meaning of such a  
> chord.

The GSoC chord work was moving in exactly that direction!

> This way we could have a transposable syntax to say e.g. des|c

Well, we wouldn't want to overload the bar-check feature, of course!  ;)

Maybe you're interested in picking up the GSoC chord ball and taking it across 
the goal line? In mid-September, I might have a little more bandwidth to sit 
down with Carl again and try it myself… but given my track record, I'd be more 
optimistic about the outcome if there were multiple developers working with me.

Cheers,
Kieren.

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi Carl!

Do you remember off-hand how polychords were handled in the GSoC code?
What was the syntax? Could it handle more than two in the stack? etc.

Thanks,
Kieren.

> On Aug 9, 2022, at 11:14 AM, Kieren MacMillan  
> wrote:
> 
> Hi Valentin,
> 
>> In my opinion the main issue here is that the chord naming strategy
>> of first transforming theoretical respesentation of a chord into
>> a bunch of notes to then have some function try to make sense
>> of that and turn in again into a theoretical representation of a chord
>> is absolute madness if we do actually already know how this chord should 
>> look.
>> 
>> Suppose we had a different way of specifying chords not as a bunch of notes, 
>> but in a representation that preserves the theoretical meaning of such a  
>> chord.
> 
> The GSoC chord work was moving in exactly that direction!
> 
>> This way we could have a transposable syntax to say e.g. des|c
> 
> Well, we wouldn't want to overload the bar-check feature, of course!  ;)
> 
> Maybe you're interested in picking up the GSoC chord ball and taking it 
> across the goal line? In mid-September, I might have a little more bandwidth 
> to sit down with Carl again and try it myself… but given my track record, I'd 
> be more optimistic about the outcome if there were multiple developers 
> working with me.
> 
> Cheers,
> Kieren.

Re: polychords: what's the current state-of-the-art?

[Jean Abou Samra]

Le 09/08/2022 à 17:44, Kieren MacMillan a écrit :

Hi Carl!

Do you remember off-hand how polychords were handled in the GSoC code?
What was the syntax? Could it handle more than two in the stack? etc.




For the record, the GSoC code and the review discussion around it
are found at
https://gitlab.com/lilypond/lilypond/-/issues/5224
and in the two links to appspot.com at the top.

Best,
Jean

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi Jean,

> For the record, the GSoC code and the review discussion around it
> are found at
> https://gitlab.com/lilypond/lilypond/-/issues/5224
> and in the two links to appspot.com at the top.

Thanks for that.

I've looked through, and I can't see where polychords are even considered. 
Maybe I just don't grasp how rich the semantics mechanism is? Happy to be shown 
how it makes polychord entry intuitive and easy for the user.

Cheers,
Kieren.

Re: polychords: what's the current state-of-the-art?

[Jean Abou Samra]

Le 09/08/2022 à 20:26, Kieren MacMillan a écrit :

Hi Jean,


For the record, the GSoC code and the review discussion around it
are found at
https://gitlab.com/lilypond/lilypond/-/issues/5224
and in the two links to appspot.com at the top.

Thanks for that.

I've looked through, and I can't see where polychords are even considered. 
Maybe I just don't grasp how rich the semantics mechanism is? Happy to be shown 
how it makes polychord entry intuitive and easy for the user.




No idea :-) I just saw that issue and thought I'd share the link.
I didn't try to apply the patch to current master. Maybe someone
else who was there back then can comment.

Re: polychords: what's the current state-of-the-art?

[David Kastrup]

Kieren MacMillan  writes:

> Hi Jean,
>
>> For the record, the GSoC code and the review discussion around it
>> are found at
>> https://gitlab.com/lilypond/lilypond/-/issues/5224
>> and in the two links to appspot.com at the top.
>
> Thanks for that.
>
> I've looked through, and I can't see where polychords are even
> considered. Maybe I just don't grasp how rich the semantics mechanism
> is? Happy to be shown how it makes polychord entry intuitive and easy
> for the user.

Hm, well the problem with meshing note mode and chord mode is that
tremolo notation interferes.  But durations are not inside of chords.

So 1 should be usable as poly-chord entry.  The representation
for the chord namer's sake (that relies on some additional info for
reconstructing something corresponding to the entry semantics rather
than just its constituent notes) is of course a different problem.

c/g could be entered as  alternatively: basically anything with :
in it would continue stacking at a pitch not lower than the previous
one.

I _think_ that syntax should be workable.  No warranties, though.

-- 
David Kastrup

Re: polychords: what's the current state-of-the-art?

[Carl Sorensen]

On Tue, Aug 9, 2022 at 12:29 PM Kieren MacMillan <
kie...@kierenmacmillan.info> wrote:

> Hi Jean,
>
> > For the record, the GSoC code and the review discussion around it
> > are found at
> > https://gitlab.com/lilypond/lilypond/-/issues/5224
> > and in the two links to appspot.com at the top.
>
> Thanks for that.
>
> I've looked through, and I can't see where polychords are even considered.
> Maybe I just don't grasp how rich the semantics mechanism is? Happy to be
> shown how it makes polychord entry intuitive and easy for the user.
>

Polychords are not considered in the GSOC work.  But the idea of having
chord semantics means that the polychord representation could be stored
with the chord.  But we would need a polychord input syntax defined to
handle polychords.

I consider the GSOC work to be necessary, but not sufficient.

Carl

Re: polychords: what's the current state-of-the-art?

[Kieren MacMillan]

Hi David,

> Hm, well the problem with meshing note mode and chord mode is that
> tremolo notation interferes.  But durations are not inside of chords.
> 
> So 1 should be usable as poly-chord entry.

Oh! That's kind of a wonderful UI, in my opinion.

> c/g could be entered as  alternatively: basically anything with :
> in it would continue stacking at a pitch not lower than the previous one.

Nice!

> I _think_ that syntax should be workable.  No warranties, though.

Certainly worth a try — all the other UIs I thought of were much less elegant.

Thanks!
Kieren.

An infix syntax for Scheme ...

[Jean Abou Samra]

Hi,

Some time ago, Jacques Menu asked on the French-speaking equivalent of
this list if it would be possible to create an infix syntax for Scheme
that would be more approachable for beginners.

As we discussed this topic privately and he asked me questions about how
a possible implementation could be done, I ended up finding that an
example was easier to give than full explanations, and this gave 
"Herescheme":


https://gitlab.com/jeanas/herescheme/

This is a Git repository. You can also download the code as a .zip archive
using the "Download" button, or from this direct link:

https://gitlab.com/jeanas/herescheme/-/archive/main/herescheme-main.zip

To use Herescheme, download that, unzip it, and \include the file
"/.../herescheme/herescheme.ily". This requires a 2.23 version of
LilyPond (tested with 2.23.11).

There are a number of examples in the file herescheme-examples.ly.
Excerpt:


\relative c' {
  \shape &"[(0, 0), (0, 1.5), (0, 0.4), (0, 0)]" Slur
  \override Beam.grow-direction =
    &"function(beam) =>
    let Y_positions = ly.grob_property(beam, |positions|) in
    {
  ly.message('Beam \\'positions are ~a', Y_positions);
  let left_position = car(Y_positions) in
  let right_position = cdr(Y_positions) in
  if left_position < right_position then {
    RIGHT
  }
  else if left_position > right_position then  {
    LEFT
  }
  else if left_position = right_position then {
    CENTER
  }
  else ly.error('this can\\'t happen')
    }"
  c'16( d e f g f e d c g c g c e g c)
}



This is experimental; comments on it are welcome, but I don't recommend
using it for serious projects yet.

To be honest, I have no idea if what I did here is actually a good idea
at all (I for one won't use it). I'm just curious to see. On the one hand,
normal Scheme syntax is used in all Scheme tutorials, in the Guile manuals,
on mailing list snippets, and when printing values, so only using Herescheme
syntax without knowing about basic Scheme syntax is likely tough. On the
other hand, I know Scheme is off-putting to some people just because of its
many parentheses and the "unintuitive" way of placing the operator as 
prefix.

If that is your case, maybe you'll find Herescheme to your taste. Or maybe
not.

It is possible to mix Scheme and Herescheme code seamlessly.

Also, please note that Herescheme is *not* a whole new language.
Don't expect to be able to write something similar to Java or
Python in LilyPond. Herescheme has the same underlying concepts
as Scheme, is just a different syntax for writing Scheme code.
It does have a syntax that is more familiar to people used to
languages other than from the Lisp family.

Finally, this was just a side project in passing for me, so by
all means do comment, but please don't expect me to update the
code fast.

Regards,
Jean

Re: An infix syntax for Scheme ...

[Thomas Morley]

Am Di., 9. Aug. 2022 um 23:46 Uhr schrieb Jean Abou Samra :
>
> Hi,
>
> Some time ago, Jacques Menu asked on the French-speaking equivalent of
> this list if it would be possible to create an infix syntax for Scheme
> that would be more approachable for beginners.
>
> As we discussed this topic privately and he asked me questions about how
> a possible implementation could be done, I ended up finding that an
> example was easier to give than full explanations, and this gave
> "Herescheme":
>
> https://gitlab.com/jeanas/herescheme/
>
> This is a Git repository. You can also download the code as a .zip archive
> using the "Download" button, or from this direct link:
>
> https://gitlab.com/jeanas/herescheme/-/archive/main/herescheme-main.zip
>
> To use Herescheme, download that, unzip it, and \include the file
> "/.../herescheme/herescheme.ily". This requires a 2.23 version of
> LilyPond (tested with 2.23.11).
>
> There are a number of examples in the file herescheme-examples.ly.
> Excerpt:
>
>
> \relative c' {
>\shape &"[(0, 0), (0, 1.5), (0, 0.4), (0, 0)]" Slur
>\override Beam.grow-direction =
>  &"function(beam) =>
>  let Y_positions = ly.grob_property(beam, |positions|) in
>  {
>ly.message('Beam \\'positions are ~a', Y_positions);
>let left_position = car(Y_positions) in
>let right_position = cdr(Y_positions) in
>if left_position < right_position then {
>  RIGHT
>}
>else if left_position > right_position then  {
>  LEFT
>}
>else if left_position = right_position then {
>  CENTER
>}
>else ly.error('this can\\'t happen')
>  }"
>c'16( d e f g f e d c g c g c e g c)
> }
>
>
>
> This is experimental; comments on it are welcome, but I don't recommend
> using it for serious projects yet.
>
> To be honest, I have no idea if what I did here is actually a good idea
> at all (I for one won't use it). I'm just curious to see. On the one hand,
> normal Scheme syntax is used in all Scheme tutorials, in the Guile manuals,
> on mailing list snippets, and when printing values, so only using Herescheme
> syntax without knowing about basic Scheme syntax is likely tough. On the
> other hand, I know Scheme is off-putting to some people just because of its
> many parentheses and the "unintuitive" way of placing the operator as
> prefix.
> If that is your case, maybe you'll find Herescheme to your taste. Or maybe
> not.
>
> It is possible to mix Scheme and Herescheme code seamlessly.
>
> Also, please note that Herescheme is *not* a whole new language.
> Don't expect to be able to write something similar to Java or
> Python in LilyPond. Herescheme has the same underlying concepts
> as Scheme, is just a different syntax for writing Scheme code.
> It does have a syntax that is more familiar to people used to
> languages other than from the Lisp family.
>
> Finally, this was just a side project in passing for me, so by
> all means do comment, but please don't expect me to update the
> code fast.
>
> Regards,
> Jean
>
>

Do you know WISP by Arne Babenhauserheide
https://hg.sr.ht/~arnebab/wisp
?

Tbh, I don't like these approaches, though WISP already exists. No
need to duplicate efforts, at least it's worth a closer look!?

Cheers,
  Harm

Re: An infix syntax for Scheme ...

[David Kastrup]

Jean Abou Samra  writes:

> Some time ago, Jacques Menu asked on the French-speaking equivalent of
> this list if it would be possible to create an infix syntax for Scheme
> that would be more approachable for beginners.
>
> As we discussed this topic privately and he asked me questions about how
> a possible implementation could be done, I ended up finding that an
> example was easier to give than full explanations, and this gave
> "Herescheme":
>
> https://gitlab.com/jeanas/herescheme/

Well, the point of Lisp is that it doesn't even have a program syntax.
You write down the parse tree as a Lisp data structure.  That makes it
easy for programs to talk about programs.

"Converting to infix" just does not make a lot of sense in that
paradigm.  Once you separate language structures and data structures,
there is no point in creating some chimera.  The computer can no longer
easily process it, so there is little point in making something only
somewhat closer to human-readable.

-- 
David Kastrup

Re: An infix syntax for Scheme ...

[Kieren MacMillan]

Hi Jean,

As someone who has used an HP-15C as my only calculator since 1982, I want a 
POSTFIX version of Scheme, not an INFIX version!  LOL

Cheers,
Kieren.

> On Aug 9, 2022, at 5:45 PM, Jean Abou Samra  wrote:
> 
> Hi,
> 
> Some time ago, Jacques Menu asked on the French-speaking equivalent of
> this list if it would be possible to create an infix syntax for Scheme
> that would be more approachable for beginners.

Re: An infix syntax for Scheme ...

[David Kastrup]

Kieren MacMillan  writes:

> Hi Jean,
>
> As someone who has used an HP-15C as my only calculator since 1982, I
> want a POSTFIX version of Scheme, not an INFIX version!  LOL

I actually prefer Lisp dialects to FORTH.  A bit of lambda calculus
makes for a more structured view.

-- 
David Kastrup

Re: An infix syntax for Scheme ...

[Andrew Bernard]

Hello Jean,

While this is interesting, I dispute the underlying assumption. Why do 
you say infix notation is easier for beginners? There's no evidence for 
this. And there is a huge amount of evidence against it. For very many 
years MIT taught computer science 6.001 exclusively in Scheme to 
freshmen with _no_ programming experience and they all took to it like 
to ducks to water. There was never any complaint that it was hard to 
learn. This is a well known fact. Now, of course, MIT freshman are the 
creme de la creme, and the course lecturers for many years were Abelson 
and Sussman, authors of SICP. Nevertheless, there is nothing 
intrinsically _easier_ about infix languages compared to LISP and 
Scheme. What one could say is that people with previous experience of 
infix languages may feel disoriented. But as with music, it's only a 
matter of familiarity. And people have noted that when learning LISP 
there is always initial perplexity and then almost everyone undergoes a 
sudden epiphany where it all makes sense. Many have written about that 
experience.


I'd argue for leaving Scheme alone and encouraging people to go ahead 
with it as it. With an editor like emacs it makes all the parentheses 
easy. [But then there are people who think emacs is too hard! SIgh.]


I do a lot of work in Haskell. It's superb for making domain specific 
languages. On odd days I think it would be great to make a DSL for 
Lilypond. Then I come to my senses by the afternoon!


While I am not an expert in pedagogy, I have a hunch that starting 
people off on a specialised infix variant of a Scheme-like language may 
make it _harder_ for them to learn Scheme when the time comes.


I'm not sure why everything has to be approachable for beginners 
nowadays. Perhaps that's why Latin in no longer taught. It's not easily 
approachable by beginners! Yes we need more developers in the Lilypond 
community, but they really do have to be conversant with lamda calculus 
and the lot, not something similar to Python.


Andrew


On 10/08/2022 7:45 am, Jean Abou Samra wrote:

Hi,

Some time ago, Jacques Menu asked on the French-speaking equivalent of
this list if it would be possible to create an infix syntax for Scheme
that would be more approachable for beginners.

Re: An infix syntax for Scheme ...

[Andrew Bernard]

My HP 48GX is still sitting on my desk. The best calculator ever.

I do not want an infix calculator! 30+ years old and still going strong.

Andrew

On 10/08/2022 11:20 am, Kieren MacMillan wrote

As someone who has used an HP-15C as my only calculator since 1982, I want a 
POSTFIX version of Scheme, not an INFIX version!  LOL