Scripting engine with static typing

Question

Hi,

I am looking for a scripting engine that can be integrated in .NET but NOT with dynamic typing! For example, JavaScript is not suitable, because it is a dynamically typed language.

Do you know any?

Answer 1

Boo?

Boo is a new object oriented statically typed programming language for the Common Language Infrastructure with a python inspired syntax and a special focus on language and compiler extensibility.

Edd Dumbill has a post about Boo scripting, and there's a tutorial on the main Boo site. It also has an interactive environment, booish.

Answer 2

CS-Script uses C# itself as a scripting language:

CS-Script is a CLR (Common Language Runtime) based scripting system which uses ECMA-compliant C# as a programming language... The main idea of CS-Script is to allow "plain vanilla" C# code execution from both command-prompt and form any CLR application hosting the script engine.

To my eyes it looks too verbose for a scripting language since it still requires all the paraphernalia of classes and namespaces and so on. But depending on your requirements the familiar syntax (as well as of course the static typing) may make it a suitable choice.

Answer 3

Why not use C# itself as a scripting language?!

This is what the Unity3d game engine does (with a Mono based implementation) and it works like a charm.

Reference:

• Treating C# Like A Scripting Language
• It Already Is a Scripting Language

Answer 4

Script. NET It is a dinamic typed language, by you canuse a duck-typing to resolve types.

Answer 5

F# is getting to be really popular: http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/

Answer 6

PowerShell is a scripting language that's actually built into the .NET Framework 3.5 SP1 and above: supported by Microsoft, extensible, under active development and plenty of documentation and samples (e.g. Bruce Payette's Windows PowerShell in Action). You can host PowerShell within your application (via the System.Management.Automation.Host namespace) -- it doesn't have to run in an external, visible console. There is some debugging support.

Cons: the syntax will look weird to people more familiar with C# (though it will make more sense to those coming from Unix scripting environments), and the hosting model is a bit forbidding compared to, say, DLR-based languages. Also, the type model is not conventional static typing, though it's not really dynamic typing either (Payette describes it as "type promiscuous"). A measure of static typing is available but is not enforced. So I am not sure if it will give you the level of type safety you're looking for: it depends on exactly what your requirement is: check it out and see whether it fits.

Answer 7

It's never clear what people mean when they say "scripting language". I've heard

• Can develop useful prototype programs very quickly.

• Lots of good string manipulation built in.

• Good at controlling other applications.

• No fascist static type system to keep you from developing things quickly.

Obviously you don't mean the last. Assuming you want "can develop useful prototype programs quickly" and you are willing to settle for regular expressions as "good string manipulation" (which most programmers are OK with although I personally am not a huge fan), then I suggest you check out F#. The link is to Don Syme's blog; Don is the lead designer as well as chief cook and bottle washer.

I recommend F# because it is based on core Caml, and many people have enjoyed a fair degree of success using languages in the ML family for scripting. Certainly, if you want a language with a static type system, you want a polymorphic one, and F# is the only statically typed language which not only supports parametric polymorphism with type inference but has also been very carefully crafted to work well within the .NET framework. That' why I think it's the clear choice for a statically typed .NET scripting language.

Answer 8

Hope this doesn't sound shirty, but if none of the other suggestions up here are suitable you're going to have to write your own language. How deep you make the implementation is up to you.

• If you want a pure scripting language - i.e. no compilation, then all you're doing is throwing around .Net object instances and marshalling function calls etc; binding them by strings. You can operate at the reflection level for this - late-binding method calls, properties etc the whole time. It will be sorely slow though.
• You could choose to be limited to the code that can be produced by System.Linq.Expressions (in .Net 3.5 it's quite limited, in .Net 4 it will be a lot richer)
• You could go just with IL generation with DynamicMethod.
• Or you can emit IL to a savable assembly that could be used in other projects via System.Reflection.Emit. This is the one that'll take you the most time. I wrote a system which dynamically built new types based on user-supplied interfaces and bases by wiring static methods written like extension methods into a new type. In the end the types were all produced from an XML file. I could build in cross-cutting and loads of other cool things. Took me a while though.

But why do all this when you can use any .Net language as a scripting language if you want. I can say first-hand that developing your own language is painful, as you start to need generic support for example, or the ability to handle delegates etc. The other .Net languages are already mature, well-documented and in the case of VB.Net very easy to learn.

Why not take fragments of C# code, surround them in a static void main, compile it into an assembly and execute it, or you can do it with VB.Net, and F#.

If you want debugging support then you're going to have to do more work whichever way you look at it.

The requirement for non-dynamic could do with some explanation though, because realistically languages built on the DLR are absolutely prime to solve your problem.

Answer 9

I have used Lua in one .net project, has nice .net binding.

However I have moved away from this to use IronPython from now on (because more people know Python than Lua)