Fix the wording of docs. More docs content. Drop obsolete stuff.
This commit is contained in:
Fedor Isakov
parent
427ec8f4ef
commit
8281e037a4
|
|
@ -3,6 +3,6 @@ layout: print
|
|||
menu: false
|
||||
---
|
||||
|
||||
Revision: 0.5.0
|
||||
Type inference and type checking is a problematic area for language authors — users of JetBrains MPS, because of inherent intricacies of the problem and sometimes inadequate support from the framework.
|
||||
|
||||
Date: Aug 23, 2018
|
||||
*Code Rules* is a new technology that brings logic programming in the form of constraints processing as a vehicle for implementing type inference.
|
||||
|
|
|
|||
|
|
@ -6,38 +6,43 @@ weight: 40
|
|||
|
||||
# Evaluating Code Rules
|
||||
|
||||
***Two stage process***
|
||||
The process of evaluating code rules consists of two stages:
|
||||
|
||||
## Aspects
|
||||
1. Collecting handlers and applying rules.
|
||||
2. Processing constraint productions collected in the first stage.
|
||||
|
||||
***Aspects***
|
||||
Stage one is executed in the background in a read action, and is expected to finish quickly. Stage two is executed on a worker thread and does not require reads or writes. After the second stage is finished there is a short write action which «publishes» collected types.
|
||||
|
||||
## Applying rule templates
|
||||
### Applying rule templates
|
||||
|
||||
The first stage of evaluating code rules is applying handlers. Handlers are collected from corresponding aspects of all languages imported into the model.
|
||||
The first stage of evaluating code rules begins with collecting handlers. Handlers are collected from corresponding aspects of all languages imported into the model. In addition to that, all extended languages are also included into the scope.
|
||||
|
||||
As rules are applied to source model nodes, they produce constraint productions generated from templates. The order of productions is kept as defined by handlers, with handlers from extension languages having higher priority.
|
||||
All handlers collected in the previous step are sorted, so that the ones coming from extensions appear earlier. This sorting order ensures that when productions are selected to match an active constraint, with the productions coming from extensions having higher priority.
|
||||
|
||||
As well as generating constraint productions, the rules are allowed to report messages to be displayed at source locations.
|
||||
After the relevant handlers are collected, the source model is traversed from the specified location, and the applicable rules are evaluated. As rules are applied to source model nodes, they produce constraint productions generated from templates. As well as generating constraint productions, the rules are allowed to report messages to be displayed at source locations.
|
||||
|
||||
Generated productions constitute the constraints program, which is then executed.
|
||||
Generated constraint productions constitute the constraints program, which is then executed in the next stage.
|
||||
|
||||
## Running constraints program
|
||||
### Running constraints program
|
||||
|
||||
In the second stage the constraints program is run. To begin execution, a query is selected, which contains the list of constraints to be activated. Query can be viewed as a regular production, which is triggered unconditionally right after all headless productions (marked as «on start») have fired.
|
||||
In the second stage the constraints program is executed.
|
||||
|
||||
***Order of productions firing***
|
||||
To begin execution, a *query* is selected, which contains the list of constraints to be activated. Query can be viewed as a regular production, which is triggered unconditionally, but no earlier than all headless productions (marked as «on start») have fired.
|
||||
|
||||
There is a fixed order in which productions are fired on start of program execution. First, all «on start» productions are triggered. All constraints activated by these productions are processed normally, and after there are no more productions to be triggered, the query is fired.
|
||||
|
||||
Order of productions fired:
|
||||
- on start
|
||||
- query
|
||||
1. «on start»
|
||||
2. productions in a query
|
||||
|
||||
While constraints program is run, it is allowed to report feedback, such as assign calculated types or report problems, using special predicates.
|
||||
While constraints program is run, it is allowed to report feedback, such as assign calculated types or report problems, using special constructs, that are available as predicates in the body of production.
|
||||
|
||||
***Feedback predicates example***
|
||||
|
||||
Failures during evaluation are caught with the help of alternative body branches, where those are provided. An uncaught failure terminates program execution and is reported to the user.
|
||||
|
||||
## Activation trace view
|
||||
***Alternative body example***
|
||||
|
||||
### Activation trace view
|
||||
|
||||
***Activation trace view***
|
||||
|
|
|
|||
|
|
@ -35,4 +35,4 @@ The rule’s body activates `valid()` constraint, therefore only reasonings that
|
|||
Finally, if the proof’s goal is marked valid, it is assigned «Ok» type, otherwise it is marked with error.
|
||||
|
||||
|
||||
[^inlog]: Stanford Introduction to Logic http://logic.stanford.edu/intrologic/homepage/index.html
|
||||
[^inlog]: Stanford Introduction to Logic [http://logic.stanford.edu/intrologic/homepage/index.html](http://logic.stanford.edu/intrologic/homepage/index.html)
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Whereas `assignment` does something more: it ensures that the actual type on the
|
|||
|
||||
_(typechecking of assignment expression)_
|
||||
|
||||
## Type Relations
|
||||
### Type Relations
|
||||
|
||||
Several kinds of relations on types are defined, surveyed in the following table.
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ Several kinds of relations on types are defined, surveyed in the following table
|
|||
| subclassing | `promote()` | subtyping among classifier types |
|
||||
| containment | `containedIn()` | type parameter containment |
|
||||
|
||||
### Conversion
|
||||
#### Conversion
|
||||
|
||||
Constraint `convertsTo()` ensures that a type can be converted to another type, that is a type A can be used instead of type B. To test if a type is acceptable in certain locations, including those that allow any type, the constraint `compatibleWith()` is used, which delegates to `convertsTo()`.
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ In its turn, `convertsTo()` delegates to either `primSubtype()`, which is respon
|
|||
|
||||
_(`convertsTo()` delegates to `promote()` for classifier type)_
|
||||
|
||||
### Subclassing
|
||||
#### Subclassing
|
||||
|
||||
Resolution of `promote()` constraint, which represents subtyping among classifier types, is implemented around a simple idea of representing all subclass paths the root (Object) to a classifier as a set of lists. This representation deliberately ignores the class parameters. As a first step, the shortest path from supertype’s classifier to subtype’s one is selected. This path is then reversed and represented as a dataform list. This makes it possible to pattern-match on this list, since it is nothing more than a cons list represented as a dataform.
|
||||
|
||||
|
|
@ -98,50 +98,3 @@ Suppose we need to decide if `Long <: Serializable`, that is if `Long` is a subt
|
|||
|
||||
|
||||
|
||||
|
||||
- types
|
||||
- term table for types
|
||||
- classifier type
|
||||
- type var type
|
||||
- capture type
|
||||
- array/vararity type
|
||||
- upper/lower bound type
|
||||
- wildcard type
|
||||
- primitive type: int, bool, etc.
|
||||
- void and null
|
||||
- macro table
|
||||
- classifier type
|
||||
- type var type
|
||||
- bounds
|
||||
- parameterised types
|
||||
- types with value
|
||||
- Query
|
||||
- Typecheck
|
||||
- checkall, recoverall
|
||||
- ConvertsTo
|
||||
- convertsTo()
|
||||
- Typechecking
|
||||
- Constant values
|
||||
- string
|
||||
- integer, long, char, …
|
||||
- expression
|
||||
- dotexpression, dot operation
|
||||
- method call
|
||||
- **type parameter substitutions**
|
||||
- equals/assignment/+assignment
|
||||
-
|
||||
- ???
|
||||
- method declaration
|
||||
- type relations
|
||||
- boxing
|
||||
- capture
|
||||
- coerce
|
||||
- conversion
|
||||
- primitive subtyping
|
||||
- subclassing/promote
|
||||
- type parameter
|
||||
- containment, hasbound
|
||||
- type annotations
|
||||
- classifier type
|
||||
- type parameters: type var, bound type, wildcard
|
||||
-
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 871 B |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.4 KiB |
|
|
@ -15,7 +15,7 @@ _(statement in `j.m.lang.typesystem` language)_
|
|||
|
||||
Albeit brief and concise, this notation leaves many questions unanswered when it comes to how exactly the system of equations and inequalities is processed. In other words, type inference is — for the most part — left up to the internal engine to decide. This limits the options for the author of type system to control how exactly subtyping is defined, and what happens with type parameters when computing sub- or supertype. Java, for instance, has several kinds of «conversions» with clearly defined rules controlling how types are transformed and what types are compatible in certain situations. All of this has to be emulated with «strong» and «weak» subtyping in MPS.
|
||||
|
||||
Another example is the all too well known *when_concrete*, which is basically a suspended block that gets executed when the type, that serves as its parameter, is computed. Sometimes this never happens during type inference, which results in numerous «*when concrete is never concrete*» warnings, leaving the user wondering what went wrong. This, however, is very much a necessary evil, since there are no other possibilities to hook into the engine in order to spy on types, and knowing the exact form of a type is sometimes required for further inference.
|
||||
Another example is all too well known *when_concrete*, which is basically a suspended block that gets executed when the type, that serves as its parameter, is computed. Sometimes this never happens during type inference, which results in numerous «*when concrete is never concrete*» warnings, leaving the user wondering what went wrong. This, however, is very much a necessary evil, since there are no other possibilities to hook into the engine in order to spy on types, and knowing the exact form of a type is sometimes required for further inference.
|
||||
|
||||
Consider how the type of a method call is calculated: the details aside, in essence *when_concrete* has to be applied to the type of each argument. Then we should either turn to inequalities and rely on the inference engine, or analyse the type structure and run closing computation when the *last* unknown type is finalised.
|
||||
|
||||
|
|
@ -26,13 +26,15 @@ Code rules may have a solution to these and other issues. The core idea is to em
|
|||
|
||||
The following is the list of features made available to users of MPS with *code rules* plugin.
|
||||
|
||||
A language `jetbrains.mps.lang.coderules` containing concept definitions for building rules that serve as production templates, and as regular «checking» rules. The templates may be concept-specific or standalone in order to provide constraints that are invariant for every invocation.
|
||||
- A language `jetbrains.mps.lang.coderules` with concept definitions for building rules that serve as production templates, and as regular «checking» rules. The templates may be concept-specific or standalone, if there is a need to provide constraints that are invariant for every invocation.
|
||||
|
||||
An extension of CHR[^chr] semantics allowing the use of unification in production head with automatic binding of logical variables on successful match. This extension also supports limited backtracking, as well as calling arbitrary Java code. Representing the inference in the form of logical productions helps achieve extensibility, as productions defined by extension languages can be easily blended in.
|
||||
- *Constraint Processing System* — an extension of CHR[^chr] semantics allowing the use of unification in production’s head with automatic binding of logical variables on successful match. This extension also supports limited backtracking, as well as calling arbitrary Java code. Representing the inference in the form of logical productions helps achieve extensibility, as productions defined by extension languages can be easily blended in.
|
||||
|
||||
A framework for evaluating a constraints program, enabling reporting of problems from the production body, as well as a façade interface for accessing the results of the program evaluation. The UI also includes a tracing tool for providing insights into how constraints are handled.
|
||||
- A framework for evaluating a constraints program, enabling reporting of problems from the production body, as well as a façade interface for accessing the results of program evaluation. The UI also includes a tracing tool for providing insights into how constraints are handled.
|
||||
|
||||
Finally, an embedded engine capable of processing constraints, which accepts a list of productions, an initial active constraint, and, optionally, a store of inactive constraints, and yields an updated store after all matched productions have been fired.
|
||||
- Finally, an embedded engine capable of processing constraints, which accepts a list of productions, an initial active constraint, and, optionally, a store of inactive constraints, and yields an updated store after all matched productions have been fired.
|
||||
|
||||
Examples are provided that demonstrate the use of this technology for type checking and other analyses.
|
||||
|
||||
|
||||
[^mps]: Meta Programming System [https://jetbrains.com/mps](https://jetbrains.com/mps)
|
||||
|
|
|
|||
|
|
@ -6,67 +6,77 @@ weight: 30
|
|||
|
||||
# Code Rules Language
|
||||
|
||||
***This section should teach how to use the language***
|
||||
### Language Aspect
|
||||
|
||||
Root concepts should be contained by a language aspect model importing the language `jetbrains.mps.lang.coderules`. For example, language `jetbrains.mps.lang.typechecking` defines aspect *types* to contain code rules related to type checking.
|
||||
Code rules are declared by handlers, which are root concepts of language `jetbrains.mps.lang.coderules`. Handlers and other roots should be created in a language’s aspect model corresponding to a specific kind of analysis. Language `jetbrains.mps.lang.typechecking` declares the aspect `types`.
|
||||
|
||||
### Root concepts
|
||||
|
||||
_(definition of aspect `types`)_
|
||||
|
||||
#### Root concepts
|
||||
|
||||
The following table contains the root concepts that belong to code rules definition.
|
||||
|
||||
| Concept | Description |
|
||||
|:-- |:-- |
|
||||
| *Handler* | contains rule templates and constraint declarations |
|
||||
| *MacroTable* | defines how terms are constructed |
|
||||
| *Handler* | contains rules and constraint declarations |
|
||||
| *Query* | entry point to the constraints program |
|
||||
| *MacroTable* | defines how terms are constructed |
|
||||
| *DataFormTable* [^dft] | defines terms, the data structure that is used in unification |
|
||||
|
||||
### Rule templates
|
||||
|
||||
### Handler
|
||||
|
||||
*Handler* serves two purposes: it declares the constraints that can be used in the *head* of productions in this handler and its extensions, and it also declares *rule templates*, which are, simply put, procedures applicable to specific concept and (optionally) its subconcepts.
|
||||
*Handler* serves two purposes: it declares the constraints that can be used in the *head* of productions in this handler and its extensions, and it also declares *rules*, which are, simply put, procedures applicable to specific concept and (optionally) its subconcepts.
|
||||
|
||||
The aim of rule templates is again twofold: firstly, they may serve as regular «checking» rules, and also, most importantly, they contribute constraint productions. These are created with a DSL that allows mixing of productions and Java code, and can also use template fragments (thus «rule templates»).
|
||||
#### Rules
|
||||
|
||||
The following example is from the experimental *control flow* aspect for baseLanguage. It demonstrates how a production is constructed using a template. A template is enclosed into a pair of `%% … %%` symbols and yields constraints wrapped into special `<% … %>` brackets. In this particular case `write()` constraint is optional and is only added to the body of the production in case the condition is satisfied (a location is written to, only if the local variable has an initialiser).
|
||||
The aim of rules defined by handlers is again twofold: firstly, they may serve as regular «checking» rules, and also, most importantly, they contribute constraint productions. These are created with a DSL that allows mixing of productions and Java code, and can also include constraint fragments inside a production template.
|
||||
|
||||
The following example is from the experimental *control flow* aspect for baseLanguage. It demonstrates how a production is constructed using a template. A production template is enclosed into a pair of `%% … %%` symbols and yields constraints wrapped into special `<% … %>` brackets. In this particular case `write/2` constraint is optional and is only added to the body of the production in case the condition is satisfied (a location is written to only if the local variable has an initialiser).
|
||||
|
||||
|
||||
_(example of code rule template)_
|
||||
_(example of rule with production template)_
|
||||
|
||||
A handler is a concept in language `jetbrains.mps.lang.coderules`.
|
||||
|
||||
|
||||
_(example of a handler declaration — without contents)_
|
||||
|
||||
Keyword `extends` allows to specify another handler, which is extended by this one. All constraint productions generated by rules in this handler will have higher priority. This enables to override the original handler’s behaviour.
|
||||
Keyword `extends` allows to specify another handler, which is to be extended. All constraint productions generated by rules in this handler will have higher priority. This enables to override the original handler’s behaviour.
|
||||
|
||||
Only declared constraints are allowed to be used in the heads of productions in rule templates. Handler should declare one or more constraints, unless it only uses the constraints from handlers being extended. Constraint declaration consists of name and arity, which together constitute a *constraint symbol*. Constraint’s arity is fixed.
|
||||
Only declared constraints are allowed to be used in the heads of productions in rules of this handler or its extensions. Handler should declare one or more constraints, unless it only uses the constraints from handlers which it extends. Constraint declaration consists of name and *arity*, which together constitute a *constraint symbol*. Constraint’s arity is fixed.
|
||||
|
||||
Rule templates can specify applicable concept, either exactly or including its subconcepts. One can also declare *standalone* templates, which are triggered automatically on every invocation of constraints program.
|
||||
Rules can specify applicable concept, either exactly or including its subconcepts. One can also declare *standalone* rules, which are triggered automatically on every rules application.
|
||||
|
||||
|
||||
_(rule template matching concept instances with condition block)_
|
||||
_(example of rule matching concept instances with condition block)_
|
||||
|
||||
A condition, is specified, is checked before applying the rule.
|
||||
An applicability condition, if specified, is checked before applying the rule.
|
||||
|
||||
|
||||
_(standalone rule template without input)_
|
||||
_(example of standalone rule without input)_
|
||||
|
||||
The contents of a rule template is a block of code that gets executed when the template is applied to the source model. If the input is specified, the declared parameter is available in the body. When no input is specified, the rule becomes «standalone» and is automatically executed once per every application of templates.
|
||||
Contents of a rule is a block of code that gets executed when the rule is applied to the source model. If the input is specified, the declared parameter is available in the body. When no input is specified, the rule becomes «standalone» and is automatically executed once per every rules application.
|
||||
|
||||
***What other features are available aside from constraint productions?***
|
||||
Rules may affect the scope of model locations that are processed during the application session. Suppose a production responsible for typechecking a location relies on presence of productions that are only available if some other location is processed as well. To guarantee that a certain model location is processed during the application session one uses `require` statement.
|
||||
|
||||
Constraint productions can be created at any place within the body of a rule template. A production has three main parts called head, guard, and body. The head defines what constraint trigger this production, and it can only contain constraints defined by the handler or one of the handlers it extends. The body can contain any visible constraints, as well as *predicates*. A production must include either the body or the head, no production can omit both. The guard is optional, and it can only contain predicates.
|
||||
|
||||
_(example of using `require` statement)_
|
||||
|
||||
#### Constraint Productions
|
||||
|
||||
*Constraint productions* can be created at any place within rule body. A production has three main parts called head, guard, and body. The head defines what constraint trigger this production, and it can only contain constraints defined by the handler or one of the handlers it extends. The body can contain any visible constraints, as well as *predicates*. A production must include either the body or the head, no production can omit both. The guard is optional, and it can only contain predicates.
|
||||
|
||||
Both the head and the body can declare *logical variables*. By default a logical variable ranges over *terms*, although any POJO may be serve as a value.
|
||||
|
||||
|
||||
_(constraint production declaring logical variables)_
|
||||
|
||||
A production with an empty head, that is not declaring any constraints to serve as the input, is considered an *automatic* production and is triggered automatically on start of constraints program execution.
|
||||
A production with an empty head, not declaring any constraints to serve as the input, is considered an *automatic* production and is triggered automatically on start of constraints program evaluation.
|
||||
|
||||
In production’s head constraints can be declared as either *kept* or *replaced*. Briefly put, the constraints that are *kept* are left alone after a production is fired, whereas the *replaced* ones are discarded after the head has been matched. Replaced constraints are marked with tilde `~`.
|
||||
|
||||
A production is triggered when there are constraint occurrences matching all constraints in production’s head. When a constraint with logical variable as one of its arguments is matched, that variable becomes bound to the corresponding argument of the matching occurrence. The scope of this binding is the guard and the body of the production.
|
||||
A production is triggered when there are constraint occurrences matching all constraints in production’s head. When a constraint with logical variable as one of its arguments is matched, that variable becomes bound to the corresponding argument of the matching occurrence. The scope of the binding is this production’s guard and body.
|
||||
|
||||
Pattern matching is also possible with terms, optionally containing logical variables, serving as patterns. For this to work, a logical variable that serves as a constraint argument should have a pattern attached.
|
||||
|
||||
|
|
@ -76,18 +86,18 @@ _(production with pattern matching)_
|
|||
Everywhere where locations in the source code (model) must be referenced, node references are used, which are introduced with the `@` symbol.
|
||||
|
||||
|
||||
_(example of a constraint argument referring to a location)_
|
||||
_(example of constraint argument referring to a location)_
|
||||
|
||||
Whereas the production’s head can only contain constraints, there are also other logical clauses that are used in the guard and the body.
|
||||
Whereas the production’s head can only contain constraints, there are also other logical clauses that are used in guard and body.
|
||||
|
||||
A *predicate* is a built-in construct that serves two purposes: when used in the guard, it serves to query if a condition is satisfied, and when used in the body it asserts this condition. An example is `unifies` predicate displayed as `=`, which tests if its arguments can be unified. There are also predicates that can only be queries, such as `isFree()` or `isBound()` testing if a logical variable is free or has value assigned.
|
||||
A *predicate* is a built-in construct that serves two purposes: when used in guard, it serves to query if the condition is satisfied, and when invoked from body, it asserts the condition. An example is `unifies` predicate, displayed as `=`, which tests if its arguments can be unified if used in guard, and invokes the actual unification if called from body. There are also predicates that can only be queries, such as `isFree/1` or `isBound/1`, testing if a logical variable is free or has value assigned.
|
||||
|
||||
Production’s guard can only contain predicates, and the body can contain both constraints and predicates.
|
||||
|
||||
|
||||
_(`unifies` predicate used in the guard and in the body)_
|
||||
|
||||
Arbitrary Java code can be called with `eval()` predicate. It accepts either an expression of `boolean` type, in which case it can be used in the guard, or expression of any type, such as static method call, which can be inserted in the body.
|
||||
Arbitrary Java code can be called with `eval/1` predicate. It accepts either an expression of `boolean` type, in which case it can be used in guard, or expression of any type, such as static method call, which is available in body.
|
||||
|
||||
|
||||
_(example of using `eval()` predicate)_
|
||||
|
|
@ -100,7 +110,7 @@ _(example of using `eval()` predicate)_
|
|||
|
||||
#### Query
|
||||
|
||||
Query is the entry point to a constraint program. The only purpose of a query is to activate constraints that trigger computation defined by productions created by handlers.
|
||||
Query is the entry point to a constraint program. The only purpose of a query is to activate constraints that trigger computation implemented by constraint productions.
|
||||
|
||||
|
||||
_(example of a query)_
|
||||
|
|
@ -109,7 +119,7 @@ A query is discovered by the API through its *kind*. Query kind specifies parame
|
|||
|
||||
#### Macro table
|
||||
|
||||
Macros allow to have parameterised constructors for terms. They can either create terms using nodes coming from the source model, or use the parameters to fill in values. By contrast with rule templates, macros are always explicitly invoked.
|
||||
Macros allow to have parameterised constructors for terms. They can either create terms using nodes coming from the source model, or use the parameters to fill in values. By contrast with rules, macros are always explicitly invoked.
|
||||
|
||||
This feature may come in handy when data types used by the constraint program are complicated and include many levels of containment. For example, type checking with *code rules* relies on types being terms, which means types can contain other types.
|
||||
|
||||
|
|
@ -122,15 +132,15 @@ Macro *expands* instances of specified concept. This means the macro can be invo
|
|||
|
||||
***Expand/call from production body***
|
||||
|
||||
Macro body is a code template, with every constraint or predicate produced from this template being inserted into the production body at the invocation site. There is a special logical variable available within macro body, `macroLogical`, which captures the logical variable on the left side of `expand` or `call` predicate.
|
||||
- Macro body is a code template, with every constraint or predicate produced from this template being inserted into the production body at the invocation site. There is a special logical variable available within macro body, `macroLogical`, which captures the logical variable on the left side of `expand` or `call` predicate.
|
||||
|
||||
***Substitutions***
|
||||
|
||||
#### DataForm table
|
||||
|
||||
DataForm table contains *data form* declarations, a.k.a. *terms*. A term is a simple recursive data type that is suitable for implementing unification. Also, terms can model any other data structure, in particular they are suitable for representing types in a programming language.
|
||||
DataForm table contains *dataform* declarations, a.k.a. *terms*. A term is a simple recursive data type that is suitable for implementing unification. Also, terms can model any other data structure, in particular they are suitable for representing types in a programming language.
|
||||
|
||||
Data form is defined by its symbol and its features, which can be a POJO, a child data form, or a list of data forms. A feature may have a default value provider. A data form extending another data form adds new features or provides default values for existing ones.
|
||||
Dataform is defined by its symbol and its features, which can be a POJO, a child dataform, or a list of dataforms. A feature may have a default value provider. A dataform extending another dataform adds new features or provides default values for existing ones.
|
||||
|
||||
|
||||
_(example of a dataform definition for classifier type)_
|
||||
|
|
|
|||
|
|
@ -6,47 +6,47 @@ weight: 20
|
|||
|
||||
# Overview
|
||||
|
||||
Analysis of source code (model) with *code rules* can be described as a two-phase process.
|
||||
Analysis of source code or model with *code rules* can be described as a two-phase process.
|
||||
|
||||
In the first phase, the languages used by the model being analysed and their prototypes (meaning the languages that are being *extended*, but not used directly) are surveyed for the appropriate code rules aspect model, which is «types» in case of type checking, for example. The contents of code rules aspect model is a contribution of this particular language. All templates are applied to the source code, with templates coming from extension languages having higher priority.
|
||||
In the first phase, the languages used by the model being analysed, and their prototypes (meaning the languages that are being *extended*, but not used directly) are surveyed for the appropriate *code rules* aspect model, which is `types` in case of type checking, for example. Contents of this aspect model is a contribution of this particular language. All rules within this model are applied to the source model, with rules coming from extension languages having higher priority.
|
||||
|
||||
The outcome of this phase is a constraints program, which is a collection of handlers, which in turn represent lists of productions. This «program», however, exists in memory only, it does not have textual representation. Aside from generating productions, the rules can also process the model normally, reporting errors as usual.
|
||||
The outcome of this phase is a *constraints program*, which is a collection of *handlers*, which in turn represent lists of *productions*. This «program», however, exists in memory only, it does not have any textual representation. Aside from generating productions, the rules can also process the model normally, reporting errors as usual.
|
||||
|
||||
This phase runs in «read action», therefore blocking potential writes, which means the editor may become unresponsive if a write action is requested. Ideally the rules should finish quickly and postpone all heavy load to the next phase, which can be run in the background, as the access to `SModel` is no longer necessary.
|
||||
The first phase runs in «read action», therefore blocking potential writes, which means the editor may become unresponsive if a write action is requested. Ideally the rules should finish quickly and postpone all heavy load to the next phase, which can be run in the background, as the access to `SModel` is no longer necessary.
|
||||
|
||||
The second phase is evaluation of the constraints program that was created in phase one. The evaluation starts with a query, which serves as an entry point to the program. For example, type system defines `TYPECHECK` and `CONVERT` queries, aimed at running type checking and testing if a type can be converted to another type, correspondingly. Queries are declared in the same aspect model.
|
||||
In the second phase the constraints program that was created in phase one is evaluated. Evaluation starts with a query, which serves as an entry point to the program. For example, type system defines `TYPECHECK` and `CONVERT` queries, aimed at running type checking and testing if a type can be converted to another type, correspondingly. Queries are declared in the same aspect model.
|
||||
|
||||
|
||||
_(example of a query)_
|
||||
|
||||
In the above example the query defines two logical variables (A and B) of type `term`, which serve to represent types internally. First, both query parameters `to` and `from` are *expanded*, meaning that their `SNode` representations are converted to terms, and then the constraint `convertsTo(A, B)` is activated, kicking off the process of evaluating the program. In case productions triggered by `convertsTo()` constraint all evaluate to true, the query is deemed successful, and if there is at least one production that evaluates to false, the query fails accordingly.
|
||||
In the above example, the query defines two logical variables (A and B) of type `term`, which serve to represent types internally. First, both query parameters `to` and `from` are *expanded*, meaning that their `SNode` representations are converted to terms, and then the constraint `convertsTo(A, B)` is activated, kicking off the process of evaluating the program. In case productions triggered by `convertsTo/2` constraint all evaluate to true, the query is deemed successful, and if there is at least one production that evaluates to false, the query fails accordingly.
|
||||
|
||||
One nice feature of using code rules is the ability to abstract away from type structure defined by the language. For example, one may decide to represent all primitive types as a term `primitive(kind=<specific kind>)`. Terms can also incorporate values, so creating an inference rule which checks if a particular constant fits the given type, be it an `int` or a `char`, is trivial.
|
||||
One nice feature of using code rules is the ability to abstract away from type structure defined by the language. For example, one may decide to represent all primitive types as a term `primitive(kind=<specific kind>)`. Terms can also incorporate values as regular Java objects, so creating an inference rule which checks if a particular constant fits the given type, be it an `int` or a `char`, is trivial.
|
||||
|
||||
Having an internal representation for types also means, that if type system is required to represent types as instances of `SNode` to the user, this has to be addressed by the query design. For instance, a type checking query may consist of two constraints:
|
||||
Having an internal representation for types also means, that if type system is required to represent types as instances of `SNode` to the user, this has to be addressed by the query design. For instance, a type checking query may consist of two constraint activations:
|
||||
|
||||
|
||||
_(example of a production)_
|
||||
_(example of a query production)_
|
||||
|
||||
Here, the first constraint `checkAll()` fires type checking, whereas the second `recoverAll()` is responsible for restoring terms to `SNode` instances and reporting them back to the user. Joining the two constraints with a conjunction establishes the order in which these are evaluated.
|
||||
Here, the first constraint `checkAll/0` fires type checking, whereas the second `recoverAll/0` is responsible for restoring terms to `SNode` instances and reporting them back to the user. Joining the two constraints with a conjunction establishes the order in which these are evaluated.
|
||||
|
||||
An of course, if something can go wrong, it will. In case type inference is unsuccessful, the second stage has no chance of being evaluated. To account for that, a partial backtracking was added to the language of production templates, which helps recover from certain failures.
|
||||
|
||||
|
||||
_(example of a production with alternative body branch)_
|
||||
_(example of a query production with alternative body)_
|
||||
|
||||
Here, `recoverAll()` constraint is moved out to an «*alternative branch*» of production body, which allows it to be activated even if there was an error while processing the main branch.
|
||||
Here, `recoverAll/0` constraint is moved out to an «*alternative branch*» of production body, which allows it to be activated even if there was an error while processing the main branch.
|
||||
|
||||
To illustrate how automatic binding of logical variables work, consider the following example. The constraint `typeOf()` associates a type with a location in source code, and `convertsTo()` ensures its 1st argument can be converted to the 2nd, which must both be types.
|
||||
To illustrate how automatic binding of logical variables work, consider the following example. Constraint `typeOf/2` associates a type with a location in source model, and `convertsTo/2` ensures its 1st argument can be converted to the 2nd, which must both be types.
|
||||
|
||||
|
||||
_(example of rule template)_
|
||||
_(example of rule with production)_
|
||||
|
||||
The production is triggered when both locations referred to by `ae.lValue` and `ae.rValue` have their types assigned, as both `typeOf()` constraints must be present for a match to be successful. Once production’s head is matched, both logical variables `LType` and `RType` become bound to whatever was the 2nd argument of first and second `typeOf()` constraint, respectively.
|
||||
This production is triggered when both locations referred to by `ae.lValue` and `ae.rValue` have their types assigned, as both `typeOf/2` constraints must be present for a match to be successful. Once production’s head is matched, both logical variables `LType` and `RType` become bound to whatever was the 2nd argument of either occurrences of `typeOf/2` constraint.
|
||||
|
||||
It’s important to note, that although on successful match both `lValue` and `rValue` have types, it’s not guaranteed that these types are *ground*. A type may be represented by a free logical variable, or a term containing free variables. Another very important thing to notice is that a logical variable enjoys full privileges of being an argument to a constraint. Which means, if in the above example both variables are free, and `LType = RType`, then both locations will have essentially the *same* type (in the sense of «same instance»), not just matching types.
|
||||
|
||||
The following example illustrates the use of *pattern matching* in production’s head. Here the first argument to constraint `convertsTo()` in the head is a logical variable with pattern expression. In this case the production will only be triggered if the active constraint’s first argument is not a free variable, and it matches the pattern.
|
||||
The following example illustrates the use of *pattern matching* in production’s head. Here the first argument to constraint `convertsTo/2` in the head is a logical variable with pattern expression. In this case the production will only be triggered if the active constraint’s first argument is *bound* (is not a free logical variable), and it matches the pattern.
|
||||
|
||||
|
||||
_(example of rule template)_
|
||||
_(example of rule with production)_
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
# TODO Evaluating Code Rules
|
||||
|
||||
- [ ] **aspects**
|
||||
- [ ] **UI**
|
||||
- [x] Two stages process
|
||||
- [x] apply all rule templates
|
||||
- [x] sort handlers by language
|
||||
|
|
@ -10,6 +8,8 @@
|
|||
- [x] build program
|
||||
- [ ] evaluate program
|
||||
- [ ] **report problems during evaluation**
|
||||
- [x] handle errors
|
||||
- [ ] **handle errors**
|
||||
- [ ] **UI**
|
||||
- [ ] **facade API**
|
||||
- [ ] **activation trace view**
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
- [ ] types
|
||||
- [ ] term table for types
|
||||
- [ ] classifier type
|
||||
- [ ] type var type
|
||||
- [ ] capture type
|
||||
- [ ] array/vararity type
|
||||
- [ ] upper/lower bound type
|
||||
- [ ] wildcard type
|
||||
- [ ] primitive type: int, bool, etc.
|
||||
- [ ] void and null
|
||||
- [ ] macro table
|
||||
- [ ] classifier type
|
||||
- [ ] type var type
|
||||
- [ ] bounds
|
||||
- [ ] parameterised types
|
||||
- [ ] types with value
|
||||
- [ ] Query
|
||||
- [ ] Typecheck
|
||||
- [ ] checkall, recoverall
|
||||
- [ ] ConvertsTo
|
||||
- [ ] convertsTo()
|
||||
- [ ] Typechecking
|
||||
- [ ] Constant values
|
||||
- [ ] string
|
||||
- [ ] integer, long, char, …
|
||||
- [ ] expression
|
||||
- [ ] dotexpression, dot operation
|
||||
- [ ] method call
|
||||
- [ ] **type parameter substitutions**
|
||||
- [ ] equals/assignment/+assignment
|
||||
- [ ]
|
||||
- [ ] ???
|
||||
- [ ] method declaration
|
||||
- [ ] type relations
|
||||
- [ ] boxing
|
||||
- [ ] capture
|
||||
- [ ] coerce
|
||||
- [ ] conversion
|
||||
- [ ] primitive subtyping
|
||||
- [ ] subclassing/promote
|
||||
- [ ] type parameter
|
||||
- [ ] containment, hasbound
|
||||
- [ ] type annotations
|
||||
- [ ] classifier type
|
||||
- [ ] type parameters: type var, bound type, wildcard
|
||||
-
|
||||
|
|
@ -1,11 +1,9 @@
|
|||
# TODO Language
|
||||
|
||||
## Intro
|
||||
- [ ] templates are usual for MPS
|
||||
- [ ] applicable to concept/+subconcepts
|
||||
- [ ] standalone
|
||||
- [ ] can serve as «checking rule»
|
||||
- [ ] produce productions to be evaluated
|
||||
## Language aspect
|
||||
- [ ] **aspects**
|
||||
- [ ] language defines aspect (eg. typechecking)
|
||||
- [ ] languages using this aspect define handlers
|
||||
|
||||
## Handler
|
||||
- [x] create handler, optionally extend another handler
|
||||
|
|
@ -15,7 +13,7 @@
|
|||
- [x] applicability condition
|
||||
- [ ] what purpose does the body serve
|
||||
- [ ] **reporting errors**
|
||||
- [ ] **_require_ statement**
|
||||
- [x] _require_ statement
|
||||
- [ ] **what features are available in a rule**
|
||||
- [ ] introduce constraint production
|
||||
- [x] declare logical variables
|
||||
|
|
|
|||
Loading…
Reference in New Issue