jonathanvdc/flame

A compiler framework for managed code.

flame's Issues

great work

great work but why not continue the project?

Design: static classes that implement interfaces

Continuing from #26, It seems to me that the obvious way to support interfaces that include static members is like this:

public class Foo : IBar
{
    public static int Bar() { /* implementation */ };
    [CompilerGenerated]
    int IBar.Bar() { return Bar(); };
}

For convertibility to C#, a static class like

public static class Foo : IBar, IBaz
{
    public static int Bar() { /* implementation */ };
    public static int Baz() { /* implementation */ };
}

could be implemented either by removing static, so that a constructor and interfaces are allowed, or by doing this harder thing:

public static class Foo
{
    public static int Bar() { /* implementation */ };
    public static int Baz() { /* implementation */ };
    public static Foo_impl Instance { get { return Foo_impl.Instance; } }
}
public static class Foo_impl : IBar, IBaz
{
    int IBar.Bar() { return Foo.Bar(); };
    int IBaz.Baz() { return Foo.Baz(); };
    private Foo_impl() {}
    // thread races don't seem to matter here
    private static Foo_impl __instance__;
    internal static Foo_impl Instance => __instance__ ??= new Foo_impl();
}

I'm not sure what you meant about lexical macros, but this cannot be done with a lexical macro since the macro can't tell which methods are members of an interface.

Removing static from static class is a problem unfortunately, because C# only allows extension methods in static classes, and there's no logical reason not to allow a static class to contain both extension methods and interface implementations. On the other hand, maybe we could flip it around and move the extension methods to a new class if necessary. In fact, yes, I like it. I've often wanted to define an extension method inside a non-static class and this would be possible like so:

// Enhanced C#
public static class Foo : IBar, IBaz
{
    public static int Bar() { /* implementation */ };
    public static int Baz() { /* implementation */ };
    public static void ExtensionMethod<T>(this T o) { };
}

// Plain C# - note that the class is no longer `static`
public class Foo : IBar, IBaz
{
    public static int Bar() { /* implementation */ };
    public static int Baz() { /* implementation */ };
    public static void ExtensionMethod<T>(T o) { return Foo_ext.ExtensionMethod<T>(o); };

    private Foo() {}
    private static Foo __instance__;
    // Note: I like the name "Singleton" better than "Instance" 
    // unless the latter is already more popular
    public static Foo Instance { get { return __instance__ = __instance__ ?? new Foo(); } }
    int IBar.Bar() { return Bar(); };
    int IBaz.Baz() { return Baz(); };
}
public static class Foo_ext 
{
    public static void ExtensionMethod(this T o) { };
}

Note: I just verified that plain C# allows using static Foo where Foo is not a static class.

More frontends

Add more language frontends

Complex example

Pls add a more complex example

So... what's the deal with D#?

I mentioned elsewhere that I didn't think there was much to be gained from making a brand-new programming .NET language because there are already nice alternative .NET languages out there - Nemerle, boo, and so on. For that reason (and because of the lack of documentation) I have to admit that I haven't been paying much attention to D#.

Your readme says it is "roughly speaking - a dialect of C#". I'm not sure what that means. What does that mean? Do you intend backward compatibility with C#? If not, why not? What's the difference? It sure looks like C#...

Loyc += Flame?

So you might have noticed I made an "organization" called loycnet (because some inactive, zero-contribution user is sitting on "loyc"). The ecsharp repo there will become the main one for the source code (and maybe for ecsharp.net too).

And I'm rewriting the front page of loyc.net. I want to make Loyc more inclusive and start building some kind of community, not that I know how to recruit. But an obvious place to start is by listing Flame as a Loyc project on the home page. Does that sound good to you? How would you describe it in one paragraph? I guess Flame doesn't have its own home page, so how about I link to here?

BTW I made a thread for general conversation which we could use to contact each other about minor questions and random thoughts. Care to subscribe/watch it?

backend tutorial

could you make a tutorial how to make a custom backend instead of a custom frontent?