briancavalier / creed Goto Github PK

Hi,
I'd love to implement promise cancellation in Creed, using the approach detailed in tc39/proposal-cancelable-promises#19. I want to do this as a proof of concept and just for fun, and chose your library for its readable source and large test-suite.

Would you like to see this as well? If no, I'll just maintain my own fork. If yes, how would you like the workflow to look like (feature-branches, how many pull requests, etc)?

Do you have any implementation tips? Any performance secrets? How would I best ask questions and get feedback from you?

Let's discuss technical details later.

Looking more closely at the async/await proposal it seems that every yield should at least wait one tick. Currently, if it yields a value or settled promise then the next step is called synchronously (_runAction instead of _when). This could even lead to a stack overflow.
Can anyone confirm this?

never() claims to "consume virtually no resources". However, this is no more true if never is used in any combinator, especially merge/all/settle. Should we detect nevers, and futures that eventually resolve to a never there and set the result accordingly?

If we want to do that, any ideas about the how? Should Action implement an onNever handler that is called by Never::_runAction?

The FL Applicative spec includes the of method but it does not seem to be available on creed:

> creed.of(1)
TypeError: creed.of is not a function

Any reason not to have it?

It could be mentioned that of is actually more basic than Applicative and is part of the Pointed Functor Spec, see also https://github.com/MostlyAdequate/mostly-adequate-guide-it/blob/master/ch9.md#pointy-functor-factory.

It seems that creed.fulfill is doing what of is meant to do,
which is somewhat non-standard name and is longer to write.
Also, when it is not called of, the question arises whether it conforms
to the Pointed Functor spec, which I understand it does.

If creed.fulfill is indeed intended to satisfy the Pointed Functor spec (together with map),
maybe also alias it as of and add tests for the spec?

Version 10.3.0 of nyc just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As nyc is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Not sure to what extent this is desired.
Some problems with the ES6-like interface are:

• methods (including static ones) don't return subclass instances
• static methods don't use this to resolve their inputs (and don't require this to be a promise constructor at all)

We might want to put up a warning for this. Not sure how complicated or performance-deteriorating it would be if we wanted to support this.

Version 3.4.0 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

From the Bifunctor, it seems a Promise has two states:

1. Error value
2. Successful value

I would like to "run" a Promise and act on each state:

/* forall x. */ Promise.of(x).fold(a => false, b => true) == true
/* forall x. */ reject(x).fold(a => true, b => false) == true
never.fold(a => true, b => true) == undefined

Is there any good reason why never() returns distinct objects?
Same could probably said for the internal Race handler.

See Conal Elliott's paper on denotational design and type class morphisms, or any of his recent talks based on it. One of the main points in the paper is that defining type class instances "can sometimes be derived mechanically from desired type class morphisms". Applying that to define, say, Promise's functor instance might go something like (using haskell-like syntax here, where fmap is the functor operation):

fmap f (Promise a) = Promise (fmap f a)

IOW, an fmapped future value is the future fmapped value. Or as it's stated in the paper: "The instance’s meaning follows the meaning’s instance"

Functor Example

That opens up some interesting possibilities .. for example:

fmap f (Promise [a]) = Promise (fmap f [a])

If we have a promise for an array of numbers and want add 1 to each number in the array, in creed 1.0, we have to map twice:

import { fulfill } from 'creed';
const ints = fulfill([1,2,3]);
const intsPlusOne = ints.map(a => a.map(x => x+1));

However, using the fmap definition above:

import { fulfill } from 'creed';
const ints = fulfill([1,2,3]);
const intsPlusOne = ints.map(x => x+1);

The exact same thing would work with a promise for a single number:

import { fulfill } from 'creed';
const one = fulfill(1);
const two = one.map(x => x+1);

Or for a promise for a tree of numbers, or a promise for a promise of a number, and so on. Applicative would likely be similar to Functor.

Questions

What about type classes for which there are two (or more) interesting behaviors? For example, creed's Promise has a monoid instance, with never as the identity element and concat returning the earlier of the two promises to settle. IOW, it doesn't rely on the monoid instance of the value type, but rather only on the time of the two promises.

That monoid definition is useful because it represents racing.

A monoid instance defined using the ideas in the paper would use the identity element of the value type (How would this even work??), and concat would apply the concat operation of the value type. IOW, concatenating two future arrays would produce a future concatenated array.

concat (Promise [a]) (Promise [a]) = Promise (concat [a] [a])

That's probably also useful, and I have no idea how to deal with wanting two monoid instances for Promise.

I also have no idea yet how to define a monad instance for Promise using this approach, if it's useful, or even possible. As far as I can tell, the paper doesn't much (if any) guidance on applying the technique for monad instances.

From #178

• Add simple "Introduction" and/or "Why would I use creed" sections
• Add another 1-2 simple examples to the README.
• Add links to helpful information about foundational functional programming concepts, such as the Mostly Adequate Guide.
• More clearly encourage exploration via REPL.
• Emphasize map, et al.
• Group A+ / ES interop functions (i.e. then, resolve) together and explain more clearly that's their purpose. (#180)

Hello,

As someone who is used to having Bluebird around, I'm wondering what creed brings over using BB?

The example converted to use Bluebird is pretty similar.

Perhaps I misunderstood and purpose of creed is only to augment native Promises with less powerful API than Bluebird's? I'd imagine it's less heavy at least, which could be a big deal in the browser side.

