Around 2005, I created a language for learning how to create compilers. It was just a learning exercise.
Between 2008 and 2010, I created a language with Java/C# like syntax, C/C++ like semantics, strongly-typed but with type inference that was meant to be embeddable into C++ apps. I wanted to use it to create a game. However, I didn't want to created a Virtual Machine for it, so I opted to use the Parrot VM[1]. The choice to use Parrot was huge mistake because that project turned out to be a clusterfok that never worked right, even though they had been working on the VM for close to a decade, by that point. I abandoned that language and moved to another language because there were no other VMs that suited me, at that point.
Since I was burned from the Parrot VM fiasco, I decided to create another language that didn't rely on a VM, so I created a general purpose API design language. In this language, you design APIs, and then write 'generators' in JavaScript that transform the API code to the final output. The benefit of this is that you only have to create one generator for each type of code/asset that you want to create, and use the same front-end API code (call schemas). So, for example, you can create a schema for some Amazon web-service, and then have generators that would output different types of clients, or some test-servers, or automatic documentation, sample inputs, dashboards, graphs, whatever based on your one schema. The language is written in C++ and it very well tested (close to 3000 tests). My vision is that a developer will design their API schema once, and then use generators (written by the developer or by others) to generate all kinds of things from that one API: client-code, server-code, test-cases, docs, graphs, dashboards, etc. This way, we can focus on actual API design and leave the mundane tasks to the generators.
The flow is like this:
[schema(s)] -> [compiler] -> [intermediat representation] -> [generator(s)] -> [final output(s)]
I think this language is neat.
While I was working on my API design language, I wanted to have really good error messages, and I wanted the error messages to be all in one file, so that I could glance at them easily while developing. So, I ended up designing a micro-language for handling text-templates, where you have things like:
"The ($noun) is ($verb)"
The thing is, you'll quickly realize that replacing variables is not enough. Eventually, you'll want conditionals, loops, .... function calls (:-0), so I added them. This micro-language is embedded in a couple of files within the API language, but I thought it was neat, so I decided to create a proper text-template language based on it, because if you do a search only for C/C++ text-template language, there are not alot of choices for this. I have the general design for the language completed in my head, and I have a basic implementation of some of the basic things like syntax parsing and variable interpolation and basic function calls, but I paused development on it for now, while C++ 17 hits the streets, because I had a real need for std::string_views to minimize string copying. Also, since I decided to make the implementation of this text-template language more robust and performant for enterprise type of use, I decided to go with an sql-like prepare->execute type of processing; this requires adding a micro-vm for the execution part, which adds to the development time.
Between 2008 and 2010, I created a language with Java/C# like syntax, C/C++ like semantics, strongly-typed but with type inference that was meant to be embeddable into C++ apps. I wanted to use it to create a game. However, I didn't want to created a Virtual Machine for it, so I opted to use the Parrot VM[1]. The choice to use Parrot was huge mistake because that project turned out to be a clusterfok that never worked right, even though they had been working on the VM for close to a decade, by that point. I abandoned that language and moved to another language because there were no other VMs that suited me, at that point.
Since I was burned from the Parrot VM fiasco, I decided to create another language that didn't rely on a VM, so I created a general purpose API design language. In this language, you design APIs, and then write 'generators' in JavaScript that transform the API code to the final output. The benefit of this is that you only have to create one generator for each type of code/asset that you want to create, and use the same front-end API code (call schemas). So, for example, you can create a schema for some Amazon web-service, and then have generators that would output different types of clients, or some test-servers, or automatic documentation, sample inputs, dashboards, graphs, whatever based on your one schema. The language is written in C++ and it very well tested (close to 3000 tests). My vision is that a developer will design their API schema once, and then use generators (written by the developer or by others) to generate all kinds of things from that one API: client-code, server-code, test-cases, docs, graphs, dashboards, etc. This way, we can focus on actual API design and leave the mundane tasks to the generators. The flow is like this: [schema(s)] -> [compiler] -> [intermediat representation] -> [generator(s)] -> [final output(s)] I think this language is neat.
While I was working on my API design language, I wanted to have really good error messages, and I wanted the error messages to be all in one file, so that I could glance at them easily while developing. So, I ended up designing a micro-language for handling text-templates, where you have things like: "The ($noun) is ($verb)" The thing is, you'll quickly realize that replacing variables is not enough. Eventually, you'll want conditionals, loops, .... function calls (:-0), so I added them. This micro-language is embedded in a couple of files within the API language, but I thought it was neat, so I decided to create a proper text-template language based on it, because if you do a search only for C/C++ text-template language, there are not alot of choices for this. I have the general design for the language completed in my head, and I have a basic implementation of some of the basic things like syntax parsing and variable interpolation and basic function calls, but I paused development on it for now, while C++ 17 hits the streets, because I had a real need for std::string_views to minimize string copying. Also, since I decided to make the implementation of this text-template language more robust and performant for enterprise type of use, I decided to go with an sql-like prepare->execute type of processing; this requires adding a micro-vm for the execution part, which adds to the development time.
[1] http://parrot.org/