Reviewing Monio's design/behavior (formerly: Typescript Support)

[Eyal-Shalev]

Do you have any plans to convert the code to typescript?
Or add .d.ts files?

[getify]

I do not have any plans to convert to TS. Internally, there are so many layers of value polymorphism to make it both lawful and ergonomic, it seems like it would a real challenge to type all those boundaries. Just curious: how would the implementation being in TS or not affect users of the library?

However, I would entertain .d.ts type bindings. Though I think by nature of this library relying heavily on iterators, it may be challenging to achieve much in the way of narrow typing. But it may be worth the effort. I don't plan to create them myself as I'm not a TS adopter, but I would happily consider a contribution of such. Interested?

[Eyal-Shalev]

I've forked the project and started working on the conversion (in my free time). But I'm currently labeling the conversion as a pet project, so don't assign it to me just yet 😅

[Eyal-Shalev]

@getify I'm working on the implementation, but I don't understand the purpose of the concat method, as it is implemented in the Just monad (for simplicity).

Why does just.of([1, 2]).concat([3]) equal [[1,2,3]]
Shouldn't it equal to Just([1,2,3])?

In other words:

1. Why does concat returns a non-monad?
2. Why does concat internally call concat on each item of the received array?

P.S.
Your implementation is not consistent. The concat method on Nothing will return a monad (Nothing), but on Just it returns a value.

[Eyal-Shalev]

@getify Also, what is the purpose of the _is function and the brand variable?

[getify]

Thanks for looking into this effort! Appreciate the help. :)

but I don't understand the purpose of the concat method

Summoning @DrBoolean for further comment if I'm unclear in any of my answers here.

The concat(..) method is implementing the so called "concatable" behavior, or in more formal terms, semigroup. Some of the monads in Monio support this, where it makes sense.

Why does just.of([1, 2]).concat([3]) equal [[1,2,3]]
Why does concat returns a non-monad?

As far as I can tell, that's a violation of the lawful usage, because Just.concat(..) expects a Just monad, and you provided it an array (which happens to have a map(..) call on it, but is not a conforming monad). Try this:

Just.of([1,2]).concat(Just.of([3])._inspect();  // Just([1,2,3])

Why does concat internally call concat on each item of the received array?

That's what concatable/semigroup does... it sorta delegates to an underlying value's concat(..) method (assuming that concat(..) method conforms to the expected behavior), which JS arrays and strings happen to have.

It only appears to be calling against the items of the array because you passed an array to concat(..) instead of another concatable monad (like Just). Otherwise, that .map(..) call you see would have been against the monad, not against an array of values.

I think another way of saying this is: unfortunately, while JS arrays (and strings) are concatable/semigroups, they're not conforming monads.

P.S. Your implementation is not consistent. The concat method on Nothing will return a monad (Nothing), but on Just it returns a value.

I indeed may have mistakes in Monio, I didn't claim it's perfect. However, in this case, I think you'll find it's consistent when the methods are used lawfully. That is, methods like chain(..), map(..), and concat(..), when called on any of Monio's monads, and when used properly/lawfully, should always return a monad of the same type as the method was called on.

Also, what is the purpose of the _is function and the brand variable?

All of the monads in Monio expose public is(..) and _inspect(..) methods for convenience and debugging purposes. It's likely rare that you'll interact with them in actual application code.

_is(..) (which is part of the public is(..) method's behavior) helps facilitate boolean "identity" checks on values, using the internal-only brand variable that's unforgeable. So Just.is(v) will only ever return true if v was created as a Just by Monio. The _is(..) function is internal only, and used as part of the cascading identity-check mechanics that need to happen for things like Maybe.is(v) delegating to Just.is(v), as well as for the _inspect() (which is public despite its _ prefix) serialization of values.

[Eyal-Shalev]

I got confused because of the test in just.test.js:

qunit.test("#concat", (assert) => {
	assert.deepEqual(
		just.of([1, 2]).concat([3]),
		[[1, 2, 3]],
		"should concat a just array to an array"
	);
});

[getify]

Sorry, that's a mistake... those tests came from another contributor and I didn't look closely enough.

[DrBoolean]

👋 Nailed it

[Eyal-Shalev]

@getify After a few months of hiatus, I returned to this conversion and had some more questions:

1. What is the purpose of the fold method?
   I see that it is defined on Either, AsyncEitehr & Maybe.
2. The ap method on IO takes a Monad and calls the map method on said monad with the function in the IO. That means that the ap method in IO will return a (maybe promise) monad. Why is that?
3. It seems like Nothing / Just monads are very similar to Left / Right monads. Is there any reason not to implement Nothing / Just on top of Left / Right?

[getify]

Thanks for picking back up the effort, welcome back! :)

Your questions all directly flow from type/category theory -- that is, none of that is particularly specific to Monio. I'm no expert on the topic, but I think I'm competent enough to give it a stab (again, with review from @DrBoolean).

Brace yourself, because this is a looooong explanation. :)

