Re: language design tradeoffs

kcoppes@aardvark.den.mmc.com (Keil Coppes)
Tue, 22 Sep 1992 14:44:58 GMT

          From comp.compilers

Related articles
[25 earlier articles]
Re: language design tradeoffs maxtal@extro.ucc.su.OZ.AU (1992-09-21)
Re: language design tradeoffs jch@rdg.dec.com (1992-09-21)
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-21)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-21)
Re: language design tradeoffs raveling@Unify.com (1992-09-21)
Re: language design tradeoffs alvin@eyepoint.com (1992-09-22)
Re: language design tradeoffs kcoppes@aardvark.den.mmc.com (1992-09-22)
Re: language design tradeoffs dmason@plg.uwaterloo.ca (1992-09-22)
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-23)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-23)
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-24)
Re: language design tradeoffs alvin@eyepoint.com (1992-09-24)
Re: language design tradeoffs rob@hoster.eng.ohio-state.edu (1992-09-24)
[3 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.human-factors
From: kcoppes@aardvark.den.mmc.com (Keil Coppes)
Organization: Martin Marietta Astronautics, Denver
Date: Tue, 22 Sep 1992 14:44:58 GMT
References: 92-09-048 92-09-117
Keywords: parse, design

e86jh@efd.lth.se (Jens Hansson) writes:
|> What I would like to see in coding is a two-layer editor. Layer one
|> contains the code, which could be in any language. Layer two contains the
|> commentary.
|>
|> When the compiler runs, it extracts layer one only. When you print the
|> file, you normally turn all layers on.


A similar type of editor is currently being implemented in the Process
Management Environment (PME) at Martin Marietta, Denver. However, the
Martin editor is implemented in a hypertext management system.


This editor, called the Data Manager, is coded on top of the Knowledge
Management System (KMS) from Knowledge Systems in Murraysville, PA. As
KMS is a hypertext and hypermedia application, large pieces of code may be
structured and managed as trees of text. That is, when a piece of code
gets sufficiently large, the text is broken down into subsections, each on
a different frame(page). However, when the code is exported to the
workspace, it is exported as a single continuous text file. Because KMS
exports this continuous code stream, code may be broken into very small
sections that may be easily handled and documented (and reused).




The editor makes a distinction from the posted article in that four data
trees are implemented instead of two.




          ---------- ---------- ---------- ----------
          | | | | | | | |
          |Equation| n:1 |Diagram | 1:1 | Source | 1:n | Prose |
          | |-----| |-----| |-----| |
          | | | | | | | |
          | | | | | | | |
          ---------- ---------- ---------- ----------




Each code fragment consists of four parts:


1. The source itself
2. An associated diagram frame to show flow inside the fragment
3. One or more mathematical basis frames (as many as desired)
4. One or more prose (code comment) frames (as many as desired)


These parts are all linked to one another and may be built up into larger
structures.


As KMS includes a graphical and text editor, flow diagrams may be easily
created on the diagram frame to connect pieces of related code and figures
may be created on the equation and prose frames to explain the code. But
at runtime, only the source is exported (extracted).


Also, pieces of code can be disabled from compiling when testing by
disabling the link that leads to the particular piece.




It is good to know that others are thinking in the same direction that we
are.


(This software runs in UNIX on SUN and HP workstations).


Questions & comments appreciated, kcoppes@aardvark.den.mmc.com
                                                                    (303) 977-1537
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.