Re: Lilypond error behaviour

[David Wright]

On Mon 18 Apr 2016 at 09:06:47 (+0200), Stephan Neuhaus wrote:
> On 2016-04-17 13:51, Urs Liska wrote:
> >Am 17.04.2016 um 04:29 schrieb David Wright:
> >>I think a better analogy than compilers writing programs would be
> >>browsers rendering web pages. Can you imagine a WWW where malformed
> >>pages produced a few error messages on the screen and nothing else?
> >>No, we expect the browser to make its best attempt at a partial
> >>rendition. So please leave LP alone and write a better server.
> >>Yes, it might be nice if LP had an indication of severity level,
> >>but my preference would be for improvements in LP's primary goals.
> >
> >I think the browser is indeed a good analogy.
> >
> >If we have malformed HTML or even worse issues like e.g. a failed CSS
> >include, then yes, we expect the browser to render as much and as nice
> >as possible. But what LilyPond currently does is displaying a big modal
> >over the page saying "I'm sorry but I couldn't render the page due to a
> >fatal error. Please click here to close this message and view the page."
> 
> Coming at this discussion rather late, and also from a totally
> different angle, I'd like to make the (slightly off-topic) point
> that I don't think that it's a good idea to make it a design
> principle that Lilypond should try to render even clearly malformed
> input.

That begs the question. How do you define "clearly malformed input."
If it is malformed, it can't be clear.

Of course, if you mean "clearly-malformed", then I contest this
vehemently. LP has a complicated syntax, and scores have complicated
structures. But often, one's next score has close similarities with
some previous one, so I often hack an old score into the new one.
I'll leave the old lyrics to start with (to spread the notes
realistically) while I type in new notes, and cut and paste any
useful lyrics I can find without bothering to hyphenate them at first.

So there'll be several LP runs of what's clearly rubbish while I check
my work so far for things like syntax, missing durations, correct
octavation, etc. I do not want to be deprived of this facility by
some misguided attempts to protect some users from their folly.

> (Note that I'm not saying that it is a happy coincidence that
> Lilypond does, in fact, do this.  It's great for debugging, as I can
> attest.  All I'm saying is that it would be a bad idea for users to
> rely on this behaviour, and for Lilypond developers to embrace it as
> a design principle.)
> 
> We have seen in HTML how malformed input quickly becomes the norm
> and how browser vendors are unable to back out of supporting it.

You're carrying the analogy too far. No one has suggested that LP
has to interpret its language differently, nor that PDF viewers
of MIDI players have to be made to support idiosyncratic output files
written by LP.

> (Just try to validate almost any web page that claims to be HTML
> 4.01 and you'll see what I mean.) The result is that render engines
> are much slower and much buggier than they need to be, because they
> have tons of exceptions for stuff that isn't really HTML but where
> the blame would ultimately fall on the browser if it didn't render
> properly.

On the contrary, LP having to take a rigorous approach to classifying
errors in its input could (possibly) slow it down, and it's also
possible to foresee bugs where an accidental misclassification makes
it censure and consequently censor some output unnecessarily.

> (I'm not saying that I advocate browsers refusing to render
> something that is almost, but not quite, entirely unlike HTML.  I'm
> just saying that once you go down that rabbit hole, you won't come
> back up in a hurry.)
> 
> Personally, I like the idea of Lilypond clearly saying to the user
> that there is something wrong with the input file.

It does. Not always clearly, as discussed above. It can't divine
the user's intent.

> If that "modal
> dialog" went away, users would simply look at the output file and
> conclude that their input must have been OK. Having a clear and
> unambiguous message (even if there is debate about the use of the
> word "fatal") that _there is something wrong with the input file_
> frees Lilypond developers to extend and otherwise develop Lilypond
> without the burden of having to support wrong but entrenched usage.

This would indicate that you're using a GUI of some sort to run LP.
If you have a GUI-oriented program, then a GUI interface is likely the
right approach. But LP is not a GUI program, it's a music processing
program (cf MS Word versus LaTeX), and benefits from having a console
for error messages.

I assume you *do* have a console for error and informational messages.
I would think that determining whether a modal dialog window has been
mapped, and what its contents are, is a harder proposition for make
users and server writers than parsing the output on the console.

However, parsing the console output is what they seem to be
complaining about, and a desire to censor the PDF output is just
anal retentiveness as far as I am concerned. I just want to get
the job done (excuse the pun).

Cheers,
David.