blocks|key|1241538|text|只要您有足够的内存，垃圾收集器就不是必需的。然而，在现实中，我们没有无限的内存，所以我们需要一些方法来回收不再需要的内存。在像C这样的不纯语言中，您可以显式地声明您已经使用了一些内存来释放它--但这是一种变异操作(您刚刚释放的内存不再安全，因此您不能在纯语言中使用这种方法。因此，它要么是静态地分析可以释放内存的地方(在一般情况下可能是不可能的)，要么是像筛子一样泄漏内存(在用完之前工作得很好)，或者使用GC。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241539|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A garbage collector is never necessary, provided you have sufficient memory. However, in reality, we don't have infinite memory, and so we need some method to reclaim memory that is no longer needed. In impure languages like C, you can explicitly state you're done with some memory to free it - but this is a mutating operation (the memory you just freed is no longer safe to read), so you can't use this approach in a pure language. So it's either somehow statically analyze where you can free the memory (probably impossible in the general case), leak memory like a sieve (works great until you run out), or use a GC.

blocks|key|1241577|text|应用于Haskell的标准实现技术实际上比大多数其他语言都需要GC模式，因为它们从不变异以前的值，而是根据以前的值创建新的、修改过的值。因为这意味着程序不断地分配和使用更多的内存，因此随着时间的推移，大量的值将被丢弃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241578|这就是为什么GHC程序往往拥有如此高的总分配数(从千兆字节到兆字节)：它们不断地分配内存，这是因为有了高效的GC，它们才能在耗尽内存之前收回内存。|1241579|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The standard implementation techniques applied to Haskell actually require a GC moreso than most other languages, since they never mutate previous values, instead creating new, modified values based on the previous ones. Since this means the program is constantly allocating and using more memory, a large number of the values will be discarded as time goes on.

This is why GHC programs tend to have such high total allocation figures (from gigabytes to terabytes): they're constantly allocating memory, and it's only thanks to the efficient GC that they reclaim it before running out.

blocks|key|1210760|text|如果一种语言(任何语言)允许动态分配对象，那么有三种处理内存管理的实用方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1210761|1210762|语言只能允许您在堆栈上或启动时分配内存。但这些限制严重限制了程序所能执行的计算类型。(在实践中。理论上，您可以通过在一个大数组中表示动态数据结构来模拟(例如)+Fortran中的动态数据结构。太可怕了..。与此discussion.)|ordered-list-item|1210763|The语言无关的是，它可以提供显式的free或dispose机制。但这取决于程序员才能把它做好。存储管理中的任何错误都可能导致内存泄漏.或者更糟的是，|offset|length|style|CODE|1210764|语言(或者更严格地说，语言实现)可以为动态分配的存储提供一个自动存储管理器；即某种形式的垃圾收集器。|1210765|1210766|唯一的其他选择是永远不要回收动态分配的存储。除了执行小计算的小程序外，这不是一个实用的解决方案。|1210767|将此应用于Haskell，该语言没有1.的限制，并且没有按2的手动脱分配操作。因此，为了能够用于非琐碎的事情，Haskell实现需要包括一个垃圾收集器。|1210768|1210769|我想不出GC在纯语言中是必要的。|blockquote|1210770|1210771|1210772|想必你指的是纯粹的函数式语言。|1210773|答案是，引擎盖下需要GC来回收语言必须创建的堆对象。例如。|1210774|1210775|纯函数需要创建堆对象，因为在某些情况下它必须返回它们。这意味着不能在堆栈上分配它们。|unordered-list-item|1210776|(例如，由let+rec产生的)这一事实意味着引用计数方法不能用于堆|1210777|--存在函数闭包.它也不能在堆栈上分配，因为它们的生存期(通常独立于在其中创建它们的堆栈框架)。|1210778|1210779|1210780|+--我正在寻找如果GC不存在的话会泄漏的示例代码。|1210781|1210782|1210783|几乎任何涉及闭包或图形型数据结构的例子都会在这种情况下泄漏。|1210784|entityMap^0|0|0|0|I|4|N|7|0|0|0|0|0|0|0|0|0|0|0|0|0|5|7|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1N|8|@$H|1O|I|1P|J|K]|$H|1Q|I|1R|J|K]]|9|@]|A|$]]|$1|L|3|M|5|E|7|1S|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1U|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1V|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|T|3|U|5|V|7|1X|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|20|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|21|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|13|3|14|5|15|7|23|8|@]|9|@]|A|$]]|$1|16|3|17|5|15|7|24|8|@$H|25|I|26|J|K]]|9|@]|A|$]]|$1|18|3|19|5|15|7|27|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|V|7|2A|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]]|1J|$]]

If a language (any language) allows you to allocate objects dynamically, then there are three practical ways to deal with the management of memory:

<ol>
<li>The language can only allow you to allocate memory on the stack, or at startup. But these restrictions severely limit the kinds of computations that a program can perform. (In practice. In theory, you can emulate dynamic data structures in (say) Fortran by representing them in a big array. It is HORRIBLE ... and not relevant to this discussion.)</li>
<li>The language can provide an explicit <code>free</code> or <code>dispose</code> mechanism. But this relies on the programmer to get it right. Any mistake in the storage management can result in a memory leak ... or worse.</li>
<li>The language (or more strictly, the language implementation) can provide an automatic storage manager for the dynamically allocated storage; i.e. some form of garbage collector.</li>
</ol>

The only other option is to never reclaim dynamically allocated storage. This is not a practical solution, except for small programs performing small computations.

Applying this to Haskell, the language doesn't have the limitation of 1., and there is no manual deallocation operation as per 2. Therefore, in order to be useable for non-trivial things, a Haskell implementation needs to include a garbage collector.

<blockquote>
 I can't think of a case where GC would be necessary in a pure language.
</blockquote>

Presumably you mean a pure functional language.

The answer is that a GC is required under the hood to reclaim the heap objects that the language MUST create. For example.

<ul>
<li>A pure function needs to create heap objects because in some cases it has to return them. That means that they can't be allocated on the stack.</li>
<li>The fact that there can be cycles (resulting from a <code>let rec</code> for example) means that a reference counting approach won't work for heap objects.</li>
<li>Then there are function closures ... which also can't be allocated on the stack because they have a lifetime that is (typically) independent of that stack frame in which they were created.</li>
</ul>

<blockquote>
 I'm looking for example code that would leak if a GC wasn't present.
</blockquote>

Just about any example that involved closures or graph-shaped data structures would leak under those conditions.

blocks|key|2101642|text|正如其他人已经指出的，Haskell需要自动，动态内存管理:自动内存管理是必要的，因为手动内存管理是不安全的；动态内存管理是必要的，因为对于某些程序来说，对象的生存期只能在运行时确定。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2101643|例如，考虑以下程序：|2101644|main+=+loop+(Just+[1..1000])+where
++loop+::+Maybe+[Int]+->+IO+()
++loop+obj+=+do
++++print+obj
++++resp+<-+getLine
++++if+resp+==+"clear"
+++++then+loop+Nothing
+++++else+loop+obj|code-block|syntax|javascript|2101645|在这个程序中，列表[1..1000]必须保存在内存中，直到用户键入“清除”为止；因此必须动态地确定它的生存期，这就是为什么需要动态内存管理的原因。|CODE|2101646|因此，在这个意义上，自动动态内存分配是必要的，在实践中这意味着：yes，Haskell需要一个垃圾收集器，因为垃圾收集是最高性能的自动动态内存管理器。|2101647|然而..。|2101648|尽管垃圾收集器是必要的，但我们可能尝试找到一些特殊情况，编译器可以使用比垃圾收集更便宜的内存管理方案。例如，给出|2101649|f+::+Integer+->+Integer
f+x+=+let+x2+=+x*x+in+x2*x2|2101650|我们可能希望编译器检测到在x2返回时可以安全地释放f+(而不是等待垃圾收集器释放x2)。本质上，我们要求编译器执行escape+analysis，以便尽可能将分配到垃圾收集堆的分配转换为allocations+on+the+stack。|2101651|这并不是不合理的要求：jhc+haskell+compiler做到了这一点，尽管GHC没有这样做。西蒙·马洛(+Simon+)认为，GHC的代际垃圾收集器使得逃逸分析几乎没有必要。|2101652|jhc实际上使用了一种名为region+inference的复杂形式的转义分析。考虑一下|2101653|f+::+Integer+->+(Integer,+Integer)
f+x+=+let+x2+=+x+*+x+in+(x2,+x2%2B1)

