Re: [GLISS] - alternative viewpoint

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> Here is my multi-stage plan for that:
>
> I essentially agree with everything.  Thanks for that plan.
>
>> b) our C++ engravers announce to the type system (and via that, to
>> the documentation) which context properties they read, modify and
>> write.  There is no reason that this does not also include the Grob
>> descriptions which are even now a special case of context property.
>
> In general, virtually all (public) Scheme functions of LilyPond
> already have some documentation strings attached to it, and I think it
> is probably one of the most important targets on the documentation
> side to make them appear in the documentation.
>
>> d) \override xxx is equivalent to \override Bottom.xxx, [...]
>
> As soon as this works it would be extremely helpful if we could have a
> command line flag to switch on tracing of those commands so that a
> user can follow which \override gets applied which context.  Actually,
> this would be extremely helpful today too.
>
>>> And finding what comes after the \override staff.Something - is it
>>> ##f. or #'4 or 4 or { 4} or what?
>> 
>> #'4 and #4 and 4 should be quite equivalent in most cases...
>
> Currently, in case of error, we basically see the parser's or lexer's
> error message which isn't very useful for the beginner.  Is there any
> possibility to fine-tune this as requested by Phil, in particular,
> emitting the right usage as an example in the error message?

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.

We have that, to some degree, concerning the type of music function
arguments.  If those don't match expectations, you'll get an error that
usually is quite more specific and user-readable than "syntax error:
unexpected STRING".  However, putting more user-specific error rules in
the syntax rules themselves increases the potential for syntax conflicts
in the parser.  As long as the major contruction work in there is not
finished, the user benefits of such rules will likely be transitory, and
it makes working on the parser even harder.

So I would first like to get to a state where I consider the
parser/syntax to be mostly "in harmony" with its design before adding
user-helpful error rules that make further work harder.

-- 
David Kastrup