Re: [Scheme coding] turning a list into a markup/string

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hi David,
>
>> Mike is a genius that will reinvent three wheels
>> in the time it takes to learn about one.
>
> That might be a little bit of the pot calling the kettle black…?  ;)

I am glacially slow for almost everything because I am ridiculously
afraid of wasting time doing something wrong.  That turns to work out
better for teaching than getting anything done myself.

> Oh! So much to learn in there. Thank you.
>
> Any idea which (if either) is more expensive, yours or Mike’s (well,
> {Mike+David N.}’s)?

Clearly Mike's, but you are not likely to be able to notice a difference
for most applications.  Either will be quite faster than parsing the
music in the first place.

>> I find it great that you understand everything that Mike does here
>
> In fact, I may have sent him down this particular path by suggesting
> that we do essentially what I would do with a list of numbers in
> maxima:
>
>    diff(nums) := rest(nums,1) - rest(nums,-1)
>
> He probably just took that idea and ran with it to the [Lily-Scheme]
> goal-line.

That may be.  Running is so little effort to him that he can just take a
route and follow it.

>> you are well-prepared to figure out what I am doing, and what may
>> be hidden away in some of the internals of the read-made tools I use.
>
> What tools are those exactly?

The main one is

  (map - (cdr res) res)

which relies on map (more exactly the (srfi srfi-1) version of it that
LilyPond input may depend on) working with a function taking more than
one argument, and not minding if the corresponding lists have different
length (it just runs until the shortest is exhausted).

And music-pitches is also convenient to know.

>> it is seminal for me to tackle problems with the simplest means I can
>> manage.
>
> I live (and die?) by the belief that "Every elegant question has an
> elegant answer".  =)

I guess in this case the answer is more blunt than elegant.  It refuses
to acknowledge the refinement of the problem.

-- 
David Kastrup