home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / specific / 534 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.8 KB  |  81 lines

  1. Newsgroups: comp.specification
  2. Path: sparky!uunet!mcsun!sunic!dkuug!daimi!pdm
  3. From: pdm@daimi.aau.dk (Peter D. Mosses)
  4. Subject: Re: Semantic definition style
  5. In-Reply-To: "Ian Sutherland" <p00117@psilink.com>
  6. Message-ID: <1992Nov16.104205.3842@daimi.aau.dk>
  7. Summary: semantics can be first-order
  8. Keywords: semantics, first-order, higher-order, actions
  9. Sender: pdm@daimi.aau.dk (Peter D. Mosses)
  10. Reply-To: pdm@daimi.aau.dk (Peter D. Mosses)
  11. Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
  12. References: <2930740056.0.p00117@psilink.com>
  13. Date: Mon, 16 Nov 92 10:42:05 GMT
  14. Lines: 65
  15.  
  16. In article <2930740056.0.p00117@psilink.com>, "Ian Sutherland" <p00117@psilink writes:
  17. >Peter Mosses writes:
  18. >>In article <1992Nov11.195443.23006@cis.ohio-state.edu>, ogden@seal (William F Ogden) writes:
  19. >>>operational semantics produce a
  20. >>>welter of irrelevant information (computational histories), from which the
  21. >>>essential information (the input/output pairs, in the case of sequential
  22. >>>programs) must be extracted. 
  23. >>
  24. >>But the denotations of statements, declarations, etc., are not I/O
  25. >>relations!  They necessarily deal with *auxiliary* entities, such as
  26. >>environments and stores, whose relevance to particular implementations
  27. >>is not nearly so direct as that of the I/O relation.
  28. >
  29. >I don't think the original poster meant "input/output" to refer simply 
  30. >to what, say, an OS designer would call "input/output".  Certainly those 
  31. >who design denotational definitions do not so limit themselves.  Both 
  32. >"input" and "output" usually include the memory and the environment.
  33.  
  34. Regarding a semantic description as a requirements specification for
  35. implementations, it seems to me that the denotational semantics of an
  36. entire program should indeed be a function from OS inputs to OS
  37. outputs (at least when assuming batch I/O and determinism).
  38.  
  39. >>>Now algebraic semantics would seem to be predicated on the dubious
  40. >>>proposition that computation is entirely describable within a limited
  41. >>>first-order subarea of mathematics -- namely algebra.
  42. >>
  43. >>- which can specify Turing machine computations, and hence is
  44. >>universal.
  45. >
  46. >But Turing machines are only "universal" in exactly the sense you took 
  47. >issue with above, namely, they are universal in the sense that they can 
  48. >produce any recursive input/output function.  I don't think Turing 
  49. >machine COMPUTATION (reading/writing head moving back and forth, reading 
  50. >and writing symbols on individual squares and changing internal state) 
  51. >is in some sense a universal model of computational PROCESSING.  Does 
  52. >anyone know otherwise?
  53.  
  54. I wasn't advocating the use of Turing machines in semantics!  I was
  55. reacting against the suggestion that there is something essentially
  56. *higher-order* about computation and the semantics of programming
  57. languages.  In my view, first-order approaches are quite adequate.
  58. (Action semantics is, as you might have guessed by now, first-order.
  59. However, it provides notation for going back and forth between actions
  60. and corresponding data items; this is analogous to an isomorphism
  61. between [D->D] and D in domain theory.)
  62.  
  63. Perhaps the notion of *action* used in action semantics comes close to
  64. what you'd call a `universal model' of processing?  It encompasses the
  65. conventional functional, imperative, and concurrent paradigms of
  66. computation.  However, there are certainly some forms of computation
  67. (e.g., interrupts, general continuation-handling) that it doesn't
  68. support directly.  And even if one incorporated those, programming
  69. language designers could presumably come up with new ones...
  70.  
  71. >---
  72. >Ian Sutherland
  73. >ian@eecs.nwu.edu
  74. >
  75. >Sans Peur
  76. -- 
  77. Peter D. Mosses | Computer Science Department | <pdmosses@daimi.aau.dk> 
  78. ~~~~~~~~~~~~~~~ | Aarhus University           | Phone: +45 86 12 71 88 
  79.                 | Ny Munkegade, Building 540  | Fax:   +45 86 13 57 25 
  80.                 | DK-8000 Aarhus C,  Denmark  | Telex: 64767 aausci dk
  81.