[RFC FS-1125 Discussion] print and println functions

[bisen2]

Discussion thread for #674, or permalink RFC FS-1125.

[abelbraaksma]

@bisen2 or @albert-du, can you update the RFC to link to the PR? It still says "FILL-ME-IN" in that spot, clicking the link gives a 404.

Implementaton is here: dotnet/fsharp#13597.

[bisen2]

Yup, just submitted a PR with the implementation link. Thanks for catching that!
#701

[jwosty]

Just noting that a bunch of very important discussion has already happened on the original PR thread: dotnet/fsharp#13597

[abelbraaksma]

I'd like to take this RFC further, that is, make the changes discussed in the old PR and create a new PR.

As discussed in the PR mentioned in the previous comments, this comment by @dsyme suggests to make the new print and printn functions generic.

Since the default behavior of interpolated strings is to use the %O behavior (that is. follow the ToString() functionality as that's the same as for C#), I propose the following changes based on these long discussion threads:

• print: 'a -> unit, behaves like string >> printf "%s"
• printn: 'a -> unit, behaves like string >> printfn "%s"
• Both will use the invariant culture for IFormattable types, which pertains to the built-in numeric types specifically. This prevents getting different output on different locales.
• null and None etc should not lead to exceptions. I'm ok with printing null for null-instances, but I can also see the benefit of printing None (and whatever else is there for known DU types that are null), if the type is known. However, this cannot be enforced if the type info is gone.

The behavior above is the same as how string is currently implemented (invariant culture). In the RFC, under "unresolved questions", several other approaches have been suggested, but none of these have prior history of being applied in existing F# functions. To get in line with existing functions and interpolated strings, I feel this is the best compromise.

Another way to put this is that they behave essentially like System.Console.Write[Line], except for the culture-[un]aware thing.

Behind the scenes, as we've done before the FSharp.Core, we can make specific compiler-paths to prevent unnecessary boxing, but that's an implementation detail.

[abelbraaksma]

In case anybody is wondering what all that culture awareness is about, it is that in F#, generally we try to get the same output of a function, if the input is the same, so not this (note the dot changing in a comma):

> Console.WriteLine 1.23e20;;
1.23E+20
val it: unit = ()

> System.Threading.Thread.CurrentThread.CurrentCulture <- System.Globalization.CultureInfo.GetCultureInfo("nl-NL");;
val it: unit = ()

> Console.WriteLine 1.23e20;;
1,23E+20
val it: unit = ()

But:

> string 1.23e20;;
val it: string = "1.23E+20"

> System.Threading.Thread.CurrentThread.CurrentCulture <- System.Globalization.CultureInfo.GetCultureInfo("nl-NL");;
val it: unit = ()

> string 1.23e20;;
val it: string = "1.23E+20"

I think it is very reasonable to expect the original design, i.e. print: string -> unit is achieved by applying the string function on the generic function of the same.

Still this leaves the oddity of string where it prints "" (i.e, the empty string) when the input is null or None. As suggested above, I think changing that to be "null" and "None" respectively makes sense.

[charlesroddie]

Thanks for taking this forward @abelbraaksma . This issue seemed emblematic of how F# finds it hard to make progress owing to bikeshedding, and it takes a lot of energy to push through these difficulties.

Still this leaves the oddity of string where it prints "" (i.e, the empty string) when the input is null or None. As suggested above, I think changing that to be "null" and "None" respectively makes sense.

That would be work around string and I would maintain the let printn = string >> Console.WriteLine definition and just let printn pick up any changes in string. Almost all the time printn is going to be given strings anyway.

[abelbraaksma]

@charlesroddie that's a good point and favors orthogonality towards the present design (even though I don't quite like the present design, but that's besides the point😆).

I hope others can agree with this approach. The less deviations from established practice, the better. I'll update the RFC so we can take this to the next step.

[dsyme]

This all seems reasonable. Ping me when the RFC update is ready