Haskell's effect on my C++ : exploit the type system • Hacker News Board

Re: Haskell's effect on my C++ : exploit the type system

#11

Post by alexchamberlain » Sun, Feb 05, 2012, 3:07 PM UTC

rquirk wrote: post #7

Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.

You make a good point, but the mistake is still made. Semantic correctness has other advantages, such as more optimisation when possible.

Re: Haskell's effect on my C++ : exploit the type system

#12

Post by landtuna » Sun, Feb 05, 2012, 3:10 PM UTC

That first example is terrible. C doesn't guarantee that the arguments to a macro are evaluated only once. At best, you might be doing the computation twice. At worst (if the function has internal state), you could get different answers for the comparison and the assignment. The non Haskell-style is better!

Re: Haskell's effect on my C++ : exploit the type system

#13

Post by cageface » Sun, Feb 05, 2012, 3:10 PM UTC

I've been reading predictions of the immanent breakthrough of FP into the mainstream for over 15 years now. I'm still waiting.

Re: Haskell's effect on my C++ : exploit the type system

#14

Post by cageface » Sun, Feb 05, 2012, 3:11 PM UTC

landtuna wrote: post #12

That first example is terrible. C doesn't guarantee that the arguments to a macro are evaluated only once. At best, you might be doing the computation twice. At worst (if the function has internal state), you could get different answers for the comparison and the assignment. The non Haskell-style is better!

Better to use the std::max template function.

Re: Haskell's effect on my C++ : exploit the type system

#15

Post by _delirium » Sun, Feb 05, 2012, 3:16 PM UTC

landtuna wrote: post #12

That first example is terrible. C doesn't guarantee that the arguments to a macro are evaluated only once. At best, you might be doing the computation twice. At worst (if the function has internal state), you could get different answers for the comparison and the assignment. The non Haskell-style is better!

I also find the non-Haskell style much more readable, but I've spent a lot more time reading C code than Haskell code, so that could just be idiomatic familiarity. To me it's clearer that it's doing: "use this value, except that if it's below 0, clamp it to 0". The MAX() reads to me semantically strangely, since I tend to view "max" as idiomatic when selecting between values, like max(left_child,right_child), but not as an idiomatic way of clamping values. It works, of course, just takes me longer to unpack, the way using short-circuit booleans for control flow takes me a second to unpack.

If it's a case where you can retrieve the value essentially free w/o side effects (as opposed to the result of a computation), one idiomatic alternative is:

    const int a = foo >= 0 ? foo : 0;

Re: Haskell's effect on my C++ : exploit the type system

#16

Post by tomjen3 » Sun, Feb 05, 2012, 3:23 PM UTC

One of the more clever not so well known C++ type system hacks I have seen is the way Ogre3D (a graphics engine for games) handle Degrees versus radians. Basically they have a class for each and have overloaded the operators so that you can mix and match operations freely (e.g you get a radian result from some computation which you can then add twenty degrees to simply by saying + Degree(20) and have the C++ type system automatically convert back and forth. And since non virtual classes (think Java classes where all members are final) take no memory and can be trivially inline there is no runtime performance hit at all.

It is a joy to use to.

Re: Haskell's effect on my C++ : exploit the type system

#17

Post by jerf » Sun, Feb 05, 2012, 3:24 PM UTC

rquirk wrote: post #7

Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.

That's an easy and one might say picturesque example to give, but there are many variants, such as an if statement that in one branch turns out to change the value in that variable, then later on you forget about it and use it incorrectly. Or it gets passed into something taking it as a reference which unexpectedly modifies it, or so on and so forth. All of these are a lot harder to give examples of in a blog post because they don't really hit you in bite-sized chunks of example code. By definition, you're supposed to understand everything going on in an example chunk of code, so it's hard to show the problems that can emerge with hard-to-understand code.

Re: Haskell's effect on my C++ : exploit the type system

#18

Post by saalweachter » Sun, Feb 05, 2012, 3:37 PM UTC

While modern C++ (or Java, for that matter) may not reflect 30 years of programming language research, it certainly has benefited 30 years of programmer feedback and development.

In C++11, the language is unaltered from the perspective of a PL researcher, its type systems unchanged, but wildly improved from the perspective of a programmer. Initializer lists, auto, lambdas, and for-each loops were added, all of which make the language more compact in ways which most programmers will appreciate. Futures will do for multi-threading in C++ what RAII did for resource management.

Programmers are not computer scientists. From the perspective a programmer, the big three languages -- C++, Java, Python -- are quite alive and changing in ways which allow us to write better, more interesting programs. Even if they are built on thirty year old type systems.

Re: Haskell's effect on my C++ : exploit the type system

#19

Post by ot » Sun, Feb 05, 2012, 3:59 PM UTC

apl wrote: post #5

> Although the newcomer C# was only introduced ten years > ago, there is little in the language to reflect the > thirty years of research into programming languages since > C++ was introduced. Not a huge fan of C#, but he couldn't have picked a worse example for language stagnation .

Agreed, especially considering the amount of cross-pollination there is between C# and Haskell, possibly through F#.

The people that develop F# and those who develop a large part of Haskell drink coffee from the same coffee machine.

Re: Haskell's effect on my C++ : exploit the type system

#20

Post by udp » Sun, Feb 05, 2012, 4:00 PM UTC

rquirk wrote: post #7

Do people really still make the `=` vs `==` mistake? GCC -Wall has had "warning: suggest parentheses around assignment used as truth value" since as long as I can remember.

It's the one mistake that everyone seems to cite when complaining about C, and I've literally never seen it happen in all my years of programming. Right up there with fall-through cases.