I've just seen a #programming pattern in #PHP where a method could return two lists of things. Instead of doing that, it takes as a parameter a callable, and passes the two lists to the callable. Instead of:
[$a, $b] = getLists($param);
// Act on both lists.
we have:
$callable = function($a, $b) {
// Act on both lists
}
actOnLists($param, $callable);
@joachim Imposing a higher-order function where it just complicates things without any gain would (if at all) be an anti-pattern.
But it might be that the implementation of actOnLists is lazy w.r.t. the lists, which would improve performance in an otherwise strict (= eager) language in case not the whole lists are needed.
(Assuming getLists isn't a mere lookup but would have to actually produce (build / compute) the lists and their content.)
@das_g Thanks for the analysis! actOnLists() isn't lazy, but it does need to make queries. Further complexity is that it actually retrieves more than one pair of lists. I imagine the higher-order function pattern was written here to avoid returning an array of arrays, or writing a value object class for just this one purpose. I'm not sure how much of a gain I consider that though, as I find the current pattern hard to get my head round.
@Jose_A_Alonso Hmm, interesting. To me, the benchmarks especially so. If it was only for normalisation, it's pretty clear that NbE is and always will be the winner. But if I understand correctly, NbE has limits; for example it would not be so simple to implement a transformation pass like GHC's Simplifier using NbE, where you apply peephole optimisations such as case-of-case, inlining etc. to the program while traversing it. I wonder if @AndrasKovacs has tried NbE for such a pass?
@flypaper@lpil not at the moment, but I really should! been following the project for a very long time so just happy for its continued growth and success :)
would say it's a proper choice for building web-based applications end-to-end, amongst other things 👍
🦾 Functional TypeScript #1: Algebraic Data Types | Injuly
"In functional programming, algebraic types are so ubiquitous that you would be hard pressed to find a language that doesn't support them. Strangely though, nothing about them demands that a language be functional by paradigm. That imperative languages have avoided ADTs for decades seems almost an accident."