g+::+Integer+->+Integer
g+x+=+case+f+x+of+(y,+z)+->+y+%2B+z|2101654|在这种情况下，简单的转义分析会得出结论：x2从f+(因为它在元组中返回)转义，因此必须在垃圾收集堆上分配x2。另一方面，区域推断能够检测到，当x2返回时，g可以被释放；这里的思想是，x2应该分配到g的区域，而不是f的区域。|2101655|超越哈斯克尔|2101656|正如上面所讨论的，区域推断在某些情况下是有帮助的，但它似乎很难与惰性评估有效地协调(请参阅Edward+Kmett's和Simon+Peyton+Jones'注释)。例如，考虑|2101657|f+::+Integer+->+Integer
f+n+=+product+[1..n]|2101658|人们可能会倾向于在堆栈上分配列表[1..n]并在f返回后重新定位它，但这将是灾难性的:它将把f从使用O(1)内存(在垃圾收集下)更改为O(n)内存。|2101659|20世纪90年代和21世纪初，对严格的函数式语言ML的区域推理进行了广泛的研究。Mads、Lars+Birkedal、Martin、Niels在他们关于区域推理的工作上写了一个可读的retrospective，其中很多都集成到了MLKit+compiler中。他们试验了纯基于区域的内存管理(即没有垃圾收集器)以及基于区域/垃圾收集的混合内存管理，并报告说他们的测试程序运行速度“比纯垃圾收集版本快10倍到4倍”。|2101660|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Escape_analysis|1|http://en.wikipedia.org/wiki/Stack-based_memory_allocation|2|http://repetae.net/computer/jhc/|3|http://en.wikipedia.org/wiki/Region-based_memory_management|4|http://www.haskell.org/pipermail/haskell/2009-August/021562.html|5|http://www.haskell.org/pipermail/haskell/2009-August/021556.html|6|http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.160|7|http://www.itu.dk/research/mlkit/index.php/Main_Page^0|K|2|N|2|0|0|0|9|9|0|W|3|0|0|0|0|D|2|P|1|14|2|1L|F|0|2L|O|1|0|B|K|2|0|D|G|3|0|0|K|2|N|1|1G|2|1Z|2|25|1|2J|2|2Q|1|2Y|1|0|0|19|E|4|1O|J|5|0|0|G|6|O|1|1A|1|0|2J|D|6|36|E|7|0^^$0|@$1|2|3|4|5|6|7|23|8|@$9|24|A|25|B|C]|$9|26|A|27|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|28|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|29|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|2A|8|@$9|2B|A|2C|B|O]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|2D|8|@$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|2G|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|2H|8|@]|D|@]|E|$]]|$1|V|3|W|5|J|7|2I|8|@]|D|@]|E|$K|L]]|$1|X|3|Y|5|6|7|2J|8|@$9|2K|A|2L|B|O]|$9|2M|A|2N|B|O]|$9|2O|A|2P|B|O]]|D|@$9|2Q|A|2R|1|2S]|$9|2T|A|2U|1|2V]]|E|$]]|$1|Z|3|10|5|6|7|2W|8|@]|D|@$9|2X|A|2Y|1|2Z]]|E|$]]|$1|11|3|12|5|6|7|30|8|@]|D|@$9|31|A|32|1|33]]|E|$]]|$1|13|3|14|5|J|7|34|8|@]|D|@]|E|$K|L]]|$1|15|3|16|5|6|7|35|8|@$9|36|A|37|B|O]|$9|38|A|39|B|O]|$9|3A|A|3B|B|O]|$9|3C|A|3D|B|O]|$9|3E|A|3F|B|O]|$9|3G|A|3H|B|O]|$9|3I|A|3J|B|O]|$9|3K|A|3L|B|O]]|D|@]|E|$]]|$1|17|3|18|5|6|7|3M|8|@]|D|@]|E|$]]|$1|19|3|1A|5|6|7|3N|8|@]|D|@$9|3O|A|3P|1|3Q]|$9|3R|A|3S|1|3T]]|E|$]]|$1|1B|3|1C|5|J|7|3U|8|@]|D|@]|E|$K|L]]|$1|1D|3|1E|5|6|7|3V|8|@$9|3W|A|3X|B|O]|$9|3Y|A|3Z|B|O]|$9|40|A|41|B|O]]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|42|8|@]|D|@$9|43|A|44|1|45]|$9|46|A|47|1|48]]|E|$]]|$1|1H|3|-4|5|6|7|49|8|@]|D|@]|E|$]]]|1I|$1J|$5|1K|1L|1M|E|$1N|1O]]|1P|$5|1K|1L|1M|E|$1N|1Q]]|1R|$5|1K|1L|1M|E|$1N|1S]]|1T|$5|1K|1L|1M|E|$1N|1U]]|1V|$5|1K|1L|1M|E|$1N|1W]]|1X|$5|1K|1L|1M|E|$1N|1Y]]|1Z|$5|1K|1L|1M|E|$1N|20]]|21|$5|1K|1L|1M|E|$1N|22]]]]

As others have already pointed out, Haskell requires automatic, dynamic memory management: automatic memory management is necessary because manual memory management is unsafe; dynamic memory management is necessary because for some programs, the lifetime of an object can only be determined at runtime. 

For example, consider the following program:

<pre><code>main = loop (Just [1..1000]) where
 loop :: Maybe [Int] -&gt; IO ()
 loop obj = do
 print obj
 resp &lt;- getLine
 if resp == "clear"
 then loop Nothing
 else loop obj
</code></pre>

In this program, the list <code>[1..1000]</code> must be kept in memory until the user types "clear"; so the lifetime of this must be determined dynamically, and this is why dynamic memory management is necessary.

So in this sense, automated dynamic memory allocation is necessary, and in practice this means: yes, Haskell requires a garbage collector, since garbage collection is the highest-performance automatic dynamic memory manager.

<h2>However...</h2>

Although a garbage collector is necessary, we might try to find some special cases where the compiler can use a cheaper memory management scheme than garbage collection. For instance, given

<pre><code>f :: Integer -&gt; Integer
f x = let x2 = x*x in x2*x2
</code></pre>

we might hope for the compiler to detect that <code>x2</code> can safely be deallocated when <code>f</code> returns (rather than waiting for the garbage collector to deallocate <code>x2</code>). Essentially, we are asking that the compiler perform <a href="http://en.wikipedia.org/wiki/Escape_analysis">escape analysis</a> to convert allocations in to garbage-collected heap to <a href="http://en.wikipedia.org/wiki/Stack-based_memory_allocation">allocations on the stack</a> wherever possible. 

This is not too unreasonable to ask for: the <a href="http://repetae.net/computer/jhc/">jhc haskell compiler</a> does this, although GHC does not. Simon Marlow <a href="http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022142.html">says</a> that GHC's generational garbage collector makes escape analysis mostly unnecessary.

jhc actually uses a sophisticated form of escape analysis known as <a href="http://en.wikipedia.org/wiki/Region-based_memory_management">region inference</a>. Consider

<pre><code>f :: Integer -&gt; (Integer, Integer)
f x = let x2 = x * x in (x2, x2+1)

g :: Integer -&gt; Integer
g x = case f x of (y, z) -&gt; y + z
</code></pre>

In this case, a simplistic escape analysis would conclude that <code>x2</code> escapes from <code>f</code> (because it is returned in the tuple), and hence <code>x2</code> must be allocated on the garbage-collected heap. Region inference, on the other hand, is able to detect that <code>x2</code> can be deallocated when <code>g</code> returns; the idea here is that <code>x2</code> should be allocated in <code>g</code>'s region rather than <code>f</code>'s region.

<h2>Beyond Haskell</h2>

While region inference is helpful in certain cases as discussed above, it appears to be difficult to reconcile effectively with lazy evaluation (see <a href="http://www.haskell.org/pipermail/haskell/2009-August/021562.html">Edward Kmett's</a> and <a href="http://www.haskell.org/pipermail/haskell/2009-August/021556.html">Simon Peyton Jones'</a> comments). For instance, consider

<pre><code>f :: Integer -&gt; Integer
f n = product [1..n]
</code></pre>

One might be tempted to allocate the list <code>[1..n]</code> on the stack and deallocate it after <code>f</code> returns, but this would be catastrophic: it would change <code>f</code> from using O(1) memory (under garbage collection) to O(n) memory.

Extensive work was done in the 1990s and early 2000s on region inference for the strict functional language ML. Mads Tofte, Lars Birkedal, Martin Elsman, Niels Hallenberg have written a quite readable <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.160">retrospective</a> on their work on region inference, much of which they integrated into the <a href="http://www.itu.dk/research/mlkit/index.php/Main_Page">MLKit compiler</a>. They experimented with purely region-based memory management (i.e. no garbage collector) as well as hybrid region-based/garbage-collected memory management, and reported that their test programs ran "between 10 times faster and 4 times slower" than pure garbage-collected versions.

blocks|key|1210969|text|让我们举一个微不足道的例子。鉴于此|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1210970|f+(x,+y)|code-block|syntax|javascript|1210971|在调用(x,+y)之前，您需要在某个地方分配对f。你什么时候能把那对换掉？你什么都不了解。当f返回时，它不能被释放，因为f可能把这对放在数据结构中(例如，f+p+=+[p])，所以这对的生存期可能比从f返回的要长。现在，假设这对被放到了一个列表中，谁能把这张清单拆开，就能找到这对吗？不，因为这对可能是共享的(例如，let+p+=+(x,+y)+in+(f+p,+p))。所以很难判断这对什么时候可以脱手。|offset|length|style|CODE|1210972|哈斯克尔几乎所有的拨款都是如此。也就是说，有可能进行分析(区域分析)，给出一个生命周期的上限。这在严格的语言中工作得相当好，但在惰性语言中就不那么有效了(在实现中，懒惰语言往往比严格语言做更多的变异)。|1210973|所以我想把问题转过来。你为什么认为Haskell不需要GC。您建议如何进行内存分配？|1210974|entityMap^0|0|0|3|6|N|1|1A|1|1O|1|25|9|2S|1|4E|Q|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]|$I|11|J|12|K|L]|$I|13|J|14|K|L]|$I|15|J|16|K|L]|$I|17|J|18|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|R|$]]

Let's take a trivial example. Given this

<pre><code>f (x, y)
</code></pre>

you need to allocate the pair <code>(x, y)</code> somewhere before calling <code>f</code>. When can you deallocate that pair? You have no idea. It cannot be deallocated when <code>f</code> returns, because <code>f</code> might have put the pair in a data structure (e.g, <code>f p = [p]</code>), so the lifetime of the pair might have to be longer than return from <code>f</code>. Now, say that the pair was put in a list, can whoever takes the list apart deallocate the pair? No, because the pair might be shared (e.g., <code>let p = (x, y) in (f p, p)</code>). So it's really difficult to tell when the pair can be deallocated.

The same holds for almost all allocations in Haskell. That said, it's possible have an analysis (region analysis) that gives an upper bound on the lifetime. This works reasonably well in strict languages, but less so in lazy languages (lazy languages tend to do a lot more mutation than strict languages in the implementation).

So I'd like to turn the question around. Why do you think Haskell does not need GC. How would you suggest memory allocation to be done?

blocks|key|1241851|text|Haskell是一种非严格的编程语言，但大多数实现都使用按需要调用(懒惰)来实现非严格性。在“按需要调用”中，您只在运行时使用“块”(等待计算，然后覆盖自己，在需要时重用其值的表达式)在运行时对其进行评估。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241852|因此，如果您懒洋洋地使用块实现您的语言，那么您已经将关于对象生存期的所有推理推迟到最后一刻，即运行时。既然你现在对生命一无所知，你唯一能做的就是收集垃圾.|1241853|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Haskell is a non-strict programming language, but most implementations use call-by-need (laziness) to implement non-strictness. In call-by-need you only evaluate stuff when it is reached during runtime using the machinery of "thunks" (expressions that wait to be evaluated and then overwrite themselves, staying visible for their value to be reused when needed).

So, if you implement your language lazily using thunks, you have deferred all reasoning about object lifetimes until the last moment, which is runtime. Since you now know nothing about lifetimes, the only thing you can reasonably do is garbage collect...

blocks|key|2101765|text|你的直觉认为这与纯洁有关，这对它有一定的真实性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2101766|Haskell被认为是纯粹的，部分原因是函数的副作用在类型签名中得到了考虑。因此，如果一个函数具有打印某物的副作用，则必须在其返回类型的某个地方有一个IO。|offset|length|style|CODE|2101767|但是在Haskell中，有一个函数被隐式地使用，它的类型签名没有考虑到某种意义上的副作用。即复制一些数据并返回两个版本的函数。在这种情况下，这可以通过复制内存中的数据来实现，也可以通过增加以后需要偿还的债务来实现。|2101768|它可以设计语言甚至更严格的类型系统(纯粹的“线性”系统)，不允许复制功能。从这样一种语言的程序员的角度来看，Haskell看起来有点不纯。|2101769|事实上，Clean是Haskell的一个亲戚，它具有线性(更严格地说是唯一的)类型，这可以给出一些不允许复制的想法。但清洁仍然允许复制“非唯一”类型。|2101770|在这个领域有很多research，如果你搜索足够多，你会发现纯线性代码的例子，不需要垃圾收集。您将发现各种类型的系统，它们可以向编译器指示可能使用的内存，从而使编译器能够消除某些GC。|2101771|在某种意义上，量子算法也是纯线性的。每个操作都是可逆的，因此不能创建、copied或销毁任何数据。(它们在通常的数学意义上也是线性的。)|2101772|与Forth+(或其他基于堆栈的语言)进行比较也很有趣，这些语言具有显式的DUP操作，可以清楚地说明何时发生重复。|2101773|另一种(更抽象)的思考方法是注意到，Haskell是由基于笛卡儿闭范畴理论的简单类型lambda微积分构成的，这类范畴带有对角函数diag+::+X+->+(X,+X)。一种基于另一种类别的语言可能没有这样的东西。|2101774|但是一般来说，单纯的线性规划太难使用，所以我们满足于GC。|2101775|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Clean_%2528programming_language%2529|1|http://home.pipeline.com/~hbaker1/|2|http://en.wikipedia.org/wiki/No-cloning_theorem^0|0|23|2|0|0|0|4|5|0|0|8|8|1|0|Z|6|2|0|0|1T|J|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1D|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@$D|1G|E|1H|1|1I]]|A|$]]|$1|N|3|O|5|6|7|1J|8|@]|9|@$D|1K|E|1L|1|1M]]|A|$]]|$1|P|3|Q|5|6|7|1N|8|@]|9|@$D|1O|E|1P|1|1Q]]|A|$]]|$1|R|3|S|5|6|7|1R|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1S|8|@$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1V|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|14]]|15|$5|10|11|12|A|$13|16]]|17|$5|10|11|12|A|$13|18]]]]

Your intuition that this has something to do with purity has some truth to it.

Haskell is considered pure partly because side effects of functions are accounted for in the type signature. So if a function has the side effect of printing something, there must be an <code>IO</code> somewhere in its return type.

But there is a function that is used implicitly everywhere in Haskell and whose type signature doesn't account for, what is in some sense, a side effect. Namely the function that copies some data and gives you two versions back. Under the hood this can work either literally, by duplicating the data in memory, or 'virtually' by increasing a debt that needs to be paid back later.

It's possible to design languages with even more restrictive type systems (purely "linear" ones) that disallow the copy function. From the point of view of a programmer in such a language, Haskell looks a little impure.

In fact, <a href="http://en.wikipedia.org/wiki/Clean_%28programming_language%29">Clean</a>, a relative of Haskell, has linear (more strictly: unique) types, and that can give some idea of what it would be like to disallow copying. But Clean still allows copying for "non-unique" types.

There is lots of <a href="http://home.pipeline.com/~hbaker1/">research</a> in this area and if you Google enough you'll find examples of pure linear code that requires no garbage collection. You'll find all kinds of type systems that can signal to the compiler what memory might be used allowing the compiler to eliminate some of the GC.

There is a sense in which quantum algorithms are also purely linear. Every operation is reversible and so no data can be created, <a href="http://en.wikipedia.org/wiki/No-cloning_theorem">copied</a>, or destroyed. (They're also linear in the usual mathematical sense.)

It's also interesting to compare with Forth (or other stack based languages) which have explicit DUP operations that make clear when duplication is happening.

Another (more abstract) way of thinking about this is to note that Haskell is built up from simply typed lambda calculus which is based on the theory of cartesian closed categories and that such categories come equipped with a diagonal function <code>diag :: X -&gt; (X, X)</code>. A language based on another class of category might have no such thing.

But in general, purely linear programming is too difficult to be useful, so we settle for GC.

blocks|key|1211214|text|GC是纯FP语言中的“必须拥有”。为什么？行动分配和免费是不纯的！第二个原因是，不可变的递归数据结构需要GC的存在，因为反向链接为人类头脑创建了深奥和不可维护的结构。当然，反向链接是好事，因为复制使用它的结构非常便宜。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1211215|无论如何，如果你不相信我，只要尝试实现FP语言，你就会发现我是对的。|1211216|编辑:我忘了。懒惰是地狱，没有GC。不相信我？只需在不使用GC的情况下尝试它，例如，C%2B%2B。你会看到..。事物|1211217|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

GC is "must have" in pure FP languages. Why? Operations alloc and free are impure! And the second reason is, that immutable recursive data structures needs GC for existence because backlinking creates abstruse and unmaintainable structures for human mind. Of course, backlinking is blessing, because copying of structures which uses it is very cheap.

Anyway, If you don't believe me, just try to implement FP language and you will see that I'am right.

EDIT: I forgot. Laziness is HELL without GC. Don't believe me? Just try it without GC in, for example, C++. You will see ... things

I'm curious as to why Haskell implementations use a GC.

I can't think of a case where GC would be necessary in a pure language. Is it just an optimization to reduce copying, or is it actually necessary?

I'm looking for example code that would leak if a GC wasn't present.

Does Haskell require a garbage collector?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我很好奇为什么Haskell实现会使用GC。我想不出GC在纯语言中是必要的。这仅仅是一种减少复制的优化，还是实际上是必要的？我正在寻找如果不存在GC就会泄漏的示例代码.

问Haskell需要垃圾收集器吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Haskell需要垃圾收集器吗？EN