Skip to content
This repository has been archived by the owner on Jan 26, 2022. It is now read-only.

How would this interop with stateful closures? #24

Closed
dead-claudia opened this issue Mar 24, 2018 · 2 comments
Closed

How would this interop with stateful closures? #24

dead-claudia opened this issue Mar 24, 2018 · 2 comments
Assignees
Labels
discussion Discussion about a design decision

Comments

@dead-claudia
Copy link

To leave a particular example, how would this interoperate with stateful primitive-like operators like distinct or scan? I know it's not directly related to this proposal, but if we go with my lifted pipeline strawman as an extension of this, how would it interop with them? (The current syntax offers no convenient escape hatch to break the "smart" default, instead requiring a new name to be assigned.)

// Usage
books >:> distinct() >:> console.log(#)

// Implementation
function distinct(by = Object.is) {
    let hasPrev = false, prev
    return x => {
        const memo = hasPrev
        hasPrev = true
        return memo || by(prev, prev = x) ? [x] : []
    }
}
@js-choi
Copy link
Collaborator

js-choi commented Mar 24, 2018

See also dead-claudia/lifted-pipeline-proposal#6.


Pasting from #16 (comment):

As a parenthetical follow-up to tc39/proposal-pipeline-operator#106 (comment), I am very interested in your own proposal. I think there’s a lot of potential there. I’m still chewing over it as I work out the formal specifications of the remaining additional features, because it’s a big problem. I’ll reply in your new issue #24 when I can.


Also pasting from tc39/proposal-pipeline-operator#106 (comment) because still relevant:

As long as we’re talking about useful abstractions from Haskell and category theory, I think it’s important to choose the right level of abstraction here for nested/plural/etc. data.

I need to think about it more, but…have you considered other abstractions, other than functor mapping, such as applicative application or monadic binding—or, as I am currently most interested in exploring, eventually extending smart pipelines into something like the proc notation of arrows or maybe Kleisli composition.

…I’m interested in extending smart pipelines to support abstractions more powerful than functor mapping—like static arrows or Kleisli arrows and Kleisli composition—especially for the purpose of tersely using lenses or Clojure-style transducers. To use your uniq example, this, in turn, might enable defining a uniq transducer that could work on reducible/plural data of any type—without unnecessary intermediate allocation, when combined with other transducers such as those for mapping, filtering, partitioning, taking/leaving/slicing, and so on. But right now I’m dealing with implementing and specifying smart pipelines themselves, so I haven’t been able to really work out how this would work in JavaScript.

From the lifted-pipeline proposal: example of syntax for simple monads.


With regard to Clojure-style transducers, which comprise an example of stateful closures that lift an abstraction: jlongster/transducers.js#22 and jlongster/transducers.js#51, as a problem of extending its transducer model to the async structures from kriskowal/gtor.

Also leaving here for other readers: Related on the Clojure side, Specter. (Frequently isomorphically on the Haskell side, lenses, traversables, foldables, as mentioned above.)


I’ll follow up after I finish #17 and #18#25. Thanks again for the outreach; your proposal is very interesting.

@js-choi
Copy link
Collaborator

js-choi commented Mar 8, 2021

Thanks for the issue; sorry about the delayed reply.

After talking more with Tab Atkins and Daniel Ehrenberg, we’ve decided to archive this proposal in favor of a simpler Hack-pipes proposal, which is a subset of this proposal.

Feel free to open a new issue in the new repository if you think it still applies.

@js-choi js-choi closed this as completed Mar 8, 2021
Complete first explainers automation moved this from To do to Done Mar 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discussion Discussion about a design decision
Projects
Development

No branches or pull requests

2 participants