Date: Fri, 6 Dec 1996 17:43:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rb@gid.co.uk (Bob Bishop) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: Yacc -p<NAME> is broken Message-ID: <199612070043.RAA24762@phaeton.artisoft.com> In-Reply-To: <v01540b01aece468c5e17@[194.32.164.2]> from "Bob Bishop" at Dec 6, 96 09:59:34 pm
index | next in thread | previous in thread | raw e-mail
> >In any case, with all the non-static globals, it's inlikely that > >you could safely use multiple lexers in the same program without > >seriously fixing lex. > > True, but you don't need to; as I said in my previous reply you can run a > lexer multiple times. If you want different lex rules for different phases > (I've usually found that most are common), you can use a state variable and > REJECT. > > [In case you missed it, in my last reply I was talking about multiple > grammars not multiple parsers.] This works well for combined encapsulation. Seperable encapsulation is a different story. Consider: I have a C++ class RFC821_class. When an SMTP connection comes in, I instantiate a class memebr object. When data becomes available, I call a parse_data method from the class. RFC821 data streams encapsulate RFC822 data streams. For Internet use of RFC821, this is a definition. Specifically, the RFC821 machine needs to provide "Received:" and "From" header items, at a minimum. At a maximum, it needs to supply "Apparently-To:" and "X-Authentication-Warning:" headers to be written with the saved RFC822-encapsulated message. For RFC822, I have a C++ class RFC822_class. The RFC822_class is subclassed from a virtual base class supporting "additiona header items". The RFC822_class is subclassed from the same class, and can therfore reference the "additional header items" class contents from the RFC821_class parent class object as if the RFC821_class object were of type "additional header items" class. When an SMTP connection comes in, I instantiate an RFC821_class object and then and RFC822_class object. In doing so, I replace the RFC821_class data_disposition interface such that data coming in via the "DATA <CR> ... <CR> . <CR>" is passed to the RFC822_class for RFC822 parsing. This is combined encapsulation. Now consider: I may wish to use the RFC822_class in an MUA as well as the MTA use I just described. In that case, the RFC822_class is *not* subclassed on the RFC821_class object: there is *no* RFC821_class object for that to happen (obviously, "additional header items" must be a virtual base class). Because of this, the RFC821_parse and RFC822_parse functions (implemented by a class specific yyparse()) must be seperate. This is seperable encapsulation. I haven't even gotten into MIME encapsulation, and use of content transfer encoding "quoted-printable" to replace a leading "From" in a mailbox with "=46rom" instead of ">From" or " From", either of which might screw up PGP authentication, or parsing for other reasons. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612070043.RAA24762>