Live data from Hacker News

C++11 and Boost - Succinct like Python

fendrich.se

171–172 of 172 posts

Re: C++11 and Boost - Succinct like Python

#171
post #169

Earlier quoted context omitted.

The distinction between your point and mine is becoming miniscule, but I must defend my position on Haskell, as a heavy user myself. If Num doesn't seem to be a problem to you, it's because you supply top-level annotations that disambiguate it. Try removing all the annotations from whatever you did last week and see if it still compiles cleanly. I'd wager it doesn't. This isn't an issue in practice because we supply…

This is one of the files in a project I've worked on last week. https://github.com/Peaker/bottle/blob/master/codeedit/Editor... I removed all the top-level type declarations, and only one definition broke, because of the MR. showP :: Show a => a -> String showP = parenify . show Once I removed the type declaration, I made it work again by adding a parameter to avoid the MR: showP x = parenify (show x) and everything…

Thanks for sticking with this conversation.

This is very good code.

One difference I see between our styles that may explain the differences in behavior we see is that you're quite meticulous about importing only the parts of modules you need, and you make heavy use of qualified imports. My style has been to import everything in case I need it later and only use qualified imports when absolutely necessary, and it must be creating the unnecessary ambiguity that I have to deal with. I will try to adopt your style and see if it cleans up my error messages, and I'll encourage my friends to do the same.

Re: C++11 and Boost - Succinct like Python

#172
post #151

Earlier quoted context omitted.

Your example, void foo() { auto items = {1,2,3,4}; return; } is the case of poorly designed syntax, in a truly Hindley-Milner system there is no expression which doesn't have a type. Now, we could add some syntax that screws that up, say: let v = I-HAVE-AN-AMBIGUOUS-TYPE in 0 But that's rather silly, isn't it? If a value isn't used then I would, personally, like my language to optimize it away. So why not ditch such…

"Hell, stop programming in C++ and start using Rust!" I plan to try to do that, when Rust has become more stable.

No need to downvote this; I'm an enthusiastic Rust follower and I as well recommend that you stay far away from Rust until it settles down a bit. Wait for 0.5 if you're adventurous, 0.6 if you expect some degree of feature-completion, 0.7 if you're fine with half-finished standard libraries, and even later if you expect a high degree of stability, ergonomics, documentation, or performance.
Post reply on HN