Janek Warchoł <[email protected]> writes: > On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup <[email protected]> wrote: >> >> You mean, currently we basically see the default error message from the >> parser generator. Improving this involves basically accepting errors in >> input and acting on them by putting out hand-tailored messages. >> >> Currently, the parser is still undergoing significant restructuring work >> in major areas and mechanisms. That work entails a lot of time spent on >> ironing out parser conflicts where some input would correspond to >> multiple and diverging interpretations according to the current syntax. >> It is significant work ironing out those conflicts. Adding additional >> rules for erroneous input means more potential for conflict, so it would >> make the ongoing work even harder. I am working towards recognizing >> elements of the syntax in isolation, and then pasting them together. >> The "pasting together" is then done outside of the immediate control of >> the parser and can trigger independent error messages based on the >> assumption that at least the elements used for combining were, by >> themselves, recognized correctly. Those error messages can be more >> specific and helpful than the boilerplate parse errors from the parser >> generator. > > Hmm, this sounds complicated. Do you mean that implementing more > informative ("custom") error messages with current parser will wreak > havoc, but if we simplify the parser first, it would be possible to do > this in a sane way?
No. I don't mean "wreak havoc" but rather "will be in the way while I am still reworking the parser internals". It's like putting up tapestry and setting up furniture before doing the plumbing. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
