top of page

LIRQ — Language Integrated Reflection Queries

Language Integrated Query (LINQ) is an extension to Microsoft .NET languages that provides query expressions that can be used to extract and process data from collections (for example, arrays, lists, dictionaries).

Concrete syntax of query expressions resembles SQL statements:

IEnumerable<Person> query;
query = from p in Persons where p.age > 90 select p;

In this post, I will introduce query expressions for program introspection in object-oriented languages. For example, query

{ field, in class <T>, <T> extends MyClass, of type int }

yields all integer fields declared in subclasses of MyClass.

Reflections on introspection… (pun intended)

What is LIRQ?

Queries can yield the following entities:

  • identifiers,

  • local variables,

  • function parameters,

  • arrays,

  • collections,

  • fields of classes,

  • classes,

  • instances of classes,

  • interfaces,

  • enumerations, and

  • functions (methods).

A query consists of one or more conditions written within curly braces and separated by Boolean operations:

  • comma , for conjunction

  • vertical bar | for disjunction

  • exclamation mark ! for negation.

In this post, I will assume that queries are embedded into Java/C#, though the concept itself does not depend on a particular language.

Value, name and type queries

For an identifier x:

  • query { &x } yields its value,

  • query { @x } yields string “x”, and

  • query { #x } yields type of x , which can be used in declarations:

int x;
{ #x } y; // int y;

Primitive queries

For each entity mentioned above, there is a corresponding query ({var}, {class}, {field}, and so on) that yields all such entities. For example, query {var} will yield all variables. To yield a non-empty result, a query should contain at least one primitive condition.

Regular expressions for names

Query {'v*'} yields all identifiers with names starting with symbol “v”. Queries can be used in qualified names, too:


Type constraints

Query {var, of type int} yields all local integer variables. It can be used in an assignment statement:

{var, of type int} = 0;



{ var, of type int, (that >= 0 | that <= 10) }

yields all local integer variables whose value is in range 0..10.

Keyword that refers to an yielded result of a query. Negation can also be used within that expressions. Queries &that , @that and #that are considered primitive queries. For example, {var, @that} yields a collection of names of all variables.

Query variables


{ var <T>, of type int, ( <T> >= 0 | <T> <= 10 ) }

is equivalent to query

{ var, of type int, (that >= 0 | that <= 10) }

given above, but uses a query variable T that refers to yielded result. Variable names are enclosed in angle brackets (remark: this syntax has nothing to do with generics).

Query variables can also be used for types and essentially all other entities, for example:

{var <X>, of type <Y>, <Y> is subtype of int}


Query {function <F>() returns <R>} yields all functions without arguments visible in the current scope. Desired parameters can be requested by using regular expressions-like syntax:

  • ? denotes any parameter,

  • * denotes 0 or more parameters,

  • + denotes 1 or more parameters,

  • int denotes an integer parameter, and so on.

Query {function <F>(?, int, *) returns string} yields all string functions whose second argument is of type integer.


Query {class <T>, <T> extends MyClass} yields all classes that extend MyClass. Part ... extends ... of this query is called a qualifier. Other qualifiers include:

  • is abstract

  • is static

  • ... implements ...

  • ... inherits ...

  • is subtype of ...

  • has ... (used to specify that a class has a certain field or method),

  • and so on.

Declared entities

Qualifier declared ... allows distinguishing between an yielded result and a condition in a query. For example, query

{class <B>, <B> extends <A>, class <A>}

is invalid because it has two primitive conditions ( class <B> and class <A>). However, query

{class <B>, <B> extends <A>, declared class <A>}

is valid and yields all subclasses of all classes.



{instance of Person}.age = 0;

assigns value 0 to field age of all instances of class Person. Depending on how semantics of queries is defined, instances may either refer to all declared instances of a class or to all instances existing during runtime.


Queries can be used in for-each loops:

for x in {var x, of type int} {
  x = 0;


Query {field, of type int, in declared class MyClass} yields all integer fields in class MyClass. Keyword declared can be omitted in in conditions.

Query {in function(int, int) returns <R>, var} yields all local variables in all functions (from the current scope) with two integer arguments.

Nested queries


{in {function(int, int) returns <R>, in class MyClass}, var}

differs from the previous one in that it only considers methods of class MyClass.

Visibility modifiers

Queries can be used to define custom visibility modifiers.

class A {
 modifier children = {class <T>, <T> extends A};
 [children] int x; // only visible in subclasses of A

Queries as first-class citizens

New primitive type query is introduced to represent reflection queries.

query a = {class, with constructor <X>()};
query b = {{a}, that extends MyClass};
<<b>> x = new <<b>>(); // parameterized statement;
                       // it creates instances of all subclasses of
                       // MyClass that have an explicit constructor

In this examples, query a yields all classes that have a constructor without parameters. Query b refines this query additionally requiring that those classes extend MyClass. An instance is then created of each matching class.

To typecheck queries, primitive type query should be annotated with the “type” of entities that a query yields. In the example above, complete definitions of a and b will be:

query<class> a = ...
query<class> b = ...

Consider now another example:

query<type> t = {#that, var, @that.startsWith('a')};
<<t>> x;

Query t yields types of all variables whose name starts with symbol “a”. These types are used then in the parameterized declaration statement.

The following query increases all integer variables by 1.

query<var> q = {var, of type int};
<<q>> = <<q>> + 1;

Type annotations (<class> , <type> , <var>, etc.) of queries might not need to be specified explicitly as they can be inferred in most cases from queries themselves.

Kinds of queries

How could it be possible to represent the “machinery” of a query so that one could “compare” them? A possible answer might be to define kinds of queries, in a way somewhat similar to kinds of types.

For example, kind of query {var, of type int} is VAR*, denoting that it yields some variable subject to some conditions, while kind of query {var age} is VAR (without the star), because it yields a specific variable define in the query itself.

For query

{instance of <T>, declared class <T>}
the kind is CLASS* -> INST* , whereas kind of query
{instance of MyClass}
is CLASS -> INST*.
Finally, for query
 declared class <A>, declared class <B>,
 <A> extends <B>,
 field, <A> has that

its kind is CLASS* -> CLASS* -> FIELD*, denoting that this query has conditions on two classes and yields a field.

Semantics and implementation

Query {var, of type int} yields all integer variables from the current scope. This query can be used in an assignment statement:

int x, y, z;
{var, of type int} = 0;   // x = 0; y = 0; z = 0;

In compile-time semantics, queries are essentially treated as macros, and the assignment above is transformed into a sequence of assignments

x = 0;
y = 0;
z = 0;

In run-time semantics, the assignment is transformed to (Java/C#/…) code that emulates the query using corresponding reflection API.

For queries with constraints, such as {var, of type int, that > 0}, only run-time semantics shall be defined. Design of LIRQ is still very experimental. I am implementing an early prototype using language workbench JetBrains MPS that allows extending Java with new constructs.

Since MPS uses projectional editing, there are no issues with possible ambiguities in concrete syntax of reflection queries (for example, no problem at all with curly braces in queries vs. curly braces in compound statements in Java).

Semantics of reflection queries is enabled by model transformation and code generation mechanisms of MPS. In compile-time semantics, generated code can also be statically typechecked.

Some related work

  • Object Constraint Language allows specifying conditions of the form context Person inv: self.age >= 0 in a manner similar to reflective queries.

  • Constraints on type parameters in LINQ and wildcards in Java are similar to qualifiers in the terminology of this paper.

  • EcmaScript has support for computed names of object members, which resembles name queries.

  • C# has nameof expression that returns name of an identifier — this is exactly what “@” queries do.

Further ideas

  • Queries like {int, that > 10} can be seen as dependent types.

  • Similarly, queries type number = {int | float}; resemble type classes (for example, in Haskell) and “multitypes”.

  • Reflection queries may be extended to access the AST, for example, query {declared [for loop] <S>, [counter] of <S>, @that} would yield names of all counters in all for loops.

Source: Medium

The Tech Platform



bottom of page