lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make music functions callable from Scheme (issue 244840043 by addres


From: David Kastrup
Subject: Re: Make music functions callable from Scheme (issue 244840043 by address@hidden)
Date: Sun, 21 Jun 2015 07:28:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

"Keith OHara" <address@hidden> writes:

> On Mon, 08 Jun 2015 18:04:44 -0700, <address@hidden> wrote:
>
>> No dice.  The main problem is dealing with all combinations of running
>> out of signature and running out of available arguments.  If you treat
>> the optional argument skipping in an inner loop, you may still run out
>> of signature, and in that case you still need to treat the case where
>> you have simultaneously run out of arguments (namely because the
>> non-matching argument triggering the skipping was \default aka
>> *unspecified) separately _and_ break out of all loops.  Since you have
>> already fetched the next signature bit (since you would not know whether
>> it was optional and skipping should continue), you can't return to the
>> main loop which would fetch it again but need to clad the whole in one
>> while (scm_is_false (scm_call_1 (pred, arg))) of its own.  Treating all
>> the terminating condition combinations in inner loop and outer loop
>> separately causes the control structures to fray apart more than the
>> "skipping" flag does, to the degree where the cleanest solution to
>> handle one of the innermost loop termination conditions with a goto
>> statement.
>
> Well, the inner loop can decide whether to continue by peeking-ahead
> at the next entry in the signature.

Then it needs to separately check that it can peek ahead.  If I'm not
mistaken, I do that in several places as well in the current single
loop.  Doing it in a double loop makes this moderately more confusing.

> Then the jobs of the inner/outer loops remain clean.
>
> Some people don't like side-effects in loop-control conditionals
>
>  while (scm_is_pair (scm_cdr (signature))     //  more slots ?
>         && scm_is_pair (scm_cadr (signature)) // next one optional ?
>         && (signature = scm_cdr (signature)));// deal with it now.

Count me among "some people" here.  At any rate, this relies on SCM
being equivalent to "true" in a boolean context which is not something
we can rely on.  So you'd rather need something like

&& ((signature = scm_cdr (signature)), true)

here and that's where we are seriously in "ugh" territory at the latest.

> so maybe I'll use test-in-the-middle loop,

Some people don't like test-in-the-middle loop either, but I usually
prefer it to the alternatives.

> but that needs only break one loop.

Well, I'm sympathetic to your argument in theory, and I have an
(unfinished) branch issue4421-keith to show for it with a day of work
behind it.  But I painted myself into a corner with it that became
uglier than what it was supposed to replace.  I am pushing that branch
(unrebased though) to dev/dak/issue4421-keith so that you have the
option of saving yourself that day or part of it but of course if you
choose to base your work on that code, you have a solid chance of
sticking in the same corner whereas starting from scratch you might find
something better that evaded me.

Take your choice.  Mine was to take my losses with the first approach
and leave.  It was certainly good enough and I was satisfied I could not
do significantly better with reasonable effort.

-- 
David Kastrup



reply via email to

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