LEL

LEL is a potential future project for giving semantics to LES. That is, unlike most programming languages which are designed as a single monolithic unit, LEL is explicitly separated into a syntax part (that's LES) and a semantics part (that's LEL).

• LeMP
• LEL

LeMP

I started by creating something extremely simple and modest: a very simple macro language that compiles down to C#. I originally called this "micro-LEL", and I used it to bootstrap the parser generator, [LLLPG], by enabling me to input a grammar into it. However, "micro-LEL" did not seem like an appropriate name because it is not descriptive and may not closely resemble whatever I finally create and call "LEL".

I decided to rename micro-LEL to LeMP (Lexical Macro Processor), which more correctly describes what it is: a fancy preprocessor. However, currently it is still built from a project called LEL to LEL.exe.

When I completed the EC# parser, I also used LeMP to process the EC# code. Thus LeMP is really not a layer built on top of LES, rather it is something syntax-independent. So one can refer to LeMP-on-top-of-LES as LeMP-LES and LeMP-on-top-of-EC# as LeMP-EC#.

LEL

So that we're clear: LEL does not exist and I have not yet even designed it. But I know what I want it to be: a simple, statically typed, imperative but expression-based, extensible and democratic language.

• "Simple" means that the LEL compiler should be small (and fast) and the core language should be easy to understand for programmers that already uses C-family languages (C#, Java).
• "Statically typed" means that variables have a data type known at compile-time.
• "Extensible and democratic" means that end-users will be able to add new features to the language, distribute and use those feature easily, combine many features written by different people, and submit features for possible inclusion in future standards.
• "Imperative but expression-based" means that the core language will be designed to support imperative programming using expression trees that will facilitate a functional style. LEL will support, but not mandate, object-oriented programming. Standard compiler extensions, called "macros", will support functional features such as pattern-matching that are not part of the core language.

Originally I thought the semantics and type system of LEL would just copy EC#, so that LEL is merely a simplified syntax for EC#. But now I'm more inclined to think that it might be better to make a superior programming language that breaks free from the history of C#... well, no, then again, I have a better idea. LEL should refer to [Standard Imperative Language] (whatever that turns out to be) as incarnated in LES, plus macros to help provide a friendly notation.

That doesn't mean there won't or shouldn't be an LES-based syntax for EC#. Once EC# exists it will be easy to create a friendly LES-based syntax for it, but it should probably be given a name like "EC#/LES" that clearly suggests what it is.

Nor can I promise I won't make my own new programming language from scratch. But "Loyc Expression Language" sounds like something that should be a universal standard, not something that belongs to me personally. So if I ever create an all-new language, I'll use a different name.

It's not easy to make a language that anyone can easily modify in a standard way. In fact, I've been thinking about the problem for years without finding a satisfying solution. Therefore, my plan is to figure out how some existing extensible languages accomplish their extensibility, and copy them. In particular, I have my eye on Nemerle.