This way we can choose at runtime if an async function is evaluated sequential or in parallel.

Consider left-biased (error propagating) and right-biased (error fixing) instances for Either. This would require distinct types. What would be meaningful names for their type and value constructors?

Say there is a Task foo and I want to reuse foo's result several times. The problem with Task is that it is based on continuations (CPS) and thus lazily evaluated. So every time I call foo.runTask(res, rej) the computation is reevaluated instead of simply returning the result.

There seems no way to allow for sharing foo's result, even not with an impure solution. The only way I can think of is to be in the right scope:

const foo = fileRead("utf8") ("./foo.txt");

foo.runTask(s => {
  // in this scope we can reuse s as often we want
}, id);

This is not satisfying, of course. Maybe someone will come up with a better solution.

Find names for $>, <$, *>, <* and implement them.

Name suggestions:

• mapConst
• apFst/apSnd

namely

• Array
• Map
• Set
• String

By additionally passing the current index we can prematurely break out of a fold of an indexed compisite type::

const strFold = alg => zero => s => {
  let acc = zero;

  for (let i = 0; i < s.length; i++)
    [acc, i] = alg(acc) (s, i);

  return acc;
};

or we can skip certain iterations. I think this approach is superior to indicate the premature break with a special type, as I've done so far.

• objDiffl/objDiffr
• objIntersect
• objDefaults
• objInvert
• objOmitProps
• objPairs
• objPickProps

• Choice
• Strong
• Closed
• Star/Costar
• Forget

specifically

• arrUnfold
• arrApo
• arrFutu

namely...

• arrDiff/arrDiffBy
• arrDiffl/arrDiffr
• arrIntersect/arrIntersectBy
• arrUnion/arrUnionBy
• arrMapAccum
• arrGroupBy
• arrFindBy/arrFindIndexBy
• arrCountBy
• arrFindBy
• arrFindIndex
• arrFindIndexBy
• arrFindLastBy
• arrFindLastIndex
• arrFindLastIndexBy
• arrFindNthBy
• arrFindNthIndex
• arrFindNthIndexBy

namely for

• Option
• Ordering
• These

I think multimethods are a more natural approach to allow function overloading for dynamically typed languages than typeclasses. Provided I've considered all aspects I will probably replace typeclasses.

multimethods must have the following properties:

• they must be closed
• they must support dynamic dispatch for one or more arguments
• methods must be individually addable one at a time
• dispatch values must be of any type (not just Strings)
• dispatch value/method tuples must be of type (a, a -> b)/(a, b, a -> b -> c)
• the dispatcher should always be uncurried for performance reasons
• multimethods should accept either curried/uncurried methods

As opposed to typeclasses multimethods cannot express return type polymorphism, because without a value you cannot introspect a type.

• isPrefixOf
• isInfixOf
• isSuffixOf
• strUnconsNth
• strUnconsNthOr
• strConsNth

There are no destructive variants since String is immutable.

lensGet et al. shouldn't leak the information whether they depend on Cont or Id internally. Additionally, these combinators need to be parameterized over the Lens type (objLens, arrLens etc.), so that they are ad-hoc polymorphic in this regard.

• dropper
• dropperNth
• dropperWhile
• taker
• takerNth
• takerWhile

I mean functions like fileCopy or fileUnlink. For the time being they just return None (from Option), They should return someting IO related, though. scriptum uses Task for asynchronous and Effect for synchronous IO. So just Task((res, rej) => res(None)) for the former and Effect(() => None) for the latter? Would that be an improvement?

The Loop type was replaced by Cont.

We can replace four functions with just two. This assumes that any call of push et al. is transformed in the following totally mechanic way:

arrPush([1,2,3]) (4);
becomes
arrAppend([1,2,3]) ([4]);

The type should implement the Iterable protocol to be destructable.

Based on hashed array mapped tries (HAMT).

In Haskell every monad transformer gets its own type and there is a lot of wrapping/unwrapping taking place.

This results in reducers for arrFoldWhile of the following form:

acc => x => k => k(...)

Pros:

• easíer composition
• simplified loop fusion

Cons:

• higher mental burden

strMatchAll should return [Matched<String>] instead of [Matched<Option<<String>>].

Since local mutations are not harmful but reasonable in a language without native persistent data types and structural sharing this seems to be a useful endeavor.

• how to lift a Semigroup into an Option forming a Monoid?
• how to create a Monoid under Applicative?
• how to create a Monoid under Alternative?

Is a Prism/Getter/Setter so Lens-like that it simply uses the Lens constructor internally? That would simplify composition with Lenses immensely.