4 ms·

What do you mean by incompatible? If you mean syntax, that's different intentionally for clarity and also we don't want to create a new C# scripting dialect hen

What do you mean by incompatible? If you mean syntax, that's different intentionally for clarity and also we don't want to create a new C# scripting dialect hence it isn't possible to "import" other files (that's not how C# works).

pjmlp 1y ago
The # declarations syntax for Assembly references.
- janjones 1y ago
  Assembly references are not really a mainline scenario, hence we support nuget package references only for now. And `#r` is just too opaque (it comes from old times when assembly references were the norm).
  - pjmlp 1y ago
    I disagree, this is the kind of decisions that make CLR the C# Language Runtime, instead of its original purpose, where there was an ecosystem of common approaches. Unless you plan to also support the same approach on VB and F# scripts.
    - janjones 1y ago
      F# and C# are intentionally different languages, I don't think it makes sense to have 100% equivalent functionality in both. AFAIK, F# already has scripting functionality built in. VB support could be added, but that seems unlikely given https://learn.microsoft.com/en-us/dotnet/fundamentals/languages https://learn.microsoft.com/en-us/dotnet/fundamentals/langua...
  - exceptione 1y ago
    janjones, can you please advocate inside your team for taking F# seriously? It should have been a first class language inside .net. I dread the moment C# introduces sum types (long overdue) and then have them incompatible with F#. On a general note, the total disregard towards F# is very much undeserved. It is far superior to the likes of Python, and would easily be the best in the areas of machine learning and scripting, but apparently nobody inside MS is that visionary.
    - electroly 1y ago
      > It is far superior to the likes of Python, and would easily be the best in the areas of machine learning... The fact that Python is the language of choice for ML makes it clear that technical superiority was not necessary or relevant. Python is the worst language around. The lack of better languages was never the problem. Making F# technically better wasn't going to make it the choice for ML.
      - exceptione 1y ago
        Agreed. But MS has certainly some weight to throw around in their own ecosystem. They have their own offerings for data processing and ambitions for AI. If they want to integrate with .net, they are already set. But that requires vision.
        pjmlp 1y ago
        Note that until the layoffs of the week predating BUILD, Microsoft was exactly one of the companies pushing for improving CPython performance. This is why I always mention, when .NET team complains about adoption among new generations not going as desired they should look into their own employer first.
        exceptione 1y ago
        > they should look into their own employer first. Indeed, it is a pattern making for some really bad optics. Why people still beat the dead horse of Python (performance) is beyond me.
  - Wolfspirit 1y ago
    I have to agree with others that it's strange this has not been in line with .net interactive and the usage of "#r" there. I think "#r" should at least be an option. You say that importing other files is not how c# works, but I think that's not entirely true. If you now treat a file as a project then an import is pretty much a project reference just to a .cs file instead of a .csproj file. So I'd love to see something like that working: #:reference ./Tools.cs Which should be the same as a ProjectReference in csproj or for a "real" project something like this: #:reference ./Tools/Tools.csproj That would also enable things like this in a csproj file: <ProjectReference Include="..\Tools\Helpers.cs" />
    - janjones 1y ago
      Referencing other projects is currently out of scope (and might always be, file based programs are intended to be simple), you can convert file based programs to full projects though to regain full functionality.
  - int_19h 1y ago
    Thing is, for quick and dirty throwaway scripts, an assembly reference is sometimes exactly what one wants. E.g. let's say I have a compiled app and I just want to reach inside of it and invoke some method.
