3 ms·
> subverting purity and laziness That's an interesting choice of words. Quite obviously no useful program can be totally pure (otherwise it'd do nothing but he
by acomar 14y ago
> subverting purity and laziness
That's an interesting choice of words. Quite obviously no useful program can be totally pure (otherwise it'd do nothing but heat the machine). And Simon Peyton Jones is on record saying that he's not sure if he'd carry the laziness torch quite so far if he had to do it all over again. Neither is to say that these aren't powerful or useful techniques, but rather that in Haskell they're chosen as defaults -- impure and/or strict code are the outliers that require justification, not the other way around. So given that, in what way is using ByteStrings (safe or unsafe) subversion? Far from it -- use the tool that makes sense.
With most functional languages, the usual technique to writing fast code is to first write it to be correct, and then transform it to be fast. And that's exactly what unsafe ByteStrings are: optimizations. There's nothing wrong with optimized code, and I see no problem with the technique. The only relation it bears to the OP is that it's an explicit unboxing. Perhaps the compiler should automatically do that unboxing, but that's easier said than done.
- jlarocco 14y agoI guess my biggest problem is all of the people claiming Haskell is pure, lazy and fast. It seems disingenuous when to actually be fast requires swapping out the standard data structures with non-pure, non-lazy versions. To put it another way, a naive implementation in C will compile and be relatively fast, while a naive implementation in Haskell will, at the very least, require replacing the standard data structures with things like ByteStrings, just to match the default C speed.
- acomar 14y agoPure and fast is certainly feasible -- you don't always need to use unsafe bytestrings for example. Laziness makes performance hard to predict because you have no clue when something will get evaluated -- there's no contract with the compiler. Maybe one day some group of really smart people will figure out how to take advantage of that to write compilers that produce really fast code, but I think language-wide laziness is not a feature bound for mainstream languages. Targeted laziness? Probably, it's very useful for expressing data structures. But not everywhere by default. In any case, I don't think people are trying to be disingenuous. Haskell is, or can be, all three of those things. It's just very hard to get them all at the same time.