language-extension

Which Haskell (GHC) extensions should users use/avoid?

落花浮王杯 提交于 2019-11-27 16:50:24
I have had the experience a few times now of having GHC tell me to use an extension, only to discover that when in using that extension I have made code far more complex when a simple refactor would have allowed me to stick with Haskell 98 (now 2010 ) and have a more straightforward solution. On the other hand, there are also times when GADT's or Rank2Types (rarely RankNTypes) make for much less work and much cleaner code. Which extensions tend generally to obscure the possibility of a better design, and which generally improve it? If there are some that do both, what should a user look for

DatatypeContexts Deprecated in Latest GHC: Why?

我与影子孤独终老i 提交于 2019-11-27 03:02:38
I was just doing some Haskell development and I recompiled some old code on a new version of GHC: The Glorious Glasgow Haskell Compilation System, version 7.2.1 And when I did I received the following error: Warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. That appears when you have code in the following format: data Ord a => MyType a = ConstructorOne a = ConstructorTwo a a My question is: Why was this feature deprecated in the first place and what am I supposed to do instead to achieve the same or similar

What's this C++ syntax that puts a brace-surrounded block where an expression is expected?

江枫思渺然 提交于 2019-11-26 22:42:32
问题 I came across this weird C++ program. #include <iostream> using namespace std; int main() { int a = ({int x; cin >> x; x;}); cout << a; } Can anyone explain what is going on? What is this construct called? 回答1: It assigns user input value to a and prints it out. it is done by using a Statement Expression . Statement Expressions are gnu gcc compiler extension are not supported by the C/C++ standards. Hence any code which uses statement expression is non standard conforming and non portable.

Which Haskell (GHC) extensions should users use/avoid?

强颜欢笑 提交于 2019-11-26 18:46:32
问题 I have had the experience a few times now of having GHC tell me to use an extension, only to discover that when in using that extension I have made code far more complex when a simple refactor would have allowed me to stick with Haskell 98 (now 2010) and have a more straightforward solution. On the other hand, there are also times when GADT's or Rank2Types (rarely RankNTypes) make for much less work and much cleaner code. Which extensions tend generally to obscure the possibility of a better

C++ Modules - why were they removed from C++0x? Will they be back later on?

戏子无情 提交于 2019-11-26 15:50:46
I just discovered this old C++0x draft about modules in C++0x. The idea was to get out of the current .h/.cpp system by writing only .cpp files which would then generate module files during compilation, which would then in turn be used by the other .cpp files. This looks like a really great feature. But my question is: why did they remove it from C++0x? Was it because of too many technical difficulties? Lack of time? And do you think they will consider working on it for an ulterior version of C++? From the State of C++ Evolution (Post San Francisco 2008) , the Modules proposal was categorized

DatatypeContexts Deprecated in Latest GHC: Why?

让人想犯罪 __ 提交于 2019-11-26 10:20:03
问题 I was just doing some Haskell development and I recompiled some old code on a new version of GHC: The Glorious Glasgow Haskell Compilation System, version 7.2.1 And when I did I received the following error: Warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. That appears when you have code in the following format: data Ord a => MyType a = ConstructorOne a = ConstructorTwo a a My question is: Why was this feature

C++ Modules - why were they removed from C++0x? Will they be back later on?

蓝咒 提交于 2019-11-26 04:37:57
问题 I just discovered this old C++0x draft about modules in C++0x. The idea was to get out of the current .h/.cpp system by writing only .cpp files which would then generate module files during compilation, which would then in turn be used by the other .cpp files. This looks like a really great feature. But my question is: why did they remove it from C++0x? Was it because of too many technical difficulties? Lack of time? And do you think they will consider working on it for an ulterior version of