debugnik 1y ago
You were already using F#'s syntax for C# NuGet references in .NET Interactive. Even NuGet itself labels this syntax "Script & Interactive" in its picker. https://github.com/dotnet/interactive/blob/main/docs/nuget-overview.md https://github.com/dotnet/interactive/blob/main/docs/nuget-o... Now you've created a new dialect.
- janjones 1y ago
  .NET interactive uses a dialect of C# - the script dialect. With file based apps, we strive to use the standard C#, so you can convert file based apps to full projects at any time.
  - debugnik 1y ago
    That doesn't explain why standard C# had to deviate further from the script dialect just for import directives. These directives don't interfere with the rest of the grammar. Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!) Has there been any effort to have the rest of .NET adopt this new syntax or share concerns? On that note, is any language other than C# supported for `dotnet run`? Is the machinery at least documented for other MSBuild SDKs to use? Considering how dotnet watch keeps breaking for F#, I suspect not.
    - janjones 1y ago
      > Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!) Yes, we believe so. There is not much to be gained from reusing the syntax (it's not like you can import cs from csx or vice versa). We are also adding other directives, e.g., `#:property` - it would not make sense to reuse `#r` for that. `#r` is short for "reference", because it was originally meant for referencing DLLs which is discouraged in modern .NET. The main motivation for file-based programs is to lower the entry barrier, and having opaquely named directives like `#r` seems counter-productive. > On that note, is any language other than C# supported for `dotnet run`? File-based programs are for C# only. F# already has `dotnet fsi`. VB support seems unlikely per the language strategy: https://learn.microsoft.com/en-us/dotnet/fundamentals/languages https://learn.microsoft.com/en-us/dotnet/fundamentals/langua... > Is the machinery at least documented for other MSBuild SDKs to use? There is really not much special machinery, an in-memory csproj file is created and built via MSBuild just like an on-disk csproj would. Any MSBuild SDK can be used via the `#:sdk` directive.

pjmlp 1y ago

The # declarations syntax for Assembly references.

janjones 1y ago
Assembly references are not really a mainline scenario, hence we support nuget package references only for now. And `#r` is just too opaque (it comes from old times when assembly references were the norm).
- pjmlp 1y ago
  I disagree, this is the kind of decisions that make CLR the C# Language Runtime, instead of its original purpose, where there was an ecosystem of common approaches. Unless you plan to also support the same approach on VB and F# scripts.
  - janjones 1y ago
    F# and C# are intentionally different languages, I don't think it makes sense to have 100% equivalent functionality in both. AFAIK, F# already has scripting functionality built in. VB support could be added, but that seems unlikely given https://learn.microsoft.com/en-us/dotnet/fundamentals/languages https://learn.microsoft.com/en-us/dotnet/fundamentals/langua...
- exceptione 1y ago
  janjones, can you please advocate inside your team for taking F# seriously? It should have been a first class language inside .net. I dread the moment C# introduces sum types (long overdue) and then have them incompatible with F#. On a general note, the total disregard towards F# is very much undeserved. It is far superior to the likes of Python, and would easily be the best in the areas of machine learning and scripting, but apparently nobody inside MS is that visionary.
  - electroly 1y ago
    > It is far superior to the likes of Python, and would easily be the best in the areas of machine learning... The fact that Python is the language of choice for ML makes it clear that technical superiority was not necessary or relevant. Python is the worst language around. The lack of better languages was never the problem. Making F# technically better wasn't going to make it the choice for ML.
    - exceptione 1y ago
      Agreed. But MS has certainly some weight to throw around in their own ecosystem. They have their own offerings for data processing and ambitions for AI. If they want to integrate with .net, they are already set. But that requires vision.
      - pjmlp 1y ago
        Note that until the layoffs of the week predating BUILD, Microsoft was exactly one of the companies pushing for improving CPython performance. This is why I always mention, when .NET team complains about adoption among new generations not going as desired they should look into their own employer first.
        exceptione 1y ago
        > they should look into their own employer first. Indeed, it is a pattern making for some really bad optics. Why people still beat the dead horse of Python (performance) is beyond me.
- Wolfspirit 1y ago
  I have to agree with others that it's strange this has not been in line with .net interactive and the usage of "#r" there. I think "#r" should at least be an option. You say that importing other files is not how c# works, but I think that's not entirely true. If you now treat a file as a project then an import is pretty much a project reference just to a .cs file instead of a .csproj file. So I'd love to see something like that working: #:reference ./Tools.cs Which should be the same as a ProjectReference in csproj or for a "real" project something like this: #:reference ./Tools/Tools.csproj That would also enable things like this in a csproj file: <ProjectReference Include="..\Tools\Helpers.cs" />
  - janjones 1y ago
    Referencing other projects is currently out of scope (and might always be, file based programs are intended to be simple), you can convert file based programs to full projects though to regain full functionality.
- int_19h 1y ago
  Thing is, for quick and dirty throwaway scripts, an assembly reference is sometimes exactly what one wants. E.g. let's say I have a compiled app and I just want to reach inside of it and invoke some method.

debugnik 1y ago

You were already using F#'s syntax for C# NuGet references in .NET Interactive. Even NuGet itself labels this syntax "Script & Interactive" in its picker. https://github.com/dotnet/interactive/blob/main/docs/nuget-overview.md https://github.com/dotnet/interactive/blob/main/docs/nuget-o... Now you've created a new dialect.

janjones 1y ago
.NET interactive uses a dialect of C# - the script dialect. With file based apps, we strive to use the standard C#, so you can convert file based apps to full projects at any time.
- debugnik 1y ago
  That doesn't explain why standard C# had to deviate further from the script dialect just for import directives. These directives don't interfere with the rest of the grammar. Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!) Has there been any effort to have the rest of .NET adopt this new syntax or share concerns? On that note, is any language other than C# supported for `dotnet run`? Is the machinery at least documented for other MSBuild SDKs to use? Considering how dotnet watch keeps breaking for F#, I suspect not.
  - janjones 1y ago
    > Is #:package <pkg> really so much nicer than #r "nuget: <pkg>" as to deserve deviating from .NET Interactive, F# and the existing NuGet picker? (It could be, if properly argued!) Yes, we believe so. There is not much to be gained from reusing the syntax (it's not like you can import cs from csx or vice versa). We are also adding other directives, e.g., `#:property` - it would not make sense to reuse `#r` for that. `#r` is short for "reference", because it was originally meant for referencing DLLs which is discouraged in modern .NET. The main motivation for file-based programs is to lower the entry barrier, and having opaquely named directives like `#r` seems counter-productive. > On that note, is any language other than C# supported for `dotnet run`? File-based programs are for C# only. F# already has `dotnet fsi`. VB support seems unlikely per the language strategy: https://learn.microsoft.com/en-us/dotnet/fundamentals/languages https://learn.microsoft.com/en-us/dotnet/fundamentals/langua... > Is the machinery at least documented for other MSBuild SDKs to use? There is really not much special machinery, an in-memory csproj file is created and built via MSBuild just like an on-disk csproj would. Any MSBuild SDK can be used via the `#:sdk` directive.