|
![](/i/fill.gif) |
Invisible escreveu:
>>> What, defining three pages of code is longer than the 1-liner I posted?
>>>
>>> The ($) operator is defined in the Haskell language standard. :-P
>>
>> The o operator is defined in my personal standard and I never look
>> back. ;)
>
> OK, but ($) is still a 1-liner:
>
> f $ x = f x
>
> And, unlike your notation, it doesn't require any brackets at all! ;-)
Why would my o operator not be a one-liner? Unless you think the
implementation of $ doesn't count. It's just as abstracted away as the
implementation of o.
I don't have a problem with brackets or parenthesis. Besides, Haskell
needs it too to solve ambiguities in all but the most simpler expressions.
And multiple $ for each call is as bad as multiple parenthesis, I guess.
> BTW, what would you say the most irritating library design flaw in
> Scheme is?
None. It's perfect. ;)
Ok, to be fair, I didn't like the latest standard very much... And given
Scheme is very minimalist, I'm used to writing my own libs, so any
design flaws are really mine. ;)
> In Haskell, my personal one is this:
>
> filter odd [1, 2, 3, 4]
>
> That takes a list and filters out the odd numbers, right?
>
> WRONG!
>
> It filters out the *even* numbers.
>
> Like, WTF?
>
> Obviously what they *should* have done is name it "select". Then you
> would write
>
> select odd [1, 2, 3, 4]
Hmm, that's just different terminology for the same things. Yes, I too
would expect filter odd to return the odds, but it certainly can be seen
working the other way around. I believe, though, that 2 functions doing
pretty much the same thing is wrong and bad design. select is really
only used in SQL. filter is a pretty common functional language idiom...
Post a reply to this message
|
![](/i/fill.gif) |