\section{Advanced Language-Sensitive Environments}
\label{alse}

Up to this section this chapter was mainly concerned with the controlling 
aspects of semantic knowledge incorporated into language sensitive editors.
The current section however treats the usage and generation of environment
information. That is, access to the database schema by DBPL-USE and access
to related abstract machines as well as generation of GKBMS information by
AM-USE.


\subsection{Semantic Guidance of the Editing Process}

\subsubsection{Database Sensitivity}
\label{db-sens}

The type rules of DBPL as described in section~\ref{dbpl-spec} apply likewise
to database objects. This uniformity enables DBPL-USE to treat database schemata
as ordinary DBPL types and database objects as variables exported
by persistent modules.

To achieve database sensitivity, two approaches are feasible:
\begin{enumerate}
\item Runtime access to database schemata defined within database definition
modules via an import interface.
\item The information contents of a given set of database definition
modules defining a DBPL database schema is incorporated within an {\em instance}
of DBPL-USE.
\end{enumerate}
The first approach allows the usage of the external interface mentioned
within section~\ref{dbpl-spec} and leads to an editor which is sensitive to
arbitrary DBPL database schemata.

The second approach leads to editors which are sensitive to syntax and semantics
of {\em specific} DBPL databases. This approach has the advantage to enable
the inclusion of integrity constraints like access restrictions within the
semantic checking component of DBPL-USE. Such constraints are not
part of DBPL database schemata. Furthermore, updatable database views could
be implemented by
specializing instances of DBPL-USE even more. Thereby the transformation
component of DBPL-USE could carry out the mapping from a database view
onto the database schema, i.e.,\ the required query transformations.
The run time behaviour of the second approach is superior to that of the
first one, since less runtime activities are required.

Considering the longevity of databases
and the size of the user community of a specific database, the loss
of general applicability of the specialized instances of DBPL-USE
implied by the second approach could pay off well.


\subsubsection{Refinement Relationships over Abstract Machines}

The syntax of a refined machine varies little from the above defined syntax
for machines at the specification level. The two extensions are:
\begin{itemize}
\item the introduction of an additional machine clause (IMPORT)
\item in case of data refinement an expanded role of the invariant.
The invariant has to
cope additionally the definition of the abstraction relation between 
variables of the more abstract machine and those of the more concrete 
machine.
\end{itemize}
...\\
We have additional constraints concerning the relationship between a machine
and it's
refined machine. The refined machine has to have the same name as the more
abstract machine differing only through a level number. Additionally the 
refined machine needs to provide the same signature as the more abstract
machine, i.e. it has to have the same number of operations, it corresponds in their
names and their input and output parameters.


\subsection{Documentation of Refinement Information}
