ESL - compiler for new programming language

I like the idea of a new language to replace C for embedded programming.

The name has some amusing connotations for me: when I started school in Canada, ESL stood for "English as a Second Language". Since I didn't know the language at all, I spent a couple of years in ESL programs in primary school.

The way records are implemented is nice. It's essentially an extensible product type. However, since you already have product types, you may as well get sum types! These are fairly useful and have a natural symmetry with products.

The particularly interesting thing to look at is how sum types could have sub-typing. With records, sub-typing is very simple. If you have a record with fields a and b, it has accessor functions:

   record -> a
   record -> b

Now you can define a record with an additional field; let's call this record1. This type has three accessor functions:

    record1 -> a
    record1 -> b
    record1 -> c

Since the first two have to be the same as for record, you can use this wherever you could use a record. Since the memory layout is going to be consistent between the records (since you can only add fields to the end), this is also very natural to implement. (Now, arrays of records are a different story!)

We can now write that record1 <: record, or that record1 is a sub-type of record.

Sum types are, in a sense, the opposite of products. This is, in fact, a mathematical fact to do with duality[1][2]. More particularly, a sum type contains an element of one of the sum's types. So a sum of a and b contains either an a or a b. An important thing to note is that the alternatives are tagged. That is, if you have a sum of int and int, the two ints can be differentiated because the sum type keeps track of which one (left or right) it was constructed with. This corresponds to a disjoin union in math.

[1]: http://en.wikipedia.org/wiki/Dual_%28category_theory%29 <br /> [2]: http://blog.ezyang.com/2012/10/duality-for-haskellers/

Where records have accessor functions, sum types have constructors. Let's imagine a sum containing a and b:

    a -> sum
    b -> sum

Essentially, we just took the record's functions and flipped them.

When we use a sum type, we have to match against the possible cases. So we need a case statement that has a branch for each possible type in the sum.

So what happens if we try to define sub-typing the same way as for products? We would get that sum1, which contains a, b and c, is a sub-type of sum. That is, sum1 <: sum. However, this doesn't work! A sum type contains a value of one of the types, and you don't know which one at runtime. So if you used a sum1 where you expected a sum, and the sum1 contained a value of type c, you wouldn't know what to do. In fact, we also need to flip the sub-typing relation. So instead of sum1 <: sum, we get sum <: sum1. That is, wherever you could use a sum of a, b and c, you can use a sum of just a and b.

Now this makes sense. Whenever you write a case statement for a sum of a, b and c, you have to have cases for a and b. So if you pass in a sum that could only have options a and b, you can obviously handle it.

So a sum type would fit naturally with the existing product types. But would it be useful? I believe it would. Now, I'm no expert in low-level programming. However, I believe there is a somewhat common idiom in C that looks something like this:

    struct sum {
      int tag;
      union value {
        float a;
        int b'
      }
    }

This is essentially a way to get a proper sum-type out of a union. A normal union is somewhat hard to work with; you usually want to know which type it currently contains. That's what the tag does. In essence, you've just implemented a real sum-type in C.

Now, this pattern isn't used too often, but I think it is useful. The main reason you don't see it much is that it's fairly complex and not immediately obvious--especially to somebody not familiar with sum types. However, if it was part of the language, I imagine it would see more use and make some code easier to write and less bug-prone.

Also, it seems the language does not have any way to replace C's union. So a sum type would be a natural and safer replacement, giving ESL more parity with C without sacrificing convenience.

I clicked the link expecting to find more about the language, but instead of the hello world or any other example, it was just a wall of text. Tried clicking around to find some example code, but no luck. I still have no idea how the code looks like.

This is not how one should mark new language.

Awesome, it's definitely an improvement on C from what I can tell.

If you're looking for examples, check out its source: http://code.google.com/p/esl/source/browse/#svn%2Ftrunk%2Fsr...

I think the world needs more better C's, C++ sucks. It's old technology, now matter how much it's amended.

A C replacing language is in my opinion a language that: Is not (implicitly) garbage collected, makes use of a preprocessor, allows explicit memory access and passing hints to the compiler, allows inline ASM.

What else should be a feature of a C replacement?

Seems to be a cross between C and Go; It uses a simple syntax much closer to Go's than to Cs, but keeps control at the C level - e.g., no garbage collection.

Nice work.

CPlus - https://github.com/orangeduck/CPlus

Good to see.. these developments..