home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3947 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.0 KB
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ukulele!eaker
  2. From: eaker@ukulele.crd.ge.com (Chuck Eaker)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: CASE tools
  5. Message-ID: <1993Jan21.153746.2948@crd.ge.com>
  6. Date: 21 Jan 93 15:37:46 GMT
  7. References: <1jl4guINN4c4@usenet.INS.CWRU.Edu>
  8. Sender: eaker@ukulele (Chuck Eaker)
  9. Organization: GE Corporate R&D Center
  10. Lines: 34
  11. Nntp-Posting-Host: ukulele.crd.ge.com
  12.  
  13. In article <1jl4guINN4c4@usenet.INS.CWRU.Edu>, cq184@cleveland.Freenet.Edu (Spencer W. Hunter) writes:
  14. |> ...
  15. |> In his book, Martin outlines a CASE methodology, known as HOS,
  16. |> wherein programs are constructed top-down and the compiler
  17. |> statically verifies the validity of each control structure
  18. |> through I/O analysis.  In contrast, traditional Forth programs
  19. |> are mostly constructed bottom-up and the programmer is
  20. |> responsible for dynamically testing individual routines for
  21. |> correctness.  However, like good Forth, each HOS routine has only
  22. |> one main control structure; this is an inevitable result of the
  23. |> rigidity of the compiler.
  24.  
  25. I don't agree that the traditional Forth development approach
  26. is bottom-up. This is certainly not the approach illustrated
  27. in Brodie's _Thinking_Forth_.
  28.  
  29. |> What does the Forth community think not only about the above, but
  30. |> of CASE tools in general?  Enquiring minds want to know!
  31.  
  32. I think it's an interesting application area. What the world
  33. needs is more and better ways to model and simulate an
  34. application's requirements, do various kinds of analyses on
  35. the model, then generate code for specific platforms in ways
  36. that yield implementations provably equivalent to the model.
  37.  
  38. It seems to me that what you have goes the other way: a
  39. language which is used to model implementations (i.e., Forth
  40. code must be translated into the modeling language) so that
  41. analysis will show them to be correct. But in this case I'm
  42. not sure what "correct" means?
  43.  
  44. -- 
  45. Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
  46. eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
  47.