Currently error reporting does keep track of every Rejected instance.
ES7 promises (and afaik basically any other promise implementations) do however keep track of the promises (futures) that are rejected without handlers.
See tc39/ecma262#76 for more links.

The problem with Creed's current approach is that it does not detect branching. Consider the example

const p = reject(…);
const q = p.then(…);
const r = p.catch(…);

While Creed does report p to be handled, it should actually have reported q as unhandled in the first place.

This is not an easy problem for sure with the nearing approach, as with x = reject(…), y = new Future, z = new Future we would have to distinguish z.become(y); y.become(x) from z.become(x); y.become(x) (in any order).

Any thoughts?

I am not sure to what extent creed does use the standardised rejection tracking events, I kinda have lost track of proposals/implementations/specifications.
Btw, node has some nice tests here.
Also this issue will probably solve the matter of silencer being an Action, I'd expect silencing to see some major change.

In v1.1.0 I'm seeing this error, but I don't see this error in v1.0.4 or v1.0.2. The specific area I'm seeing this is when using a coroutine, so creed.coroutine(generator)(val).then(x => x) is enough to trigger it for me.

I have trouble taking native/A+ promises seriously, mostly due to its impossible-to-analyze behavior around automagically unwrapping thenables (I believe this is commonly known as "failure to be a monad").

As I consider long-term solutions, alternatives like fantasy-land and creed::async become quite attractive.
But, frustratingly, my several attempts to dive into either one of them have failed, due to my failure to being able to follow the documentation of either, to any significant depth. I also have the feeling that, even if I succeed in vaulting the very high bar to entry, I will leave my normal friends and coworkers behind, since they will be unable to ever read my code from then on.

• The fantasy-land doc dives straight into algebraic "abstract nonsense" (I don't neceessarily use the term dismissively, but it does make that doc impenetrable and thus not useful to me for learning).
• fluture-js/Fluture might be a decent alternative; I'll explore that in parallel.

This creed::async certainly sounds great, from its introductory blurb (great marketing!), so I'd really like to try it, so that's what brings me here.

As I continue reading the README, I encounter:

• The async-problem example. Ok, I guess it solves this puzzle neatly. Can't really make head nor tail of the details at this point, and it's doesn't seem that relevant to my wish to learn the library.
• The "Try it" section. Ok, I follow this section: it looks just like the Promises I know, so far, but there's not a lot in this section.
• ... scrolling down, hoping to see some more introductory examples of how to use various features, and I reach:
• API : Run async tasks: coroutine :: Generator -> (...* --> Promise e a) : Create an async coroutine from a promise-yielding generator. [... example that doesn't seem relevant to me yet ...] WHOA! I suddenly feel very far out of my depth...
• fromNode :: NodeApi e a --> (...* --> Promise e a) [... more stuff that doesn't seem relevant to me at all ...]
• scrolling down more, I see lots more API reference and code examples, but they all seem to assume I already know what's going on. I'm lacking any context or feeling like I know how to get my foot in the door.

What I'm trying to say is... is there any chance of getting some introductory material in there,
to bridge the large gap between the shallow "Try It" section and the deep "API" section, for programmers like me who want to learn this library?

In particular, I'd be interested in some dedicated material explaining, in both plain language and code:

• A list of each the async constructs/styles that creed::async provides, with high-level description of pros and cons of each compared to each other.
• Compare/contrast these constructs/styles with native/A+ promises and native async/await, point out the differences / added-value that are the reason a reasonable person would want to use this library.
• Maybe also compare/contrast with other alternative libraries like Fluture? I actually don't know how you view creed::async in relation to other alternatives at this point, and it would be good to know.
• Then ease into more depth, with some well-motivated examples of each construct/style without assumption of prior knowledge, with explanations and code comments less terse than the API examples.
• My impression, from reading your and others' comments in other discussion threads that lead here, is that a crucial motivating point about this library is something like "creed::async::Promise is A+ compliant since it has a compliant then, but if you want something with analyzable semantics, don't use that, use its 'chain' instead". But I don't see that stated or even alluded to anywhere in the creed::async doc! (And, truthfully, I'm not even sure I have it straight.) I feel like there may be a lot of other important context and motivation like this that I'm missing, too. A dedicated "Motivation" section might go a long way.

A final note-- personally, I know Promises/A+ already, so I don't mind if the doc assumes that knowledge, for my own use in learning the library. However, if this library is intended to be a serious option for the world for doing async, it would be great if there were also an introduction from first principles for javascript programmers, so that people can skip A+ and get right to the sane stuff. That would be a more ambitious undertaking, though.

Version 0.12.6 of jsinspect just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As jsinspect is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.2.0 of eslint-plugin-standard just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-plugin-standard is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

There's been some recent updates to fantasyland/fantasy-land#137, and it looks like the bifunctor spec is mostly stable.

The implementation seems like it would be quite simple.

Other than the lack of typing information, I find this to be my favorite promises (non-tasks/futures) library.

Would you be interested in trying to get type information added? Do you foresee any problems with typing certain things?

The merge callback f is called with the this of the merge(…) call as the receiver. This doesn't seem exactly useful to me.
Are there any use cases? Does any code use merge.call(o, f, …) instead of merge(f.bind(o), …)?
Could we just drop this "feature"?