I've read up on EC# as you suggested. The way D# has diverged from C# mostly seems like a small subset of the features EC# has added. I'll try to break down the relevant points of convergence and divergence between D# and EC# here.

A (maybe not so) brief comparison between D# and EC

Things that D# and EC# agree on:

D# and EC# both seem to like the D-style public this() { ... } as constructor syntax, though D# does not permit C#-style public Foo() { ... } constructors.
Annotating parameters with set, e.g. public this(set int Value) { ... }. Same semantics as the macro in EC# (though D# does not require a using LeMP; declaration for set to work).
const as a keyword that indicates function purity. Flame uses this as a hint when optimizing. Though nonstandard, the EC# parser generously accepts const, and Flame.Loyc reduces it to Flame's PrimitiveAttributes.ConstantAttribute.
The virtual entirety of C#.

D#-specific stuff that C#/EC# don't do:

Extension properties. Constructs such as public static bool IsAbstract[this IMember Member] { const get { ... } } are commonplace in Flame, and are consumed same as instance properties.
Methods, constructors and accessors take a single statement as their body in D#, rather than a block statement like C# does. This is particularly useful when writing constructors, where usage of set has drained the constructor's body into oblivion, and writing an empty set of parentheses would otherwise be mandatory. With this, public Foo(int x, int y) { this.X = x; this.Y = y } becomes public this(set int X, set int Y);. Note the semicolon, which is a perfectly legal function body.
static means "make this type a singleton" or "add this member to the enclosing type's associated singleton" (except when defining extensions - this is a C# extensions ABI compatibility problem). Writing out a singleton's type name is then made equivalent to accessing that singleton's instance. Flame's EmptyStatement is a fine example of this. Perhaps an EC# macro could do the same?

C#/EC# stuff that D# doesn't have:

The typeof operator. D# tries to remain somewhat platform-agnostic, and as such does not yet have language-level support for reflection. I chose not to duplicate C#'s typeof operator because typeof(T) yields a System.Type, which would make D# reliant on the .Net framework forever.
Generic type inference. This is something I just haven't got around to implementing yet.
Macros in general.

Things that D# and C#/EC# do differently:

C#'s continue; is next; in D#. I've always considered continue to be a particularly poor way of stating "jump to the next iteration", and next was my own sad attempt at rectifying the situation.
D# handles delegate declarations differently. Instead of C#'s Func<int, double>, D# prefers double(int) - though Func<int, double> is by no means illegal -, which the CLR back-end then lowers to ye olde Func<int, double>. If I ever get around to implementing delegates in the C++ back-end, double(int) will likely be transformed into std::function<double(int)>, and the D# front-end will have no idea what Func<int, double> means, because Func<,> is part of the .Net framework core library.
D# lambdas are slightly different from C# lambdas:
- They are explicitly typed. x => x + 1 is int(int x) => x + 1 in D#.
- Rather than replicating C#'s error-prone by-reference closures, lambdas capture by-value in D#.
- Lambdas are a fairly new addition to the D# front-end and Flame in general. As a result, dsc's lambda support is full of bugs, which have taken up residence mainly in the front-end.
ref has been replaced by T^ "reference pointers", i.e. pointers which don't do pointer arithmetic and other things that tend to cause segfaults. Pointer indirection on these T^ types is explicit. My reasoning for this is twofold:
- ref causes hidden pointer indirection, which may conflict with other language features, such as lambdas.
- T^ lets you know what's really going on. Sure, using pointers can be challenging, but if someone's not comfortable with using the pointer indirection operator (*) because they don't know what will happen if they do, they probably shouldn't be using ref either, because that merely hides the superficial syntax of pointer indirection, rather than the underlying semantics.

Template expansion

I'll elaborate on this because it's more of a philosophical topic to me.

Expanding templates is easy, but I would much rather tackle the few remaining template expansion use-cases with generics and hidden delegate parameters. This may sound like a performance killer, but that need not be the case if the generated code is sufficiently optimized.

For example, consider this D# snippet:

public const int Apply(int(int, int) op, int lhs, int rhs)
{
    return op(lhs, rhs);
}

public const int Plus(int lhs, int rhs)
{
    return lhs + rhs;
}

public const int ApplyPlus(int lhs, int rhs)
{
    return Apply(Plus, lhs, rhs);
}

Compiling this with -Og (dsc's default optimization level) will result in the following IL for ApplyPlus:

IL_0000: ldarg.0
IL_0001: ldarg.0
IL_0002: ldftn instance int32 Sugar.Program::Plus(int32, int32)
IL_0008: newobj instance void class [mscorlib]System.Func`3<int32, int32, int32>::.ctor(object, native int)
IL_000d: ldarg.1
IL_000e: ldarg.2
IL_000f: call instance int32 Sugar.Program::Apply(class [mscorlib]System.Func`3<int32, int32, int32>, int32, int32)
IL_0014: ret

Obviously, that's a major performance killer. Now. let's try compiling with the (albeit experimental and maybe even dangerous) -O3 optimization level.

IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add
IL_0003: ret

Same source code, different set of optimization passes. -finline and -fpropagate-locals kicked in with that -O3 option, to be specific. These passes make a living out of cheapening abstractions such as this. A generic constraint such as this could be introduced:

public T Add<T>(T lhs, T rhs)
    where T operator+(T, T)
{
     return lhs + rhs;
}

which would then be lowered to:

public T Add<T>(T lhs, T rhs, T(T, T) op_plus)
{
    return op_plus(lhs, rhs);
}

And the optimizer would make calling this "performance disaster" a breeze.

Now, I don't think "the compiler will take care of it for me" a lot when I write code. I do, however, believe that this is one of those rare situations where the compiler itself can at first generate suboptimal code because it knows for sure that specific instantiations of said code sequence will be optimized in the release build.

Conclusion

D# and EC# seem highly similar to me, especially if the right macros are used. Unifying them doesn't look all that hard to me, really. I do wonder, though, if we wouldn't be better off considering how features such as non-nullable references will fit in first. Last time I checked, the Roslyn folks were still arguing over how to add those to C# without breaking the default(T) operator. Creating a new programming language gives us a clean slate, which I think is an opportunity we shouldn't waste.

In response to your question: actually, I stumbled upon Loyc in a Google search results page, though I can't quite recall the specifics of my search query.

I'm also actively interested in developing a cross-platform standard library which can then be linked (and LTO'ed) with a platform-specific "primops" library. However, I don't see that happening any time soon without some intermediate format - not quite unlike SIL, though I would require said format to have an efficient, easy-to-parse binary representation: parsing source code has always proven to be prohibitively expensive in my experience.

Also, this comment ended up being way longer than I intended. Sorry about that.

Comments: Projects' status & task list #3

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions