home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / compiler / 2250 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.3 KB  |  55 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!world!iecc!compilers-sender
  3. From: swl26@cas.org (Steve Layten x3451)
  4. Subject: justify use of flex vs lex
  5. Reply-To: swl26@cas.org (Steve Layten x3451)
  6. Organization: Compilers Central
  7. Date: Mon, 25 Jan 1993 14:48:49 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <93-01-178@comp.compilers>
  10. Keywords: flex, lex, question, comment
  11. Sender: compilers-sender@iecc.cambridge.ma.us
  12. Lines: 41
  13.  
  14. I need to use flex instead of lex for a job I have that exceeds capacities
  15. of some lex features.  I want to put this into a "production" job stream,
  16. and our current "standards" seem to discourage use of public-domain code
  17. in production, the standard managment argument being that we should use
  18. vendor-supported code so we don't have to spend time maintaing the code
  19. ourselves.  I must justify the use of this "non-supported" code in
  20. production.
  21.  
  22. I would appreciate hearing comments from this community regarding
  23. arguments for or against the use of flex vs. the vendor-supplied lex.
  24. Some additional considerations which I think are important are:
  25.  
  26.    Support across multiple platforms/environments - flex can be ported to
  27.    all of the environments we use, and thus we would be sure to have a
  28.    consistent environment.
  29.  
  30.    Fewer constraints or "limits" built in.
  31.  
  32.    I believe that support for flex is "better" than most vendors; how many
  33.    in this list would say that UNIX vendors focus much time or effort in
  34.    keeping their "lex" up to date and bug-free?
  35.  
  36. Feel free to respond via e-mail or to the group.  I'll summarize e-mail
  37. esponses if appropriate, so please indicate in any private communication
  38. if you wish that it not become public.
  39.  
  40. Thank you for your time.
  41.  
  42. Steve Layten
  43. --
  44. Steven W. Layten, Senior Engineer
  45. Chemical Abstracts Service, PO Box 3012, Columbus, OH 43210    +1 614 447 3600
  46. INET: swl26@cas.org         BITNET: swl26@cas      UUCP: osu-cis!chemabs!swl26
  47. [The reality is that lex is still riddled with bugs after over 15 years of
  48. alleged vendor support, while flex is nearly bug-free.  When revising
  49. O'Reilly's lex&yacc, I found many lexers needed fiddling to work around lex
  50. bugs, a few I couldn't get to work at all with lex.  They all work with flex.
  51. -John]
  52. -- 
  53. Send compilers articles to compilers@iecc.cambridge.ma.us or
  54. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  55.