%
% File: dbplenv4.tex
% Author: FM
% Date: 5.8.1991
% Included by: dbplenv.tex
%
\section{DBPL-USE -- A Language-Sensitive Editor}

Data-intensive applications are developped in contexts, in which certain of the
required computational objects may preexists. This applies to newly developped
application programs which have to comply with already existing databases, their
type definitions, predefined transactions, views etc. as well as to local
modification of existing application programs which have to maintain the interfaces
to the constant part of their environment.

In this situation, substantial support can be gained by editing facilities with a
certain amount of syntactic and semantic knowledge about the context in which local
program extension and modification takes place.  This support
requires, of course, an editor which is sensitive to the language in
which databases are defined and applications are programmed. In an
integrated linguistic framework as given by DBPL, such a
language-sensitive tool (DBPL-USE\footnote{DBPL Usage Sensitive
Environment, see also Fig.~\ref{dbpl-system}.}) can be pushed very
far by exploiting advanced software generating and synthesizing tools
\cite{ReTe88,ReTe89} based on attribute grammers
\cite{Reps83}.

Productivity in defining and extending computational objects benefits
from the following properties of advanced editing environments:

\begin{itemize}
	\item The amount of text that has to be entered by the user
		can be extremely reduced without producing cryptic code.
		The user merely selects one of the possible constructs
		at the current position instead of entering the text itself.
		The selection is carried out according to the definition of the
		language.

	\item The editor is working in a tree-oriented fashion. A top
		down approach in the development of design objects is therefore
enforced.

	\item Layout rules and documentation standards may be set throughout
		a user community; the editor is completely responsible
		for the layout of the design objects (this is accomplished by {\em
		unparsing} rules).

	\item Most of the syntactic and many of the semantic details need
		not be remembered by the user.
		On selection of a menue item, a whole text pattern is inserted
		automatically.

 \item References to objects defined in related documents can be checked with
   respect to their appropriate use (it does not matter whether this
   feature is provided by the language definition or not).

	\item Certain semantic errors and all syntax errors are 
		discovered and reported at the earliest possible stage
		(on input). 

	\item A wide range of semantic preserving transformations on the
		source text level can be done automatically.
\end{itemize}

The acceptance of the environment is improved by state-of-the-art
interactive interface technology\footnote{There exist (functionally
equivalent) DBPL-USE editor versions for Sun View, Open Look and plain
X-Windows environments.}.

\subsection{Compiler Generation Technology}

Mainly due to two reasons, language editors qualify perfectly for the application of
modern software generation technology. First, the knowledge about the target objects
of a language-sensitive editor --- programs in a specific language with its syntactic
restrictions, type and scope rules etc. --- can easily be formalized, e.g., by 
semantic actions or \e{Attribute Grammars}. Second, most of the
language independent  functionality of editors is ``standard'' and can
be provided by a set of predefined library functions accessed by a
\e{Synthesizer Generator}.

The two rival approaches to integrate semantic analysis into a language-sensitive
tool can be characterized as follows:
\begin{description}
\item[Semantic actions:] Every change of a design object implies the call
of imperative routines that inspect and update the altered context.
Every such routine must have a corresponding ``inverse'' one. The main problem
concerning this approach is to determine the range of changes after the
modification of a program.
Advantageous is the use of global data structures (symbol tables), that
can be read and updated being at an arbitrary node of the syntax tree.
Therefore, the semantic action approach is very efficient concerning space.  
For compiler generating systems or, more generally, for all systems that work
on complete source objects and do not need incremental updates, this approach
is rather efficient.

\item[Attribute Grammars:] They describe properties of a language
by means of {\em semantic equations}. Design objects are represented as attributed
syntax trees. As opposed to the semantic action approach, the changes needed in case
of a program modification are given imlipicitly in the formalism. Therefore, the
design of attribute grammars does not have to consider the internal
representation of a design object. Obtaining a new, consistently
attributed tree after a modification is not a matter of design, but
can be done automatically by means of an incremental attribution
algorithm \cite{Knu68,Knu71,Reps83}. A major drawback of attribute
grammars is their considerable space consumption. This is due to the
fact that every node on the path between the node of information
creation and the node of information use must store all the propagated
information\footnote{This problem seems to be overcome by means of
{\em remote attribute updating}. The {\em synthesizer generator}
permits a restricted form of such remote access.}.  
\end{description}

