Skip to main content

Roslyn shopping cart DSL – Part 4


Why Source to source translation?

In order to answer that question, I wanna provide some background on what are the choices that we have when building a DSL on .NET (at least the most common that I’ve used).

Prior to the “magic lambda” era, there were few choices, the one I've used the most, was a hand written parser that creates syntax trees and a code generator that traverses those trees generating MSIL code using Reflection.Emit. This solution was OK but it was also a lot of work, even for a simple "Hello World DSL". It’s definitely a path I wouldn't take nowadays.

When .NET 3.5 saw the light, we had more options, back then it was possible to use linq expressions to represent our programs and traverse those expressions in order to emit target code. It wasn’t  the easyest thing, but at least the days were we have to build a bunch of classes to represent or compose expressions were gone. Then we had the lambda compiler and linq statements which allowed us to compose and compile more complex lambdas to delegates and invoke those delegates just as normal code.

Along the way (between 2.0 and 3.5) the DLR was born and gave us a net way to work with call sites, dynamic types, runtime binders, and so on. We still had to write our own parsers, but the rest of what we need was ready to use. And also we could peek at the IronPython code, IronRuby and the DLR itself and see how things work under the hood.

And finally we got Roslyn which give us a whole bunch of magic right out of the box as long as we provide valid C# or VB code, and this is why I choose source to source translation. It's way easier to implement than any of the options mentioned above, because almost all of the components are already built, this allow us to build a walking skeleton in a couple of hours or a maybe one or two days.

There’s a couple of ways to do source to source translation, usually the choice relies on the DSL's syntax complexity (which should remain simple for our DSL to succeed). In this post I took the "the simplest code that maybe works" approach , which was string substitution. The end result was a piece of sloppy code, that you may never want to use in a real app, but it was good enough to get the job done ;)

In future posts I’ll be showing how to implement source to source translation for non trivial scenarios. I’ll try to include how to parse source code, build syntax trees and traverse those trees emitting target language code.

There is a bunch of aspects I didn’t cover in this series such as error handling, performance, code optimizations, parser generators and so on and so forth, but I think was a good starting point to start playing with DSLs on top of the Roslyn APIs.


Comments

  1. any full source code sample about it ?

    ReplyDelete
    Replies
    1. Hi Kiquenet, I thought I was added the link at the bottom of the page... any way here it goes https://github.com/amiralles/roslyn-shopping-cart-dsl
      (The source to source translation as shown in this series is really sloppy, I wouldn't use it as a starting point, the rest it's let say ok ;))

      Delete

Post a Comment

Popular posts from this blog

Moving to Medium

It's been a long time since I want to give medium a try, and finally, I made some time to do it. To get started on the new platform, I'll be doing series on "Getting programming concepts, languages and tools". If it sounds interesting to you, please take a look at the first post  Getting AWK  and spread the word if you like it. I'm not going to migrate old entries to the new web site. They will remain here safe and sound! As usual, thanks for reading!

Working with unattended reports

In this post I‘ll show you how to create reports that NRapid will execute into an unattended mode. I strongly recommend using this kind of reports in automation scenarios only , and let the user see the print preview dialog in the rest of cases. The only difference between this reports and the standard ones, is that you will cannot make use of dialogs, the runtime will always pass in empty views to the ConfigureReport method. The ConfigureReport method will be executed, but you will have to grab the arguments from somewhere else. The execution pipeline is the same that NRapid uses for standard reports. This is the code to print out the whole list of categories in a dialogless mode. Notice that this report inherits from UnattendedReport class, this class tells to NRapid “run the report unattended”. Also notice that this class comes with a convenience method to configure the report with no arguments. You still can override the one that gets the view data but you will always

How to create MS Word documents from Office templates using C#

The OpenXML SDK allows you to do pretty much anything you want with office files such as Excel, Word, etc… While many people like this library, I found it complex, unintuitive and poorly documented, not to mention the awful xml format that uses under the hood to represent the documents, styles, etc. So I decided not to use it and build my own solution. If you, like me, don’t like that library, you will find in this post an alternative approach to build word documents from templates using c#. A neat trick to work with Office is to use the macro recorder to understand how things work. The macro recorder allows you to start a macro, do something by hand, stop it, and then take a look at the generated VBA code. Once you do this, you are pretty much set. This is how it looks the template I’am going to use. Note: save the file as a Word template (.dotx) This is the code to create Word documents from C#: By running the code, you should get a document that looks