Re: [GLISS] differentiating pre/post/neutral commands

[Graham Percival]

On Mon, Sep 03, 2012 at 02:43:51AM -0300, Han-Wen Nienhuys wrote:
> On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup <address@hidden> wrote:
> > Most of the proposals are a bad idea
> > without actually having to look at implementability because they
> > introduce ambiguities that are hard to resolve

Yes.  That's why I think it's worth discussing ideas before having
formal proposals.  If we can find problems in an idea from a few
minutes of casual discussion, then we can avoid potential hours of
creating a patch.

> > The problem is that the discussion tends to focus on lines
> > leading nowhere for various reasons, and that causes a state
> > of panic for those actually working on the parser, and
> > frustration for those who feel that their proposals are not
> > taken seriously by those "in power", namely actually working
> > with and on the parser code.

Right, both of those are problems.  But these are problems of
*organization* and *perception*.

Why not allow & encourage casual discussions of the syntax?  That
will give people a chance to explore ideas.  If 90% of the ideas
run into obvious problems and are dropped after an hour or two...
good!  At this preliminary stage, those actually working on the
parser should not be involved.  No panic, no overreaction.  Most
of the ideas are going to die before you see them anyway.  If this
ends up with non-parser-experts wasting 10 hours discussing stuff
that goes nowhere, that's fine!  It still gives non-experts a
venue to be heard.

Then, once the people involved in the preliminary discussion have
a firm idea of what they think will work, an actual proposal can
come to -devel.  But there's still no need for panic!  If it won't
work, just say so.  Technical knowledge will of course trump any
fluffy user discussion.  A one-line "I think this would make the
parser way too complicated" will block any proposal.  Unless/until
somebody has an actual patch, of course.


> I would much rather see patches to the parser rather than proposals
> that show examples. Examples always show how things would work in
> obvious situations, but the problem is not in the obvious cases.

Of course.

> The problem is in all the ambiguities that have to be resolved.
> Without working on the parser, it is difficult to appreciate the
> subtleties of specifying a grammar unambiguously and maintaining
> backward compatibility.

Of course.

> Rather than proposing something by way of example, I would like to see
> all proposals in the form of a parser patch that does not introduce
> extra shift/reduce or reduce/reduce conflicts, and maintains general
> backward compatibility. If a proposer manages to get that far, I
> promise I will take a serious look at it.

I agree that proposals including a patch are much stronger than
proposals without a patch.  So... coming back to the initial
question: *before* we have a patch for an idea, should we discuss
these ideas on -devel, or should we have a separate mailing list?

So far the discussion has gone according to my predictions.
There's panic (and IMO overraction) from people who actually know
the parser, which does not encourage open discussion of ideas.
Why not hold the preliminary discussions on a separate list (to
which parser experts are encouraged *not* to read), then only
bring a proposal to -devel when it's ready?

I mean, what possible downsides are there to this?  It will be
made abundantly clear to those on the
lilypond-fluffy-syntax-discuss list that their ideas will not
become code unless there's a good way for that to happen, and that
nobody (especially not David) is responsible for turning them into
code, and that technical concerns will trump any amount of
"niceness" in examples, and any other disclaimers you want to add.

- Graham