Moving Away from Monolithic Languages towards syntax and language extensions as libraries


Currently most of the languages are monolithic. It would be good as a very long term goal to make the languages extensible and more like libraries from which you import and get new syntax as well as define new syntax.

A good example of such language is: and also to some extent:

Hopefully we will see more of similar language and syntax creation meta programming support in .net core.

When this is done to code in VB or C# you just import the relevant syntax and this will become available.


It would be good as a very long term goal to make the languages extensible and more like libraries from which you import and get new syntax as well as define new syntax.

I wholeheartedly disagree with this. Imagine moving from a C# project to another C# project, only to discover it has a completely different syntax, and you’re totally unable to understand a single thing.

Language fragmentation is totally undesirable. Each language needs to have a single specification and all implementations have to follow that implementation verbatim.

Roslyn enables people to create their own language features if they want, but for any give feature to be part of the official specification/implementation, it’ll have to be really helpful and generally applicable for MS to consider adding it.


I agree. The Tower of Babel consequences are undesirable.

I also appreciate the desire to tinker with languages and make extensions. But that makes private language and maybe small-community languages. Great for experimental and academic interests, but not for sustainability of a code base and of the skills to support it.


I think both extremes are bad. Yes having macros is good and yes having a good foundation and standard language design and syntax are good. I totally agree with you on the point of people wanting to fragment a language instead of agreeing on standards is just stupid. Its one of the things I don’t like about the Nim lang.


I disagree with the fragmentation concern, at the end of the day there’s not that much difference between that kind of fragmentation and library fragmentation. Try porting one application to a different, say, web framework. Full disclosure: I develop excess, probably the first website to allow users to extend a language (c# w/Roslyn)

Now let see the advantages:

1- Domain specific languages will always exist and programming languages should be aware of this. The way it is now, code must be written in ways that are inefficient and lack the expressiveness necessary for such domains.

2- Programming languages would become more community driven, anyone can write an extension, if it is not good, nobody would use it. If it is very good it could be adapted by language designers. Democracy, if you wish :smile:

3- Companies could develop their own “best practices” and bake them into their language of choice, thus avoiding the “newbie programmer” problem that doesn’t really have any other good solution.

In general, I feel it would accelerate innovation and lesser extensions, although certainly problematic, would be rejected by the community, not the few designated language designers.

But then again, I might be a little biased, lol. I leave you with an example of an extension of c# I have always wanted and now its possible to write in about 150 lines of code:



I think there is a big difference between a library dependency and a dependency on the language itself (although with all of the JavaScript frameworks, I am never certain which is which).

Maybe that is just how the interface boundaries are drawn?

Perhaps it matters how extensions are introduced and how one can determine what extensions a unit of source code requires?

I’d hate to get snarled up in licensing issues around one more boundary for integrating software, though.

By the way, I agree about domain-specific languages.

Esc, how do you signal dependency on your extension to users of your code?


The lines seems blurry to me, like you mention all javascript frameworks try to look like language features, in fact, most libraries ever written try to “look” like language features. Which is another word for being “expressive”, the ultimate goal of programming languages imho.

The way I look at language extensions is as libraries, with the same licensing framework. Until the community and the language owners decide it is a great idea an incorporate them into the language.

[Edit] In fact, extensions work better than libraries since they could signal the best practices and change underlying implementations without touching the code. Let alone the fact that extensions provide implementors with the ability to perform compile-type checking instead of runtime only for language libraries.

Regarding signal dependency, I haven’t done anything about it in particular other than showing the extensions as keywords, but I’m sure there are many ways to do it (including a language extension, lol). Do you have a suggestion for that particular task, orcmid?


See Racket. This can import languages as a library.


I’d like to show my experiment to the language extensibility :smiley:
Metah.W(MW) is a C#-derived metaprogramming language for Windows Workflow Foundation 4.5. It provides an alternative way of composing activities to the WF designer.
Please visit for more info.


Meta programming will not fragment the language. It just provides sugar on top of what is existingly available. These extensions will only be available within namespaces that use them.

Look at Racket language and its design:

.NET Foundation Website | Blog | Projects | Code of Conduct