On 7/22/09 8:29 AM, "Kieren MacMillan" <kieren_macmil...@sympatico.ca>
wrote:
> Hi all,
>
> Just adding my 2ยข...
>
>>> I might disagree. I'm big on semantics, and I would rather have a
>>> lot of commands that create the same look but mean different
>>> things, than have one command that creates a look which could mean
>>> a lot of different things. I don't know how people will be using
>>> LilyPond in the future, but I'd like for the program not to get
>>> stuck in ambiguous semantics.
>>
>> I agree with your concern with semantics.
>
> -1: I would much rather see one WISIWYG (What It Says Is What You
> Get) function rather than multiple WIMGRITSCDF (What It Means Gets
> Resolved Internally To Some Completely Different Function) functions.
> First of all, it minimizes namespace crowding; secondly, it reduces
> confusion and complexity in the docs (no need for crossrefs, etc.).
>
>> The user semantic would be worse.
>
> -1: The *composer-user* semantic might [!] be worse, but the
> *engraver-user* semantic would be better.
>
>> There are two different kinds of semantics that apply. One is the
>> semantic
>> that the composer sees. The other is the semantic that the
>> engraver sees.
>
> If by "engraver" you mean "person who is using Lilypond to engrave",
> then +1. =)
>
> The main problem I see in this thread is that we're trying to turn
> Lilypond into a *composing* application rather than thinking of it as
> purely an *engraving* application: when I *compose* for strings (I
> use pen and paper) I create/use/think "harmonics", but when I
> *engrave* the score (I use Lilypond) I code/use/think "diamond".
>
I think I have a better definition now. Instead of "user" and "engraver", I
want "music" and "engraving". The key objective of LilyPond is to have the
author of a LilyPond input file specify only the musical semantics (i.e. the
intended musical meaning). Then a perfect LilyPond would know exactly what
to do with that musical meaning to make a perfectly-engraved score.
"harmonics" is a muscial semantic; "diamond" is an engraving semantic. I
think that the closer we get to musical semantics, the better LilyPond input
is.
As an example of this point, I cringe every time I have to tweak something
to make it work, because I'm working in engraving semantics, not musical
semantics. Moving slur control points is an example of this; there's no
musical content at all in the location of slur control points; it's all
engraving content. While I want to have access to the engraving content,
I'd prefer never to have to touch it, because a perfect LilyPond would do
all the engraving automatically. I'd tell it what I want musically; it
would give me perfect output sheet music.
For me, I think the "correct musical semantics" argument overrides the
"don't expand the namespace" argument.
Thanks,
Carl
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
