home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0017.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  2.0 KB  |  39 lines
  1. Submitted-by: sjc@borland.com (Steve Correll)
  2.  
  3. In article <1991Nov25.002551.10887@uunet.uu.net> henry@zoo.toronto.edu (Henry Spencer) writes:
  4. >..."how many people here have implemented 1003.2 regular expressions
  5. >from scratch straight from the spec?".  Based on the number of problems I
  6. >found in the spec when I did the syntactic part of this a couple of months
  7. >ago, I am quite certain that none of the people involved had ever tried it.
  8. >I found, and reported, half a dozen serious problems in a spec that was
  9. >supposed to be very near its final state.  And this, mind you, was in
  10. >a fairly well-understood area with a lot of existing practice to draw on.
  11.  
  12. Perhaps Unix is none of my business, but people in the Fortran community have
  13. just watched the ANSI X3J3 committee make the mistake of standardizing a
  14. painstakingly designed but unimplemented language, and consequently the
  15. Fortran 90 standard is full of outright bugs and missing provisions.
  16.  
  17. For example, Fortran 90 introduces a construct which is comparable to a C
  18. prototype declaration. One would like to write a tool which would generate
  19. such prototypes automatically for every Fortran procedure, which would be much
  20. less error-prone than generating prototypes by hand or doing without them.
  21.  
  22. If someone had actually written such a program and tried it out on real,
  23. existing applications prior to adoption of the standard, they would have
  24. immediately found a bug in the standard which for certain procedures makes it
  25. impossible to write a legal prototype at all.
  26.  
  27. Unless you believe that a sufficiently large group of programmers can write
  28. bug-free programs without ever testing them, it's folly to write a standard
  29. without testing it. Specifications of standards are, if anything, harder to
  30. write than actual programs.
  31.  
  32. I think one of the greatest strengths of the ANSI C committee was its
  33. reluctance to incorporate new features unless somebody could point to an
  34. existing implementation with a history of user satisfaction.
  35.  
  36.  
  37. Volume-Number: Volume 26, Number 18
  38.  
  39.