The {\em Synthesizer Generator} (henceforth called {\em sgen}), developed
by Thomas Reps and Tim Teitelbaum at Cornell University, accepts an attributed
grammar as its input and constructs a {\em full screen editor} from this grammar. The
editor accepts exactly the words (structured text objects) that can be derived by
the given grammar and executes the semantic checks and actions specified there. The
grammar must be written in a language that has been developed specifically for the
definition of attribute grammars, namely the {\em Synthesizer
Specification Language}. In order to process the specification and to
construct the editor, the following actions are taken:
\begin{enumerate}
\item The grammar is parsed whereby completeness (exactly one semantic equation must
exist for every nonterminal in the affected productions) and termination (every
sequence of derivations must have a terminating production) are checked.

\item The generator tests the grammar for ``orderedness''. This can be done in
polynomial time. 

\item Lexical definitions (regular expressions) are passed to Lex
\cite{LeSc75} which constructs a finite automaton for the lexical
analysis according to the specified regular expressions.

\item Parsing rules are translated into a form that is suitable as an
input for the compiler generator Yacc \cite{Joh75}. Yacc is then called
to construct a pushdown automaton (which is implemented as a procedure
in {\em C} source code) according to these rules.

\item Evaluation strategies are computed for every possible situation and translated
into {\em C} procedures.

\item Transformations and {\em unparsing} declarations are translated
into appropriate sequences of function calls.

\item The created {\em C} program is compiled and the library functions
supplied by the editor are linked.
\end{enumerate}

The Synthesizer Generator Specification Language is a strongly typed,
side-effect free language based on the concept of a {\em term algebra}
defining sets of operator-operand trees (i.e.\ abstract syntax trees).
The trees that can be derived from a given nonterminal are considered
as {\em terms}. The operators of these terms denote nodes of a tree
whereas the operands denote subtrees, hence terms again. Nullary
operators are the atomic objects of these trees (leaves).

Since operators are associated uniquely with a production of the grammar,
the definition of a set of trees may be considered as a type definition for the
nonterminal which generates these trees. Attribute definitions are
carried out in the same way and therefore attribute values are
abstract syntax trees themselves. Simple predefined types\footnote{
The predefined simple types are integer, real, bool, char, string, and
references.} are (possibly infinite) sets of primitive trees (they
only consist of the root of a tree).

For a more detailed discussion of the particular DBPL-USE specification and
generation process see \cite{Nieb91}.

\subsection{The Language-Sensitive Editor DBPL-USE}

In a multi-lingual and semi-formal environment like DAIDA there will always be a
need for the production of language texts under user control. On the CML level, this
is the only way to get information into the system, but also on lower levels pieces
of code will have to be produced manually. On the DBPL level, for example, there may
be specific sets of formally justified {\em definition modules} for which -- at a
given system development stage -- the {\em implementation modules} may be hand-coded
or re-coded, e.g., for prototyping or for reasons of performance. DBPL-USE supports
those needs for ``programming in the small'' by enforcing the interfaces of the
definition modules plus all the syntactic and semantic rules of the DBPL language.
Furthermore, it enforces the standards that have been set for program documentation
and layout.

A text that has been edited by DBPL-USE is known to be more than
just a sequence of characters; instead, the global knowledge base can be made aware
of the fact that the text is a DBPL program which meets guaranteed semantic and
syntactic criteria. The extent to which the knowledge represented by the tool may
become explicit and common knowledge via the global knowledge base depends, of
course, on the knowledge representation framework used in both components.

The central objectives of the implementation of DBPL-USE are semantic support
for the strong typing of DBPL and syntactic support for expanding and
restructuring of programs. Thereby, the user should have maximal
freedom in choosing his style of editing. This is achieved by enabling
menue driven insertions of every possible language construct as well
as text input and parsing even for structures of low granularity.
Furthermore, not only program expansions can be accomplished by
selecting menue items but also restructurings of DBPL statements,
simplifications of boolean expressions and derivations of (frames for)
implementation modules out of definition modules and vice versa.

