On Sun, Aug 11, 2013 at 10:49:27PM +0200, Jan Stary wrote: > Tha yacc(1) manpage uses > > .Tn LALR(1) > .Tn LR(1) > > I don't think LALR or LR is a tradename. > This seems to be what mdoc(7) describes as: > > Since this macro is often implemented to use a small caps > font, it has historically been used for acronyms (like > ASCII) as well. Such usage is not recommended because it > would use the same macro sometimes for semantical annotation, > sometimes for physical formatting. > > So would it be better to just say "LALR(1)" without > any markup, just as we say e.g. "BNF"? > > Jan >
yes, Tn gets abused horribly. however it's everwhere, so i wouldn;t want to tackle it in a single page. we would have to decide where exactly it makes sense (never, as far as i'm concerned), then do it everywhere consistently. jmc > > Index: yacc.1 > =================================================================== > RCS file: /cvs/src/usr.bin/yacc/yacc.1,v > retrieving revision 1.26 > diff -u -p -r1.26 yacc.1 > --- yacc.1 18 Oct 2010 14:42:16 -0000 1.26 > +++ yacc.1 11 Aug 2013 20:48:37 -0000 > @@ -37,9 +37,7 @@ > .Os > .Sh NAME > .Nm yacc > -.Nd an > -.Tn LALR(1) > -parser generator > +.Nd an LALR(1) parser generator > .Sh SYNOPSIS > .Nm yacc > .Op Fl dlrtv > @@ -51,11 +49,8 @@ parser generator > .Nm > reads the grammar specification in > .Ar file > -and generates an > -.Tn LR(1) > -parser for it. > -The parsers consist of a set of > -.Tn LALR(1) > +and generates an LR(1) parser for it. > +The parsers consist of a set of LALR(1) > parsing tables and a driver routine > written in the C programming language. > .Nm > @@ -176,8 +171,7 @@ is defined and non-zero. > .Sh DIAGNOSTICS > If there are rules that are never reduced, the number of such rules is > written to the standard error. > -If there are any > -.Tn LALR(1) > +If there are any LALR(1) > conflicts, the number of conflicts is also written > to the standard error. > .Sh SEE ALSO
