From owner-freebsd-hackers Fri Dec 6 17:03:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21693 for hackers-outgoing; Fri, 6 Dec 1996 17:03:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA21684 for ; Fri, 6 Dec 1996 17:03:36 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA24762; Fri, 6 Dec 1996 17:43:29 -0700 From: Terry Lambert Message-Id: <199612070043.RAA24762@phaeton.artisoft.com> Subject: Re: Yacc -p is broken To: rb@gid.co.uk (Bob Bishop) Date: Fri, 6 Dec 1996 17:43:28 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: from "Bob Bishop" at Dec 6, 96 09:59:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >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 ... . " 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.