Introduction

Welcome to the Excess Platform Prototype. Here is what we have:

1. A semi-useless programming language created as a super-set of C#
2. A still raw method to augment the C# language independent of xs
3. A lot of ideas

A bit of history, I spent an inane amount of time in the previous incarnation of xs that went very far in terms of technology and that nobody ever used. It eventually died and you can find it here, for nostalgic reasons. The idea of the project was not only for me to have fun with languages, but to create one with the ability to generate code for multiple platforms.

Back in the present, Microsoft has released Roslyn, a compiler platform which is, by any means; great. I was able to recreate the old xs in about 2 weeks, and now we're here.

As for xs, the language; it intents to be a useful for quick prototyping without all the seriousness of production languages. The main intention of this project is not that language and it can be considered made-for-fun, because one must have fun.

Now, for the useful part of the project, we intended to utilize the various aspects of the old project:

1. To link language artifacts with external data. In other words, to allow parts of the definition of objects, etc to come from a data source (XML, JSON, etc)
2. User created DSLs, or the ability for users to modify the language (by adding domain specific languages) independently of the original language designers.
3. Multiple language targets, the platform will translate to xs code into multiple existing programming languages.

At the moment there is very little of all that done, but the work has started on DSLs, here is an example:

        asynch()

        {

          var x = expensive();

         

          synch()

               {

                  notify(x);

               }

        }

This was fairly revolutionary when first written, now with the asynch additions to C# it is more of a sad example, but it will do. The functioning of the sample should be clear, the expensive operation will be executed in a separate thread while its result will be notified in the same thread that triggered the asynchronous operation, possibly the UI thread.

The asynch/synch construct is not meant to be part of the xs language, and it is done using the tools the project wants to perfect. Next post will get to that, but in the meantime we will leave you with the result of compiling the sample code using the Excess compiler:

        SynchronizationContext __ASynchCtx = SynchronizationContext.Current;
        Task.Factory.StartNew(() =>
        {
              var x = expensive();
              __ASynchCtx.Post(() =>
              {
                    notify(x);
              });
        });

Not as pretty.

These small languages are fun and can be quite cool, it shouldn't be hard to imagine variations. It would be great to be able to to write F# alongside C# code for certain problems. This is a sample we intend to provide and should quite useful. SQL is another prime example and I'm sure your ideas are quite better. Leave a comment, try the site.

Writing languages

We want language writing to be as simple as possible, and it usually never is. Every language is different in their own way and there is really no unique solution. Not all languages, for instance, can be represented by traditional grammars or understood by parser technologies such as Antlr.

A good solution, then, would be made of multiple solutions, the first of which we'll discuss here. We make the distinction between two processes: compiling and linking. Compiling will transform the language's syntax into a common syntax (in this case a Roslyn parse tree) and linking will assign semantic meaning to the result of the compilation process after all code has been compiled.

With that we introduce the first way to create Excess languages: A Roslyn compiler. This is the lowest level of of planned compilers and consists of traditional Roslyn tree transformations, this would work particularly well on languages which syntax is c# compatible. One clear example of it is the synch/asynch languages introduced in the previous post.

Right onto the compilation process, these compilers do not have to deal with its encompassing syntax, which means they do not need to worry about the outer asynch syntax unless it needs to access its parameter list or similar info which is provided via context. As such, it would only need to transform the user code:

            SyntaxNode xscode = ctx.Compile(code);
         
            return CodeTemplate.ReplaceNode(
                              CodeTemplate.DescendantNodes().OfType<BlockSyntax>().First(),
                              xscode);