What is the purpose of the fold method? I see that it is defined on Either, AsyncEitehr & Maybe.

fold(..) is the so-called "foldable" behavior, which in these cases is taking a "sum type" (i.e., a monad holding one of two or more values) and "folding" that down to a single value. It's sort of like reduce(..) on an array, which is often called foldL(..) in FP speak.

As applied to Either and Maybe, it's essentially reducing (or, unwrapping) the duality choice inherent in those monads, such that you get the underlying value. It does so by "deciding" which of two functions to invoke (and provide the value). For Maybe, it invokes the first function in the case of Maybe:Nothing, and the second function in the case of Maybe:Just. For Either, it invokes the first function in the case of Either:Left and the second function in the case of Either:Right.

This function is somewhat special (in my perspective) in that the end result of calling it is extracting the underlying value, as opposed to requiring that it produce another Monad of the same kind as fold(..) was invoked on, the way chain(..), map(..), and others do.

The ap method on IO takes a Monad and calls the map method on said monad with the function in the IO... Why is that?

The ap(..) method is "applicative". It's a bit of a strange one, but you'll notice it's on all the monads, not just IO. The purpose of it is when your monad is holding a unary function (only expecting a single input argument), and you want to "apply" the value of another monad as the input to that function, and wrap that result back in the monad.

It's perhaps more easily illustrated in code, like this (using a curried sum(..) function):

const sum = x => y => x + y;

var threePlus = Just( sum(3) );  // Just( y => x + y ) ... IOW, a Just holding a unary function

var four = Just(4);  // a Just holding a single numeric value

var seven = threePlus.ap( four );  // Just(7)

// which is the same as (the not quite lawful but still illustrative):

var three = Just(3);
var seven = four.map( three.chain(sum) );  // Just(7)

That last line isn't "lawful" in that the three.chain(..) method is supposed to be provided a function that will return another Just monad, but here it's returning a curried function instead (holding the inner 3 value via closure), which is then passed as the unary mapper function to four.map(..), resulting in the Just(7) value.

Since that kind of transformation is possible but not lawful, the ap(..) method provides a lawful way to accomplish it instead.

To your original question, ap(..) might seem a natural fit for an IO monad, since IO monads always already hold functions. However, the use of that might be a fair bit unintuitive, since effectively, the function held in one IO is passed in as the argument to the other IO's held function. IOW, the function held in the IO that you're going to invoke ap(..) on has to be a higher-order function (HOF) that can receive another function as input.

Moreover, since the functions in IOs are for the laziness of IO, and thus aren't typically part of the operations/transformations themselves, to make ap(..) work, the function wrapping is going to be awkward from what I can tell.

var x = IO( () => v => v * 3 );  // IO holding a simple unary function
var y = IO( fn => fn(7) * 2 );  // IO as a HOF

var z = y.ap(x);  // IO essentially holding the lambda function () => 42
z.run();  // 42

Actually, TBH, I'm not even positive IO's implementation of ap(..) is correct, since I personally haven't found any use for it. That code works, but it seems weird to me (notice the difference in extra lambda wrapping on one but not the other). I just included ap(..) with IO for completeness sake, since it's already on the other monads.

That means that the ap method in IO will return a (maybe promise) monad.

Not quite. Again, the "lawful" use of ap(..) is that it must be called with a monad argument of the same kind as the monad you invoke ap(..) on -- so IO.ap(IO) or Just.ap(Just). You're not supposed to do Just.ap(Maybe) or some other mixture like that.

It seems like Nothing / Just monads are very similar to Left / Right monads

Similar, yes. Equivalent (interchangable)? No.

Is there any reason not to implement Nothing / Just on top of Left / Right?

I think that would be challenging/unwise for a few reasons, mostly implementation related to Monio, but I think in theory it would be possible to do so lawfully, though you couldn't do so the other way around (since Nothing is lossy -- holds no value -- and Left holds a distinct value).

