kongware / scriptum Goto Github PK

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.

namely

• Array
• Map
• Set
• String

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

Based on hashed array mapped tries (HAMT).

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.

• 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.

namely...

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

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

specifically

• arrUnfold
• arrApo
• arrFutu

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.

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.

namely for

• Option
• Ordering
• These

• 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?

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

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.

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

There are no destructive variants since String is immutable.

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

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]);

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

The type should implement the Iterable protocol to be destructable.

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

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?

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

Name suggestions:

• mapConst
• apFst/apSnd

The Loop type was replaced by Cont.