Skip to content

Conversation

@dsyme
Copy link
Contributor

@dsyme dsyme commented Feb 19, 2019

I suppose this is a form of bike-shedding, but the source in our tree doesn't match our binary names, which irks me every time I come to it. We refer to

  • FSharp.Compiler.Private.dll
  • FSharp.Compiler.Service.dll
  • FSharp.Compiler.Interactive.Settings.dll

and so on but our source is always Microsoft.FSharp.Compiler.

Among other things this means you see a wall of text whenever you look at the open declarations at the head of the file on the F# compiler. Personally I think the compiler code looks simpler and more approachable with the shorter, plainer names - everyone knows Microsoft contribute heavily to F# and package it, we don't need to tell them 1700 times in the compiler code.

So I suggest we rename Microsoft.FSharp.Compiler --> FSharp.Compiler in our source.

  • This only affects the internal compiler code and the API of FSharp.Compiler.Service.dll

  • The one exception is FSharp.Compiler.Interactive.Settings, where open Microsoft.FSharp.Compiler.Interactive.Settings can be opened from existing F# scripts. I've added 10 lines to make sure still works

  • This doesn't affect FSharp.Core, which must remain binary compatible. (As background: Back in F# 3.1 we did a while lot of work to allow "open FSharp.Core" to be used instead of "open Microsoft.FSharp.Core". This is in line with that but we can simply rename the source)

  • This doesn't affect the name of the Microsoft.FSharp.Compiler nuget package which is built as part of Microsoft's the distribution of F# in the .NET SDK.

  • This doesn't affect the Visual F# bits.

  • This also does Microsoft.FSharp.Build --> FSharp.Build - again the DLL name is not changed, and the UsingTasks references don't refer to namespaces

@7sharp9
Copy link
Contributor

7sharp9 commented Feb 19, 2019

Ooooh, this would be a good time to check for internal reflection calls :-)

The namespace discrepancy is quite annoying.

@cartermp
Copy link
Contributor

This is a good change to make, assuming there aren't some policy issues that come up.

@dsyme
Copy link
Contributor Author

dsyme commented Feb 19, 2019

@cartermp Same test failing again, will need to look into this:

   at FSharp.Compiler.Service.Tests.PerfTests.Test request for parse and check doesn't check whole project() in D:\a\1\s\tests\service\PerfTests.fs:line 75

@dsyme
Copy link
Contributor Author

dsyme commented Feb 19, 2019

Another failure in Test request for parse and check doesn't check whole project

Will re-run and put in a separate PR to diagnose that test

@dsyme dsyme mentioned this pull request Feb 19, 2019
@dsyme dsyme merged commit a26d32a into dotnet:master Feb 20, 2019
nosami pushed a commit to xamarin/visualfsharp that referenced this pull request Jan 26, 2022
* Microsoft.FSharp.Comiler --> FSharp.Compiler

* Microsoft.FSharp.Build --> FSharp.Build

* fix small mistakes

* fix build

* fix flakey test (?)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants