home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.edu
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sdd.hp.com!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!math.zko.dec.com!edp
- From: edp@math.zko.dec.com (Eric Postpischil)
- Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
- Message-ID: <1992Sep8.204155.2983@nntpd.lkg.dec.com>
- Sender: usenet@nntpd.lkg.dec.com (USENET News System)
- Reply-To: edp@math.zko.dec.com (Eric Postpischil)
- Organization: Digital Equipment Corporation
- References: <1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.GOV>
- Distribution: na
- Date: Tue, 8 Sep 1992 20:41:55 GMT
- Lines: 25
-
- In article <135691@lll-winken.LLNL.GOV>, blair@lll-crg.llnl.gov (Gary
- Blair) writes:
-
- >Wrong. If your compiler uses ANY kind of table-driven parsing scheme, it is
- >next to impossible to allow programmer-defined operators. The parser must
- >know what an operator looks like, and what precedence it has with respect
- >to all other operators. This is usually predetermined, at
- >compiler-generation time.
-
- Nah, it's trivial. You do the operator recognition in the lexical
- analyzer, which then passes a token of type "operator" to the parser.
- Thus, a program would declare the operator. The compiler stores
- knowledge about the operator in some data structure. From then on, the
- analyzer recognizes the operator as an operator from the knowledge in
- the data structure.
-
- Handling precedence is a bit trickier. But if you are willing to stick
- with a number of levels determined at compiler-generation time (by
- encoding them into the grammar), it's trivial to give any operator any
- precedence at compile time.
-
-
- -- edp (Eric Postpischil)
- "Always mount a scratch monkey."
- edp@alien.enet.dec.com
-