[Top][All Lists]

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

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

From: David Kastrup
Subject: Re: [Scheme coding] turning a list into a markup/string
Date: Tue, 21 Jan 2020 22:44:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

reply via email to

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