Re: [Lilypond-auto] Issue 3182 in lilypond: Patch: Defuse the obfuscated Scheme programming contest

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 15.02.2013 14:02, schrieb address@hidden:
>> Status: Started
>> Owner: address@hidden
>> Labels: Type-Enhancement Patch-new
>>
>> New issue 3182 by address@hidden: Patch: Defuse the obfuscated Scheme
>> programming contest
>> http://code.google.com/p/lilypond/issues/detail?id=3182
>>
>> Defuse the obfuscated Scheme programming contest
>>
>> This merely grepped for occurences of &quot;reduce&quot; and
>> replaced most of
>> them (and possibly the close surroundings) with something saner. The
>> winner definitely has been in bar-line.scm.
> ;-)
>
> I had a (do ...) construct here before replacing it with reduce.

git blame points to Pál.  It could have been that he was just
reformatting, but it is the kind of searching for space between barlines
that would match the tasks I remember him doing.

Looking at the history of changes, it turns out that I did not touch
your use of "reduce" since it looked superficially like the intended use
of "reduce": I have no beef with reduce as such, but it should be used
for its principal and documented effect and patterns, not in some
side-effect loaden contraption.  Looking again at the code, it seems
that I was fooled by the "curr" and "prev" arguments and some other
things and skipped over this.  Indeed, this instance is run for its side
effects, its return value (which is a _string_ for empty extents, for
heaven's sake!) is discarded, it works with a secret inner loop variable
iterating over make-span-bars: in short, it is just as broken as the
stuff from Pál which I fixed.  Can you try fixing this?

The easiest way for that is to write out in plain text (or comments)
what you are doing here.  Then one looks for Scheme constructs which are
_intended_ to deal with the pattern you are trying to deal with.  Just a
hint: whenever you are tempted to fudge side-effects into an existing
Scheme function and/or discard its return value and/or ignore its
documented purpose and focus on its _operation_, you are more likely
better off using "named let".  "named let" is harder to understand than
a Scheme function used for its intended purpose, and easier to
understand than a Scheme function used against its intended purpose.

In many cases, additional arguments to for-each, map, and similar will
make it possible to find a nice Schemeish variant of writing things.

If you find, for efficiency considerations, that you really, really,
really need to use a function _against_ its intended purpose, then write
a separate wrapper function _implemented_ through the function used
against its intended purpose, and document the resulting intended
purpose and use _that_.

Don't ever use the constructions fold/reduce/unfold together with
additional side effects on variables: that's not the pattern they were
written for, so it makes it impossible to recognize what you actually
want.

-- 
David Kastrup