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) |
||
|---|---|---|
| .. | ||
| .mps | ||
| languages | ||
| solutions | ||
| README.md | ||
| build.gradle | ||
| build.xml | ||
README.md
MPSCORE
This project contains sample applications of coderules framework providing the implementations of source code analysis for baseLanguage and its extensions.
The two aspects are implemented here:
- Type system
- Control flow
Installation
The code in this project relies on coderules languages and solutions to be available, either as a project library or as a plugin. There are two possibilities to install coderules:
- Follow the instructions for building the root project, or
- Install the compiled plugin (see the latest release on GitHub).
License
Copyright 2014-2018 JetBrains s.r.o.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.