Discussion / proposal: usage of any installed programming language

As @TrendyTim mentioned in #46:

Public Class TestClass
    Private vbVar as String
#Language CS
    public static void Main()
    {
        bVar = "From C#";
        MoreVBCode();
    }
#End Language
    Sub MoreVBCode()
    End Sub
End Class

I think this would be a very nice construct to use the language of choice (for us here VB) and still be able to use any installed language in the cases where another language better fits the job without resorting to different projects in different languages.

Syntax as proposed by @TrendyTim
#Language CS
#Language C
#Language C++
#Language F#
#Language IL
etc, any installed language should be usable.

Implementation: The #language/#End Language functions should be compiled into a separate assembly using the specific language compiler.

ADDED
In the example above, the call to MoreVBCode would cause a circular reference; The main VB assembly references the C# assembly where Main is defined, and this function needs a reference to the main VB assembly.
To fix this, the call to MoreVBCode should be implemented as a delegate,Invoke.
In the generated C# code, all references needed in the VB Assembly must be available in the generated function call.

The c# function above would get the following signature:
void TestClass_Main(Delegate MoreVBCode, out string vbVar);

[TrendyTim]

I’m glad you like the idea, although it would be problematic to compile to separate assemblies, as you would lose access to the private members without using reflection (unless the compiler can sneak around that limitation)

As nice as that syntax is, and how powerful it could be, now I think about it, I’m not sure how one could solve the issue of cyclic dependency if the VB code needs the c# code and the c# needs the vb code how would it be able to reconcile it. Maybe someone a lot smarter than me would know a way, but I am far from qualified for that, just the thought of it make my brain meltdown..

@TrendyTim
Just added that part.

AS I think of it, the out string vbVar would not work, bacause it updates the var after the call to MoreVBCode.

So it should be implemented as "fieldInfo vbVar" and updated using reflection.

[Bill-McC]

When you consider compiler directives, imports/using statements, etc, partial classes and one language per partial class code file is probably more functional.

@Bill-McC
I think the inline idea is much more readable then a separate project.
Also, a separate project could be overkill (in form of maintainability) when you have to create a complete C# project for one or 2 functions.

@TrendyTim
I implemented your idea:

VBCode:

'In VB project: MultiProgrammingLanguageTest
Public Class TestClass
    Private vbVar as String = "From VB"
#Language CS
    public void Main()
    {
       string CsString ="From C#";
        vbVar =CsString ;
        MoreVBCode();
    }
#End Language
    Sub MoreVBCode()
        Msgbox(vbVar)
    End Sub
End Class

The following CS code is generated:

//Auto created CS Project: CSMultiProgrammingLanguageTest

//Auto generated code:
using System.Reflection;

namespace CSMultiProgrammingLanguage
{
    public class TestClass
    {
        //Every field referenced in the VB Code gets a getter and a setter.
        static void SetvbVar(object Instance, FieldInfo vbVar, string value)
        {
            vbVar.SetValue(Instance, value);
        }
        static string GetbVar(object Instance, FieldInfo vbVar)
        {
            return (string)vbVar.GetValue(Instance);
        }

        //a delegate for every VB function that is called
        public delegate void Action();
       //instance and fieldinfo for every instance and field that is used, delegate for every call made
        public static void CSMain(object Instance, FieldInfo vbVar, Action MoreVBCode)
        {
            string CsString ="From C#"; //plain CS, not converted
            SetbvVar(Instance, vbVar, CsString); //var= value is converted because var is a VB var
            MoreVBCode.DynamicInvoke(); //VB Function call is converted to an invoke
        }
    }
}

The CS code in the VB file is converted to the following generated code:

    'Reference to the generated CSMultiProgrammingLanguage is automatic added
    Public Sub Main()
        CSMultiProgrammingLanguage.TestClass.CSMain(Me, Me.GetType.GetField("vbVar", Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.Instance), AddressOf MoreVBCode)
    End Sub

A call to (new Test).Main() now shows a messagebox with the text "From C#"

[Bill-McC]

Separate code file in the same project, not separate projects.

@Bill-McC
I can live with that, but that takes a second change; multi-language projects.
And I do not think that will be easy given the differences in the project files, especially with languages as C++ combined with languages as VB.

