Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Nov 1996 14:55:33 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        jkh@time.cdrom.com (Jordan K. Hubbard)
Cc:        terry@lambert.org, hackers@freebsd.org
Subject:   Re: Lex/Yacc question
Message-ID:  <199611282155.OAA01125@phaeton.artisoft.com>
In-Reply-To: <11590.849149149@time.cdrom.com> from "Jordan K. Hubbard" at Nov 27, 96 06:45:49 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > PS: Why isn't there a Lex or Yacc FAQ?
> 
> Because they both have more than ample manuals in the 4.4 doc set?  I
> dunno - I never really saw a need for FAQs, and I've written quite a
> few parsers (including the entire parser for an ANSI C interpreter I
> wrote a few years back).  It's very straight-forward to use both tools
> if you understand the basics of parser operation, and if you don't
> think you probably don't really need to use Lex and Yacc anyway. ;-)

I've written a number of parsers, too.  Nonen of them needed:

	KEYWORD rest of stuff to end of line

Like the "HELO" keyword in RFC821 requires...:

-------
telnet smtp.lambert.org smtp
Trying 137.190.16.16...
Connected to smtp.lambert.org.
Escape character is '^]'.
220 smtp.lambert.org Sendmail 4.1/SMI-4.1.1 ready at Thu, 28 Nov 96 14:52:19 MST
helo foo foo foo
250 smtp.lambert.org Hello foo foo foo (host.lambert.org), pleased to meet you
quit
221 smtp.lambert.org closing connection
Connection closed by foreign host.
-------

This is for historical compatability with hand-coded RFC821 parsers,
implemented as a C++ encapsulation class for an RFC821 transport
subclassed from a transport facility:

class RFC821_channel : protected Transport {
		enum {	STATE_PENDING,		// no connection
			STATE_READY,		// connected, no HELO/EHLO
			STATE_HELLO, 		// seen HELO
			...
		};
	private:
		int	state;		/* current command state*/
	public:
		...
};

Then I subclass TCP/IP, NITS, X.25, etc. from this...

The RFC822 is an envelope parsing (input), cannonizaton (output)
mechanism.

RFC1341/RFC1342 is a subclass of the RFC822 envelope class for formatting
the body pointed to by the envelope class using RFC822 envelope header
items... ie:

	MIME-Version: 1.0
	Content-type: audio/basic
	Content-transfer-encoding: base64  

The "MIME-Version:" header from 1341 also needs "text to end of line"
recognition.  I'm not working on an RFC1341 lexing/grammar (yet).


I'm astonished that no one has done this all before.  It seems so obvious...


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611282155.OAA01125>