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 <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
