home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / contrib / krsg / krdesc.txt < prev    next >
Text File  |  1994-11-08  |  37KB  |  925 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                   Knowledge Representation System Generator
  7.  
  8.                               Description
  9.  
  10.                               Dave Kuhlman
  11.                                   Reify
  12.                             dkuhlman@netcom.com
  13.                               1-415-368-8450
  14.  
  15.  
  16.  
  17.         Topics:
  18.  
  19.             -- Preliminary -- Rational
  20.  
  21.             -- What it does: (1) Functions and code generated; (2) support
  22.                 code; (3) embedded language interface
  23.  
  24.             -- What it does NOT do
  25.  
  26.             -- System requirements
  27.  
  28.             -- Rights
  29.  
  30.             -- How to use KR-SG
  31.  
  32.             -- Possible uses
  33.  
  34.             -- Current status
  35.  
  36.             -- Future directions
  37.  
  38.             -- Problems
  39.  
  40.             -- Miscellaneous comments
  41.  
  42.             -- Addresses and Sources for Support Code
  43.  
  44.  
  45.  
  46.         Preliminary -- Rational
  47.  
  48.         Suppose you want to develop an application that enables users to
  49.         manipulate and browse/edit a complex set of objects.  Your approach
  50.         might me to define a set of C++ classes, one for each type of object
  51.         to be manipulated, to implement these C++ classes, and to write a
  52.         graphical browser editor.  In doing so, you will produce three
  53.         categories of code:  (1) application specific code, (2) generic
  54.         object manipulation code, (3) GUI code implementing the graphic
  55.         interaction between the user and the objects.  KR-SG enables you to
  56.         generate (2) the generic object manipulation code.
  57.  
  58.  
  59.  
  60.         What It Does
  61.  
  62.  
  63.  
  64.         KR-SG -- Description                                    Page 1        
  65.  
  66.  
  67.  
  68.  
  69.                                                                               
  70.  
  71.  
  72.         KR-SG enables the user/developer to define a set of types.  For each
  73.         type, the developer specifies the contents of the type, i.e. the
  74.         fields or member data items in the type and the type of each of
  75.         these fields, and, optionally, a base type or superclass for the type.
  76.  
  77.         For each specified type, KR-SG generates a C++ class for each type
  78.         described by the developer.  The data members are protected members
  79.         of a C++ class, so that they will be inherited by subclasses of the
  80.         type.  KR-SG generates member functions for each class, as described
  81.         below, plus some support code, e.g. for compiling objects of the
  82.         described types.
  83.  
  84.         KR-SG generates for each specified type a canonical C++ class
  85.         containing the following functions:
  86.  
  87.             -- Default ctor
  88.  
  89.             -- Copy ctor
  90.  
  91.             -- Virtual dtor
  92.  
  93.             -- Assignment operator
  94.  
  95.         KR-SG generates for each specified type a set of member functions:
  96.  
  97.             -- A Copy function which does a deep copy.
  98.  
  99.             -- A Save function that will save the object into a database.
  100.  
  101.             -- A Load function that will load an object from a database.
  102.  
  103.             -- A decompile function that will convert the internal, binary
  104.                 form of an object into an external, text (ASCII) form.
  105.  
  106.             -- Code which, when processed by a parser generator (PCCTS),
  107.                 will convert the external, text (ASCII) form of an object
  108.                 into the internal, binary form.  This code can also be used
  109.                 as the front end for a developer's parser of language
  110.                 processor.
  111.  
  112.             -- A function that will, when called, generate code for IPFC
  113.                 (the Information Presentation Facility Compiler) from the
  114.                 contents of specified string fields.
  115.  
  116.         For each member data item of each type (class), KR-SG generates set
  117.         an get public member functions.  If the name of a member data item
  118.         is M and its type is T, then the prototype of the get and set
  119.         functions are:
  120.  
  121.             T Get_M();
  122.             void Set_M(T newValue);
  123.  
  124.         KR-SG comes with a sample application.  It is a C++ program that (1)
  125.         constructs some objects, (2) saves the objects into a database, (3)
  126.         loads the objects from the database, (4) decompiles the object to
  127.         produce an ASCII file.  This application also contains a REXX
  128.  
  129.  
  130.         KR-SG -- Description                                    Page 2        
  131.  
  132.  
  133.  
  134.  
  135.                                                                               
  136.  
  137.  
  138.         interface, i.e.  it will run and execute the REXX code in a REXX
  139.         file which contains calls to a sub-command handler which is
  140.         implemented in the sample application.
  141.  
  142.         KR-SG contains a working skeleton for a command-line app that is a
  143.         compiler and decompiler.
  144.  
  145.             -- When executed with the '-c' operation, it creates a new
  146.                 database.
  147.  
  148.             -- When executed with the '-a' operation, it compiles an ASCII
  149.                 file and adds a new object to a database.
  150.  
  151.             -- When executed with the '-x' operation, it loads an object
  152.                 from a database and decompiles it to an ASCII file.
  153.  
  154.             -- When executed with the '-d' operation, it deletes an object
  155.                 from a database, making the space available for reuse.
  156.  
  157.         The sample/test program distributed with KR-SG contains a REXX
  158.         interface.  It shows how to call a user/developer's REXX file and
  159.         execute the REXX code in that file.  It contains a REXX subcommand
  160.         handler which will process commands in the REXX file that are
  161.         unknown to REXX or are in quotes (a signal to the REXX interpreter
  162.         that the command is to be excuted in an external environment).  This
  163.         sample subcommand handler supports operations to get and set member
  164.         data items (fields in a type), create and delete objects, as well as
  165.         operations to create, delete, and manipulate cursors used to point
  166.         to and mantain position among objects.
  167.  
  168.         KR-SG provides a string class KrString.  It is a subclass of the
  169.         string class offered by the compiler vender (class String for
  170.         Borland C++ for OS/2; class string for WATCOM C++ for OS/2).
  171.  
  172.         KR-SG provides support for lists of objects.  For each type
  173.         specified, KR-SG generates a type-specific list class.  This means
  174.         that adding and accessing objects in lists is type-safe.  If the
  175.         name of a user's type is X, then the generated list type is a class
  176.         named XList.  The developer can inspect generated code and the
  177.         sample app for code samples showing how to create, added to, and
  178.         access data in lists.  There is also a string list class
  179.         (KrStringList).
  180.  
  181.         Comments on decompiling and compiling -- Why you might want to be
  182.         able to do it.  If you feel that a decompiler and compiler is of no
  183.         use, you can either (1) turn off the flag that causes KR-SG to
  184.         generate it or (2) read the following reasons and uses:
  185.  
  186.             -- A decompiler and compiler provides a bootstrap mechanism for
  187.                 producing data during early development, e.g. before you
  188.                 have implemented a graphical f your own.  For example, you
  189.                 can use the set_x() member functions to create a small set
  190.                 of objects, then decompile the objects, then use your text
  191.                 editor to copy the objects, then re-compile.
  192.  
  193.             -- A decompiler can be used to produce backup.  This may
  194.  
  195.  
  196.         KR-SG -- Description                                    Page 3        
  197.  
  198.  
  199.  
  200.  
  201.                                                                               
  202.  
  203.  
  204.                 provide some assurance, if you do not trust the binary
  205.                 database or worry that that database can be corrupted.
  206.  
  207.             -- A decompiler and compiler can be used to move data from one
  208.                 platform to another.  A text file may port across platforms
  209.                 where the binary database might not.  You can decompile to
  210.                 text on one platform, move the text form to the other
  211.                 platform, then recompile.
  212.  
  213.             -- A compiler can provide a mechanism for importing data from
  214.                 other applications.  If you can add code or macros to the
  215.                 other application that produces a text file that satisfies
  216.                 the syntax of a decompiled file, then you can import that
  217.                 database by using the compiler.
  218.  
  219.             -- You can use the compiler to produce programs that transform
  220.                 data while they compile it.  The compiler is composed of a
  221.                 front-end (an Antlr grammar; Antlr is a part of PCCTS; it
  222.                 creates the parse tree) and a back-end (a Sorcerer tree
  223.                 grammar; it walks the parse tree and creates the objects).
  224.                 You can add C code to the actions in the rules in the
  225.                 back-end, to perform transformations on those objects.
  226.  
  227.             -- You can use the generated grammars to produce a compiler of
  228.                 your own, possibly by keeping the front-end grammar, but
  229.                 then replacing the actions in the back-end grammar.
  230.  
  231.             -- The ability to use a decompiler produce a text form of your
  232.                 data may enable you to use tools that you could not
  233.                 otherwise use.  For example, you can use grep as well as the
  234.                 search commands in your text editor to find things.  You may
  235.                 be able to use your the search and replace facility in your
  236.                 text editor to make rapid global changes.  You may be able
  237.                 to use REXX or some other text processing language to write
  238.                 filters and transformers.  And the code the KR-SG generates
  239.                 for the compiler can be used as the basis for pattern
  240.                 matching operations.  (Remember that the grammars generated
  241.                 by KR-SG contains a rule that matches each object and field
  242.                 in your data.
  243.  
  244.  
  245.  
  246.         What It Does Not Do
  247.  
  248.         KR-SG does not generate a GUI (graphical user interface) or code to
  249.         support one.  If you get any ideas on what KR-SG could do to support
  250.         such a need, please let me (Dave Kuhlman, dkuhlman@netcom.com,
  251.         415-368-8450) know about them.
  252.  
  253.         The code produced by KR-SG does no memory management.  This is C++,
  254.         remember; you asked for a low level language; now you live with it.
  255.         You need to delete anything that you create (with new) and a lot of
  256.         things that the generated code creates, too.
  257.  
  258.  
  259.  
  260.  
  261.  
  262.         KR-SG -- Description                                    Page 4        
  263.  
  264.  
  265.  
  266.  
  267.                                                                               
  268.  
  269.  
  270.         System Requirements
  271.  
  272.         In order to use KR-SG you will need the following:
  273.  
  274.             -- ANSI C/C++ compiler.  KR-SG has been tested with Borland C++
  275.                 for OS/2, [WATCOM C++ for OS/2, IBM CSet++, and MetaWare C++
  276.                 for OS/2].
  277.  
  278.             -- Softfocus BTree package, a BTree and record manager
  279.                 distributed in C source code form.  KR-SG contains a small
  280.                 file containing glue functions which provide the interface
  281.                 between KR-SG generated code and the Softfocus BTree
  282.                 package.  The developer can substitute a different BTree
  283.                 package by replacing/rewriting the functions in this file.
  284.  
  285.             -- PCCTS -- the Purdue compiler construction  toolset.  This
  286.                 parser generator is in the public domain and is distributed
  287.                 in source code form.  I supply the needed support/header
  288.                 files and executables for OS/2.
  289.  
  290.             -- The Icon programming language -- I supply executables for
  291.                 OS/2.  These are sufficient for using KR-SG.  If you make
  292.                 serious use of the Icon programming language, then you
  293.                 should send money to the Icon Project, so that they can
  294.                 track users, so that you can help support the development
  295.                 and distribution of Icon, and so that you will be sent the
  296.                 Icon newsletter.  (See below for address of the Icon
  297.                 Project.)  Icon is a high level language that contains
  298.                 powerful built-in data types (strings, sets, lists,
  299.                 tables/dictionaries, records), generators, co-expressions,
  300.                 backtracking, garbage collection, etc.
  301.  
  302.  
  303.  
  304.         Rights
  305.  
  306.         I have placed KR-SG in the public domain.  You can use the generated
  307.         code, the code generator, and support code in any way you wish.
  308.         KR-SG is provided "as-is" without warranty or liability.  I
  309.         ask only the following: (1) if you pass on the code I provide, that
  310.         you leave my name and address in place, and (2) if you create an
  311.         application, that you place the following notice at the beginning of
  312.         your documentation and in the help file in a window labeled
  313.         "Credits" in the top level of the Contents list:
  314.  
  315.             This application produced with the help of the
  316.             Knowledge Representation System Generator
  317.             developed by
  318.                 Dave Kuhlman
  319.                 Internet:   dkuhlman@netcom.com
  320.                 Phone:      415-368-8450
  321.  
  322.         Please send suggestions and bug reports to me at the above E-mail
  323.         address.
  324.  
  325.  
  326.  
  327.  
  328.         KR-SG -- Description                                    Page 5        
  329.  
  330.  
  331.  
  332.  
  333.                                                                               
  334.  
  335.  
  336.         How to use KR-SG
  337.  
  338.         This section is an overview of how to use KR-SG.  More details can
  339.         be found in the KR-SG User Guide.
  340.  
  341.         A developer uses KR-SG to produce an application by performing the
  342.         following steps.  Some of these steps will be unnecessary for some
  343.         applications and uses:
  344.  
  345.             -- Unzip the distribution file to produce the KR directory
  346.                 structure on the developer's hard disk.
  347.  
  348.             -- Describe the objects/types.
  349.  
  350.             -- Create a control file.
  351.  
  352.             -- Run MSG (the system generator) to produce source code.
  353.  
  354.             -- Review and make any desired changes to the generated code.
  355.  
  356.             -- Compile the generated code to produce a library.
  357.  
  358.             -- Compile supporting code (DB, SUP).
  359.  
  360.             -- Compile KRC (the Knowledge Representation Compiler).
  361.  
  362.             -- Make changes to the sample application.
  363.  
  364.             -- Compile the sample application.
  365.  
  366.             -- Embed KR-SG into your application.
  367.  
  368.             -- Modify the generator to customize generated code.
  369.  
  370.             -- Integrate the generated REXX interface support.
  371.  
  372.             -- Integrate with VX-REXX.
  373.  
  374.             -- Integrate generated template insertion code into you text
  375.                 editor (EPM or Preditor/2).
  376.  
  377.  
  378.  
  379.         Unzip the distribution file to produce the KR directory structure on
  380.         the developer's hard disk -- Doing so will produce the following
  381.         directory tree:
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.         KR-SG -- Description                                    Page 6        
  395.  
  396.  
  397.  
  398.  
  399.                                                                               
  400.  
  401.  
  402.            kr ----+---- h
  403.                   |
  404.                   +---- sup (support code for KrStrings, KrStreams, etc)
  405.                   |
  406.                   +---- db (database support code, BTree glue functions, etc)
  407.                   |
  408.                   +---- gen (code and support for the generator itself)
  409.                   |
  410.                   +---- kr (the generated code goes here)
  411.                   |
  412.                   +---- krc (the KR command line compiler/decompiler)
  413.                   |
  414.                   +---- test (a sample program)
  415.                   |
  416.                   +---- libx (x: b=Borland, i=IBM Cset++, w=WATCOM)
  417.  
  418.         Describe the objects/types -- Produce a knowledge representation
  419.         specification file (called, say, myapp.krs).  This file contains a
  420.         description of each type that you intend to define and manipulate.
  421.         For each type, you specify the fields in that type.  Each field must
  422.         be one of the following types: (1) integer, (2) float, (3) string (a
  423.         pointer to a KrString), (4) boolean, (5) user defined type (a
  424.         pointer to a user defined type), (6) a list of one of the above.  In
  425.         addition, optionally specify a superclass for the type.
  426.  
  427.         Create a control file -- This file contains command line flags used
  428.         by the generator.  These flags specify, for example, whether to
  429.         generate specific types of code (C++ code, parser code, VX-REXX
  430.         interface code, REXX interface code, etc), the input specification
  431.         file, whether to generate comments in the code, etc.
  432.  
  433.         Run MSG (the system generator) to produce source code -- MSG reads
  434.         the type specification file and generates the various code output
  435.         files.  Copy these files to the /kr/kr directory.  A batch file in
  436.         the /kr/kr directory can be used to do this copy.
  437.  
  438.         Review and make any desired changes to the generated code --
  439.         Although this may not be necessary, and although you as a developer
  440.         should attempt to avoid modifying the generated code (for one,
  441.         because then you will not be able to change your type specification
  442.         file and re-generate code.), still let's look at where some of the
  443.         different types of code go.  MSG generates the following files:
  444.  
  445.             myapp.hpp -- C++ header file for the type definitions.
  446.                 Contains C++ class definitions and record definitions for
  447.                 saving each type into the database.  Also contains a list
  448.                 class for each type.
  449.  
  450.             myapp.cpp -- C++ code for the member functions for each
  451.                 class/type.  For each type, the following functions are
  452.                 generated:  (1) default constructor, (2) copy constructor,
  453.                 (3) virtual destructor, (4), Load function to load object
  454.                 from a database, (5) Save function to save function into
  455.                 database, (6) Decompile function to translate the object
  456.                 into a text form, (7) GenIpf function that produces code for
  457.                 the IPFC help compiler.  Also contains member function
  458.  
  459.  
  460.         KR-SG -- Description                                    Page 7        
  461.  
  462.  
  463.  
  464.  
  465.                                                                               
  466.  
  467.  
  468.                 definitions for the member functions in the list classes.
  469.  
  470.             myappg.g -- Parser grammar used to produce a compiler for the
  471.                 types specified.
  472.  
  473.             myappg.sor -- Tree parser grammar used to produce a
  474.                 compiler for the types specified.
  475.  
  476.             myapp*.h -- miscellaneous header files.
  477.  
  478.         Compile the generated code to produce a library.  The /kr/kr
  479.         directory contains make files for compiling the generated code.
  480.  
  481.         Compile supporting code in the following directories: /kr/db,
  482.         /kr/sup.  These contain make files for compiling the generated code.
  483.  
  484.         Compile KRC (the Knowledge Representation Compiler).  The /kr/krc
  485.         directory contains make files.
  486.  
  487.         Make changes to the sample application.  The calls to the Set_xxx()
  488.         functions will have to be changed.
  489.  
  490.         Compile the sample application.  Run it.  It should produce a
  491.         database, a decompiled file, and a .IPF file (that can be compiled
  492.         with IPFC.EXE.
  493.  
  494.         Embed KR-SG into your own application.  This should reasonably easy
  495.         if you follow the sample code in the sample application, the command
  496.         line compiler, and the generated code itself (/kr/test/test.cpp,
  497.         /kr/krc/krc.cpp, and /kr/kr/kr.cpp respectively).
  498.  
  499.         Modify the generator to customize generated code.  This step is
  500.         optional.  Do this if, for example, you need to embed some kinds of
  501.         hooks or function calls into the generated code.  You can help
  502.         yourself here by going to the /kr/gen directory, uncommenting the
  503.         line at the beginning of GEN.ICN that defines msg_debug, then run
  504.         MSG.EXE using the '-C' flag for comments (either in the MSG.CFG file
  505.         or on the command line).  This will generate comments in you .CPP
  506.         file containing the file and line numbers of the code that produced
  507.         the generated code.  This will help you find the location where you
  508.         need to make changes.  Hopefully, you will be able to add a line of
  509.         code that calls your function to a list of strings (lines) that
  510.         become the generated code.
  511.  
  512.         Integrate the generated REXX interface support.  The sample
  513.         application (/test/test.cpp) contains a sample REXX interface.  In
  514.         addition, you will need to provide the C code which implements
  515.         procedures that you want your users to be able to call from REXX
  516.         code.  KR-SG helps you with this; it generates code that provides
  517.         data access procedures that can be called from REXX to get and set
  518.         the contents of member data items in your defined data types.  This
  519.         code is in the file krrex.inc.  You will need to #include this into
  520.         your (sample/test/real) application.
  521.  
  522.         Integrate with VX-REXX.  [I haven't figured this one out yet.]
  523.  
  524.  
  525.  
  526.         KR-SG -- Description                                    Page 8        
  527.  
  528.  
  529.  
  530.  
  531.                                                                               
  532.  
  533.  
  534.         Integrate generated template insertion code into your text editor
  535.         (EPM or Preditor/2).  KR-SG generates two types of text editor
  536.         template code:  (1) ASSIST code for EPM and (2) .PEL code for
  537.         Preditor/2.  If you understand either of these, I believe you will
  538.         be able to figure out where and how to integrate this code.
  539.  
  540.  
  541.  
  542.         Possible Uses
  543.  
  544.         A bibliography and references database -- The sample application is a
  545.         starter set for such an application.  This application contains
  546.         types: Bibliography, Author, Documentation, Publisher.
  547.  
  548.         A GUI description language -- Actually, my work for several years on
  549.         such a language, and the wish I had to be able to generate a system
  550.         to process such a language without all the hand coding I had to do,
  551.         was the possible motivation for the invention and implementation of
  552.         KR-SG.
  553.  
  554.         Plant/factory and work station description and modeling -- This
  555.         application might contain types Plant, WorkStation,
  556.         WorkStationQueue, WorkPiece.  If each WorkStation has a list of
  557.         Events which each contain a list of Actions to be performed when
  558.         that Event is received by the WorkStation, and if these Events were
  559.         broadcast on (simulated) clock ticks, this could be a discrete event
  560.         simulation (DES) system.
  561.  
  562.         Political party control application -- This application might track
  563.         the activities of the units and people working within a political
  564.         party.  This application might contain the types Party,
  565.         LocalCommittee, Activist, RadicalActivist, etc.
  566.  
  567.         A system for tracking fruit shipments -- This application might
  568.         contain the types Truck, Railcar, Grower, RailwayTerminal, Buyer.
  569.         Railcars are filled with packed fruit from Growers, then sent to an
  570.         RailwayTerminal.  Buyers request that Railcars containing specific
  571.         types of fruit, be routed to destination RailwayTerminals where they
  572.         are available for unloading and distribution to SuperMarkets.
  573.  
  574.         A action language system -- Most likely, this would be a part of a
  575.         larger application.  This action language might deal with Objects,
  576.         Events (messages sent to sets of objects), and Actions.  An object
  577.         in this application might contain a list of Events; each event would
  578.         contain a list of Actions.  The application executes an event loop
  579.         that takes Events from a queue and sends them to objects.  If the
  580.         object contains that Event, then it executes each of the Actions in
  581.         that Event.
  582.  
  583.         A Dungeons and Dragons or role playing game -- In this application
  584.         Players each have a current Role.  A Player's current role enables
  585.         that player to respond to certain events in specific ways (i.e.  the
  586.         role contains a list of Events each of which contain a list of
  587.         Actions (powers) that can be performed.
  588.  
  589.  
  590.  
  591.  
  592.         KR-SG -- Description                                    Page 9        
  593.  
  594.  
  595.  
  596.  
  597.                                                                               
  598.  
  599.  
  600.         Current Status
  601.  
  602.         Currently implemented and tested:
  603.  
  604.             -- Database (BTree) support code
  605.  
  606.             -- Misc support code -- KrString, KrOstream
  607.  
  608.             -- C++ code generation, C++ class generation -- member
  609.                 functions:  default constructor, copy constructor, virtual
  610.                 destructor, Save, Load, Decompile, GenIpf; type safe list
  611.                 class; minor miscellaneous support functions.
  612.  
  613.             -- Compiler grammar generation -- Antlr grammar generation;
  614.                 Sorcerer grammar generation.
  615.  
  616.             -- KRC (Knowledge Representation Compiler) -- create database,
  617.                 compile, decompile, delete object.
  618.  
  619.             -- Sample application.
  620.  
  621.         The following work is "in progress" and not yet completed:
  622.  
  623.             -- Generation of REXX support code
  624.  
  625.             -- Generation of VX-REXX support code.
  626.  
  627.  
  628.  
  629.         KR-SG has been tested with:
  630.  
  631.             -- Icon version:
  632.                 Version: Icon Interpreter Version 9.0.  May 26, 1994
  633.                 Features:
  634.                     OS/2
  635.                     interpreted
  636.                     ASCII
  637.                     co-expressions
  638.                     direct execution
  639.                     environment variables
  640.                     external functions
  641.                     fixed regions
  642.                     keyboard functions
  643.                     large integers
  644.                     multiple regions
  645.                     pipes
  646.                     string invocation
  647.                     system function
  648.  
  649.             -- PCCTS version 1.23 compiled for OS/2 with WATCOM C++ v. 10.
  650.  
  651.             -- C/C++: (1) Borland C++ for OS/2 v. 1.5; (2) WATCOM C++ v. 10
  652.                 running under OS/2; (3) IBM CSet++ v. 2.01.
  653.  
  654.             -- Softfocus BTree v. 3.1.
  655.  
  656.  
  657.  
  658.         KR-SG -- Description                                   Page 10        
  659.  
  660.  
  661.  
  662.  
  663.                                                                               
  664.  
  665.  
  666.         Future Directions
  667.  
  668.         Here is a list of things from which I'll most likely select future
  669.         work on KR-SG:
  670.  
  671.         SQL/relational database support -- It would be nice to be able to
  672.         store objects into and load objects from a relational database.  And
  673.         it would be useful to be able to search for objects using SQL.
  674.  
  675.         GUI support -- It would be beneficial to be able to implement
  676.         graphic front ends and graphical editor/browsers for applications
  677.         produced with the aid of KR-SG and to do so in a platform
  678.         independent way.  How?  I don't know.  Perhaps when Tcl and Tk is
  679.         supported on multiple platforms...
  680.  
  681.         Some of us feel that a language which is higher level than REXX is
  682.         needed.  The problem with REXX is that its only data type is the
  683.         string, and that is not very appropriate for a system (KR-SG) whose
  684.         intent is to enable developers and users to manipulate objects and
  685.         lists of objects.  Icon (the language used to implement the code
  686.         generator for KR-SG is a possibility.  Python, an interpreted,
  687.         object-oriented language, is also a possibility.  Both Icon and
  688.         Python handle lists of objects well.  The difficulties are:  (1)
  689.         embed the language into the application and (2) write the interface
  690.         code that maps KR-SG objects into Icon/Python objects and back.
  691.  
  692.         CEnvi/Cmm support -- Cmm is a C-like language that could serve as a
  693.         more platform independent macro language than REXX.
  694.  
  695.         An Oberon-2 connection -- C++ is a language for suicidal masochists.
  696.         I'd like to see developers able to write their applications in
  697.         Oberon-2 and still be able to access the classes, member data items,
  698.         and member functions generated by KR-SG.  One large step in this
  699.         direction would be an Oberon-2 compiler that translates Oberon-2
  700.         code into C++ code and provides a good foreign function interface to
  701.         Oberon-2 function calls.  What KR-SG should do to support this is to
  702.         generate Oberon-2 (interface) modules that define the type/record
  703.         equivalent to the generated C++ classes.  This needs design work.
  704.         Since Oberon-2 does garbage collection, Oberon-2 support from KR-SG
  705.         should take advantage of garbage collection so that developers do
  706.         not have to worry about when to delete objects.
  707.  
  708.  
  709.  
  710.         Problems
  711.  
  712.         Code bulk -- KR-SG makes it easy to generate code.  So, applications
  713.         bulk up very quickly.  None of the current C/C++ linkers strip
  714.         un-needed functions from .OBJ files containing at least one needed
  715.         function or un-needed member functions from needed C++ classes.
  716.         Also note that C++ templates generate code when instantiated.  If
  717.         C++ templates are good, then I suppose that generating lots of code
  718.         is good.
  719.  
  720.         Limited and awkward database connections -- KR-SG does not currently
  721.         provide any specific support for conventional relational or SQL
  722.  
  723.  
  724.         KR-SG -- Description                                   Page 11        
  725.  
  726.  
  727.  
  728.  
  729.                                                                               
  730.  
  731.  
  732.         databases.  We need a grouping facility in the database, possibly a
  733.         hierarchical directory structure.
  734.  
  735.         The design of the generated code requires that an entire data object
  736.         be loaded from the database into memory at once.  There is no
  737.         support for reading individual sub-objects one by one.  KR-SG is
  738.         most likely not appropriate for an application that must process a
  739.         large database of hundreds of thousands of records, especially where
  740.         transaction processing and transaction rollback support must be
  741.         provided by the database.
  742.  
  743.         KR-SG is currently tied to a specific BTree package (Softfocus) for
  744.         file support.  However, note that the access functions are all in a
  745.         single file (/kr/db/bt.cpp), which should make it reasonably easy to
  746.         substitute a different BTree package, or possibly even a relational
  747.         DB package if it supports BLOBs (variable size binary blocks), as,
  748.         for example, WATCOM's SQL package does.
  749.  
  750.         The code generator itself is written in a high level language with
  751.         good support for manipulating text strings (the Icon programming
  752.         language), but is still relatively difficult to modify and extend.
  753.         We need a better code generator implementation strategy/technology.
  754.         I don't have a solution to this problem; we need exploration and
  755.         research to find better code generator implementation technologies.
  756.         Somebody needs to make my work and my life easier.
  757.  
  758.         KR-SG is tied to C++ (it generates C++ code and supporting code is
  759.         written in C++).  C++ is a terrible language.  It is low level and
  760.         dangerous.  Although, as a target language for code generation, it's
  761.         not so bad.
  762.  
  763.         KR-SG had weak collection classes.  KR-SG generates only lists.  On
  764.         the positive side, there is no dependence on a compiler vender
  765.         specific collection class library.
  766.  
  767.         KR-SG provides no way for the developer to generate code, modify the
  768.         code, and then re-generate code without losing her/his
  769.         modifications.  The developer can modify the code generator so that
  770.         it inserts hooks and callbacks in the generated code, but even that
  771.         is awkward.
  772.  
  773.         KR-SG generates static class/type definitions.  KR-SG provides no
  774.         support for the development of applications that enable end users to
  775.         define new types and to modify existing types at runtime.  Most of
  776.         us respond to this criticism by saying, "Who cares?"  However, this
  777.         is a severe restriction for someone who is seeking a means for doing
  778.         artificial intelligence style programming.
  779.  
  780.         KR-SG does not permit cycles in data structures.  Data structures
  781.         must be acyclic.  For example, in the case of a Bibliography which
  782.         contains a list of Authors each of which contains a list of
  783.         Documents, you cannot put a pointer to an Author in a Document.
  784.  
  785.  
  786.  
  787.         Miscellaneous Comments
  788.  
  789.  
  790.         KR-SG -- Description                                   Page 12        
  791.  
  792.  
  793.  
  794.  
  795.                                                                               
  796.  
  797.  
  798.         Populist programming -- I want to expand the set of people who can
  799.         produce applications.  That's why the REXX interface is an
  800.         essential, not incidental part of KR-SG.  I'm hoping that KR-SG will
  801.         enable developers to produce application platforms, so that users
  802.         who are programmers but not systems programmers can create and
  803.         extend applications.
  804.  
  805.         Why I'm putting KR-SG in the public domain:
  806.  
  807.             -- KR-SG is not all that packagable.  I don't really believe it
  808.                 could be successfully sold.
  809.  
  810.             -- I hope to make money from KR-SG related work, perhaps by
  811.                 using KR-SG to create applications for pay.
  812.  
  813.             -- I want to support populist programming.  I want (1) to help
  814.                 people to create applications much more easily and (2) to
  815.                 help make programming available to more people.  I believe
  816.                 that KR-SG is a valuable tool to achieve this.
  817.  
  818.  
  819.  
  820.         Questions for Contemplation and Research
  821.  
  822.         Question: Is the technology behind KR-SG (code generation) the
  823.         solution to all our future software development problems?  Not
  824.         likely.  KR-SG seems a reasonably natural way to produce code for
  825.         applications needing definitions and code that does a lot of the
  826.         same kind of things for different objects.  What about app
  827.         frameworks?  Are these an alternative to code generators?  Are they
  828.         complementary?  Are code generators and app frameworks suitable for
  829.         different situations?  What are the characteristics of these
  830.         different situations?
  831.  
  832.  
  833.  
  834.         Arguments for Using Code Generators
  835.  
  836.         You get lots of code.
  837.  
  838.         You get it quickly.
  839.  
  840.         You save lots of work.
  841.  
  842.         Once the code generator has been debugged, there is a range of bugs
  843.         that do not get into your (generated) code.  For examples, typos,
  844.         errors in copying code, etc.
  845.  
  846.         You don't have to figure out how to do some of the things that the
  847.         generated code does.  Examples: save to and load from a database;
  848.         implement a parser/compiler; implement type-safe list classes.
  849.  
  850.         Code generators generate regular, uniform code.  In the case of
  851.         KR-SG, once you have looked at one class generated by KR-SG, you
  852.         have seen them all.  The next time you generate a class with KR-SG,
  853.         you will know where to look and what to look for in those classes.
  854.  
  855.  
  856.         KR-SG -- Description                                   Page 13        
  857.  
  858.  
  859.  
  860.  
  861.                                                                               
  862.  
  863.  
  864.         This regularity and consistency has benefits for those who must
  865.         maintain and modify a system.
  866.  
  867.  
  868.  
  869.  
  870.         Addresses and Sources for Support Code
  871.  
  872.         Icon Programming Language:
  873.  
  874.             The Icon Project
  875.             Department of Computer Science
  876.             Gould-Simpson Building
  877.             University of Arizona
  878.             Tucson, Arizona 85721
  879.             1-602-621-8448
  880.             Internet: icon-project@cs.arizona.edu
  881.  
  882.         Softfocus BTree Library:
  883.  
  884.             Softfocus
  885.             1343 Stanbury Rd.
  886.             Oakville, Ontario, Canada
  887.             L6L 2J5
  888.             1-905-825-0903
  889.  
  890.         PCCTS (Purdue Compiler Construction Toolset):
  891.  
  892.             Internet anonymous ftp:
  893.                 everest.ee.umn.edu:/pub/pccts
  894.                                    /pub/pccts/sorcerer
  895.             Also see Internet newsgroup: comp.compilers.tools.pccts
  896.  
  897.  
  898.  
  899.         References
  900.  
  901.         [Gris 1990] Griswold, Ralph E. and Madge T. Griswold; The Icon
  902.             programming Language; Prentice Hall, 1990.
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.         KR-SG -- Description                                   Page 14        
  923.  
  924.  
  925.