home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / tex / baxter.bib < prev    next >
Text File  |  1993-09-13  |  13KB  |  324 lines
  1.  
  2. @incollection(Kant90a:synthesizing-finite-difference-programs,
  3.   key        = "Kant",
  4.   author     = "Elaine Kant and Fran\c{c}ois Daube and William MacGregor and Joseph Wald",
  5.   title      = "{Automated Synthesis of Finite Difference Programs}",
  6.   booktitle  = "Symbolic Computations and Their Impact on Mechanics,
  7.         PVP-Volume 205",
  8.   editor     = "",
  9.   publisher  = "The American Society of Mechanical Engineers 1990",
  10.   address    = "New York, NY",
  11.   year       = 1990,
  12.   note       = "ISBN 0-791800598-0"
  13. )
  14.  
  15. @incollection(Kant91a:scientific-program-synthesis,
  16.   key        = "Kant",
  17.   author     = "Elaine Kant and Fran\c{c}ois Daube and William MacGregor and Joseph Wald",
  18.   title      = "{Scientific Programming by Automated Synthesis}",
  19.   booktitle  = "Automating Software Design",
  20.   editor     = "M. Lowry and R. McCartney",
  21.   publisher  = "AAAI Press",
  22.   year       = 1991
  23. )
  24.  
  25. @article(Kant93a:sinapse-overview,
  26.   key        = "Kant",
  27.   author     = "Elaine Kant",
  28.   title      = "{Synthesis of Mathematical Modeling Software}",
  29.   journal    = "IEEE Software",
  30.   volume     = 10,
  31.   number     = 3,
  32.   pages      = "30-41",
  33.   month      = may,
  34.   year       = 1993
  35. )
  36.  
  37. @article(Baxter86a:transformational-model-of-maintenance,
  38.    key = "Baxter",
  39.    title = "{TMM: Software Maintenance by Transformation}",
  40.    author = "Guillermo Arango and Ira Baxter and Peter Freeman
  41. and Christopher Pidgeon",
  42.    journal = "IEEE Software",
  43.    volume = 3,
  44.    number = 3,
  45.    month = may,
  46.    year =  1986,
  47.    pages = "27-39",
  48.    annotation = {Early paper characterizing formal types of maintenance, and
  49. describing a successful porting project based on this perspective.}
  50. )
  51.  
  52. @article(Baxter92b:design-maintenance-systems-overview,
  53.    key   = "Baxter",
  54.    title = "{Design Maintenance Systems}",
  55.    author = "Ira D. Baxter",
  56.    journal = "Communications of the ACM",
  57.    year = 1992,
  58.    month = apr,
  59.    volume = 35,
  60.    number = 4,
  61.    pages = "73-89",
  62.    annotation = {Thesis synopsis.  Suggests Design Maintenance rather
  63.         than Code Maintenance should be focus.  Shows how
  64.         formal (transformational) model of software
  65.         construction can be used to generate design histories,
  66.         and also implicitly defines types of formal
  67.         maintenance deltas.  Procedures for updating a
  68.         captured design history are sketched.}
  69. )
  70.  
  71. @article(Neighbors84a:DRACO,
  72.   author     = "James Neighbors",
  73.   title      = "{The Draco Approach to Constructing Software from Reusable Components}",
  74.   journal    = "IEEE Transactions on Software Engineering",
  75.   volume     = "SE-10",
  76.   number     = 5,
  77.   month      = sep,
  78.   year       = 1984,
  79.   annotation = {A shortened version of \cite{Neighbors80a:thesis-DRACO}}
  80. )
  81.  
  82. @inproceedings(Baxter91b:using-abstract-parallelism,
  83.    title = "{Using Domain-Specific, Abstract Parallelism}",
  84.    booktitle = "Proceedings of Parallel-Code Generation Workshop at ICLP91",
  85.    author = "Ira D. Baxter and Elaine Kant",
  86.    year = 1991,
  87.    month = oct,
  88.    location = "San Diego, California",
  89.    publisher = "IEEE Computer Society",
  90.    annotation = {Describes capture and harness of parallel code in
  91.         Sinapse domain-specific code constructs.}
  92.  
  93. )
  94.  
  95. @book(Wolfram88a:mathematica-user-guide,
  96.    author  = "Stephan Wolfram",
  97.    title = "{Mathematica: A System for Doing Mathematics by Computer}",
  98.    publisher = "Addison-Wesley Publishing Company, Inc.",
  99.    address = "Reading, Massachusetts",
  100.    year = 1988,
  101.    note = "ISBN 0-201-19334-5, QA76.95.W651988",
  102. )
  103.  
  104. @book(Brownston85a,
  105.    title = "{Programming Expert Systems in OPS5:
  106. An Introduction to Rule-based Programming}",
  107.    author = "Lee Brownston and Robert Farrell and Elaine Kant
  108. and Nancy Martin",
  109.    publisher = "Addison-Wesley",
  110.    note = "ISBN 0-201-10647-7",
  111.    year = 1985
  112. )
  113.  
  114. @article(Cytron91:computing-SSA-form-efficiently,
  115.   author =     "Ron Cytron and Jeanne Ferrante and Barry Rosen
  116.          and Mark Wegman and Kenneth Zadeck",
  117.   title="Efficiently Computing Static Single Assignment Form and the 
  118.       Control Dependence Graph",
  119.   journal=toplas,
  120.   volume=13,
  121.   number=4,
  122.   month=oct,
  123.   year=1991,
  124.   pages="451-490",
  125.   annotation = {Defines Static-Single-Assignment (SSA) form, useful
  126.         for many optimizations, in which a program assigns
  127.         values to each variable at most one time.
  128.         Conventional imperative programs, having multiple
  129.         assignments to the same variable (say, V), are translated to
  130.         SSA form by adding so-called "phi" functions at the beginning of
  131.         each basic block which definitions of V reach,
  132.         assigning the result of the phi function to a newly
  133.         generated variable, and repeating this process until only
  134.         only single assignments remain. Array/records are
  135.         handled by introducing "update(array/record,index/slot)"
  136.         value modifying-functions. [IDB: SSA form is also
  137.         described \cite{Alpern88a:detecting-equality-via-SSA},
  138.         having a kind of phi node which also depends on the
  139.         predicates controlling region exits, which seems more
  140.         sensible to me; this also seems to match dataflow language
  141.         compiler methods very well.]  Minimal SSA form is that in which
  142.         the fewest phi nodes are inserted.  This paper shows
  143.         how to accomplish the minimal SSA-conversion process
  144.         efficiently, by: (p. 463)
  145.             1) Computing a "dominance frontier" from
  146.             dominator trees derived from the control flow graph,
  147.             in worst-case time O(N+E^2).  [Empirical evidence is
  148.             provided that this process is linear in practice.]
  149.             2) Using dominance frontiers, computing
  150.             locations of phi-functions assigning V_i for each
  151.             variable V in original program,
  152.             3) Renaming variables by replacing each
  153.             mention of a variable V with appropriate mention of V_i.
  154.         Detailed algorithms are provided, as well as proofs
  155.         that the dominance-frontier algorithm is correct and
  156.         that minimal SSA-form is achieved. Control dependences
  157.         \cite{Ferrante87a:program-dependence-graph-overview}
  158.         can be constructed from dominance
  159.         frontiers of the reversed control flow graph; these
  160.         can presumably be used to annotate control-dependent
  161.         SSA-nodes.   So computing dominance frontiers is
  162.         important to building SSA-form.  Lastly, the paper
  163.         describes how to translate from SSA-from back to
  164.         conventional form, by applying dead-code elimination
  165.         [possibly introduced by to-SSA from conversion, and/or
  166.         other optimizations] and allocation of variables to
  167.         phi-nodes by a coloring scheme.  A pretty paper.
  168.         \par
  169.         Clearly SSA form is useful for optimizations; this
  170.         paper suggests that its efficient dominance frontier
  171.         computation be used to construct SSA from program
  172.         instances. The claim is made (page 478) "The
  173.         phi-functions have precise semantics..." but those
  174.         semantics are *not* given, to my disappointment.
  175.         \par
  176.         For transformation systems, it appears that
  177.         SSA-form internally is probably a good idea; this idea
  178.         is reinforced by the \cite{Alpern88a:detecting-equality-via-SSA} paper;
  179.         this would require the to- and from- SSA-from conversions.
  180.         For synthesis systems, SSA form looks useful, but only
  181.         the from-SSA form is needed.
  182.         An interesting question is whether AST-expressed rewrite rules
  183.         for imperative programs could be translated to SSA-form, allowing
  184.         convenience of external expression,
  185.         and accuracy/speed of internal application.}
  186. )
  187.  
  188. @book(Pagan81a:formal-spec-primer,
  189.   title = "{Formal Specification of Programming Languages: A Panoramic Primer}",
  190.   author = "Frank G. Pagan",
  191.   publisher = "Prentice-Hall, Inc.",
  192.   address = "Englewood Cliffs, New Jersey 07632",
  193.   year = 1981,
  194.   note = "ISBN 0-13-329052-2",
  195.   annotation = {Primer on various techniques for formally
  196. specifying programming language constructs.  Covers BNF, attribute
  197. grammars, Van Wijngaarden W-grammars, VDL, denotational semantics, and
  198. axiomatic approaches.  Pretty good.}
  199. )
  200.  
  201. @phdthesis(Arango88a:thesis-domain-engineering,
  202.    title = "{Domain Engineering for Software Reuse}",
  203.    author = "Guillermo Arango",
  204.    school = "Department of Information and Computer Science, University
  205. of California at Irvine",
  206.    month = "July",
  207.    year =  1988,
  208.    note = "ICS-RTP-88-27",
  209.    annotation =
  210. {Original abstract was ``A precondition for reusability is the
  211. existence of reusable information. There is a lack of systematic
  212. methods for producing reusable information.  We propose a method for
  213. {\it practical domain analysis}, defined as the process of
  214. identification, acquisition and evolution of information to be reused
  215. in the construction of software systems for restricted classes of
  216. applications, or problem-domains.  The method for domain analysis is
  217. presented in the context of a {\it domain engineering framework} that
  218. views reuse systems as composed of two parts, a performance component
  219. and a learning component.  The methods for domain analysis realize the
  220. learning component.  Methods and representations are demonstrated in
  221. the context of first-order reuse---the reuse of software components."}
  222. )
  223.  
  224. @book(Partsch90a:transformation-textbook,
  225.   author = "Helmut A. Partsch",
  226.   title = "{Specification and Transformation of Programs}",
  227.   publisher = "Springer-Verlag",
  228.   year = 1990,
  229.   note = "ISBN 52356-1",
  230.   annotation = {Saw ref to this on page A-6 of June 1990 CACM.
  231. \abstract{This book provides insight into formal specifications and
  232. transformational development... Intended as a textbook...}
  233. Given that it is done by Partsch, it ought to be pretty good.
  234. Springer says it won't be available until Sept 23, 1990.}
  235. )
  236.  
  237. @techreport(Genesereth92a:knowledge-interchange-format-reference,
  238.   author     = "Michael R. Geneserth and Richard E. Fikes",
  239.   title      = "{Knowledge Interchange Format Version 3.0 Reference Manual}",
  240.   institution= "Computer Science Department, Stanford University",
  241.   number     = "Logic Group Report Logic-92-1",
  242.   month      = jun,
  243.   year       = 1992,
  244.   note       = "",
  245.   annotation = {genesereth@cs.Stanford.EDU
  246.         This document defines a draft standard for knowledge
  247.         interchange. [There seems to be considerable controversy
  248.         in the KR community about whether the field is mature
  249.         enough to define such a standard according to Matt
  250.         Ginsberg of Stanford].
  251.         \par
  252.         \originalabstract{Knowledge Interchange Format (KIF)
  253.         is a computer-oriented language for the interchange of
  254.         knowledge among disparate programs.  It has
  255.         declarative semantics (i.e., the menaing of
  256.         expressions in the representation can be understood
  257.         without appeal to an interpreter for manipulating
  258.         those expressions); it is logically comprehensive
  259.         (i.e., it provide for the expression of arbitrary
  260.         sentences in first-order predicate calculus); it
  261.         provides for the representation of knowledge about the
  262.         representation of knowledge; it provides for the
  263.         representation of nonmonotonic reasoning rules; and it
  264.         provides for the definiton of objects, functions and
  265.         relations.}
  266.         \par
  267.         KIF is essentially FOPC encoded in a LISP-like syntax.
  268.         As well as writing logical sentences, one can define
  269.         bounded sets (one that don't have Russell paradox
  270.         problems), relations over bounded sets, functions over
  271.         bounded sets (as a special kind of relation where the
  272.         equal prefixes of relation tuples imply equal last
  273.         values in the relation tuple), forward chaining rules,
  274.         and default inferencing rules.
  275.         \par
  276.         The idea is the knowledge is encoded in KIF for
  277.         transport. An application program would read a
  278.         KIF-encoded KB and "compile" it into internal
  279.         structures and procedures that use the KB knowledge
  280.         efficiently. By having an interchange format,
  281.         presumably KBs could be exchanged.
  282.         \par        
  283.         IDB: how do I use something like KIF to encode
  284.         transformation system knowledge?        
  285.         \par
  286.         There is an impressive array of additional well-respected
  287.         co-authors.
  288.         } 
  289. )
  290.  
  291. @techreport(Smith89a:KIDS-overview,
  292.   author = "Douglas R. Smith",
  293.   title = "{KIDS: A Semi-Automatic Program Development System}",
  294.   number = "",
  295.   month = oct,
  296.   year = 1989,
  297.   institution = "Kestrel Institute, Palo Alto, California 94304",
  298. )
  299.  
  300. @incollection(Marcus88a:SALT-ka-for-propose-and-revise-systems,
  301.   author     = "Sandra Marcus",
  302.   title      = "{SALT: A Knowledge Acquistion Tool for
  303.         Propose-and-Revise Systems}",
  304.   booktitle  = "Automating Knowledge Acquisition for Expert Systems",
  305.   editor     = "Sandra Marcus",
  306.   publisher  = "Kluwer Academic Publishers",
  307.   address    = "Boston",
  308.   pages      = "81-123",
  309.   year       = 1988,
  310.   note       = "",
  311.   annotation = {}
  312. )
  313.  
  314. @book(Boose90a:knowledge-acquisition-foundations,
  315.   author     = "J. Boose and B. Gaines",
  316.   title      = "{The Foundations of Knowledge Acquisition, Vol. 4}",
  317.   publisher  = "Academic Press",
  318.   address    = "New York",
  319.   year       = 1990,
  320.   annotation = {Summaries from Knowledge Acquisition Journal.
  321.         Covers set of issues in KA, and a number of papers on
  322.         KA issues for varying domains.}
  323. )
  324.