it's transducers, no?

[sdboyer]

just happened to notice this on my feed - not trying to troll or squash.

looking at the readme, seems like the place this ends up being is clojure-esque transducers? if so, there's https://github.com/mtdowling/transducers.php

i realize you literally just started this, so please feel free to just disregard :)

[morrisonlevi]

I have actually talked a fair bit with @mtdowling about transducers in the past, and we agree that more powerful transforms in PHP would be a big deal. We both really like Rich Hickey's transducers a lot. I spent a fair bit of time trying to make a strict port of transducers to PHP but PHP is ill-suited for it:

• PHP doesn't work very well with arity overloading
• Knowing if a function supports the result arity is difficult (maybe impossible)
• Modelling it as two interfaces works a bit better but then you have to create classes that extend the interfaces and you end up with a lot of boilerplate just to say $value * 2.

The library you linked went with a specially structured array and it works okay, but I personally thought there must be some way to solve the same problem that's easier to explain (because transducers are not trivially explainable -- that or I'm a really bad learner and teacher).

So, I put the idea on the shelf for a while. Recently I started thinking about this again and realized that as long as you define the algorithms carefully you can just use regular bind and compose to make them composable . Perhaps later I can show an example of how much simpler this ends up being.

[sdboyer]

cool, all solid thoughts imo. i think i mostly wanted to make sure you were aware of transducers, and @mtdowling's lib :smile:

if you're a bad learner or teacher, then so am i, and a lot of other folks - transducers are very meta. i went through a similar reflective process in writing a transducers implementation in Go. no arity overloading there either, but the interface system did handle at least that part easily. but figuring out a language-idiomatic port for transducers is often hard, it seems.

with that lib, it was the loss of static typing that ultimately led me to the conclusion that it just wasn't a good fit. typical discussions in Go-dom around 'generics' are focused on parametric polymorphism, but that's not even sufficient for transducers. you need an algebraic type system...say, Haskell. or, i've been meaning to give it a shot in Rust. in any case, my big takeaway was that transducers are so abstract that unless their interface is basically frictionless (like, syntax-level), they rapidly lose their efficacy.

i can imagine how rebinding closures could be used to manifest the pipeline, though. could work :+1:

[morrisonlevi]

Closing, since this isn't exactly an "issue".

[sdboyer]

:+1: