lack of fantasy-land compatibility

[krzysztofpniak]

Readme says that it is compatible with fantasy-land while it is not. Simple proof:

import { map } from "ramda";
import { runEffects, periodic, tap } from "@most/core";
import { newDefaultScheduler } from "@most/scheduler";

const test = tap(x => console.log(x), map(() => "1", periodic(1000)));

runEffects(test, newDefaultScheduler());

https://codesandbox.io/s/stupefied-kapitsa-s48mp

[TylorS]

Hey @krzysztofpniak thanks for reaching out! I don't currently see fantasy-land mentioned in this repository's readme. Correct me if I'm wrong, but do you mean the README for cujojs/most?

As for @most/core I don't think it's intended for us to add support for fantasy-land directly, but possibly through another library built atop of @most/core. cc @mostjs/maintainers to make sure I'm not off-base

[davidchase]

hi @krzysztofpniak, thanks for the comment, check out #239 where the discussion for adding fantasy was originally requested. So its probably because you thought of https://github.com/cujojs/most#interoperability which is the original mostjs.

let us know your thoughts

[krzysztofpniak]

Hi, you are right, thanks for clarification. The Readme from cujojs/most caused my assumption that @most/core also implements it. Anyways, I think @most/core should implement fantasy-land because at the moment it is still more popular than static land. Currently both ramda and sanctuary have only fantasy-land support. This holds me from using @most/core, because I see it as an addition to the basic operations library that ramda or sanctuary provides. Don't get me wrong, I still think static land is simpler and better approach but in my opinion it is too soon to use it without fantasy-land backup.

[TylorS]

@krzysztofpniak, in the mean time something like this might work for you - https://codesandbox.io/s/practical-ganguly-8jc13

[krzysztofpniak]

@TylorS Thanks

[semmel]

Coming from BaconJS (which assembles everything in a huge Observable class), I appreciate mostjs's fp-style API of free-standing, auto-curried, stream-last-argument functions. It makes my stream (mostjs) and data-processing (ramda) code look very similar and pretty. 😃

In my code I'd like @krzysztofpniak 's example of using ramda's map with mostjs' Stream to work too. Because, who needs map, chain, ap, etc. imported in n versions anyway?

However I think creating a FantasyLand Stream type might be the wrong way. As already stated by @briancavalier in #239:

It'd currently be much simpler for @most/core to implement static-land (it mostly already does, but of is named now) than fantasy-land 3.x, since @most/core streams don't share a common prototype (they only share an interface).

Another way would be to patch ramda's FL functions to dispatch to mostjs, as I've attempted for Promises. With that you can

import {chain, map, lift} from 'ramda';
chain(x => Promise.resolve(x + 3), Promise.resolve(2)) // ~> Promise 5
map(x => x + 3)(Promise.resolve(2)) // ~> Promise 5

const concat = lift((a, b) => a + b);
concat(Promise.resolve("A"), Promise.resolve("B")) // ~> Promise "AB"

Should be a no-brainer to do the same for mostjs and even straight-forward to do it for baconjs.

It should be the right place for the adapter too, since ramda switches implementations depending on the data type. Also such a general adapter layer was already mentioned in a ramda discussion.

Since that did not get much traction, sadly I have to tend my own fork of ramda. 😢

[Frikki]

Closing in favor of #239

[semmel]

What about the FL laws?

@krzysztofpniak, in the mean time something like this might work for you - https://codesandbox.io/s/practical-ganguly-8jc13

@TylorS Its a nice code snippet.
Maybe add a warning that it does not satisfy the FL condition for deriving ap from chain ?

I mean

ap(mf, ma) ≡ chain(f => map(f, ma), mf)

is clearly not the case for @most/core, because ap ≅ combine(f => a => f(a)).

I don't know what implication this has, if one just employs a FL compatible utility library like Ramda.
Ramda not only dispatches to FL methods, but also derives a few functions such as lift from ap and map, and pluck from map. Those should work fine regardless or not?