Comments on: Self-optimizing data structures: using types to make lists faster

By: anonymous

anonymous — Sun, 18 Oct 2009 14:13:51 +0000

Using tolist gives you back your pattern matching. With a rule that eliminated fromList . toList, would Haskell be able to eliminate them from tail’ = fromList . tail . toList to give you the same results as you have above? That would be the best of both worlds.

By: dons00

dons00 — Sun, 18 Oct 2009 01:55:32 +0000

@Antonio I think one benefit of the approach outlined in this talk is that you do get clean code. List Int really does generate a list of unboxed ints, and the code is indentical to boxed ints.

By: Antonio

Antonio — Sat, 17 Oct 2009 22:21:16 +0000

Generic as they are, these optimizations require more work and make the code less transparent. It sounds like only C++ has generic unboxed data structures (this is not meant to suggest that C++ is better than Haskell, otherwise I would just write in C++ and not bother with Haskell). One writes Vector[A] and that’s it. Is it possible to write an unboxed compiler for Haskell? Fast by design, not by mastery, that should be the goal. Then we can focus on what the application should do, not the language.

By: ok-but

ok-but — Tue, 13 Oct 2009 05:00:47 +0000

great work, but it’s a shame that pattern matching is lost. Is it feasible to deconstruct pattern matching and rewrite automatically?

By: dons00

dons00 — Mon, 12 Oct 2009 14:59:54 +0000

@Visscher With head and tail it was easy to rewrite pattern matches. A general list elimination form would probably work just as well.

By: Heinrich Apfelmus

Heinrich Apfelmus — Mon, 12 Oct 2009 13:52:06 +0000

What about type classes, like Functor and Monad? I think it should be possible to do

    instance Functor List where
        fmap f xs = if null xs then empty else
                  cons (f $ head xs) (fmap f $ tail xs)

but that would need an AdaptList constraint on the data type family List?

By: Sjoerd Visscher

Sjoerd Visscher — Mon, 12 Oct 2009 10:23:35 +0000

Is it for performance that you built the Class around the ugly head and tail eliminators? I would prefer something like this:

elimList :: b -> (a -> List a -> b) -> List a -> b

Which would clean up the code a lot, but I don’t know about performance.

By: Vyacheslav Egorov

Vyacheslav Egorov — Mon, 12 Oct 2009 07:33:13 +0000

I am curious what is rationale behind the post’s title. Judging from it I expected that you would present a data structure (probably accompanied with rewrite rules) that adopts/optimizes itself for different usages (sounds a little scifi-ish ;) ).

On a side note, it seems that such “strict unpacked lists” of type [!a] (which is currently not valid) can be easily introduced at the compiler’s level. When compiler encounters application f x (f :: [a] -> b, x :: [!b]) it can just try to generate a special version of f adopted to the representation of x (unpacked elements).

By: dons00

dons00 — Mon, 12 Oct 2009 01:45:17 +0000

Thanks Lf and BadAxes: yes, I’m using criterion, and there is a feature request against it to allow multiple benchmarks to yield graphs with the same axes. Until then, we’ll just have to hang on.

By: Bad Axes

Bad Axes — Mon, 12 Oct 2009 01:29:29 +0000

Agreed. There have been a few posts lately around the Haskell blogosphere that have used the same style plots (is there some plotting package that made these that people are using now?), and have had the same issue with inconsistent axes. It’s bad form to present data for comparison and use inconsistent axes.