Top level statements and member declarations (embrace scripting dialect) (VS 16.8, .NET 5)

[MadsTorgersen]

The C# compiler currently understands a dialect of the language used for various scripting and interactive purposes. In this dialect, statements can be written at the top level (without enclosing member bodies) and non-virtual members (methods etc) can be written at the top level (without enclosing type declarations).

Usage of the scripting dialect has been relatively minor, and in some ways it hasn't kept up with the "proper" C# language. However, usage is picking up through Try.NET and other technologies, and I am concerned with being stuck with two incompatible dialects of C#.

I think there is merit to allowing top-level program code instead of requiring the "program" to be in a Main method. And I think there is merit to allowing functions to be declared at the top level of a program, without needing to be enclosed in a class. I think these allow small programs to be meaningfully simpler, and make the language easier to learn.

public int Fac(int x) => x < 0 ? x * Fac(x-1) : 1; // Top-level function
Console.WriteLine(Fac(5)); // Top-level statement

As opposed to:

public class Functions
{
    public int Fac(int x) => x < 0 ? x * Fac(x-1) : 1; // Top-level function
}
public class Program
{
    static void Main()
    {
        Console.WriteLine(Functions.Fac(5)); // Top-level statement
    }
}

I believe we should consider putting these extensions into C# "proper" and do away with the separate scripting dialect. In doing so we should not feel too bound by design details of the scripting dialect, but make sure we resolve those details in a way that's best for C# as a whole. I'm not so worried about "breaking" the C# scripting dialect. Since its use is mostly interactive, there probably isn't going to be all that much source code around that depends deeply on its semantics.

I hope that adding these features can help create a more continuous growth path from someone experimenting in a Jupyter workbook to having a full-blown C# application, and that sort of scenario.

I don't have a concrete fleshed-out proposal at this point. I think we should start by reviewing the current state of affairs and brainstorming what would work well and less well from the scripting dialect.

[HaloFour]

If the top-level members are only accessible within the current assembly (my preference) I'd be in favor of all top-level members being implicitly static members of a partial internal static class with an unspeakable name. Other source files would automatically using static to import those top-level members. If the top-level members are defined within a namespace, then there would be additional static classes defined within those namespaces, and those static members would only be auto-imported if the namespace is imported.

If you want these top-level members to be accessible between assemblies, you can take a cue from Kotlin which offers this same feature. It's similar to above but the name of the static class is predictable and based on the package/namespace. You can apply attributes/annotations to cause the compiler to emit a different type name if you want, which is useful for Java interop scenarios in Kotlin and I think would be similarly useful here with the .NET ecosystem.

But to be honest, is it worth doing at all? Is there actually that much (or any) usage of C# script, enough to warrant that C# adopt it's syntax and idioms? To be honest I'd probably like to use it, but as far as I can tell it's not available on Mac. I've never seen it used in any Windows shop. To me it only functions as a slightly nicer Immediate Window. It could be more than that.

[yaakov-h]

At the risk of stating the obvious, how would this work if multiple source files in a single compilation declare top-level statements?

[orthoxerox]

@yaakov-h The simplest option would be to raise an error when there are multiple source files in a single compilation and at least one has top-level statements.

[canton7]

(What follows is a brainstorm around the topic. I'm not invested in any of it - please feel free to shoot it down).

I'm a little bit worried about allowing people to interleave top-level code with things like class definitions (although I know plenty of scripting languages allow this). I can imagine finding unexpected surprises hidden in larger applications.

One thought is introducing something like a script block:

script
{
    public int Fac(int x) => x < 0 ? x * Fac(x-1) : 1; // Top-level function
    Console.WriteLine(Fac(5)); // Top-level statement
}

(You could either allow top-level functions only inside a script block, or both inside and out).

This makes it a bit more obvious that this code should be interpreted as a script. If there are features which are only available to top-level statements (I'm think of things like #r), it might make it a bit easier to explain that "these particular scripting features are only available in a scripting context, as denoted by a script block", rather than trying to explain why top-level code has access to some features that code in a "normal" method does not.

It also might make it a bit more intuitive that a script can't be split across multiple files (if that is indeed something that's forbidden). It might also make the error messages a bit nicer, since it gives an explicit name to a block of top-level code: "application already contains a 'script' definition" might be a bit clearer than "top-level code found in more than one file".

One could also imagine being able to name scripts (script Foobar { }), and then execute them (FooBar.Execute()) or access functions inside them (FooBar.Fac). They would conceptually map to a class which contains methods, and an Execute method containing code. You can take this further and allowing remapping things like Console for a script, and you're starting to reach the functionality provided by things like ScriptCS.

Once your script's got a name, that makes importing scripts across assemblies more intuitive. No attributes required.

A natural step is then allowing files with a particular extension (e.g. .csx) to be in a implicitly placed in a script block by the compiler (perhaps with the same name as the filename), or providing APIs for importing text as a script at runtime, iterating over all scripts in an application, etc...

Or maybe this is just piling on a lot of unnecessary complexity...

---

Scripting languages get away with having top-level code in multiple files, because there's a clear "entry" file and a tree of files included recursively from that entry file in a deterministic and defined order. A file's top-level statements are run when that file is first included. C# doesn't have that luxury, so "which bit of top-level code is executed when" is always going to be a bit harder to explain.

If we want C# to behave like a scripting language (in certain contexts), maybe we need to mimic this. That would mean giving script files a separate file extension (e.g. .csx), and allowing them to include each other (e.g. #load). One such script file could then be designated as the "entry" one (e.g following some naming convention, and/or by allowing "normal" C# code to execute a particular script file). Top-level statements would then be executed across different script files in the order that they are #loaded.

The downside is that there are now two distinct paradigms for people to learn, with the inevitable transition between them. There's also the challenge of explaining "this snippet of code only works if you put it in a file ending with .csx).

[YairHalberstadt]

I think what's more important for c# scripting than the syntax is the tooling. There are countless times when I would like to spin up a repl to test my C# code, but unfortunately I find the tooling for c# interactive to be lacking, and I'm forced to experiment via unit tests instead.

[pie-flavor]

@canton7 For all that C# lets you do, it is still a thoroughly unambiguous language; things like duplicate names are checked aggressively by the compiler more so than other languages. What could it be possible to screw up with top-level members that isn't possible to screw up without them? And aside from that, what utility would there be in keeping a script separate? Top level code isn't much of a sticking point, void Main() is easy to rationalize, but there's no reason you shouldn't be able to define any function (including Main) outside of a class.

[orthoxerox]

If we want to provide a smooth ramp-up for language learners, then I can envision the following approach:

• top level statements, single file
• top level statements, local functions, single file
• Main, local functions, type declarations, load instructions, multiple files

That is, as soon as you want to declare a type or include a file, you need Main.

[gulshan]

Personally I like the idea of top-level functions and top-level const members. I think, top-level variables should be avoided. Also, instead of top level statements, I prefer a specific entry point or Main function. Which means, the C# script will still be a separate dialect, with special syntax for top-level statements as well as referencing other scripts and assemblies (and separate file extension .csx). But then C# proper will be much more aligned with C# script. I think this is similar to the path chosen by F# and Kotlin.

[ghord]

How about in addition to disallowing multiple files with top-level statements we also treat such statements as an implicit Main function? This way if user declares seperate Main, it will error out because of multiple declarations.

I think top level function declarations will be fine spread across multiple files.

[yaakov-h]

Something else that might be useful for scripting would be treating the first line of a file as trivia if it starts with #!.

[svick]

@yaakov-h That's already supported in the current scripting dialect.