In a previous blog post, I said that you can now use .NET as the standard library, and I expanded the specification further and it now supports interoperability with other .NET languages via assemblies. In addition, I also revised the specification of the import statement, so I'll cover it.
Let's say we have the following C# source code:
//In TestInterface.cs
using System;
using System.Collections.Generic;
namespace InteroperabilityTest
{
public interface TestInterface
{
void DoSomething();
int GetSomeInt();
List<int> GetIntList();
}
}
// In InteroperabilityTest.cs
using System;
using System.Collections.Generic;
namespace InteroperabilityTest
{
public class InteroperabilityTest : TestInterface
{
public void DoSomething()
{
Console.WriteLine("Hello from 'DoSomething'");
}
public List<int> GetIntList()
{
Console.WriteLine("GetIntList called");
return new List<int>{1, 2, 3, 4, 5};
}
public int GetSomeInt()
{
Console.WriteLine("GetSomeInt called");
return 100;
}
}
}
// In StaticTest.cs
using System;
using Expresso.Runtime.Builtins;
namespace InteroperabilityTest
{
public class StaticTest
{
public static void DoSomething()
{
Console.WriteLine("Hello from StaticTest.DoSomething");
}
public static bool GetSomeBool()
{
Console.WriteLine("GetSomeBool called");
return true;
}
public static ExpressoIntegerSequence GetSomeIntSeq()
{
Console.WriteLine("GetSomeIntSeq called");
return new ExpressoIntegerSequence(1, 10, 1, true);
}
}
}
Assume that the DLL containing the above code is named InteroperabilityTest.dll and we'll write this Expresso code:
module main;
import InteroperabilityTest.{InteroperabilityTest, StaticTest} from "./InteroperabilityTest.dll" as {InteroperabilityTest, StaticTest};
def main()
{
let t = InteroperabilityTest{};
t.DoSomething();
let i = t.GetSomeInt();
let list = t.GetIntList();
StaticTest.DoSomething();
let flag = StaticTest.GetSomeBool();
let seq = StaticTest.GetSomeIntSeq();
println(i, list, flag, seq);
}
Then we'll see the Console.WriteLine outputs, 100, [1, 2, 3, 4, 5, ...], true and [1..11:1] on the console. As you can see, although you generally call only functions using FFI(Function Foreign Interface), here you can create instances and even call instance methods. Of course, it's because we run on the same runtime environment, the CLR. With the compiled DLL, you can create instances and call methods from other .NET languages such as C#. We take full advantage of the .NET environment, huh?
Apr. 7 2018 added: Although you could have "gotten" properties, it now supports "setting" properties.
It's almost there where we achieve complete interoperability with foreign .NET languages. Apr. 8 2018 added: Now you can refer to enums defined on IL codes. That means that we have achieved complete interoperability with other .NET languages, I suppose.
C# can interoperate with C++, so we could interoperate with C++ from Expresso if we wrap it in C#.
So notice the import statement has changed? In the previous post, the import clause takes a string but now it looks more like the ones in Python or maybe Rust(Rust calls it use statements, though). When the import statement is written in EBNF, it looks something like the following:
"import" ident [ "::" ( ident | '{' ident { ',' ident } '}' ) ] { '.' ( ident | '{' ident { ',' ident } '}' ) [ "from" string_literal ] "as" ( ident | '{' ident { ',' ident } '}') ';'
This means that you can't omit the as clause unlike Python. In Expresso, you have to alias imported names. Otherwise you would have to refer to them with names containing "::" or "." but Expresso doesn't allow it. You use "::" when you refer to a type that belongs to a module. This is also true for other expressions.
On the other hand, you also specify the namespace when you're referring to a type in external assemblies that are written in C#. In addition, when doing so you can't import variables and functions directly. This is because IL code doesn't allow you to define variables or functions on assemblies.
The file names in the from clause is relative to the source file that the import statement resides in. That means that InteroperabilityTest.dll locates on the same directory as the source file. This rule applies as well when you refer to .exs source files.
Now that we can interoperate with C#, I'm expecting to write the Expresso compiler itself in Expresso.
