Roadmap V2.0

[gusty]

I think for V2.0 we can start discussing features here, before moving to a formal project.

What comes to my mind at the moment is:

1. Remove subsumption from Applicatives: Right now seq "eats" all custom types implementing seq

2. Same for Traversable, same situation: although this might not require a breaking change (todo find out)

3. Implement IEnumerable for Vectors, now that (1) has to be done.

4. New ListT monad transformer, possibly new SeqT as well, coded using a similar technique as the one used for Free Monads.

5. Review computation expressions: autosense will be removed but we have to do something to make it easy for users to understand why a strict monad can't be used with the non-strict CE. Maybe make compilation fail when calling a TryWith?

6. Add ValueTuple, ValueTask and other latest addition to the framework. We can require a higher framework version

7. Consider suggestions by @dsyme regarding using the return type for type inference.

Am I missing something?

EDIT

8. Better task support (maybe an intermediate type like Step with conversions to/from Task and its use in Bind an other methods for task).

9. Consistent type parameters order, this would need to swap type parameters in Validation<'err,'t> to Validation<'t,'err>.

10. Revisit sequential vs non-sequential applicatives for types like Result (right now map is sequential) and for Matrix (not sure if the current applicative derives from Monad).

11. Implement a mechanism for Delay/Run strict CE like task, so errors before the first bind are included into the task workflow.

12. Prioritize operators instead of static members for SRTP defaults, for instance the default for map should be <!> so user types can be used without F#+

[adz]

I would like to organise namespace so that we: 1) can more easily generate docs per functional area (thinking of how operations is separated nicely into sections by banner comment, but API docs are resorted alphabetically and all at same level), 2) reduce possible instances by opening only what you're using.

The later requires to split the Invokables so that each implentation sits with the 'openable' type. Such as Arrow, or NonEmptyList, etc.

This should help considerably with compiler error messages as there is reduced implementations. I also wonder if it would help speed up compiler time?

I'm not exactly sure on how to arrange for optimal dev work flow, but could be that there is separation between common and exotic abstractions, or maybe that there is 'open common' and otherwise opt in for each type...

WDYT?

[gusty]

No doubt namespaces should be re-organized.

I personally don't see a big benefit on splitting Invokables in different namespaces, but at the same time I don't see any harm on doing that, since they are rarely used in client code directly.

Separation between common and exotic abstraction could be interesting but hard to draw the line.

One thing I definitely would like to change is a few extensions (like List.traverse) which lives in .Data right now. I think they don't belong there, since List is not in .Data.

So I would say, if/when you have a concrete proposal in mind please drop the details and we can analyze it, because this is the right time to do it ;)

[NinoFloris]

#245

I would vote for defaulting to left for success right for error

[cmeeren]

You could consider removing functions that are part of FSharp.Core, e.g. List.singleton.

Also personally I'd like String.trimWhiteSpaces to be String.trim, and the current String.trim to be String.trimChars or something else, but that seems like a fairly indulgent breaking change, so I'm not expecting anything there 😅 (Alternatively, trimWhiteSpaces should ideally have lower-case s for consistency with String.IsNullOrWhitespace, but again, that's a fairly indulgent change.)

[gusty]

You could consider removing functions that are part of FSharp.Core, e.g. List.singleton.

Good point, based on the min version of F# core we could remove some now-redundant functions.

Regarding the String.trim suggestions, we can consider some breaking changes for V2, at the very least your alternative suggestion (consistency) should be implemented.

[cmeeren]

Regarding the String.trim suggestions, we can consider some breaking changes for V2, at the very least your alternative suggestion (consistency) should be be implemented.

Thanks! (For the record, my primary suggestion regarding String.trim is based on my experience of using String.Trim() (empty, trimming whitespace) a lot more often than specifying what I want to trim. That's why I suggest that to be the behaviour of the "simple" String.trim.)

[gusty]

Yes, definitely. I think more than 90% of the cases are white-spaces.

[wallymathieu]

Perhaps there should be a doc site for v1 so that it's possible to browse the docs for v1 and v2 once v2 is available?

[wallymathieu]

So perhaps a PR @cmeeren with the change?

[cmeeren]

Regarding seq and subsumption: Seems it's also happening with tryFind (foldable) and empty (functor). When used for Map<_,_>, it's subsumed as seq<KeyValuePair<_,_>> in both cases.

[gusty]

Let's discuss it in #322

[cmeeren]

Again regarding seq and subsumption: Does that mean that currently, length is an O(N) operation also for arrays?

[gusty]

Yes, if there is subsumption, but AFAIK in that case, the overload which is specific for arrays have priority, so it shouldn't. If it does it is a bug.
These kind of things, have to admit, are hard to test.
I do normally test it before committing with some prints to see which overloads get actually called.