

ESL - compiler for new programming language - protomyth
http://code.google.com/p/esl/

======
tikhonj
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.

------
markokocic
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.

~~~
protomyth
Under the downloads <http://code.google.com/p/esl/downloads/list> there is a
reference manual
[http://code.google.com/p/esl/downloads/detail?name=ESLProgra...](http://code.google.com/p/esl/downloads/detail?name=ESLProgrammingLanguage.pdf&can=2&q=)
and examples [http://code.google.com/p/esl/downloads/detail?name=esl-
examp...](http://code.google.com/p/esl/downloads/detail?name=esl-
examples.tgz&can=2&q=)

------
tinco
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...](http://code.google.com/p/esl/source/browse/#svn%2Ftrunk%2Fsrc)

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?

------
beagle3
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.

------
crudbug
CPlus - <https://github.com/orangeduck/CPlus>

Good to see.. these developments..

