A New Programming Language — IM/C

I have worked on a toy programming language for a while now. I call it a slightly IMproved C language, aka. IM/C.

I personally like C language a lot. It has a minimalistic set of syntaxes, but since all of them are goal oriented and useful, the minimalism doesn't make the language lacking in terms of features. Its instructions and memory model is very close to the hardware, instead of building a lot of abstract layers upon it. Regarding the manual memory management, with good habits developed and best practises applied, one can achieve a huge flexibility with it. All of these features fit to my philosophy about IT very well.

But if I have the freedom to choose which language to use while I'm starting with a new project, I wouldn't pick up C. It is not because of the language itself, but rather the eco-system. First of all, C doesn't really have a strong and organized standard library (thinking about std*.h), while some other libraries are platform dependent (thinking about POSIX), which makes it unnecessarily difficult even to finish an easy task, e.g. keeping a set of randomly accessible data (linked list or array list) or parsing JSON.

The lack of the project management system and dependency management system is also a huge problem stopping the growth of the language. Although C has always been criticised for being platform dependent, which has prevented the development of a unified dependency and project management system. Most reusable libraries, like regular expressions and so on, however, seldomly fall into this group — at least on the code level. And even if some of the functionalities are indeed platform dependent, once being carefully structured, the exposed interface of the reusable library could still be platform independent (taking SDL as an example). So there is actually no excuse not to provide a unified project and dependency management system, so that the works of different people can be shared easily.

And there are also some language features that I want to adjust. First of all. I personally don't think the macro system of C is a good idea being used as a templating system. Since it nullifies all the modern features of IDEs, e.g. to do the type checking, name prompt and so on. I find the C++ templating system in this case much better.

Motivated by the idea to keep the features that I like, and to improve the lacking parts in C language, I decided to create my own language which will be transpiled into C. In this case, it should also be interactable with C without any overhead.

The following code is demonstrating the differences between two languages:

#include <stdio.h>

int main(int argc, char * argv[]) {
  printf("hello world\n");

  for (int i = 0; i < argc; i++) {
    printf("  argv[%d] = %s\n", i, argv[i]);
  }

  return 0;
}

And the IM/C counter part will be:

import std::io;

func main(argc: int32, argv: arr[ptr[char]]): int {
  std::io::printf(c"hello world\n");

  loop
  with { var i: int32 = 0; }
  while (i < argc)
  do {
    std::io::printf(c"  argv[%d] = %s\n", i, argv.(i));
  }
  then { i = i + 1; } 

  return 0;
}

From this comparison, I guess it is clear that:

• the general concept of IM/C is very close to C;
• everything is made more explicit than implicit, e.g. the type system with array and pointer;
• some features could be exotic to those C-alike-family of languages, e.g. using loop ... with ... while ... do ... then to unify and replace for, while and do ... while, and using array.1 or array.(i) to access the elements instead of using array[1] or array[i].

This is motivated by the fact that I'd like to keep the syntax as explicit as possible, and as unified as possible. Each an every keyword should clearly say what it is doing, and each symbol should only have one single meaning. I believe this will help us to get rid of a lot of ambigiouity not only for the source code, but also for the language implementation.

Currently, there is still no stable feature set for the new language yet. Everything is still going through a try-and-fail-process. But I personally have hope in it. I believe, it will become my "go-to" language for most of my hobby projects in the future.