[Top][All Lists]

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

Re: LilyPond 2.1.22 released

From: Mats Bengtsson
Subject: Re: LilyPond 2.1.22 released
Date: Mon, 16 Feb 2004 13:26:52 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Han-Wen Nienhuys wrote:
address@hidden writes:

Han-Wen Nienhuys wrote:

I want the syntax to reflect what Lily is doing inside. If you can
figure out a way to unify both types of properties internally, I will
unify the syntax.

Ideally, the user shouldn't need to know anything about the structure
of the implementation.

No, but they should know the "specification" of what LilyPond input
means.  I want to change implementation matches closely the (mental
model) of the input language. That's also why I'm doing some major
brain surgery on the Translation part, so we can have more consistency
and have

  \context Score \with { .. }

I think that

If we need the separation, we also have to be
able to explain it in a way that's obvious to a person who has never
done any programming.

misses the point. If we fail to explain things logically, then the
implementation is at fault.

I agree completely on this point of view!

Also, one problem from the users side, even when you have realized the
difference between translator properties and backend properties,
is that it's not always obvious if a certain feature belongs to the
translator or to the backend, when you start searching for a property.

When you unify both, the search space doubles in size - that doesn't
exactly help the users.

Yes! And, regarding unification, one of the main points of the
backend is that many different output objects share the same
properties. If we didn't have this nice feature, the search space
wouldn't just double, it would explode!


reply via email to

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