The DBPL-USE objectives are accomplished by extracting the context information from
DBPL language constructs and using it to check contextual constraints
which can be roughly characterized through the notions {\em type},
{\em scope} and {\em mode}:
\begin{description}
\item[Type Rules] Since DBPL is a {\em statically typed} language,
complete type consistency checks can be done at compile time. DBPL-USE
utilizes the incremental availability of typing information to do type
checks at the earliest possible point in time, i.e., at edit time. The
uniformity of the DBPL type rules across all DBPL objects --- from
volatile computational data (e.g. boolean variables) to persistent
databases greatly improves the exploitation of type information by the
editor.

\item[Scope Rules] The {\em scope} of an identifier is the part of the
program text in which it may be referenced. Scope rules
determine the various scopes depending on the positions where the
identifiers are declared. As it is the case in DBPL, the possible
regions can also depend on the kind of usage (e.g., use within
statements or within declarations). The application of scope rules
associate every applied occurence of an identifier uniquely with the
proper declaration. The scope rules of block-structured languages like
Pascal or C are refined in DBPL as follows: (1) the scope of
\e{exported} identifiers can be extended by import declarations to
other, non-nested scopes; (2) identifiers introduced in \kw{for each}
and \kw{with} statements or in quantified expressions  (\kw{some, all,
each}) have a scope that is local to individual subexpressions or
statements.

Sophisticated scope rules (like the rules encountered in DBPL)
support higher levels of abstraction in the organization of large
systems. The concept of locality allows programmers to concentrate on
a small, understandable set of names, abstracting from  declarations
which are valid elsewhere in the system.

\item[Object Modes] The {\em mode} of an object denotes the possible
usage of this object in the context of expressions, statements,
declarations etc. In this way, additional control concerning
accidental use is imposed. In programming languages the mode usually
is declared by a keyword preceding the object declaration (e.g.,
\k{type}, \k{var}), but some modes are given implicitly.  For
instance, the declaration of a procedure defines a {\em constant}
object. This object may be used as a statement or in assignments to
procedure variables but not as the target of an assignment. DBPL
provides the following object modes: constant, variable, type, value
parameter, variable parameter, field, tagfield, procedure,
transaction, selector, constructor and module.

\end{description}

\subsection{A Session with DBPL-USE}

The editors functionality is illustrated by a small but typical editor
session. If the editor is started without any input file the following
pattern is displayed in a newly created window:
\begin{xple}
\k{module} $<$name$>$
\k{begin}
   $<$statement$>$
\k{end} $<$name$>$.
\end{xple}
The symbols included in ``$<$ $>$'' are placeholders refering to
nonterminals of the DBPL grammar. They denote positions where the
program is syntactically incomplete.

\begin{figure}[htb]
\centerline{\epsfbox[0 0 250 230]{scr-dump2.ps}}
\caption{Pop-up-menue and transformation selection} 
\label{scr-dump1}
\end{figure}

\begin{figure}[htb]
\centerline{\epsfbox[0 0 250 230]{scr-dump1.ps}}
\caption{Change propagation and incompatibility messages}
\label{scr-dump2}
\end{figure}

From the transformations enabled at the current source text position
-- corresponding to the root of the DBPL grammar -- the expansions
\kw{Def-Module} and \kw{Imp-Module} and the option \kw{Database} are
enabled. The user selects \kw{Imp-Module}. After inserting the module
name and selecting the (not yet expanded) node \kw{$<$statement$>$},
the user chooses to display the actual transformation menue to choose a
DBPL statements to be inserted at this source code position (see
Fig.~\ref{scr-dump1}). After a few more steps, the user has expanded
the program by some type, variable and transaction declarations. By
renaming the attribute \kw{Name} in the record type \kw{Person}, two
program inconsistencies are detected by the editor and immediately
tagged by the error message \kw{``identifier not declared''} within
the source text (see Fig.~\ref{scr-dump2}).  

The current DBPL-USE implementation includes full recognition of the
extended type-complete syntax of DBPL and provides full type and mode
checking as well as control of internal import and export of DBPL
objects.

Under the assumption that for some applications the user community of
a specific \e{database} may exceed that of a certain (special-purpose)
\e{language}, we are considering specializations of DBPL-USE to
editors that are sensitive to specific sets of DBPL modules, thus
providing editors that provide programming against specific DBPL
databases.