One challenge is the internal type (aka "kind") checking I do with is(..), and the cascading that it does so that Maybe.is( Just(3 ) returns true as well as Maybe.is( Maybe.from(3) ). Those are technically different kinds of values, but I pave over the difference ergonomically, and thus I ensure the is(..) type-kind checking reflects that intention.

That's mostly done because typically Just and Nothing are not implemented as separate standalone monads, but rather as directly tied to Maybe. Monio did that because it makes illustrating monad concepts easy when you have, essentially, the identity monad with Just(..), and I didn't want a whole separate identity monad that completely duplicated everything I did for Just(..).

OTOH, Either:Left / Either:Right are deeply tied to Either, and don't exist in Monio standalone. So I can't really see how Just / Nothing could be cleanly implemented on top of them, without separating them from Either -- which there's no real reason to do, since they're not particularly useful as standalone monads.

Also, the Nothing monad is different from the Either:Left monad, from a performance perspective, because its short-circuiting is to always return the public Nothing interface (since we don't need to hold any instance value in closure). By contrast, the short-circuiting that Either:Left does is instance-sensitive (which is slightly less performant than what Nothing does).

---

(deep breath) Phew, hope that was helpful. Hope I didn't make things worse by confusing or overwhelming the situation.

Bottom line: just about everything you'll encounter in Monio's monads is there for a reason -- generally for some aspect of type or category theory. Only some of that space is personally in my comfort zone, but Monio is designed to pull together a lot of those things into a set of all-powerful monadic goodness. ;-)

[getify]

I should also mention that while I endeavor to maintain "lawful" uses and avoid "unlawful but possible" uses, internally there are definitely cases where I intentionally violate the laws because it's more performant or more convenient with my implementation. For example, the _inspect() function basically needs to violate the law by calling chain(v => v) to "extract" a value to display in the serialized output.

My point is, while the TS typings can be aware of these lawful vs unlawful usages, we shouldn't design them such that they restrict such usages.

[Eyal-Shalev]

That was helpful. I had a hunch on most of the stuff you explained, but wanted to make sure instead of making assumptions.

Putting aside my TS implementation I think you can simplify the inspect function like so:

function inspect(val?: unknown): string {
  if (typeof val === "string") return `"${val}"`;
  if (typeof val == "undefined") return String(val);
  if (typeof val === "function") return val.name || "anonymous function";
  if (val instanceof Either) {
    return val.fold(
      (v) => "Left(${inspect(v)})",
      (v) => `Just(${inspect(v)})`,
    );
  }
  if (val instanceof Maybe) {
    return val.fold(
      () => "Nothing",
      (v) => `Just(${inspect(v)})`,
    );
  }
  if (Array.isArray(val)) return `[${val.map(inspect).join(", ")}]`;
  if (val instanceof Object && val.constructor === Object) {
    return JSON.stringify(val);
  }
  return String(val);
}

[Eyal-Shalev]

@getify Expanding on your previous answer, is it true that the Maybe methods (map,bind,ap,...) will always return a Maybe type. And the same goes for all the other categories?
If yes, then it simplifies the typings a great deal.

[getify]

I think you can simplify the inspect function like so:

I'm not quite sure what you're suggesting. Is this a single central inspect(..) utility to be shared by all the monad kinds, instead of each one having its own like currently? Where does the val input argument come from? Are you suggesting that users of the lib would call a static Monio.inspect( myMonad )?

Or are you suggesting that each monad kind would call this central util from their own respective _inspect(..) methods?

Some things to be aware of in the current implementation of the various inspect functions:

1. I already have a "sharing" of this behavior across monads by, for example, Either._inspect(..) casting its value using Just._inspect(..). That's not super elegant, in doing the regex match and such, but there's a predictable and limited set of inputs/outputs to be concerned with.

2. Just(Just(Just(42)))._inspect() needs to be able to show Just(Just(Just(42))) as its output, meaning that there's a need to have "recursion" of the serializing of output. Indeed, nesting of monads is common, and can be mixed: Either:Right(Maybe:Just(42)). You might want to look at the typeof v._inspect == "function" checks, which are duck-typed handling for that recursive inspecting.

3. These monads aren't constructed with new constructors, but rather as plain function calls, so I don't think the instanceof checks will work as a strategy.

4. Either knows internally what kind of value it holds (Left vs Right), and so does Maybe (Just or Nothing). But this utility you've suggested "externalizes" (duplicates) that determination by relying on their respective public fold(..) methods. While that's a lawful operation, I think it's less elegant (and a tiny bit less performant).

5. Not all of the monad kinds can hold all the possible value types... for example, IO never holds anything but a function or another monad. Centralizing the inspection rather than having it be per-monad-kind seems like it could be slightly misleading in that this detail would no longer be as obvious from looking at the inspection logic.

   I suspect you may be intending information like that to be communicated via Types. However, in general, I don't want readers of the code to have to rely on TypeScript for this kind of communication. Monio is not, and won't be, a natively TypeScript project. The TS typings are welcome as additional information that TS users can benefit from. But non-TS devs should be able to open up the JS of Monio's source code and get the information they need.

Those concerns aside, are there other reasons you think inspect should be centralized/shared rather than per-kind as it currently is? In your opinion, how does that "simplifiy" compared to the current approach?

[Eyal-Shalev]

I'm suggesting a single inspect(...) function in the testing utility library.