"Keith OHara" <k-ohara5...@oco.net> writes: > On Mon, 08 Jun 2015 18:04:44 -0700, <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
