fslang-suggestions VS FSharpPlus

Trying to extend this https://github.com/fsharp/fslang-suggestions/issues/1089 to have two generics:

Basically, what I've made in Spiral. There is even a F# issue to improve the syntax.

Not currently supported but it's an open language suggestion that's likely to end up in F#. https://github.com/fsharp/fslang-suggestions/issues/506

Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issu...

I found this post (https://github.com/fsharp/fslang-suggestions/issues/975) which is about the same thing, but I'm confused as to what the final resolution was. There was mention of a taskSeq, but I can't find much info on that.

An issue in FSharp suggestions

F# doesn’t currently seem to support source generators.

"Blessed" literals: only FSharp.List and System.Array have a built-in collection syntax in the language ([ ] and [| |]). Only FSharp.List has a special pattern matching constructor (::). The language itself shouldn't favor a particular type over another: it should be possible, at the library level, to write the same code but using different collection types (related discussion here).

I mostly write F# so I can only speak for F#, but if you want you can create a module which extends Seq to add the OCaml names. I suspect the same is possible in OCaml. The authors are not trying to impede compatibility, but compatibility is not a goal. If you value compatibility, or adhering to ML norms, and you use F#, I recommend you (kindly) advocate for it in relevant issues on the F# language discussion repo. https://github.com/fsharp/fslang-suggestions/issues

This should all be prefaced by saying that F# tends to avoid such category theory generalizations (unless you're using a library such as F#+ ). So, while I would encourage your continued understanding of the theory (it can be fun!), it's not as practical for writing good F# code as it would be in, say, Haskell. There are no type classes in Haskell, nor are there plans to add them.

There maybe be a way to make it not have overhead. But there is precedent that this is not the case with Statically Resolved Type Parameters, and existing mechanism in F# that already lets you encode Haskell-style typeclasses and is the backbone of FSharpPlus, a typelevel (and more) library for F#. Solving constraints like this at compile-time (as opposed to having a runtime natively understand them) absolutely, positively leads to explosive compile times if you're not careful. I worked on the F# compiler for 5 years and I can attest to numerous reports related to accidental compile-time explosions just because SRTPs or inline was used a particular way.

F# devs tend to use SRTP (Statically resolved type parameters) see F#+ https://github.com/fsprojects/FSharpPlus .

F#+ (FSharpPlus) 1.2 released with the following changes: