There are some GHC extensions that are too good to live without.  Among my favorites are

  - Multiparameter type classes
  - Scoped type variables
  - Higher-rank types
  - Generalized algebraic data types (GADTs)

Of these the really essential one is multiparameter type classes.

Some GHC extensions are very speculative and experimental, and you may want to use with caution.  A good way to identify a stable and trusted extension is to see if it is slated for inclusion in [Haskell Prime](http://hackage.haskell.org/trac/haskell-prime/), which is hoped to be the successor the Haskell 98.

I second Don Stewart&#39;s suggestion that every extension should be marked using the `LANGUAGE` pragma in the source file.  *Don&#39;t* enable extensions using command-line options.


Yes, use extensions as appropriate. 

But be sure to enable them *intentionally* -- only when you decide you need them.
Do this on a per-module basis via `{-# LANGUAGE Rank2Types #-}` (for example).

Generally speaking people do use GHC extensions quite heavily, because they&#39;re so useful and Haskell 98 is quite old. Once there&#39;s a more up to date standard people may make more effort to stick to it.

You can find the status of proposals for the next standard [here][1].


  [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Status

The other answers here are good ones. I would add that GHC extensions are not as future-vulnerable (*) as they might be, because GHC seems to be far and away the most popular Haskell compiler, and I don&#39;t see that changing soon.

(*) as in the opposite of &quot;future-proof&quot;

I couldn&#39;t find documentation on an equivalent of Java&#39;s `final` in Python, is there such a thing?

I&#39;m creating a snapshot of an object (used for restoration if anything fails); once this backup variable is assigned, it should not be modified -- a final-like feature in Python would be nice for this.

`final` keyword equivalent for variables in Python?

Is it possible to declare a variable in c++ without instantiating it? I want to do something like this:

    Animal a;
    if( happyDay() ) 
        a( &quot;puppies&quot; ); //constructor call
    else
        a( &quot;toads&quot; );

Basially, I just want to declare a outside of the conditional so it gets the right scope.

Is there any way to do this without using pointers and allocating `a` on the heap? Maybe something clever with references?


Declaring an object before initializing it in c++

As I am learning Haskell, I see that there is a lot of [language extensions][exts] used in real life code. As a beginner, should I learn to use them, or should I avoid them at all cost? I see that it breaks compatibility with Haskell&amp;nbsp;98 and limits code to pretty much GHC only. However, if I browse packages on Hackage, I see that most of them are GHC-only anyway.

So, what is an attitude of community towards using language extensions?

And if use of extensions is OK, how can I distinguish extensions which I can use “safely” (those which are likely to become part of the next Haskell standard) from those which are mostly “experimental”? For example, I suppose that [-XDisambiguateRecordFields][recorddisamb] is nice and useful, but is it likely to be supported in the future?

[exts]: http://haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html
[recorddisamb]: http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields


Should I use GHC Haskell extensions or not?

As I am learning Haskell, I see that there is a lot of <a href="http://haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html" target="_blank" rel="noopener noreferrer">language extensions</a> used in real life code. As a beginner, should I learn to use them, or should I avoid them at all cost? I see that it breaks compatibility with Haskell 98 and limits code to pretty much GHC only. However, if I browse packages on Hackage, I see that most of them are GHC-only anyway.
So, what is an attitude of community towards using language extensions?
And if use of extensions is OK, how can I distinguish extensions which I can use “safely” (those which are likely to become part of the next Haskell standard) from those which are mostly “experimental”? For example, I suppose that <a href="http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields" target="_blank" rel="noopener noreferrer">-XDisambiguateRecordFields</a> is nice and useful, but is it likely to be supported in the future?

I&#39;m going to be teaching a lower-division course in discrete structures. I have selected the text book [Discrete Structures, Logic, and Computability][1] in part because it contains examples and concepts that are conducive to implementation with a functional programming language. (I also think it&#39;s a good textbook.)

I want an easy-to-understand FP language to illustrate DS concepts and that the students can use. Most students will have had only one or two semesters of programming in Java, at best. After looking at Scheme, Erlang, Haskell, Ocaml, and SML, I&#39;ve settled on either Haskell or Standard ML. I&#39;m leaning towards Haskell for the reasons outlined below, but I&#39;d like the opinion of those who are active programmers in one or the other.

* Both Haskell and SML have pattern matching which makes describing a recursive algorithm a cinch.
* Haskell has nice list comprehensions that match nicely with the way such lists are expressed mathematically.
* Haskell has lazy evaluation. Great for constructing infinite lists using the list comprehension technique.
* SML has a truly interactive interpreter in which functions can be both defined and used. In Haskell, functions must be defined in a separate file and compiled before being used in the interactive shell.
* SML gives explicit confirmation of the function argument and return types in a syntax that&#39;s easy to understand. For example: val foo = fn : int * int -&gt; int. Haskell&#39;s implicit curry syntax is a bit more obtuse, but not totally alien. For example: foo :: Int -&gt; Int -&gt; Int.
* Haskell uses arbitrary-precision integers by default. It&#39;s an external library in SML/NJ. And SML/NJ truncates output to 70 characters by default.
* Haskell&#39;s lambda syntax is subtle -- it uses a single backslash. SML is more explicit. Not sure if we&#39;ll ever need lambda in this class, though.

Essentially, SML and Haskell are roughly equivalent. I lean toward Haskell because I&#39;m loving the list comprehensions and infinite lists in Haskell. But I&#39;m worried that the extensive number of symbols in Haskell&#39;s compact syntax might cause students problems. From what I&#39;ve gathered reading other posts on SO, Haskell is not recommended for beginners starting out with FP. But we&#39;re not going to be building full-fledged applications, just trying out simple algorithms.

What do you think?

----------


Edit: Upon reading some of your great responses, I should clarify some of my bullet points.

In SML, there&#39;s no syntactic distinction between defining a function in the interpreter and defining it in an external file. Let&#39;s say you want to write the factorial function. In Haskell you can put this definition into a file and load it into GHCi:

    fac 0 = 1
    fac n = n * fac (n-1)

To me, that&#39;s clear, succinct, and matches the mathematical definition in the book. But if you want to write the function in GHCi directly, you have to use a different syntax:

    let fac 0 = 1; fac n = n * fac (n-1)

When working with interactive interpreters, from a teaching perspective it&#39;s very, very handy when the student can use the same code in both a file and the command line.

By &quot;explicit confirmation of the function,&quot; I meant that upon defining the function, SML right away tells you the name of the function, the types of the arguments, and the return type. In Haskell you have to use the `:type` command and then you get the somewhat confusing curry notation.

One more cool thing about Haskell -- this is a valid function definition:

    fac 0 = 1
    fac (n+1) = (n+1) * fac n

Again, this matches a definition they might find in the textbook. Can&#39;t do that in SML!


  [1]:http://www.amazon.com/Discrete-Structures-Logic-Computability-James/dp/0763772062

Haskell or Standard ML for beginners?

I want to do something in Haskell that looks like this:

    main1 = do s &lt;- getLine
               if s == &quot;foo&quot; then putStr &quot;You entered foo&quot;

Obviously this isn&#39;t legal since there&#39;s no `else`. One alternative I&#39;ve thought of:

    nop :: IO ()
    nop = sequence_ []

    main2 = do s &lt;- getLine
               if s == &quot;foo&quot; then putStr &quot;You entered foo&quot; else nop

This is a little verbose, but I would settle for it if necessary. I would be surprised if there weren&#39;t a built-in version of `nop`, though.

Alternatively:

    doIf :: Bool -&gt; IO () -&gt; IO ()
    doIf b m = if b then m else nop

    main3 = do s &lt;- getLine
               doIf (s == &quot;foo&quot;) (putStr &quot;You entered foo&quot;)

This is more concise, but the syntax is not particularly nice. Again, I wouldn&#39;t be surprised to find something built-in that already exists.

What&#39;s the preferred way to do this?

Haskell &quot;do nothing&quot; IO, or if without else

Correct me if I&#39;m wrong, but it seems like algebraic data types in Haskell are useful in many of the cases where you would use classes and inheritance in OO languages. But there is a big difference: once an algebraic data type is declared, it can not be extended elsewhere. It is &quot;closed&quot;. In OO, you can extend already defined classes. For example:

    data Maybe a = Nothing | Just a

There is no way that I can somehow add another option to this type later on without modifying this declaration. So what are the benefits of this system? It seems like the OO way would be much more extensible.

Why are Haskell algebraic data types &quot;closed&quot;?

I have a list of strings, and tried this:

    ls = [ &quot;banana&quot;, &quot;mango&quot;, &quot;orange&quot; ]
    
    main = do
           map PutStrLn list_of_strings

That didn&#39;t work, and I can&#39;t understand why.

    ghc print-list.hs
    print-list.hs:3:0:
        Couldn&#39;t match expected type `IO t&#39; against inferred type `[IO ()]&#39;
        In the expression: main
        When checking the type of the function `main&#39;

Any hints? I suppose it has to do with map returning a list and not a value, but I didn&#39;t find an easy way to fix this.

Right now the only way I know to print a list of strings is to write a function that will iterate the list, printing each element (print if the list is [a], but print and recurse if it&#39;s (a:b)). But it would be *much* simpler to just use map...

Thanks!

Haskell: can&#39;t use &quot;map putStrLn&quot;?

What is the difference between the dot `(.)` and the dollar sign `($)`?

As I understand it, they are both syntactic sugar for not needing to use parentheses.



What is the difference between . (dot) and $ (dollar sign)?

If you&#39;ve bought into the functional programming paradigm, the chances are that you like both Erlang and Haskell.  Both have purely functional cores and other goodness such as lightweight threads that make them a good fit for a multicore world.  But there are some differences too.

Erlang is a commercially proven fault-tolerant language with a mature distribution model.  It has a seemingly unique feature in its ability to upgrade its version at runtime via hot code loading.  (Way cool!)

Haskell, on the otherhand, has the most sophisticated type system of any mainstream language.  (Where I define &#39;mainstream&#39; to be any language that has a published O&#39;Reilly book so Haskell counts.)  Its straightline single threaded performance looks superior to Erlang&#39;s and its lightweight threads look even lighter too.

I am trying to put together a development platform for &lt;i&gt;the rest of my coding life&lt;/i&gt; and was wondering whether it was possible to mix Erlang and Haskell to achieve a best of breed platform.  This question has two parts:

   1. I&#39;d like to use Erlang as a kind of fault tolerant MPI to glue GHC runtime instances together.  There would be one Erlang process per GHC runtime.  If &quot;the impossible happened&quot; and the GHC runtime died, then the Erlang process would detect that somehow and die too.   Erlang&#39;s hot code loading and distribution features would just continue to work.  The GHC runtime could be configured to use just one core, or all cores on the local machine, or any combination in between.   Once the Erlang library was written, the rest of the Erlang level code should be purely boilerplate and automatically generated on a per application basis.  (Perhaps by a Haskell DSL for example.)   How does one achieve at least some of these things?
   2. I&#39;d like Erlang and Haskell to be able to share the same garabage collector.  (This is a much further out idea than 1.)   Languages that run on the JVM and the CLR achieve greater mass by sharing a runtime.  I understand there are technical limitations to running Erlang (hot code loading) and Haskell (higher kinded polymorphism) on either the JVM or the CLR.  But what about unbundling just the garbage collector?  (Sort of the start of a runtime for functional languages.)  Allocation would obviously still have to be really fast, so maybe that bit needs to be statically linked in.  And there should be some mechansim to distinguish the mutable heap from the immutable heap (incuding lazy write once memory) as GHC needs this.  Would it be feasible to modify both HIPE and GHC so that the garbage collectors could share a heap?

Please answer with any experiences (positive or negative), ideas or suggestions.  In fact, any feedback (short of straight abuse!) is welcome.

**Update**

Thanks for all 4 replies to date - each taught me at least one useful thing that I did not know.

Regarding *the rest of coding life* thing - I included it slightly tongue in cheek to spark debate, but it is actually true.  There is a project that I have in mind that I intend to work on until I die, and it needs a stable platform.

In the platform I have proposed above, I would only write Haskell, as the boilerplate Erlang would　be automatically generated.  So how long will Haskell last?  Well Lisp is still with us and doesn&#39;t look like it is going away anytime soon.  Haskell is BSD3 open source and has achieved critical mass.  If programming itself is still around in 50 years time, I would expect Haskell, or some continuous evolution of Haskell, will still be here.

**Update 2** *in response to rvirding&#39;s post*

Agreed - implementing a complete &quot;Erskell/Haslang&quot; universal virtual machine might not be absolutely impossible, but it would certainly be very difficult indeed.  Sharing just the garbage collector level as something like a VM, while still *difficult*, sounds an order of magnitude less difficult to me though.  At the garbage collection model, functional languages must have a lot in common - the unbiquity of immutable data (including thunks) and the requirement for very fast allocation.  So the fact that commonality is bundled tightly with monolithic VMs seems kind of odd.

VMs do help achieve critical mass.  Just look at how &#39;lite&#39; functional languages like F# and Scala have taken off.  Scala may not have the absolute fault tolerance of Erlang, but it offers an escape route for the very many folks who are tied to the JVM.

&gt; While having a single heap makes
&gt; message passing very fast it
&gt; introduces a number of other problems,
&gt; mainly that doing GC becomes more
&gt; difficult as it has to be interactive
&gt; and globally non-interruptive so you
&gt; can&#39;t use the same simpler algorithms
&gt; as the per-process heap model.

Absolutely, that makes perfect sense to me.  The very smart people on the GHC development team appear to be trying to solve part of the problem with a parallel &quot;stop the world&quot; GC.

**[http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf][1]**

(Obviously &quot;stop the world&quot; would not fly for general Erlang given its main use case.)  But even in the use cases where &quot;stop the world&quot; is OK, their speedups do not appear to be universal.  So I agree with you, it is unlikely that there is a universally best GC, which is the reason I specified in part 1. of my question that

&gt; The GHC runtime could be configured to
&gt; use just one core, or all cores on the
&gt; local machine, or any combination in
&gt; between.

In that way, for a given use case, I could, after benchmarking, choose to go the Erlang way, and run one GHC runtime (with a singlethreaded GC) plus one Erlang process per core and let Erlang copy memory between cores for good locality.

Alternatively, on a dual processor machine with 4 cores per processor with good memory bandwidth on the processor, benchmarking might suggest that I run one GHC runtime (with a parallel GC) plus one Erlang process per processor.

In both cases, if Erlang and GHC could share a heap, the sharing would probably be bound to a single OS thread running on a single core somehow.  (I am getting out of my depth here, which is why I asked the question.)

I also have another agenda - benchmarking functional languages independently of GC.  Often I read of results of benchmarks of OCaml v GHC v Erlang v ... and wonder how much the results are confounded by the different GCs.  What if choice of GC could be orthogonal to choice of functional language?  How expensive is GC anyway?  See this devil advocates blog post 

**[http://john.freml.in/garbage-collection-harmful][2]**

by my Lisp friend John Fremlin, which he has, charmingly, given his post title &quot;Automated garbage collection is rubbish&quot;.  When John claims that GC is slow and hasn&#39;t really sped up that much, I would like to be able to counter with some numbers. 


  [1]: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf
  [2]: http://john.freml.in/garbage-collection-harmful

Mixing Erlang and Haskell

I read that hash tables in Haskell had performance issues (on the [Haskell-Cafe][1] in 2006 and [Flying Frog Consultancy&#39;s blog][2] in 2009), and since I like Haskell it worried me.

That was a year ago, what is the status now (June 2010)? Has the &quot;hash table problem&quot; been fixed in GHC?


  [1]: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/11070
  [2]: http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.html

Curious about the HashTable performance issues

I&#39;m beginning to understand how the `forall` keyword is used in so-called &quot;existential types&quot; like this:

    data ShowBox = forall s. Show s =&gt; SB s

This is only a subset, however, of how `forall` is used and I simply cannot wrap my mind around its use in things like this:

    runST :: forall a. (forall s. ST s a) -&gt; a

Or explaining why these are different:

    foo :: (forall a. a -&gt; a) -&gt; (Char, Bool)
    bar :: forall a. ((a -&gt; a) -&gt; (Char, Bool))

Or the whole `RankNTypes` stuff...

I tend to prefer clear, jargon-free English rather than the kinds of language which are normal in academic environments.  Most of the explanations I attempt to read on this (the ones I can find through search engines) have these problems:

 1. They&#39;re incomplete.  They explain one part of the use of this keyword (like &quot;existential types&quot;) which makes me feel happy until I read code that uses it in a completely different way (like `runST`, `foo` and `bar` above).
 2. They&#39;re densely packed with assumptions that I&#39;ve read the latest in whatever branch of discrete math, category theory or abstract algebra is popular this week.  (If I never read the words &quot;consult the paper *whatever* for details of implementation&quot; again, it will be too soon.)
 3. They&#39;re written in ways that frequently turn even simple concepts into tortuously twisted and fractured grammar and semantics.

So...

On to the actual question.  Can anybody completely explain the `forall` keyword in clear, plain English (or, if it exists somewhere, point to such a clear explanation which I&#39;ve missed) that doesn&#39;t assume I&#39;m a mathematician steeped in the jargon?

-----

*Edited to add:*

There were two stand-out answers from the higher-quality ones below, but unfortunately I can only choose one as best.  [Norman&#39;s answer](https://stackoverflow.com/questions/3071136/what-does-the-forall-keyword-in-haskell-ghc-do/3071365#3071365) was detailed and useful, explaining things in a way that showed some of the theoretical underpinnings of `forall` and at the same time showing me some of the practical implications of it.  [yairchu&#39;s answer](https://stackoverflow.com/questions/3071136/what-does-the-forall-keyword-in-haskell-ghc-do/3071932#3071932) covered an area nobody else mentioned (scoped type variables) and illustrated all of the concepts with code and a GHCi session.  Were it possible to select both as best, I would.  Unfortunately I can&#39;t and, after looking over both answers closely, I&#39;ve decided that yairchu&#39;s slightly edges out Norman&#39;s because of the illustrative code and attached explanation.  This is a bit unfair, however, because really I needed both answers to understand this to the point that `forall` doesn&#39;t leave me with a faint sense of dread when I see it in a type signature.

What does the `forall` keyword in Haskell/GHC do?

When compiling my Haskell application with the &lt;code&gt;-Wall&lt;/code&gt; option, GHC complains about orphaned instances, for example:

    Publisher.hs:45:9:
        Warning: orphan instance: instance ToSElem Result

The type class &lt;code&gt;ToSElem&lt;/code&gt; is not mine, it&#39;s defined by [HStringTemplate][1].

Now I know how to fix this (move the instance declaration into the module where Result is declared), and I know [why GHC would prefer to avoid orphaned instances][2], but I still believe that my way is better.  I don&#39;t care if the compiler is inconvenienced - rather it than me.

The reason I want to declare my &lt;code&gt;ToSElem&lt;/code&gt; instances in the Publisher module is because it is the Publisher module that depends on HStringTemplate, not the other modules.  I am trying to maintain a separation of concerns and avoid having every module depend on HStringTemplate.

I thought that one of the advantages of Haskell&#39;s type classes, when compared for example to Java&#39;s interfaces, is that they are open rather than closed and therefore the instances do not have to be declared in the same place as the data type.  GHC&#39;s advice seems to be to ignore this.

So, what I&#39;m looking for is either some validation that my thinking is sound and that I would be justified in ignoring/suppressing this warning, or a more convincing argument against doing things my way.


  [1]: http://www.haskell.org/haskellwiki/HStringTemplate
  [2]: http://www.haskell.org/ghc/docs/6.10.3/html/users_guide/separate-compilation.html#orphan-modules

Orphaned instances in Haskell

How can I find the actual amount of memory required to store a value of some data type in Haskell (mostly with GHC)? Is it possible to evaluate it at runtime (e.g. in GHCi) or is it possible to estimate memory requirements of a compound data type from its components?

In general, if memory requirements of types `a` and `b` are known, what is the memory overhead of algebraic data types such as:

    data Uno = Uno a
    data Due = Due a b

For example, how many bytes in memory do these values occupy?

    1 :: Int8
    1 :: Integer
    2^100 :: Integer
    \x -&gt; x + 1
    (1 :: Int8, 2 :: Int8)
    [1] :: [Int8]
    Just (1 :: Int8)
    Nothing

I understand that actual memory allocation is higher due to delayed garbage collection. It may be significantly different due to lazy evaluation (and thunk size is not related to the size of the value). The question is, given a data type, how much memory does its value take when fully evaluated?

I found there is a `:set +s` option in GHCi to see memory stats, but it is not clear how to estimate the memory footprint of a single value.

Content Type	Original Author	Original Content on Stackoverflow
Question	sastanin	View Question on Stackoverflow
Solution 1 - Haskell	Norman Ramsey	View Answer on Stackoverflow
Solution 2 - Haskell	Don Stewart	View Answer on Stackoverflow
Solution 3 - Haskell	GS - Apologise to Monica	View Answer on Stackoverflow
Solution 4 - Haskell	Phil Darnowsky	View Answer on Stackoverflow

Should I use GHC Haskell extensions or not?

Haskell Problem Overview

Haskell Solutions

Solution 1 - Haskell

Solution 2 - Haskell

Solution 3 - Haskell

Solution 4 - Haskell

Declaring an object before initializing it in c++

`final` keyword equivalent for variables in Python?

Attributions