It is possible the inner code contains other xs features, so the compiler will first use the provided xs compiler to transform said user code. Other than that, it is just a simple Roslyn template substitution where the code in the template is replaced by the user code. The template looks like :

        static private StatementSyntax CodeTemplate = SyntaxFactory.ParseStatement(@"
            Task.Factory.StartNew(() =>
            {
            });");

As for the linking process:

        public SyntaxNode link(ExcessContext ctx, SyntaxNode node, SemanticModel model)
        {
                return node;
        }

Which does nothing since the user code is already written in c# and thus already have all semantic information needed... and that is all. It is a very simple example, however, for most languages out there not named c# 4.5 these would be nice constructs to have.

For the future there are a couple of parser utilities planned. Obviously using Antlr grammars for the compilation process, since they integrate so well with the Microsoft stack. Also planned are a couple of excess languages to aid both compilation and linking. Stay tuned.

The Useless Language

I have made sufficiently clear that the xs language is not the main feature of this project. It is, however, very dear to my heart and as such I will make the case for it, yet again. The philosophical foundations here state that programming should be simple and that could be achieved by having the right tools for every particular task. The industry seems to believe the exact contrary: one tool (read Java, C#) should handle all tasks and that tool has to be oh-so-serious and handled only by the most delicate of minds.

Which takes us to prototyping, where my humble belief is that it (prototyping) represents at least 60% of all software development. Rapid prototyping makes everyone on the team better, allow management to interact with the product at early stages and developers to easily identify use cases that might have caused painful refactoring later on. This seems to be the trend the industry is moving towards to, or it should, anyway.

The problem here is that "rapid" and "serious" tend to be mutually exclusive. Rapid prototyping should be dirty (sometimes right-down-nasty) in order to be effective. Why would you force your developers to spend copious amounts of energy writing "correct" code for a feature that might just be dropped or significantly changed? And make no mistake, I am talking about the enemy here, the dark lord of over-design. Developers tend to get creative and stubborn and before you know it the code is made of many over-complicated design patterns that don't play nice with other developer's patterns. There are meetings, passionate arguments, hurt feelings and lost of productivity. Before you know it a couple months have gone by and a big refactoring is in order.  And nobody is happy.

So, xs is meant to be quick and dirty and beautiful, OK?  But at the same time is good old typed C#, so the choice is yours. Keep in mind that we fully intend to translate xs code to other languages, so you could do your prototyping no matter the language where you intend to do your production work. So, here is what this useless programming language allows:

1. Structural leeway:  We will include default usings for you and do our best to guess the ones you need based on your code. We will use convention over configuration whenever possible, for instance: if you just write some code it will be assumed to be the "main" function, or if you just write some methods the assumption will be that it represents the "application" object. No namespace will mean default namespace, things like that.
2. Javascript feel: We will allow the user the illusion of javascript, geared towards simplicity. Write some functions, pass them to methods, etc. Incidentally, we plan to use the keyword function to declare types, to spare the programmer the ugly Func c# type. Write arrays in js form because, who needs all those new constructs? var arr = [1, 2, 3, 5]; Declare untyped parameters, see if we can infer them.  
3. Events: We will allow the syntax: on event() { ... }  because sometimes you don't want to add delegates, you would rather just do something when someone clicks that button.
4. typedef:  Because C++ lives in our hearts, you silly young people. Also, because I usually feel like breaking stuff when I have to write multiple times the same Dictionary<SomeLongType, SomeEvenLongerTypeMaybeAFunc>
5. Inferrable types: We plan some language types that allow the compiler to select the implementation type. Because sometimes you are not sure if you want to use a List or an IEnumerable or a MyType[]. This types would look something like: array<MyType> or map<int, MyType>. Because the C++ standard library lives in our hearts and Dictionary is such a long word.

Some disclaimers:

1. Some of these are already implemented and testable, please check the samples in our online compiler. Some others not so much, stay tuned.
2. I might add a few more of this, I will even add your suggestions if you let me know. You might want to implement some.
3. None of these are guaranteed to work, so you may get some errors from time to time and will be forced to be more explicit, we tried, tho.
4. I did not include features that are considered useful to the Excess platform such as DSL and external data.

So, there it is, xs. Be quick, dirty and happy.

Events

I like C# a lot, probably as much as I dislike Java, but that's just personal taste. However, I never liked events in C#, frankly, most of the time I can't even remember the proper syntax. Here it is:

        public delegate void FinishedHandler(int x, int y);
      public event FinishedHandler FinishedEvent;

        ....

        FinishedEvent += method;

That's a little convoluted considering a new concept delegate is used just to indicate the signature of the event. Also, the += operator does not convey its intended meaning particularly well. I do, however, understand the thinking behind this and its usefulness. But there should be an easier way if we are to prototype freely. So here is the xs syntax for events, which works already on the site and augments the traditional C# syntax:

       public event FinishedEvent(int x, int y);

As declarations go, this is much clear in my opinion. There is only one construct event representing the concept and it already includes its signature. Conversely, adding implementation is much more meaningful in xs:

        on  FinishedEvent(int x, int y)

       {

            ...

       }

Here the intention is clear to add a handler to the finished event instead of "adding" (+=) a method to a property of type delegate.But there's more! since the xs compiler knows you are implementing an event it knows the signature of that event and can deduct the parameters, its types, etc. As such, all these are valid xs event implementations:

        on  FinishedEvent(x, y)

        on  FinishedEvent(int y)

        on  FinishedEvent()

Which might not be great but its neat and in the spirit of the prototyping freedom we are looking to provide. And just to top it off I went creative (never a good thing) and allowed event name matiching. At the end of the day, if you have a FinishedEvent the following code should be understandable:

        on  finished(x, y)

Too far?