e2b3c21b2f
Motivation is that implicit (non-overriden) list features must unify with list of any length. Consider an example: `classifier(cls: node-ptr/A/) = classifier(cls: node-ptr/A/ param: [B,C])` With previous approach it would fail, which seems counter-intuitive to me. So, if empty list (e.g. of type parameters) is meant, then it must be specified explicitly. There's one thing to remember, though: such wildcard list features won't match with MetaLogicalArrays in rule heads. (e.g. see dpromote_* rules and consider what happens when a classifier with unbound `parameter` feature comes in) |
||
|---|---|---|
| .. | ||
| doc/img | ||
| languages | ||
| solutions | ||
| README.md | ||
README.md
Code Rules - Implementation Notes
Structure
The project modules are separated into several groups to separate levels of abstraction.
Logic
Define fundamental ideas used throughout the implementation, such as «data form» (a.k.a. term), logical variables, and others.
Code rules
Modules in this group define the core concepts of coderules and the logic behind it. This includes constraints, predicates, handlers, as well as code rule templates.
Constraints activation trace view for debugging the process of evaluating constraint rules.
Once finished, constraint rules produce inferred types and type errors, which are added as highlighter annotations to the editor.
Type checking
Defines a custom aspect «types», which is used to store the typing rules in the language source code.
Type checking plugin for MPS provides the actions for checking the types in a currently opened root.
Control flow
Declares only control flow aspect. All functionality is inherited from coderules language.