Daniel Fischer
An important point of a powerful type system is to model your program so that only sensible code is legal.
That would be an awesomely powerful type system :)
Heh. But while we're waiting for it, we can try to use what we got to eliminate as much non-sensical code as possible. (Which, btw, I think is an under-sold point: people used to C-style type systems think that all the type system does is label variables for you, which dynamic type systems (like our algebraic data types) let you do the same run-time. But you get a lot more mileage by careful type design.)
I don't think there would be any doubt what 'deleteBy (<= 5) [1..10]' would do.
Well, if you don't know about filter, you could think it deletes all elements satisfying the predicate, but apart from that, it's clear.
I'd probably call it 'filter1', but that's just my personal convention.
And I just don't see what the requirement for an equivalence relation buys you.
For the type deleteBy has, predictability. Currently, you can't know whether deleteBy pred x tests pred x y or pred y x without looking at the source.
...which is a worry my implementation removed by letting the user decide through partial application.
For a symmetric relation, you needn't care.
But the docs (are interpreted to) say equivalence relation, so woe betide you if you give it a symmetric but non-transitive or non-reflexive function! deleteBy (\x y -> abs (x-y) == 2) 5 [1..5] Anyway: I guess the point here is that if all 'deleteBy f x ys' does with arguments f and x is apply f to x and then use the result, we might as well feed it that result and eliminate a lot of uncertainity as well as some documentation all too few of us bother to read. -k -- If I haven't seen further, it is by standing in the footprints of giants