home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / compiler / 1555 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  16.1 KB

  1. Xref: sparky comp.compilers:1555 comp.theory:1927
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!faatcrl!iecc!compilers-sender
  3. From: aet@mullian.ee.mu.OZ.AU (bert thompson)
  4. Newsgroups: comp.compilers,comp.theory
  5. Subject: COMPILERS FROM DENOTATIONAL SEMANTICS: SUMMARY
  6. Keywords: denotational semantics, summary, bibliography
  7. Message-ID: <92-09-078@comp.compilers>
  8. Date: 15 Sep 92 06:25:53 GMT
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: aet@mullian.ee.mu.OZ.AU (bert thompson)
  11. Organization: Computer Science, University of Melbourne, Australia
  12. Lines: 372
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. Hi!
  16.  
  17. A number of people have asked me to summarize the responses I've received
  18. on the topic of producing interpeters and compilers directly from a
  19. language's denotational semantic definition. 
  20.  
  21. There are some interesting responses that I have not included because I
  22. haven't received an ok to post.
  23.  
  24. Some of the ideas suggested include writing the denotational description
  25. directly in a lazy functional language such as Haskell. (In fact someone
  26. even sent such a realization in Gofer for a small language --
  27. unfortunately not included in this summary.)
  28.  
  29. Another idea is the automatic generation of compilers from interpreters
  30. using a self-applicable partial evaluator. some such partial evaluators
  31. I've heard of are Similix, Schism and Mix. (of these, I think Mix is the
  32. only one that is strongly-typed -- please correct me if I'm wrong.)
  33.  
  34. Thanks to everyone who replied!
  35.  
  36. Here are the responses:
  37.  
  38. --------------------------------------------------------------------------------
  39.  
  40. Reply-To: davidm@ctbu.rational.com (David Moore)
  41.  
  42. I do not know about tools specifically. There was an article on April TOPLAS
  43. that is in this area: A Self-Applicable Partial Evaluator for the
  44. Lambda Calculus:Correctness and Pragmatics. Carsten A Gomard.
  45. acm Transactions on Programming Languages and Systems, Vol 14 No 2 pp 147-172
  46. --------------------------------------------------------------------------------
  47. From cailm@cs.tamu.edu Wed Sep  9 04:42:40 1992
  48.  
  49. Hi, there, to my knowledge, there is a tool called Navel developed in UK
  50. which can accept denotational description of a language and produce a
  51. n interpreter for the language. The tool could only deal with context-free
  52. semantics and then was improved by some Chinese to accept context-sensitive
  53. semantics using attributed-grammar technique. For more information, you may
  54. contact: 
  55.     Prof. Lin Xing-Liang
  56.     Tsinghua Univ.
  57.     Beijing 100084
  58.     P.R.China
  59.  
  60.     Dr. Greg Michealson
  61.     Dept of Computing
  62.     Heriot-watt Univ.
  63.     Edinburgh, UK
  64.     greg@cs.heriot-watt.ac.uk
  65.  
  66. good luck,
  67.  
  68. Liming Cai
  69. --------------------------------------------------------------------------------
  70. Reply-To: loegel@fegatello.ssc.gov (George Loegel)
  71.  
  72. There was a system developed about 1980 by Peter Mosses (Aahrus Univ)
  73. that accepted a denotational semantic description of a language and
  74. produced an interpreter for it. The system is called SIS (Semantic
  75. Implementation System) and is described in Bodwin, J. et.al.
  76. "Experience with an experimental compiler generator based on
  77. denotational semantics" 1982 SIGPLAN Symposium on Compiler
  78. Construction, SIGPLAN Notices 17,6 (1982)
  79. --------------------------------------------------------------------------------
  80. Reply-To: "Jeffrey V. Cook" <jvc@la.TIS.COM>
  81.  
  82. I don't know if this is what you want, but I have written a free tool in
  83. Common Lisp that produces a Common Lisp IMPLEMENTATION of a denotational
  84. semantic specification of a computer language.  This tool is called JADDS
  85. (Jeff's Automated Denotational Definition System).  It has an internal
  86. Lisp-like language that lets you define abstract syntax and specify
  87. denotational semantic equations based on abstract syntax, and also lets you
  88. define auxiliary functions.  The tool allows one to generate LaTeX
  89. pretty-printed files holding the semantic definitions, for inclusion in
  90. reports that discuss the semantics.  It also permits the generation of a
  91. semantic implementation, by implementing the denotational semantic
  92. specification in Common Lisp.  A semantic implementation, when applied to an
  93. abstract syntax tree for a program, generates the denotation specified in the
  94. semantics.  If the denotations generated are in machine language, then you
  95. have a formal implementation of a compiler.
  96.  
  97. Now, if you are talking about generating an interpreter or a compiler from a
  98. denotational semantic specification whose denotations are more abstract, this
  99. is a totally different sort of problem.
  100. --------------------------------------------------------------------------------
  101.  
  102. Reply-To: mmcg@bruce.cs.monash.edu.au (Mike  Mc Gaughey)
  103.  
  104. It's relatively straightforward to translate denotational semantics
  105. into a program in a lazy functional language (aka LML, haskell),
  106. assuming you haven't buggered up the types in the DS definition (if you
  107. _do_ want type-free DS, translate into lisp instead).  It would
  108. probably take an afternoon or two to write such a tool in lex & yacc.
  109. LML, yacc, and lisp compilers are generally free.
  110.  
  111. I write my semantics directly in LML, usually.
  112. --------------------------------------------------------------------------------
  113.  
  114. Reply-To: Greg Michaelson <greg@cs.heriot-watt.ac.uk>
  115.  
  116. Hi! I built a system some years ago which given a grammar and semantic functions
  117. implements an interpreter for the defined language.
  118. --------------------------------------------------------------------------------
  119.  
  120. Reply-To: "Ramakumar Kosuru" <kosuru@point.cs.uwm.edu>
  121.  
  122.  
  123.  Peter lee's Realistic Compiler geneartion should be a big help to you. 
  124. Call no: QA 76.76 C 65 L 44.
  125.  
  126. Hope this helps.
  127.  
  128. Ram
  129. --------------------------------------------------------------------------------
  130.  
  131. Reply-To: chapnerk@bambi.WG.WAII.COM (Asha V. Chapnerkar)
  132.  
  133. Bert,
  134.  
  135. There is a system known as SPS that is described in the
  136. paper below that does exactly what you are looking
  137. for:
  138.    Wand, Mitchell, "A Semantic Prototyping System",
  139.    Proceeding of the 1984 SIGPLAN Symposium on 
  140.    Compiler Construction, 1984, pp. 158-164.
  141.  
  142. It takes a denotational definition, written
  143. in Scheme, and gives you an interpreter for the 
  144. language.
  145.  
  146. Dr. Asha V. Chapnerkar
  147. --------------------------------------------------------------------------------
  148. Reply-To: nehaniv@math.berkeley.edu (Chrystopher L. Nehaniv)
  149.  
  150. Take a look at the book "Compiler Generators" by Mads Tofte. I believe it
  151. has some material relevant to denotational semantics and compiler
  152. generators (in particular the compiler generator CERES which he and others
  153. developed). This book is EATCS 19 Monographs on THeoretical Computer
  154. Science, published by Springer Verlag 1990. [The silver books with 3 red
  155. stripes across the top].
  156.  
  157. Cheers,
  158.  
  159. Chrystopher Nehaniv
  160. --------------------------------------------------------------------------------
  161.  
  162. Reply-To: thiemann@informatik.uni-tuebingen.de (Peter Thiemann)
  163.  
  164. Several people are working on this:
  165. - Jens Palsberg (generates SPARC code from action notation) see IEEE
  166. International Conf. on Computer Lang.'92
  167. - Mikael Peterson, see also ICCL92
  168. - There is a group in Glasgow that also uses action notation, I think
  169. it is headed by D. Watts, PLILP92 has a system description of an
  170. interpreter, at least.
  171.  
  172. Sorry for not being more explicit, I don't have the refs at hand.
  173.  
  174. Cheers, Peter
  175. --------------------------------------------------------------------------------
  176.  
  177. Reply-To: Frank Silbermann <fs@rex.cs.tulane.edu>
  178.  
  179.  
  180. You might try to contact Uwe F. Pleban or Peter Lee who wrote about it.
  181. My addresses may be out of date, though.
  182. In 1988, Pleban was at uwe%tekchips.tek.com@relay.cs.net,
  183. and Lee was at Peter.Lee@cs.cmu.edu.
  184.  
  185. --------------------------------------------------------------------------------
  186.  
  187. Reply-To: wilson@mailhost.aa.cad.slb.com (David Wilson)
  188.  
  189. Try to track down Peter Lee at Carnegie Mellon.  I think he is at least an
  190. assistant prof by now.  I worked with him when he was just a summer
  191. programmer while still in school.  I know his dissertation was along the
  192. lines of what you're looking for.  Also, the last MIT Press catalog I saw
  193. had a book or two on the subject authored (or maybe just edited) by him.
  194.  
  195. Sharpest kid I've ever run into.  If what you want is available, he will
  196. know.  (He's not a kid anymore -- it was a dozen years ago when he worked
  197. here).
  198.  
  199. Dave Wilson
  200. --------------------------------------------------------------------------------
  201.  
  202.  
  203. Reply-To: Greg Michaelson <greg@cs.heriot-watt.ac.uk>
  204.  
  205. G.Michaelson, `Interpreters from functions & grammars', Computer
  206. Languages, Vol. 11, No. 2, pp. 85-104, 1986
  207.  
  208. G.Michaelson, `Interpreter prototypes from language definition style
  209. specifications', Information & Software Technology, Vol. 30, No. 1,
  210. pp. 23-31, 1988
  211.  
  212. G.Michaelson, `Text generation from grammars', Information and
  213. Software Technology, Vol. 32, No. 8, pp 566-568, October 1990
  214.  
  215. ------------------------------------------------------------------------
  216.  
  217.  
  218.  
  219.  
  220.         References
  221.  
  222.         1.   L.  Allison,  A  practical   introduction   to   denotational
  223.              semantics, CUP, (1986).
  224.  
  225.         2.   R. Bahlke and G. Snelting,  "The  PSG  -  Programming  System
  226.              Generator,"  SIGPLAN Notices, Vol. 20, (7), pp. 28-33, (July,
  227.              1985).
  228.  
  229.         3.   R. Bahlke and G.  Snelting,  "The  PSG  system:  from  formal
  230.              language     definitions     to    interactive    programming
  231.              environments," ACM Transactions on Programming Languages  and
  232.              Systems, Vol. 8, (4), pp. 547-576, (October, 1986).
  233.  
  234.         4.   D. Bjorner, C. B. Jones, and (Eds.), The  Vienna  Development
  235.              Method: the metalanguage, LNCS 61, Springer Verlag, (1978).
  236.  
  237.         5.   D.  Bjorner,  "Rigorous  development  of   interpreters   and
  238.              compilers," in Formal specification and software development,
  239.              ed. D. Bjorner & C.  B.  Jones,  pp. 271-320,  Prentice-Hall,
  240.              (1982).
  241.  
  242.         6.   J. Bodwin, L. Bradley, K. Kanda, D. Little,  and  U.  Pleban,
  243.              "Experience  with an experimental compiler generator based on
  244.              denotational  semantics,"  SIGPLAN  Notices:  Proceedings  of
  245.              SIGPLAN'82  Symposium on Compiler Construction, Vol. 17, (6),
  246.              pp. 216-229, (June, 1982).
  247.  
  248.         7.   S-J. Chao  and  B.  R.  Bryant,  Denotational  semantics  for
  249.              program analysis, pp. 83-91, ??? ACM ???, (???).
  250.  
  251.         8.   I. Cottam, "discussed in  'Workshop  on  Software  Tools  for
  252.              Formal Methods'," FACS FACTS, Vol. 8, (2), (February, 1986).
  253.  
  254.         9.   H.  Ganzinger,  "Some  principles  for  the  development   of
  255.              compiler     descriptions    from    denotational    language
  256.              definitions,"  TUM-I8006,  Technische  Universitat   Munchen,
  257.              (May, 1980).
  258.  
  259.         10.  C. B. Jones, "Compiler design," in Formal  specification  and
  260.              software  development, ed. D. Bjorner & C. B. Jones, pp. 253-
  261.              269, Prentice-Hall, (1982).
  262.  
  263.         11.  N. D. Jones and D.  A.  Schmidt,  "Compiler  generation  from
  264.              denotational   semantics,"  in  Semantics  directed  compiler
  265.              generation, ed. N. D. Jones, pp. 70-93,  LNCS  94,  Springer-
  266.              Verlag, (1980).
  267.  
  268.         12.  P.  Jouvelot,  Designing  new  languages  or   new   language
  269.              manipulation   systems   using  ML,  21,  pp. 40-52,  SIGPLAN
  270.              Notices, (August, 1986).
  271.  
  272.         13.  H.  A.  Klaeren  and  H.  Petzsch,  The  development  of   an
  273.              interpreter   by   means   of   abstract  algebraic  software
  274.              specifications, Lehrstuhl fur  Informatik  II,  RWTH  Aachen,
  275.              (???).
  276.  
  277.         14.  R. E. Milne and C. Strachey, A theory of programming language
  278.              semantics, Chapman and Hall, (1976).
  279.  
  280.         15.  G. O'Neill, "Automatoc translation of VDM specifications into
  281.              Standard   ML   programs,"  DITC  196/92,  National  Physical
  282.              Laboratory, (February, 1992).
  283.  
  284.         16.  L.   Paulson,   "Compiler   generation   from    denotational
  285.              semantics,"  in  Methods and tools for compiler construction,
  286.              ed. B. Lohro, pp. 219-250, CUP, (1984).
  287.  
  288.         17.  L. Paulson,  A  compiler  generator  for  semantic  grammars,
  289.              Department   of   Computer   Science,   Stanford  University,
  290.              (December, 1981).  PhD Thesis .
  291.  
  292.         18.  U. F. Pleban, "Compiler prototyping using formal  semantics,"
  293.              SIGPLAN  Notices: Proceedings of the AC_M SIGPLAN'84 Symposium
  294.              on Compiler Construction, Vol. 19,  (6),  pp. 94-105,  (June,
  295.              1984).
  296.  
  297.         19.  M. Rakovsky and P. Collier, "From standard to  implementation
  298.              denotational   semantics,"  in  Semantics  directed  compiler
  299.              generation, ed. N. D. Jones, pp. 94-139, LNCS  94,  Springer-
  300.              Verlag, (1980).
  301.  
  302.         20.  V.  Royer,  "Transformations  of  denotational  semantics  in
  303.              semantics   directed   compilers,"  SIGPLAN  Notices:  ?????,
  304.              Vol. 21, (7), p. ?????, (July, 1986).
  305.  
  306.         21.  K. Slonneger, Denotational Semantics in Prolog, University of
  307.              Iowa, (1990).
  308.  
  309.         22.  S.  Stepney,  D.  Whitley,  D.  Cooper,  and  C.  Grant,   "A
  310.              demonstrably  correct compiler," Formal Aspects of Computing,
  311.              Vol. 3, (1), pp. 58-101, (Jan-March 1991).
  312.  
  313.         23.  J.  E.  Stoy,  Denotational  Semantics:  the   Scott-Strachey
  314.              approach to programming language theory, MIT, (1977).
  315.  
  316.         24.  M. Takeichi,  Inserting  inject  operations  to  denotational
  317.              semantics, 4, pp. 365-381, New Generation Computing, (1986).
  318.  
  319.         25.  M. Tofte, Compiler generators, Springer-Verlag, (1990).
  320.  
  321.         26.  M. Wand, "A semantic prototyping  system,"  SIGPLAN  Notices:
  322.              Proceedings   of   the  SIGPLAN  '84  Symposium  on  Compiler
  323.              Construction, Vol. 19, (6), pp. 213-221, (June, 1984).
  324.  
  325. --------------------------------------------------------------------------------
  326. The GIPE group at CWI has a system that uses initial algebra specification, 
  327. called ASF+SDF, described in:
  328.  
  329.     J. A. Bergstra, J. Heering, and P. Klint (eds),
  330.      Algebraic Specification,
  331.      ACM Frontier Series, The ACM Press in cooperation with
  332.      Addison-Wesley, 1989.
  333.  
  334.      P. Klint,
  335.      A meta-environment for generating programming environments,
  336.      In J.A. Bergstra and L.M.G. Feijs (eds), Proceedings of the
  337.      METEOR workshop on Methods Based on Formal Specification,
  338.      Springer LNCS Vol. 490, 105-124, 1991.
  339.      (Revised version submitted to ACM TOSEM)
  340. --------------------------------------------------------------------------------
  341. From loegel@fegatello.ssc.gov Mon Sep 14 23:50:11 1992
  342.  
  343. [Pau82a] Paulson, L.  {\it A Compiler Generator for Semantic
  344. Grammars}, Ph.D.  dissertation, Stanford University, 1982
  345. [Pau82b] Paulson, L. ``A Semantics-Directed Compiler Generator'', in
  346. Conference Record of the Ninth Annual ACM Symposium on Principles of
  347. Programming Languages, ACM, 1982, pp. 224-233
  348.  
  349. We used Paulson's system to generate Pcode in 
  350. [Mil84] Milos, D.  Pleban, U. and Loegel, G.  ``Direct Implementation
  351. of compiler specifications, or: The Pascal P-compiler revisited'',
  352. Conference Record of the 11th Annual ACM SIGPLAN/SIGACT Symposium on
  353. Principles of Programming Languages, 1984, pp. 196-207
  354.  
  355. Another reference would be the papers in:
  356. _Semantics-Directed Compiler Generation_, Jones, N. D. ed., Lecture
  357. Notes in Computer Science no. 94, Springer-Verlag, Berlin, 1980
  358.  
  359. --------------------------------------------------------------------------------
  360. Reply-To: jbs@congruent.com
  361.  
  362. It is pretty trivial to transform denotational semantics into a Scheme
  363. (or other Lisp) program implementing an interpreter for the language.
  364. I did this in a graduate programming languages cource at MIT.
  365.  
  366. Compilers are harder.
  367.  
  368. But given a good enough Lisp compiler, the compiler itself can turn
  369. the interpreter into a compiler!
  370.  
  371. (define (interpreter->compiler interpreter)
  372.    (lambda (form)
  373.        (lambda arguments
  374.        (apply interpreter form arguments)))
  375.  
  376. (define my-compile (interpreter->compiler my-interpret))
  377.  
  378. (define my-compiled-form (my-compile my-form))
  379.  
  380. It all falls out as a consequence of aggressive procedure inlining,
  381. constant-folding, and other optimizations.
  382.  
  383. Jeffrey Siegal
  384. -- 
  385. Send compilers articles to compilers@iecc.cambridge.ma.us or
  386. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  387.