[Bill-McC]

I don’t see how having the language separated by blocks is anyway easier than separate by file. For anything other than trivial, you really need the file structure, e.g. Imports vs Using. You could also add compiler directives, either to the code file, or a project file (sub-project file) .

Either way is acceptable for me, inline or language by code file (I would prefer the possibility to use both).

The bottom line is that I think we should be able to mix the capability several languages, to be able to use the right language for the right job; for example using unsafe methods in C#, functional programming in F# and that all while building the bulk code in VB.

[paul1956]

I love the idea of mixing languages in a project, I don't need in a file. Virtually every real VB project I work on has a C# Project to handle some Unsafe Code. Maybe Span(Of T) someday will fix this. Today VSIX projects seem to be able to compile C++ code in the vsct file. One specific example is the Hash Class from Roslyn, which I need to use in one of my refactoring's and it is marked Friend. It is extremely difficult to if not impossible to implement in VB. So I had to create a project, rename the namespace and class to avoid conflicts, and track changes in the Roslyn version, all extra work.

[TrendyTim]

@tverweij Not bad, it probably comes at a little performance hit, but generally its probably not going to be a big deal, would still be nice if it could be in the same assembly for lower overhead/ and fewer files for deployment (perhaps if it did an IL merge or something). Its not quite as nice as just compiling each block to IL and having it render out one class in IL that came from two languages (if thats even remotely possible), but it gets the job done.

@Bill-McC Both methods have their pros and cons the biggest pro of inline is you don't have to context switch, if it was in a separate file and we could do partials have to ensure case sensitivity of class names and translate the access modifiers correctly which may be a little tricky for people not well versed in both languages to keep them in sync, if partials weren't supported its another helper class that's required, and you lose easy access to private members.

If you have C# files in the project you might end up with some confusing assumptions like folders in c# give you automatic namespaces (something i WISH vb .net did, the number of times i forget to add namespaces because of that (even though i do almost all my work in VB i suppose i live in denial that C# has a lazy programmer feature that VB doesn't). You also have the context switch of going to another file to work on the same class and you may also find yourself going back and forth a lot.

Sometimes i want to have one method in C# because it offers features that for some reason VB doesnt (like dynamic types or unsafe code, but only wanted it in one method, other times a whole file might be useful to be in C# like back when webapi was almost impossible to use in vb)

So long story short, both would be awesome, and technically if inline was done, separate files would be as well by association (just that it could allow for the default language from the file type). Though i image a new project type would be required to be able to configure language specific options (but hopefully most things can be unified, C# projects have some things that would be nice in VB projs and vice versa if i recall)

Either way i would still be a happy camper, and all .Net languages could work together in perfect harmony.

[AdamSpeight2008]

@tverweij There is an implicit assumption here that #Language ... and #End Language means the same across all languages, that could be untrue.

[TrendyTim]

Actually how’s this, a combination of both methods, building off of what @tverweij did, what if when support for multiple language files in same project is added, the #Language directive region generates a language file of the same name but that language ext (either virtually, temporarily or as a “subordinate” file like the .designer files, perhaps as filename.generated.cs or filename.mixedlang.cs).

If the language directive is inside a class it could automatically generate the partial class (and any needed namespace) as appropriate (also means to enable #Language inside a class you need to make it partial).

If it’s outside a class it just “moves it” verbatim though ensuring the namespace (assuming one would want to support that modality).

Any imports/using would need to get converted into the auto generated file as well and of course I don’t think supporting it inside a method is valid (nor modules because you can’t have partial modules as far as I know).

That way we get best of both worlds, with little extra work.

Edit: just to clarify that’s not to say that anyone can’t add te other language file themselves, this would just builds on that as an added ease of use. But as i said before it would be nice but not necessary for inline, I’d take what I can get.

@AdamSpeight2008 not really, here #Language is assumingly talking about vb, it can of course be whatever the default language (ie file type) defines it to be, c# or f# may just want is as #lang VB

[AnthonyDGreen]

Why do people hate managing two projects and two DLLs so badly?

[AdamSpeight2008]

@TrendyTim #Language CS would switch the parsing in be parse as CSharp, so the #End Language also has be parsed in C# not VB. Thus has to able to be parse in all languages.