am11
commented
2 years ago I was testing .NET 7 preview 5 SDK (daily build), which has added out of the box support for NativeAot. It seems to handle %A with a simple program (despite some errors and warnings in ILC step).
A quick How-To
OS: Ubuntu 20.04 x64 Setup: ```sh mkdir ~/.dotnet7 curl -sSL https://aka.ms/dotnet/7.0.1xx/daily/dotnet-sdk-linux-x64.tar.gz | tar xzf - -C ~/.dotnet7 alias dotnet7=~/.dotnet7/dotnet cat > ~/NuGet.config <Despite the error:
Failed to load type 'Microsoft.FSharp.Core.FSharpFunc
2<T1_System.__Canon, Microsoft.FSharp.Core.FSharpFunc2<T2_System.Canon, Microsoft.FSharp.Core.FSharpFunc2<T3_System.__Canon, Microsoft.FSharp.Core.FSharpFunc2<T4_System.Canon, Microsoft.FSharp.Core.FSharpFunc`2<T5_System.__Canon, TResult_System.__Canon>>>>>' from assembly 'FSharp.Core, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
ILC succeeds. If we can work this error out first in .NET 7 timeframe, that would be cool (since it seems benign, and showing up for a simple "Hello from F#" app as well).
cc @MichalStrehovsky
kant2002
MichalStrehovsky
abelbraaksma
The need for AOT and linker support
.Net code is deployed to devices where performance - including startup time - and download size are important. JIT is ruled out by this and may be explicitly prohibited (UWP and iOS) or result in unacceptably slow application startup (Xamarin.Android).
Current .Net plans (.Net Form Factors) involve a supported AOT option across .Net, with greater usage of linkers:
F# string problems affecting AOT/linker support
F# Support lists incompatibilities with CoreRT and .Net Native. These pick out the aspects of F# that are likely to be problematic for any performant AOT and linkers. (Note: F# is generally compatible with current mono AOT but this is not performant, and compatibility may not include linking.)
The largest problem here is F# string methods:
string,ToString(), andsprintf %Ado.The offending part of FSharp is lacking in type safety, with everything done via casting, uses reflection without restraint, and encapsulates poorly (e.g.
.ToString()methods in FSharp record and DU types just callingsprintf "%A"on the entire record).Solution part 1: localize by generating ToString() overrides on F# types
We have effectively, on F# record and DU types (just check SharpLab to confirm this):
The sprintf "function" doesn't have legitimate access to the data needed to generate the string, so has to use reflection to get the structure.
Instead this method should be compiled:
Note that once this is done,
CompiledToStringdoes not need to know how to print records and DUs.Solution part 2: compile
A method (represented above as pseudocode
CompiledToString<'t>) should be created to generate compiled code for any concrete type't, to be used in place of the current dynamic sprintf code where possible.Where the method sees only
objit could preferably use .ToString(), or else use a very light form of reflection, making sure that codegen is not used.Solution part 3: integrate
We need to decide where to use the method
CompiledToString<'t>:sprintfthat it is likely to replacesprintfin most F# code. If string interpolation is always compiled and ToString() methods work as above, then it will be easy for F# users to avoid AOT/linker incompatibilities.sprintf: https://github.com/dotnet/fsharp/issues/8621 . Note that we'd need to preserve some functionality for displaying records to deal with F# libraries compiled with earlier versions of F#: if they haveoverride t.ToString() = sprintf "%A" t, thensprintf "%A" tcan't useToString().It may be simplest to start by doing this for string interpolation as the first step, adding extra methods and preserving existing sprintf code, and afterwards migrate this work to sprintf.
TBD
Generics/inlines