What technology to use when creating a DSL for rules?

Question

What technology would you recommend creating a DSL for Business Rules and a validation application block for .NET ? And why?

The architecture of the framework is established and verified on a production basis. I just want to create a .NET processor to convert plausible rules into compiled rule implementations.

The options that I know of are as follows:

• Use the .NET Boo Compiler Pipeline
• Use the parser constructors that come with F # - FsLex and FsYacc

Unfortunately, none of these approaches provides anything to create a more or less friendly development environment for DSL editing, given the DSL syntax (which will evolve).

Any ideas or tips?

Answer 1

Microsoft's next-generation application development platform, codenamed Oslo

Makes it easier for people to record things in ways that make sense for the problem area in which they work in

Oslo seems to consist of a visual design tool called the Quadrant, a modeling language named M, and the Oslo repository (SQL Server database) that stores the rules.

So, if I read it right, you can define a modeling language in M, use Quadrant to define and edit validation rules using your own modeling language, and write an application using the Oslo repository that creates your business rules and Application Validation block for .NET.

Answer 2

A graphical language for business rules is not a good idea. I would avoid this. There are a lot of checks and loops in business rules that don't render well.

You are much better off with a text language for describing business rules.

To get the phenomenal user interface for editing the code you need:

• Parser with good error recovery
• Ability to do incremental recompilation

Good error recovery allows you to effectively determine the intention of a programmer from syntactically incomplete constructions. This is important for introducing intelligence.

The ability to do incremental recompilation gives you the ability to do an efficient compilation of the background in response to user changes.

The easiest way to get a good bug fix is ​​to write your parser manually. That way, you can use any number of look-aheads or algrorithmic algorithms to figure out what to do when there are syntax errors.

When you use the parser generator to create a parser, you lose a lot of flexibility when dealing with syntax errors. This flexibility makes the difference between good perception experience and therapy. Therefore, I recommend that you simply write it manually using a recursive descent.

Implementing effective recompilation requires that you can: 1) Break the semantic analysis correctly into phases (for something like C # it will be: first create a namespace and type characters, then enable the use of operators, then enable the base classes, etc. ) 2) The ability to build a phase-dependence diagram 3) Algorithms for processing the dependency graph and the invalidity of its parts in response to user changes

For a fully functional programming language, implementing recompilation can be a very difficult task. In your case, since you are describing business rules, there may be a lot of simpiler for you (or if the compilation is fast enough, you might not need it).

So, I would start with a parser, and then build supervision on it.

If you can avoid VS integration, I would do it. Integration in VS requires a lot of plumbing, and interaction can cause headaches. There are several companies that sell window editor controls that you have connected to your parser. It is much easier to integrate with VS.

Answer 3

Another possible interesting alternative is to use F # quotes.

Quotations allow you to consider part of the program as data, so you can get an AST, analyze it and translate it into another language or execute it in a non-standard way. Along with the flexibility of F #, you should be able to express many things, so you need to develop an internal F # DSL / combinator library to describe the rules and a translator / interpreter for F # quotes to run them.

I don't know what a business rule looks like, but you can write something like this:

let rule = <@ if (exists customer having validEmail) then success else require whatever @> 

I wrote an introduction to this topic on my blog. Unfortunately, there have been some big changes in F # CTP, and I haven't updated the source code yet, but it should give you a good idea of ​​the possibilities and limitations of this approach.

• F # Quotes Samples on CodePlex - TomasP.Net

A good example of DSL is F # unit test fusion:

• FsTest Announcement - Testing DSL for F # - Matthew Podwiski

[EDIT] Just to clarify why I think this might be a good approach:

• If you use Visual Studio to edit DSL (and you can use the Shell version with F # installed for free), you will get very good editing for free. Not only syntax highlighting, but also IntelliSense, which will suggest possible designs, as well as background type checking, which serves as a grammar check for your DSL.
• Compared to other approaches, this is perhaps one of the easiest to implement.
• The only limitation is that you are limited by the F # syntax. However, creating your own language is really difficult, so it may not be at all. Especially considering the flexibility of F #.

[/ EDIT]

Hope this helps!

Answer 4

I would use Boo, I believe that at present it is one of the most flexible tools for creating DSL. There is a very good book on the subject. The Ayende and Rodrigo Blog are good inspirations.

In the IDE, you can extend SharpDevelop , take a look at this .

Answer 5

The standard DSL ANTLR seam tool is a powerful lexer / parser generator with many target languages ​​for compiler output. It has backends for C #, Java, C / C ++, Python, etc. (See the list of code generation goals ) and allows you to enter your own code into your compiler in your target language easily.

There is also a very powerful IDE (ANTLRWorks) and a lot of documentation. (Visit the Grounded ANTLR Reference from Terrence Parr, author of ANTLR). For links to who else uses it, see the Testimony Page .

You still need to do most of the plumbing for the IDE yourself, but it should be a lot easier, given the robust compiler structure you get from ANTLR. This should be the case for most of the solutions posted here ...

I am currently using a compiler written with ANTLR to preprocess our own DSL output in C / C ++ and am very pleased with this. Enough advertising, you should try it for yourself :) Good luck!

Answer 6

JetBrains Metaprogramming System

You can define custom language editors and other restrictions for any new language, so working with these DSLs will become very simple. Domain experts who are not familiar with traditional programming can easily work in MPS with their domains using domain-specific terminology.

Answer 7

I'm new to this, but OMeta seems like the perfect tool for developing DSL. There seems to be no IDE around it, but the good news is that the “rules” that you can write in OMeta are very readable. (And he deals with left-recursion, which is very cool.)

There are currently OMeta implementations, at least in Javascript (very interesting for me) and Python, possibly others. As for C #, Jeff Moser is working on what you can read about on your blog and check out CodePlex . Good luck.

Answer 8

Boo + OMeta = Boo.OMeta.Parser

The analyzer is currently under development, but it can already be used to create complex external DSLs. OMeta is a powerful tool that allows programmers to easily implement lexical analyzers and parsers. The extensible pipeline architecture of the Boo compiler allows you to replace the standard Boo.Parser with Boo.OMeta.Parser. It can be used to extend Boo syntax with almost any syntax. This example can be found here .

Answer 9

My meta # project is trying to solve this problem.

Answer 10

If you want to create a friendly IDE that edits DSLs, make the IDE fully graphical and compile .NET objects (or use something like IronPython as the glue language).

If the rules are simple enough, you can implement the entire structure of the rules graphically. If the rules are complex enough, human readability becomes an impossible goal.

In any case, if the set of .NET classes or IronPython objects that create the intermediate code is not human readable enough, then there is a chance that you need something more dummy than a grammar.

However, if you just want to create a simple language that programmers can use to create business rules, feel free to use any of the above and making the minimum minimum syntax is not enough to not require the Visual Studio IDE.

Answer 11

Ruby is a great language for creating DSL. For example, Rake is a DSL with a script construct written with Ruby.

With the upcoming IronRuby, you can write scripts that invoke your C # code directly.

Here are some articles about writing DSL in Ruby.