lilypond-devel
[Top][All Lists]
Advanced

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

Re: how to make decisions?


From: Trevor Daniels
Subject: Re: how to make decisions?
Date: Tue, 4 Sep 2012 22:22:40 +0100

Han-Wen, you wrote Tuesday, September 04, 2012 2:58 PM
Subject: Re: how to make decisions?


> On Tue, Sep 4, 2012 at 5:03 AM, Trevor Daniels <address@hidden> wrote:
>
>> David, it wasn't anything /you/ said; it was Han-Wen's reply which
>> dismissed my cautionary offering as "bed-shedding" and referring
>> to a sneering video about other syntax failures.  Which, incidentally,
>> illustrated my real point (which he missed) ideally.
> 
> I'm sorry - I have been doing these kinds of syntax discussions for
> too long, and have too little time for them now.

I can appreciate that.  Thanks for following this up.
 
> The video is intended to illustrate how a small features of a language
> may make sense (ie. was created with the best intentions) when viewed
> on small scale, but makes the language as a whole confounding.  For

I'm quite familiar with the concepts of grammar, parser design and
BNF.  In the '60s I learnt my first programming language, Atlas
Autocode, largely by reading its formal description used by the
compiler-compiler on the Ferranti Atlas computer at Manchester.

> If I missed your point, can you state it more explicitly?

I can see now my point was not stated clearly.  It was:  

At this stage in the discussions it is important to be clear about what 
problems we are trying to solve, "In this discussion we must always 
consider what it is we are trying to optimise."  I take your point that
the syntax should be unambiguous, but I don't see why this should
dominate the discussion.  Improving the syntax from the point of
view of usability is equally if not more important; certainly those
considerations and discussions should come before thinking how they
might be handled in the parser.  When you and Jan first started thinking 
about the LilyPond language I'm sure you began by considering how 
music could best be encoded.  Only later did you devise the precise 
syntax.  We should continue in the same way.

So what problems do the users have, exactly?  We should address this 
question first.  Janek apparently has his list, which would be a good start.
But we should not invent problems where they don't exist.  I've probably 
read every email on the user list for the last 4 years, and inconsistent parser
rules have not figured prominently.  Another example is the considerable 
discussion so far about pre- and post-fix notation.  Again, has this been a 
problem prominent on the user list?  I don't think so.  So why try to solve it?
Especially in ways that would screw all existing code.  In fact, I don't think
/users/ have any serious problems with the syntax as it currently exists,
other than getting to grips with it initially.

So I'd be happy to let David continue his work straightening out the
parser, which is good, and improving the functionally, even better.
But if we are to have a discussion about syntax let's first list the problems
we need to solve, and reach agreement on which ones need to be tackled.
Then we know what it is we are trying to optimise.

Trevor

reply via email to

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