[TUHS] The 'usage: ...' message. (Was: On Bloat...)

[TUHS] The 'usage: ...' message. (Was: On Bloat...)

[Douglas McIlroy]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

> was ‘usage: ...’ adopted from an earlier system?

"Usage" was one of those lovely ideas, one exposure to which flips its
status from unknown to eternal truth. I am sure my first exposure was on
Unix, but I don't remember when. Perhaps because it radically departs from
Ken's "?" in qed/ed, I have subconsciously attributed it to Dennis.

The genius of "usage" and "?" is that they don't attempt to tell one what's
wrong. Most diagnostics cite a rule or hidden limit that's been violated or
describe the mistake (e.g. "missing semicolon") , sometimes raising more
questions than they answer.

Another non-descriptive style of error message that I admired was that of
Berkeley Pascal's syntax diagnostics. When the LR parser could not proceed,
it reported where, and automatically provided a sample token that would
allow the parsing to progress. I found this uniform convention to be at
least as informative as distinct hand-crafted messages, which almost by
definition can't foresee every contingency. Alas, this elegant scheme seems
not to have inspired imitators.

Doug

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

[TUHS] Re: The 'usage: ...' message. (Was: On Bloat...)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Sun, May 19, 2024 at 10:03 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

>
> Another non-descriptive style of error message that I admired was that of
> Berkeley Pascal's syntax diagnostics. When the LR parser could not proceed,
> it reported where, and automatically provided a sample token that would
> allow the parsing to progress. I found this uniform convention to be at
> least as informative as distinct hand-crafted messages, which almost by
> definition can't foresee every contingency. Alas, this elegant scheme seems
> not to have inspired imitators.
>
> The hazard with this approach is that the suggested syntactic correction
might simply lead the user farther into the weeds.  It depends on how far
the parse has gone off the rails before a grammatical error is found.
Pascal and BASIC (at least the original Dartmouth BASIC) have simple,
well-behaved grammars and the suggested syntactic correction is likely to
be correct.  It doesn't work as well for more syntactically complicated
languages such as C (consider an error resulting from use of == instead of
=) or PL/I.  And it's nigh on impossible for languages with ill-behaved
grammars such as Fortran and COBOL (among other grammatical evils, Fortran
has context-sensitive lexiing).

Commercial compiler writers avoid this techniq

[-- Attachment #2: Type: text/html, Size: 1663 bytes --]

[TUHS] Re: The 'usage: ...' message. (Was: On Bloat...)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

Ack!  I finger-fumbled and accidentally sent this message incomplete.
Here's the complete version.  Sorry about that, Chief!

On Sun, May 19, 2024 at 12:18 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On Sun, May 19, 2024 at 10:03 AM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
>
>>
>> Another non-descriptive style of error message that I admired was that of
>> Berkeley Pascal's syntax diagnostics. When the LR parser could not proceed,
>> it reported where, and automatically provided a sample token that would
>> allow the parsing to progress. I found this uniform convention to be at
>> least as informative as distinct hand-crafted messages, which almost by
>> definition can't foresee every contingency. Alas, this elegant scheme seems
>> not to have inspired imitators.
>>
>> The hazard with this approach is that the suggested syntactic correction
> might simply lead the user farther into the weeds.  It depends on how far
> the parse has gone off the rails before a grammatical error is found.
> Pascal and BASIC (at least the original Dartmouth BASIC) have simple,
> well-behaved grammars and the suggested syntactic correction is likely to
> be correct.  It doesn't work as well for more syntactically complicated
> languages such as C (consider an error resulting from use of == instead of
> =) or PL/I.  And it's nigh on impossible for languages with ill-behaved
> grammars such as Fortran and COBOL (among other grammatical evils, Fortran
> has context-sensitive lexiing).
>
> Commercial compiler writers avoid this techniq
>

Commercial compiler writers avoid this technique because it turns into an
error report generator.  The potential user benefit is outweighed by all of
the "your compiler suggested X as a correction when the problem was Y"
that need to be answered.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 2515 bytes --]

[TUHS] Re: The 'usage: ...' message.

[Ralph Corderoy]

Hi Doug,

> Perhaps because it radically departs from Ken's "?" in qed/ed

That spread elsewhere.  When PDP-7 Unix's cp.s is given an odd number of
arguments, leaving the last unpaired, it prints the argument followed by
‘ ?’.  https://www.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix/cmd/cp.s

    mes:
       040000;077012		

    unbal:				
       lac name2			
       tad d4			
       dac 1f
       lac d1
       sys write; 1: 0; 4
       lac d1
       sys write; mes; 2
       sys exit

-- 
Cheers, Ralph.

[TUHS] Re: The 'usage: ...' message. (Was: On Bloat...)

[Dave Horsfall]

On Sun, 19 May 2024, Douglas McIlroy wrote:

> Another non-descriptive style of error message that I admired was that 
> of Berkeley Pascal's syntax diagnostics. When the LR parser could not 
> proceed, it reported where, and automatically provided a sample token 
> that would allow the parsing to progress. I found this uniform 
> convention to be at least as informative as distinct hand-crafted 
> messages, which almost by definition can't foresee every contingency. 
> Alas, this elegant scheme seems not to have inspired imitators.

I did something like that for our compiler-writing assignment.  An 
ALGOL-like language (I think I used ALGOLW) it would detect when a 
semicolon was missing, and insert it (with a warning).  As a test case, it 
successfully compiled a program with no semicolons at all...

-- Dave