Reasons for using a DLR-based language rather than C# for scripting tasks?

Question

I'm considering embedding a scripting language into one of my software projects and have identified two options: compiling C# at run-time via CodeDOM and embedding a DLR-based scripting language. Both options would give me full access to the .NET Framework.

The operation that I'd be scripting would be a user-defined transformation of a DataRow and a set of metadata resulting in a modified DataRow. I expect these transforms will be composable and frequently invoked. Of course, I expect the transforms to be provided and modifiable by the end-user.

With this workload in mind, are there any clear advantages to using one approach over another?

Answer 1

For users it's usually better to use languages with a more forgiving syntax, for obvious reasons. So I would recommend using a DLR based-language. If you have the time and resources, a specialized DSL is the best choice, because you can offer a small and easy-to-learn syntax, and it's easier to keep the user from doing things they should not be doing (like accessing the filesystem, for instance...)

I can't speak from experience, but, from what I've seen, the DLR can be quite fast (IronPython does better than native Python!). But dynamic dispatch always entails a slight overhead. On the gripping hand, cross-AppDomain calls are pretty expensive. While the dynamic dispatch cost is paid everywhere inside the script, the cross-AppDomain cost is paid only once per script call. Which one does better depends on how much your scripts will do.

Embedding a DLR Scripting Host is not difficult at all. What's difficult is to roll your own DSL, if you choose to go that way.

You could also look into boo. It's a static CLI language that looks like Python, thanks to type inference. Its compiler is highly extensible, and I've had some success writing some small DSLs on it. You could also look into Oren's book Writing DSLs with boo.