fantasy-land VS promises-spec

(This was one of the purposes of the Fantasy Land specification, to define common interfaces for generalized operations that could benefit from language-syntax-support.)

2. https://github.com/fantasyland/fantasy-land (A bit heavy on jargon)

Note there is a python version of Ramda available on pypi and there’s a lot of FP tidbits inside JAX:

3. https://pypi.org/project/ramda/ (Worth making your own version if you want to learn, though)

4. For nested data, JAX tree_util is epic: https://jax.readthedocs.io/en/latest/jax.tree_util.html and also their curry implementation is funny: https://github.com/google/jax/blob/4ac2bdc2b1d71ec0010412a32...

Anyway don’t put FP on a pedestal, main thing is to focus on the core principles of avoiding external mutation and making helper functions. Doesn’t always work because some languages like Rust don’t have legit support for currying (afaik in 2023 August), but in those cases you can hack it with builder methods to an extent.

Finally, if you want to understand the middle of the midwit meme, check out this wiki article and connect the free monoid to the Kleene star (0 or more copies of your pattern) and Kleene plus (1 or more copies of your pattern). Those are also in regex so it can help you remember the regex symbols. https://en.wikipedia.org/wiki/Free_monoid?wprov=sfti1

The simplest example might be {0}^* in which case

0: “” // because we use *

It was never really my jam, but I used to follow the up-and-coming fantasy-land specs with great interest. It just seemed like a sharp dedicated community of folks trying to figure out better fp & algebraic stuff. I'm not sure who trailed off - in general I feel like there's much less connection in tech world, that the tech twitter and every other ultra-active tech channel has somewhat decayed. https://github.com/fantasyland/fantasy-land

Thanks for the links. I know I've seen @gcanti's name a thousand times already, but it's already quite murky to me what it was attached to. Something in this sphere.

Look at the implementations of Fantasy Land. List-in-JS might do the trick.

There are respective fantasy land and static land specs, with the law conformance checks.

While building a purely functional data structure library for personal fun and professional use, and while using other libraries, I found that the "Fantasy Land Specification" was mentioned from time to time. They use this hierarchy. Although I did read some about category theory (tried and failed to fully understand all the concepts), some of the terms used in the specification are unknown to me (like Chain, Apply). My question:

No: neither of those examples are "properties of futures and of lists as such." "Async/Await" in particular is a special case of monadic behavior of a concurrency monad. This specifically (infamously) came up in the evolution of the Prommise spec in ECMAScript, which in turn led to the development of the Fantasy Land Spec and various implementations of it.

If you're programming in TypeScript you can checkout the fantasy land spec. It provides a spec for all the algebraic structures used in the JS world. You can learn what they are. You'll want to find alternative resources to learn what they are how they work. Fantasy land is just a spec not a guide.

A Promise represents the eventual completion (or failure) of an asynchronous operation and its resulting value. Technically, it’s an object conforming to the Promises/A+ specification. In Node.js, the built-in Promise constructor provides this functionality. Crucially, Promises are thenable – they have a then method that allows chaining asynchronous operations.

With careful attention given to potential pitfalls, performance disparities, and advanced debugging techniques, this guide should serve as a valuable resource for senior developers looking to master not just the Promise API, but the subtleties that come with custom implementations. For further reading, consult resources like the MDN Web Docs on Promises and the Promises/A+ Specification.

Not so much a representation of a side effect (after all List is a Monad as is addition on integers no side effects anywhere in sight) as the reification of a particular category.

JavaScript's `Promise` is particularly interesting because it is a Monad over "all JS values which do not contain a method called `then` in their prototype chain" or as Dominic put it 12 years ago:

> Indeed, I like the way @medikoo phrases it. There's, practically speaking, nothing wrong with being a monad on the category of non-thenables.

https://github.com/promises-aplus/promises-spec/issues/101#i...

The core Promises/A+ specification does not deal with how to create, fulfill, or reject promises. It's up to you. But the implementation you provide for the promise's construction has to be compatible with asynchronous APIs in JavaScript. Here is the first draft of our Promise class:

The method getAsync, as well as their similar postAsync, putAsync, deleteAsync and so on, return a Promise, which implements the Promises/A+ spec. You can chain their calls or wait for all of them concurrently, as we've done. Executing this script would result in something like:

Today, I tried implementing Promises/A+ from scratch to test my coding skill. In the process, I’ve crafted this guide to share my insights and experiences with those who share a similar interest. Without further ado, let’s dive in.

That made me chuckle.

For those not familiar with the promise design controversy:

http://brianmckenna.org/blog/category_theory_promisesaplus

https://github.com/promises-aplus/constructor-spec/issues/24

https://github.com/promises-aplus/promises-spec/issues/94

If you really want to go down the rabbit hole on this one, start here

Advantage 1, nesting, is the most important here, and it's often the most-overlooked advantage. Overlooking nesting is how Promises in Javascript got to be fundamentally broken.

Have you read the infamous GitHub thread where people tried to fix this before it got finalized? It's quite a trip