How many HOFs in Phobos?
Jonathan M Davis
jmdavisProg at gmx.com
Tue Feb 1 14:58:26 PST 2011
On Tuesday, February 01, 2011 13:37:44 Andrei Alexandrescu wrote:
> On 2/1/11 2:53 PM, Jonathan M Davis wrote:
> > On Tuesday 01 February 2011 12:27:32 bearophile wrote:
> >> Walter:
> >>> It's exponentially bad performance makes it short, not useful.
> >>
> >> A program with high complexity is not a problem if you run it only on
> >> few very short examples. There is a place to care for performance (like
> >> when you design a function for Phobos) and there are places where you
> >> care for other things.
> >>
> >> I suggest top stop focusing only on a fault of a program that was not
> >> designed for performance (and if you want to start looking at the
> >> numerous good things present in Haskell. Haskell language and its
> >> implementation contains tens of good ideas).
> >
> > The issue is that if you want something in Phobos, it _does_ need to be
> > designed with performance in mind. Anything which isn't efficient needs
> > to have a very good reason for its existence which balances out its lack
> > of efficiency. If the Haskell implementation isn't performant enough,
> > then it doesn't cut it for Phobos, even if it's a good fit for Haskell.
> >
> > - Jonathan M Davis
>
> I think this is a bit much, though probably a good principle to live
> into. For example Phobos does include linear search routines that are
> "inefficient" - i.e. O(m * n). It also has many abstractions that are
> arguably not as efficient as they could be, either at high level, low
> level, or both. But something like foldr that uses head recursion would
> be indeed rather dangerous to include.
Okay. Perhaps, I said it a bit too strongly, but I think that the gist of what I
said is sound. Inefficient algorithms need to be bring something to the table that
is worth their inefficiency. And generally, if we can reasonably make algorithms
more efficient, that's something that we want to do. That's not to say that we
don't have or never will have less efficient algorithms in Phobos, but they're
there because they're worth what they bring, and just because an algorithm would
be considered reasonable for Haskell does not necessarily mean that it would be
considered reasonable for Phobos.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list