@voidhawk In short, it would be an unnecessary abstraction with terrible consequences for performance.
@voidhawk Monadic ⍸ is currently {(,~~⍵)/,⍳⍴⍵} but we're considering changing it to {(,⍵)/,⍳⍴⍵} so it isn't thats simple. Also, it has no performance cost, and isn't an abstraction, but rather a well-defined unit of thought.
@ngn No, there are two arguments which may or may not be the same. Filter A by B. There could be a filter operator F←{⍵/⍨⍺⍺ ⍺} which you could use with "selfie" as in (2∘|)F⍨A just like "⍋" in J, which is defined as {⍺←⍳≢⍵ ⋄ ⍺⌷⍨⊂⍋⍵}. But it just makes for awkward syntax if you want ⍺⍺ called dyadically.
@ngn Right, that's an unnecessarily restricted instance of a general concept. We don't need a summation function when we have the more general reduction.
@Adám "unnecessary abstraction" is a matter of opinion. with phrases like "tool of thought" and "unnecessary abstraction" you can justify anything you like and discredit anything you don't like. aren't +.× and ⊥ unnecessary abstractions over + and ×?
and i don't understand the performance argument. filter would be each-y and slower, of course. / and ⌿ would still be there for the cases when the filtering function can be applied to whole vectors
Certainly, ⍋ and / are mirror in their "philosophy", though if ⍋ returned the sorted array, getting the same result as we currently do wouldn't be too hard :)
@Ven Right, but that wasn't the point, rather B[⍋A] ≡ B⍋A and thus A[⍋A] ≡ ⍋⍨A while ⍋A retains its current meaning. So just like the dyadic form sorts the left argument by the grade of the right argument, so too Filter (say ƒ) could filter the left argument by the mask of the right argument, i.e. (B/⍨g A) ≡ Bƒg A but why have such an operator when you can have the more general / and just write B/⍨g A ?
@Ven Yeah. Also, I think I use /⍨ more than /. Maybe there would be room for a function defined as {⍵⌿⍺} "filter by". Then you could write B ƒ g A or tacitly ƒ∘g and "filter self" would be ƒ∘g⍨
@Ven deriving ⍋ from ⍋' is way easier though (and much more simple & fast). the philosophy of both ⍋ and / is to allow separation of the "settings" and the array the settings are are applied to.
@Adám that's a different meaning of "where". in haskell you can write something like expr where name1=expr1, name2=expr2. "where" simply introduces name-value bindings for the expression, nothing to do with "filter"
@Adám thanks, that discussion makes sense from a performance standpoint. I just frequently find myself doing something like temp/⍨5<temp←⍳10 , whereas it would be nice to do something like F←{⍵/⍨⍺⍺⍵}⋄5∘<F⍳10 . But I haven't done any serious thinking around making it sufficiently general (performance characteristics/APL philosophy adherence aside)
