3 ms·

Of course the include operation on a set is a trivial operation but that's been the first example for junction I found when googling. It's not a problem with a

by bhaak 11y ago

Of course the include operation on a set is a trivial operation but that's been the first example for junction I found when googling. It's not a problem with an open mind but rather with understanding what data type a junction is trying to be. If I go to the official specification (my fault, should have gone there from the beginning), I read the definition "A junction is a superposition of data values pretending to be a single data value". But that's a fuzzy definition and it is absolutely not clear what that's supposed to mean. The given examples don't help either. Especially when I look at this discussion and see that several people including you are not sure what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? The autothreading feature is cool but also nothing too special. Every pure functional language can implement map/reduce/filter in parallel. tl;dr I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter.

raiph 11y ago
> what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? Afaik junctions are simple and have an obvious intuitive read. But I'm not yet 100% confident of expressing that view without qualification. Given Estragon's "no idea" comment I allowed that my intuitive read might be bogus. In fact the intuitive read is correct: if all(ar1) < any(ar2) # if all in ar1 are numerically less than any in ar2 > The autothreading feature is cool To be clear, the whole point of junctions is autothreading; passing junctions to any code that does not have an overload for junctional arguments is automatically (semantically, at least) data parallelized and that's the win that makes them significant. > Every pure functional language can implement map/reduce/filter in parallel. I note "can implement" and your choice of just three functions. Which languages provide a mechanism equivalent to junctions and their most significant use-case -- automatically generating data parallelized versions of any sequential functionally pure code? > I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter. What equivalent of "all(ar1) < any(ar2)" -- all ar1 less than any ar2 -- is "expressed easier to understand"?

by bhaak 11y ago

raiph 11y ago

> what "all(@ar1) < any(@ar2)" is supposed to mean. That's not a complicated expression and that's already puzzling to people who know the language? Afaik junctions are simple and have an obvious intuitive read. But I'm not yet 100% confident of expressing that view without qualification. Given Estragon's "no idea" comment I allowed that my intuitive read might be bogus. In fact the intuitive read is correct: if all(ar1) < any(ar2) # if all in ar1 are numerically less than any in ar2 > The autothreading feature is cool To be clear, the whole point of junctions is autothreading; passing junctions to any code that does not have an overload for junctional arguments is automatically (semantically, at least) data parallelized and that's the win that makes them significant. > Every pure functional language can implement map/reduce/filter in parallel. I note "can implement" and your choice of just three functions. Which languages provide a mechanism equivalent to junctions and their most significant use-case -- automatically generating data parallelized versions of any sequential functionally pure code? > I don't see what junctions bring to the table that's not expressed easier to understand with set operations or map/reduce/filter. What equivalent of "all(ar1) < any(ar2)" -- all ar1 less than any ar2 -- is "expressed easier to understand"?