Loyc: Language conversion & interoperability

Loyc is a label for standards, code libraries, and programming tools that

We believe that programming languages should interoperate with each other on a high level and share as much technology and terminology as possible. Poor interoperability is a serious problem today, and we want to fix that.

We also believe interoperability is a serious problem within individual languages, because of a lack of standardization of data types and interfaces, and in some cases, standard types being poorly-designed: inefficient, limited, etc. We want to fix that too, but haven’t really gotten started on it yet.

The original idea of Loyc was a multi-syntax compiler, which would have taken code written in several languages and compile it as a single program with a single compiler, allowing code to call between languages and share data, easily and directly. We have not had the necessary volunteers or resources to create such a compiler; instead we working on bits and pieces that may be useful for such a compiler eventually.

In general, the Loyc initiative is about finding ways to bring the world’s programs and programming languages closer together, to grease the wheels of developers everywhere.

Currently, all Loyc projects are written in C# and Enhanced C# because the .NET platform is the only one specifically designed for multiple languages. Eventually though, we hope to shift our focus to WebAssembly, especially since Microsoft has not been fixing the CLR’s design flaws.

Core projects

Loyc trees

Loyc trees are a general-purpose tree structure designed to represent source code. They are comparable to LISP syntax trees, with just enough added complexity to represent programming languages from the Algol family, such as C#.


LES is a syntax/data interchange format for Loyc trees, designed to resemble other languages in the C family, such as Javascript.


LeMP is a programming-language agnostic LISP-style lexical macro processor.


Flame is a set of “middle-end” components designed to help write managed (C#-like) compilers. It has is own IR (separate from Loyc trees) which it can optimize, and it supports static linking of Flame IR files. The CLR backend is the only stable one; a WebAssembly backend is in early stages.

Loyc Core Libraries for .NET

The Loyc Core Libraries are libraries of general-purpose stuff, most of which fits the theme “things that should be built into the .NET framework, but aren’t”. These libraries also include the LES parser and the standard base classes for LLLPG parsers.

Projects built on Loyc technology


The Loyc LL(k) Parser Generator is a parser generator designed to help you write parsers with performance similar to hand-written parsers. The parsers for LES and Enhanced C# use LLLPG.

Enhanced C#

Enhanced C# is a programming language that is backward-compatible with C#. It’s nowhere near done, but you can add Enhanced C# code to any vanilla C# project via the LeMP Custom Tool for Visual Studio.

Future core projects

API standardization projects

Interoperability within a single language is often limited. For example, there’s no standard for how to represent “points” and “vectors” (X-Y and X-Y-Z groups) in C++. Typically, two geometric libraries that both operate on “points” and/or “vectors” are not directly compatible and require conversion steps between them. Even strings in C++ aren’t standardized: wchar_t and wstring is UTF-16 on Windows and UCS-4 on Linux.

Even when something is standardized, it may be misdesigned and deserves a new and better design. For example, in the .NET BCL, points are not treated as general concepts but as GUI-specific concepts. The types Point (int coordinates) and PointF (float coordinates) are defined in the namespace for GDI+ (Windows Forms), while WPF has its own Point type with double coordinates and a somewhat different API. All these APIs are limited in some ways.

So we would like to start a movement to create standard APIs that attempt to simultaneously achieve

  1. high performance (e.g. A 2D or 3D Point should be a value type with coordinates stored directly in the structure, rather than as a heap-allocated array)
  2. Type safety (e.g. separating the concepts of Vector and Point even though they are physically identical)
  3. Ease-of-use (e.g. taking advantage of operator overloading: (p - q) * 2)
  4. Generality (e.g. Point<Coord> rather than baking in a particular coordinate type, and somehow generalizing points to N dimensions)
  5. Interoperability (e.g. a point or vector should implement interfaces that let it act like a list of numbers)

Multi-Lanuage Standard Library

The MLSL would form the basis of a system for writing code that can be converted automatically to many languages.

Standard Imperative Language

When converting code from one programming language to another, SIL is the concept of a schema for Loyc trees that would lie at the midway point between two languages. SIL has not been designed yet; the plan is to base it on conventions created by WebAssembly and by Enhanced C#.

The Ultimate Programming Language

Humans have puzzled over the question of how programming languages should work for about 65 years, and explored innumerable solutions. Now is the time for consolidation: to create a language in which you can quickly become comfortable, whether you’re used to Java, C#, C++, Javascript, Go, Lisp, OCaml, Erlang, Julia or Python.

The ultimate programming language would be designed for all purposes:

Obviously, Loyc would need a lot of funding to do this, and it currently has - let’s see now - zero.

We’d like to list other projects here related to interoperability, API standardization and code conversion, even if they are unaffiliated with Loyc. Do you think a project should be listed here? You can make it an issue or reach me at gmail.com, with account name qwertie256. All standards and tools listed here have an open source implementation.

Help wanted

We need help to

Currently, we are severely undermanned and have no sponsors. If you’d like to help, make an issue or reach me at gmail.com, with account name qwertie256.