Using C# as a Scripting Language

At AINIRO.IO we've just created a new release of Magic, where the most important feature is the ability to dynamically compile C# code and load the resulting IL code into the AppDomain, almost turning C# into an "interpreted language" due to an execution model that is more similar to PHP and JavaScript than traditionally compiled languages.

This has a lot of benefits, especially for Business Process Workflows, since it allows you to use C# in a dynamic runtime, where you've got dynamic actions that are executed from Hyperlambda being a high-level execution orchestration runtime. Below is some example code illustrating the idea:

using System;
using magic.node;
using magic.node.extensions;
using magic.signals.contracts;

[Slot(Name = "foo")]
public class Foo : ISlot
{
    public void Signal(ISignaler signaler, Node input)
    {
        input.Value = $"Hello {input.GetEx()}, najs to meet you";
    }
}

The point about the above code, of course, is that it implements the ISlot interface, which allows me to interact with it from Hyperlambda, as illustrated below.

foo:Thomas Hansen

The above Hyperlambda, of course, will invoke my C# slot, passing in "Thomas Hansen," and my C# slot, of course, will do some simple string concatenation, returning the result to the caller. If you save the above C# code as "/etc/csharp/foo.cs", you can execute the following Hyperlambda code to dynamically compile the file and execute the slot.

// Loading file.
io.file.load:/etc/csharp/slot.cs

// compiling file into an assembly.
system.compile
   references
      .:netstandard
      .:System.Runtime
      .:System.ComponentModel
      .:System.Private.CoreLib
      .:magic.node
      .:magic.node.extensions
      .:magic.signals.contracts
   code:x:@io.file.load
   assembly-name:foo.dll

// Loading assembly as plugin now that we've created it.
system.plugin.load:x:@system.compile

// Invoking dynamically created C# slot.
.name:John Doe
foo:x:@.name

// Unloading plugin.
system.plugin.unload:foo.dll

Notice that the above [system.compile] never saves the assembly but returns it as a byte[]. To save the compiled code, you can use, for instance [io.file.save.binary].

In the video below, I am demonstrating some features related to this and showing you how you can almost treat C# as if it's a 100% dynamic scripting language due to the dynamic nature of the process. This has a lot of advantages, especially related to BPW or Business Process Workflows, where you've got tons of smaller building blocks or composables you need to orchestrate together dynamically without having to go through an entire process of deployment and more rigid processes.

This allows you to dynamically orchestrate C# snippets together, where Hyperlambda becomes the orchestration tool, loosely coupling building blocks of C# code together that somehow perform a larger task. Due to the dynamic nature of Hyperlambda again, allowing you to build anything from scheduled tasks to HTTP endpoints, this has a lot of really interesting advantages for more complex domains, where the end state of your system is in constant flux, possibly due to integrating with hundreds of different parts, where each part is a separate application, often changing over time, making statically compiled code sub-optimal.

Statically compiled code is amazing, and you should, of course, prefer it when you can — However, there are problem domains it is fundamentally incompatible with — Workflows being one example.

Now, with the ability to compile C# code on the fly in Hyperlambda, this is no longer a problem, and you can use statically compiled C# as much as you wish for such problems. As long as you obey the Hyperlambda interface being the ISlot interface, allowing Hyperlambda to orchestrate your code together.