Skip to content

Latest commit

 

History

History
51 lines (33 loc) · 4.74 KB

architecture.md

File metadata and controls

51 lines (33 loc) · 4.74 KB

>> Title << >> Synopsis << >> Contents << >> API Index <<


Library Overview

Architecture

To use RACR within Scheme programs, it must be imported via (import (racr core)). The imported library provides a set of functions for the specification of AST schemes, their attribution and the construction of respective ASTs, to query their information (e.g., for AST traversal or node type comparison), to evaluate their attributes and to rewrite and annotate them.

Every AST scheme and its attribution define a language -- they are a RACR specification. Every RACR specification can be compiled to construct the RACR language processor it defines. Every RACR AST is one word in evaluation by a certain RACR language processor, i.e., a runtime snapshot of a word in compilation w.r.t. a certain RACR specification. Thus, Scheme programs using RACR can specify arbitrary many RACR specifications and for every RACR specification arbitrary many ASTs (i.e., words in compilation) can be instantiated and evaluated. Thereby, every AST has its own evaluation state, such that incremental attribute evaluation can be automatically maintained in the presence of rewrites. Figure 2.1 summarises the architecture of RACR applications. Note, that specification, compilation and evaluation are realised by ordinary Scheme function applications embedded within a single Scheme program, for which reason they are just-in-time and on demand.

runtime-structures

Figure 2.1: Runtime structures/entities of RACR Applications

The relationships between AST rules and attribute definitions and ASTs consisting of nodes and attribute instances are as used to. RACR specifications consist of a set of AST rules, whereby for every AST rule arbitrary many attribute definitions can be specified. ASTs consist of arbitrary many nodes with associated attribute instances. Each node represents a context w.r.t. an AST rule and its respective attributes.

Instantiation

Three different language specification and application phases are distinguished in RACR:

  • AST Specification Phase
  • AG Specification Phase
  • AST construction, query, evaluation, rewriting and annotation phase (Evaluation Phase)

The three phases must be processed in sequence. E.g., if a Scheme program tries to construct an AST w.r.t. a RACR specification before finishing its AST and AG specification phase, RACR will abort with an exception of type racr-exception incorporating an appropriate error message. The respective tasks that can be performed in each of the three specification phases are:

  • AST Specification Phase Specification of AST schemes
  • AG Specification Phase Definition of attributes
  • Evaluation Phase One of the following actions:
    • Construction of ASTs
    • Querying AST information
    • Querying the values of attributes
    • Rewriting ASTs
    • Weaving and querying AST annotations

The AST query and attribute evaluation functions are not only used to interact with ASTs but also in attribute equations to query AST nodes and attributes local within the context of the respective equation.

Users can start the next specification phase by special compilation functions, which check the consistency of the specification, throw proper exceptions in case of errors and derive an optimised internal representation of the specified language (thus, compile the specification). The respective compilation functions are:

  • compile-ast-specifications: AST => AG specification phase
  • compile-ag-specifications: AG specification => Evaluation phase

To construct a new specification the create-specification function is used. Its application yields a new internal record representing a RACR specification, i.e., a language. Such records are needed by any of the AST and AG specification functions to associate the specified AST rule or attribute with a certain language.

API

The state chart of Figure 2.2 summarises the specification and AST and attribute query, rewrite and annotation API of RACR. The API functions of a certain specification phase are denoted by labels of edges originating from the respective phase. Transitions between different specification phases represent the compilation of specifications of the source phase, which finishes the respective phase such that now tasks of the destination phase can be performed.

user-interface

Figure 2.2: RACR Application Programming Interface

Remember, that RACR maintains for every RACR specification (i.e., specified language) its specification phase. Different RACR specifications can coexist within the same Scheme program and each can be in a different phase.