home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / parallel / 1780 < prev    next >
Encoding:
Text File  |  1992-07-23  |  1.7 KB  |  45 lines

  1. Newsgroups: comp.parallel
  2. Path: sparky!uunet!gatech!hubcap!fpst
  3. From: Steven Zenith <zenith@kai.com>
  4. Subject: Re: CSP to STRAND/Parlog
  5. Message-ID: <1992Jul23.134920.4944@hubcap.clemson.edu>
  6. Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
  7. Organization: Clemson University
  8. Date: Wed, 22 Jul 1992 10:15:31 -0500
  9. Approved: parallel@hubcap.clemson.edu
  10. Lines: 33
  11.  
  12. In article <1992Jul20.075511.17628@dcs.qmw.ac.uk>, mmh@cs.qmw.ac.uk
  13. Matthew Huntbach writes:
  14.  
  15. > If you think that Strand or Parlog are basically
  16. > "parallel Prologs", you are completely wrong. Many people who
  17. > program in them, such as myself, think of them more in CSP-like
  18. > terms than in Prolog-like terms.
  19.  
  20. I'm pleased to hear it, I don't dispute that a parallel between CSP and
  21. Strand or Parlog can be drawn - but you don't answer my question: why is the
  22. parallel between committed choice concurrent logic languages closer than any
  23. other (say, CSP and functional or concurrent imperative languages)?
  24.  
  25. > >> In fact
  26. > >> part of my current work is considering methods of translating
  27. > >> from CSP to Strand/Parlog,
  28.  
  29. > ... What's the rationale here?
  30. > I would have thought the usefulness of the
  31. > transformation is obvious.
  32.  
  33. It wasn't clear from your earlier posts that execution was your primary
  34. interest. I'm still not sure that if I was considering a target language for
  35. the execution of CSP scripts that STRAND or Parlog would be a good choice. So,
  36. we should clarify what you are interested in when executing CSP scripts. Is
  37. performance an important issue? Behavioral correctness? Perhaps you are
  38. deriving something from the execution of the program that you can't derive
  39. from static analysis? etc..
  40.  
  41. Steven Ericsson Zenith
  42. Disclaimer: Opinions expressed are my own and not necessarily those of KAI.
  43.  
  44.