home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / cobol / 690 < prev    next >
Encoding:
Text File  |  1993-01-25  |  3.2 KB  |  69 lines
  1. Newsgroups: alt.cobol
  2. Path: sparky!uunet!pipex!mfmail!jfid
  3. From: jfid@mfltd.co.uk (James Fidell (x5320))
  4. Subject: Re: cobol
  5. Message-ID: <1993Jan25.120413.24471@mfltd.co.uk>
  6. Sender: jfid@mfltd.co.uk (James Fidell (x5320))
  7. Organization: Micro Focus Ltd., Newbury, UK
  8. References: <1993Jan13.4605.763@dosgate> <1jm43fINN8rv@mirror.digex.com> <1993Jan21.133510.4271@mfltd.co.uk> <9302421.22722@mulga.cs.mu.OZ.AU>
  9. Date: Mon, 25 Jan 1993 12:04:13 GMT
  10. Lines: 57
  11.  
  12.  
  13. In article <9302421.22722@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  14. > jfid@mfltd.co.uk (James Fidell (x5320)) writes:
  15. > 
  16. > >In fact, the Micro Focus COBOL compiler (and many of the other tools) *are*
  17. > >written in COBOL.  (Yes, I was gob-smacked when I found out as well :-). I
  18. > >do believe you'd have to be a masochist to want to do it, but then again,
  19. > >the compiler ports to just about any system first time, which is more than
  20. > >can be said for the C runtime.
  21. > 
  22. > The difference is due to the nature of the tasks, not the languages used
  23. > to implement them. It would be easy enough to write a completely portable
  24. > compiler in C.
  25.  
  26. I agree, in principle.  The ease and speed with which characters and small
  27. numbers can be manipulated in C are far greater than that of COBOL, thus
  28. lexical and syntactic analysis will be faster.  Pointers are another area
  29. where C benefits greatly -- I really wouldn't want to try to implement a
  30. parse tree in COBOL.
  31.  
  32. However, my experience on 40+ different machines running different flavours
  33. of UNIX and different C compilers makes me skeptical about how easy it is
  34. to write truly portable C.  Of course, ANSI, POSIX et al will probably go
  35. a long way towards sorting this out.
  36.  
  37. In comparison, the COBOL compiler, which is delivered to my own group in
  38. interpreted code (we don't even get to see the source unless we ask for it)
  39. runs first time on just about any platform.
  40.  
  41. > Is the Micro Focus COBOL compiler actually written and compiled in Micro
  42. > Focus COBOL?
  43.  
  44. Yes it is.  However, the interpreted code is not what is delivered as the
  45. final product -- we use a code generator (which is also written in COBOL,
  46. and part of the final product) to turn the interpreted code into something
  47. which is very similar to a linkable object file (in fact, the generator can
  48. produce these too).  These then make calls to the runtime interpreter to
  49. provide support for things which are not easy or worthwhile doing in the
  50. actual object (screen and file io, for instance).
  51.  
  52. > That would make it fairly inefficient. (I'm presuming from
  53. > what you said above that Micro Focus uses a runtime interpreter.)
  54.  
  55. I have no idea of how this compares to C in terms of efficiency, but I
  56. believe that the greatest loss is in providing a mechanism for C and COBOL
  57. to be able to understand each other's datatypes.
  58.  
  59. > -- 
  60. > Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  61. > This .signature virus is a self-referential statement that is true - but 
  62. > you will only be able to consistently believe it if you copy it to your own
  63. > .signature file!
  64. -- 
  65.  "Yield to temptation --             |
  66.   it may not pass your way again"    |     jfid@mfltd.co.uk
  67.                                      |
  68.         - Lazarus Long               |              James Fidell
  69.