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

[Marc Hohl]

Am 16.02.2013 09:29, schrieb 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.
Ah, you are right.
> 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?
Sorry, I don't have much time for coding at the moment – which is very
frustrating, because improving lilypond seems to me like a valuable way
to spend time programming and learning scheme, but after the
bar line interface project, I didn't manage to do something useful for
lilypond, mostly due to the lack of time.

If this erroneous use of reduce cannot be resolved quickly, it would be
best to raise an issue for 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.
Well, a do loop in scheme felt kinda weird, but map didn't work here
(I rewrote a bunch of other do loops this way, but here it failed).
I didn't manage to iterate over the list (or two lists in this case), 
building
up a list of results where a specific element is inserted only when
certain conditions are fulfilled. Grepping through the code, I found out 
that
reduce would work here, but I understand now that it is far from being
optimal here, because reduce is used very much like a do loop without
using its intended functionality.

Regards,

Marc