Location are a central mechanism in Rascal for referring to (parts of) files and for referring to language constructs that have "qualified names".
These are all schemes that map to locations of files in physical or logical file systems:
|an absolute file-system path. Separators always like so: |
|file-system path relative to the current working directory of the JVM running Rascal|
|file-system path relative to where this OS/JVM thinks the temp folder is|
|file-system path relative to where the current user's home directory is|
|opaque virtual file system that points to the root of the (deployed) Rascal standard library|
|fast in-memory file system that is transient between runs of the JVM. Guarantees |
|file-system for what is inside a jar file|
|file-system for what is insied a zip file|
|opaque file-system that is relative to the root a an IDE project in the current workspace of an IDE. The project must be "open" and active for this to work.|
|opaque file-system that is relative to the (binary) target compilation folder of a project that is active and open in the workspace of the current IDE|
|opaque file-system that points to the deployed code of a Rascal library. The library must have a RASCAL.MF file with the right |
|Simply a page on a website.|
|Simply a page on a website.|
|this is the root of the JVM class and resource path for the current JVM|
|this is an opaque file system into an OSGI bundle (which must be loaded and initialized). Works only in Eclipse. It defers to |
|this is an opaque file system into an Eclipse plugin (which must be loaded and initialized). Works only in Eclipse. It defers to |
|this is an opaque file system into an (unzipped) resource partition of an OSGI bundle (whichmust be loaded and initialized). Works only in Eclipse|
For all of these schemes it is natural to use offset/length and start/end line/column information as described here.
To get access to a file in your current project you can use
project://<your-project>, however it will only work while in development mode in your IDE. For a more robust reference to a local file, also after deployment, use findResources
Next to the above file-systems we also map the "mangled" or "qualified" naming schemes of programming languages and domains-specific languages to locations. These exact references can then be used instead of file locations to analyze source code and to generate (interactive) visualizations.
The general scheme is this:
- language-name would be
- concept-name would be
- resolution-authority defines what the scope of name resolution is. It can be empty if you are doing an open-world analysis, or it could be the name of the top project you are currently analyzing. That project defines the search path for all of the other names and library projects used.
- qualified-name is typically represented by the names of nested scopes in the programming languages. Sometimes explicit names are generated for implicit concepts (such as anonymous classes and lambdas).
In the M3 model, qualified names are mapped to their declaration locations in the
.declarations table. This table is also used by Registry to provide interactive resolution. This is how Rascal jumps to the source code of a qualified name location when it is clicked.
The other direction in M3 core is the
.uses table. This maps the places where a declaration
is used to their qualified name. By composing
.declaration you get a reference resolver.
It is also common to annotate Parse Trees and Abstract Syntax Trees with qualified names after name and type resolution. You can use a keyword field of an algebraic data-type. It is typically called
decl as in
data Expression | variable(str identifier, loc decl = |unknown:///|) and the last part of the qualified name in
decl would be equal to the