On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson wrote:
> Once you have that bit set up, you can copy *most* of the libraries
> .so's you're using to that folder on the install target and they'll be
> loaded from there. (Copying libc.so is ill advised, but most of the
> others will work just fine.
On Tue, 12 May 2020 at 17:30, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:
> From your list of examples I deduce that the proposal is about programming
> errors. But we have HasCallStack for that one. How does the proposal
> improve or alter the HasCallStack solution? And how does
I used to fight with a combination of system and cabal installed packages
under debian testing.
Then, about a year ago, the frustration became too much and I switched to
using nix, intero in emacs, and stack with the nix resolver, all installed
with nix on my debian machine. Couldn't be happier.
On 14/05/16 02:31 PM, Harendra Kumar wrote:
The difference seems to be entirely due to memory pressure. At list size 1000
both pure version and IO version perform equally. But as the size of the list
increases the pure version scales linearly while the IO version degrades
exponentially. Here
I came across something that seems a bit strange to me. Here is a simplified
version (the original was trying to move from a lens ReifiedFold to a
lens-action ReifiedMonadicFold)
{-# LANGUAGE RankNTypes #-}
import Control.Applicative
newtype Wrap = Wrap { extract :: forall f. Functor f =
On February 10, 2015 17:44:54 Dan Doel wrote:
Really, I think the least ad-hoc solution (other than a hypothetical
best-of-both-worlds inference algorithm) would be to allow code like:
runST do ...
where you can apply expressions directly to certain syntactic constructs
without an
On February 10, 2015 16:28:56 Dan Doel wrote:
Impredicativity, with regard to type theories, generally refers to types
being able to quantify over the collection of types that they are then a
part of. So, the judgment:
(forall (a :: *). a - a) :: *
is impredicative, because we have a
On January 11, 2013 13:55:58 Simon Peyton-Jones wrote:
| The -XOverlappingInstances flag instructs GHC to allow more than one
| instance to match, provided there is a most specific one. For example,
| the constraint C Int [Int] matches instances (A), (C) and (D), but the
| last is more
On January 10, 2013 13:56:02 Richard Eisenberg wrote:
Class instances that overlap are chosen among by order of specificity;
Sorry to jump in the middle here, but this caught my attention as this sort of
specificity determination is exactly what I had in mind when I was working on
my The shape
On Thu, 2013-01-10 at 22:17 +, Simon Peyton-Jones wrote:
Is
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap
insufficiently clear? If so, let's clarify it.
Thanks for getting back to me Simon. The document says
For example, consider
On November 28, 2012 04:45:57 Joachim Breitner wrote:
Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead:
I was so excited for a bit thinking that this would finally mean that
Debian would move to a dynamic system. Every haskell binary being 10s
of MBs (e.g., pandoc = 25MB
On November 27, 2012 22:02:33 Jens Petersen wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
I am very happy to hear this news.
I have long been a quiet proponent
On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote:
Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be
On July 11, 2012 04:51:50 Christian Maeder wrote:
Is it not enough to store floats into memory just before equality tests
(or add rounding in the instance definitions of Float and Double in Eq
and Ord)?
You have to be 100% consistent in how you do every operations in all cases
otherwise
On July 10, 2012 09:28:27 Christian Maeder wrote:
Am 10.07.2012 13:06, schrieb Sönke Hahn:
I've attached the code. The code does not make direct use of
unsafePerformIO. It uses QuickCheck, but I don't think, this is a
QuickCheck bug. The used Eq-instance is the one for Float.
The
On July 10, 2012 10:39:41 Colin Adams wrote:
Sure they would be better modelled that way, but the whole point of using
floating point arithmetic is to sacrifice accuracy for performance, is it
not?
True. I just find it interesting that some types have a builtin Nothing value.
Some further
It seems my suggestion isn't getting too much traction.
It occurs to me this may be because I jumped right into layout rules and
didn't first give some simple motivating examples to get the idea across.
SHORT VERSION:
Assume '\' is a grouping construct. I proposed always interpreting
...
On July 7, 2012 00:08:26 Tyson Whitehead wrote:
The very limited scope of this (i.e., it would only apply to lines that end
with a grouping construct where the next line is indented further than that
line) should also address Simon's concerns regarding things like
f x y = x + y
On July 6, 2012 05:25:15 Simon Marlow wrote:
Why not just let enclosed scopes be less indented than their outer ones?
Let me be entirely clear about what I was thinking about. The third case for
the layout mapping in Section 9.3 of the report is
L ({n}:ts) (m:ms) = { : (L ts
On July 6, 2012 11:49:23 Tyson Whitehead wrote:
Currently it depends on the depth of this new level of indentation relative
to all the groupings started on that line. I think most people would
expect it to just apply to the last grouping though. That is
where { f x = do {
stmt1
stmt2
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
After 21 months of occasional arguing the lambda-case proposal(s) is in
danger of being buried under its own trac ticket comments. We need fresh
blood to finally reach an agreement on the syntax. Read the wiki
page[1], take a look at the
On June 18, 2012 04:20:51 John Lato wrote:
Given this, can anyone suggest any likely causes of this issue, or
anything I might want to look for? Also, should I be concerned about
the much larger gc_alloc_block_sync level for the slow run? Does that
indicate the allocator waiting to alloc a
On April 25, 2012 04:15:41 Yitzchak Gale wrote:
The only reason I don't like using OverloadedStrings
for typing string literals as Text and ByteString
is that when you turn on OverloadedStrings, you turn
it on for all types, not just Text and ByteString.
I don't want to be forced to do that.
On April 25, 2012 12:20:16 Johan Tibell wrote:
On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead twhiteh...@gmail.com
wrote:
Is there a technical reason this couldn't be done? The Haskell report
only says doing this is not part of haskell. It doesn't say why.
I think the problem
On March 28, 2012 04:41:16 Simon Marlow wrote:
Sure. Do you have a NUMA machine to test on?
My understanding is non-NUMA machines went away when the AMD and Intel moved
away from frontside buses (FSB) and integrated the memory controllers on die.
Intel is more recent to this game. I believe
On March 28, 2012 12:40:02 Sajith T S wrote:
Tyson Whitehead twhiteh...@gmail.com wrote:
Intel is more recent to this game. I believe AMD's last non-NUMA
machines where the Athalon XP series and Intel's the Core 2 series.
An easy way to see what you've got is to see what 'numactl
On March 9, 2012 06:44:33 John Meacham wrote:
A weakness of jhc right now is its stop the world garbage collector,
so far, I have been mitigating it by not creating garbage whenever
possible, I do an escape analysis and allocate values on the stack
when possible, and recognize linear uses of
On January 19, 2012 05:14:30 Malcolm Wallace wrote:
I find it completely unreasonable for a reply to a very long post to quote
the entire text, only to add a single line at the bottom (or worse,
embedded in the middle somewhere).
+1
___
On January 11, 2012 08:41:04 Simon Marlow wrote:
On 10/01/2012 16:18, Dan Doel wrote:
Does the difference have to do with unboxed types? For instance:
foo :: () - Int#
foo _ = foo ()
bar :: () - (# Int# #)
bar _ = (# foo () #)
baz = case bar () of _ - 5
On January 8, 2012 23:49:47 wren ng thornton wrote:
An alternative is to distinguish, say, (# x #) and its spaceful
constructor (# #) from the spaceless (##); and analogously for the boxed
tuples, though that introduces confusion about parentheses for boxing vs
parentheses for grouping.
I
On December 23, 2011 09:37:04 Ganesh Sittampalam wrote:
On 23/12/2011 13:46, Ian Lynagh wrote:
On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote:
Arguments Boxed Unboxed
3 ( , , )(# , , #)
2 ( , ) (# , #)
1
0 () (#
On April 27, 2011 23:01:50 Denys Rtveliashvili wrote:
Question 1: what is the meaning of those magic numbers
-9223372036854775808, -6677706553, -7418931981405, -8257271295304186?
Question 2: under which circumstances those strange branches of
execution will be used and what those results would
On February 19, 2011 12:11:13 Edward Z. Yang wrote:
I was thinking it might be useful if we had a per-thread circular buffer in
memory for which we pushed a pointer to the info table we had just entered.
In the event of a crash, you could dump the contents of the buffer to see
what code had
On February 17, 2011 20:18:11 Johan Tibell wrote:
* Can we use SSE instructions?
* Can we get the C memcpy code inlined into the C-- source (crazy, I
know). If so we could perhaps benefit directly from optimizations in
libc.
From the standpoint of numerical code, it would be very nice to
On January 21, 2011 14:01:36 Ryan Ingram wrote:
Interesting little paper, Tyson.
Hi Ryan,
Thanks for comments and kind words.
I think what a programmer actually wants from ambiguity resolution is
something *predictable*; C++'s system is definitely stretching the
boundaries of
On January 19, 2011 15:28:33 Conor McBride wrote:
In each case, the former has (++) acting on lists of strings as pure
values,
while the latter has (++) acting on strings as values given in
[]-computations.
The type [String] determines a domain, it does not decompose uniquely
to a
notion
On November 18, 2010 05:12:11 Simon Marlow wrote:
On 17/11/2010 14:34, Christian Maeder wrote:
ghc can be built without and with libffi.
Which build option are you referring to here? libffi is required for
FFI support in GHCi, and for FFI wrapper imports. However on x86 and
x86_64 we
On November 17, 2010 09:34:02 Christian Maeder wrote:
ghc can be built without and with libffi. What advantage do I gain in
the latter case? The packages that come with ghc (displayed by ghc-pkg
dump) don't use it.
I can't find this right now, but, from when I last looked through the code, I
On November 4, 2010 13:38:12 Simon Peyton-Jones wrote:
From: Gideon Yuval (Gideon Yuval)
Sent: Wednesday, November 03, 2010 7:15 AM
To: Simon Peyton-Jones; Burton Smith
Cc: Tolga Acar
Subject: RE: Random number generation
As long as the key, and the non-counting part of the counter, are
On May 3, 2010 08:04:14 Johan Tibell wrote:
On Mon, May 3, 2010 at 11:12 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
In truth, nested data parallelism has taken longer than we'd hoped to be
ready for abuse :-). We have not lost enthusiasm though -- Manual,
Roman, Gabi, Ben, and I
On April 30, 2010 06:32:55 Duncan Coutts wrote:
In the last few years GHC has gained impressive support for parallel
programming on commodity multi-core systems. In addition to traditional
threads and shared variables, it supports pure parallelism, software
transactional memory (STM), and data
I'm just wondering how exactly are the literate files in the GHC source suppose
to be treated. I would like to read some of the documentation.
The presence of various latex commands such as subsection strongly suggests
they are done in latex. Running pdflatex, however, doesn't work. Nor does
On March 16, 2010 20:01:32 Iavor Diatchki wrote:
Optionally disabling executable heap blocks would be a separate patch.
As far as I know, the only reason that the heap is executable is to
support the adjustor thunks used to implement wrapper imports. The
static_wrapper patch provides a way
On March 16, 2010 09:29:06 Louis Wasserman wrote:
I'd like to request some more feedback on the
proposedhttp://hackage.haskell.org/trac/ghc/ticket/3909implementation
for priority queues in containers. Mostly, I feel like
adding a new module to containers should be contentious, and there
On March 15, 2010 12:48:02 Iavor Diatchki wrote:
I have implemented a small extension to the FFI which allows for
static_wrapper imports. These are a variation on wrapper imports
that do not use run-time code generation. This is important in
security sensitive contexts because it avoids
On March 3, 2010 21:10:56 Daniel Fischer wrote:
Well, GHC takes only the class head into account for instance selection,
and
u - (v - w)
matches both,
a - b -- (a == u, b == v - w)
and
m (c - d)-- (m == ((-) u), c == v, d == w),
... snip ...
are indeed conflicting, so you
Consider what would happen if GHC optionally inserted a morphism on fexps (the
expression at the head of an application) as it currently does with integer
literals and optionally with string literals. A standard function call
f x y
would windup as
morph (morph f x) y
With the following
The following code
{-# LANGUAGE FlexibleInstances, TypeFamilies #-}
import Control.Applicative
class Z t where
type W t
z :: t - W t
instance Z (a - b) where
type W (a - b) = a - b
z = id
instance Z (IO (a - b)) where
type W (IO (a - b)) = IO a - IO b
On March 3, 2010 18:35:26 Daniel Fischer wrote:
Because:
instance Applicative ((-) a) -- Defined in Control.Applicative
so, from the instance Z (a - b), with b == c - d, we have an
instance Z (a - (b - c))
and from instance Z (m (u - v)), we have, with m == ((-) x), an
instance Z (x -
On March 2, 2010 06:17:46 Simon Marlow wrote:
For now I suggest you use setjmp. If you want to suggest an API to tell
the RTS about a longjmp, then perhaps we could implement something, but
I'm not sure what the API would look like, because you don't have a
handle to the in-progress calls.
On February 21, 2010 20:57:25 Don Stewart wrote:
I tried out some of the vector and uvector fusion benchmarks with the
new LLVM backend
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghc
s-new-llvm-codegen/
and got some great results for the tight loops generated
I was working on a shared library that loads up the GHC runtime (via hs_init)
and have been running into a bunch of undefined stg symbols.
A bit of digging and it seems that GHC doesn't embed
- the dependency libHSrts-ghc6.12.1.so, and
- the associated rpath /usr/lib/ghc-6.12.1
into shared
On February 22, 2010 17:00:25 Max Bolingbroke wrote:
Hi Tyson,
This blog post
(/) might help explain the motivation (actually there are a few relevant
posts on the well-typed site).
Essentially, I believe that this is done so that you can vary the RTS
by changing LD_LIBRARY_PATH. I've
I'm writing a perl module that interfaces some haskell code and its a bit of a
pain because both perl and ghc have their own custom build system.
Is there a way to get ghc to give you the gcc/as/ld options (library paths,
include paths, flags, etc) required for the FFI stub files it generates?
On February 2, 2010 19:48:27 Max Bolingbroke wrote:
It's a shame that TH is too widely used to be amenable to refactoring
into this sort of form.
I thought the standard thing to do in this case was to add either a pragma
that gives you the new behaviour or trigger it with an alternative syntax
On February 1, 2010 06:43:40 Simon Marlow wrote:
That's a very old document and is inaccurate in various ways. The
Commentary is more up to date:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts
That's good to know. Thanks for the link. : )
Cheers! -Tyson
signature.asc
I was looking through the code for 6.12.1 and am a bit confused about 11.1.3
in the runtime system documentation docs/rts/rts.tex.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641rep=rep1type=pdf
It says the arguments passing convention to a known combinator differs from
that of
On January 27, 2010 05:44:00 José Pedro Magalhães wrote:
Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843
In any case, for now I am willing to hard-code a new core-to-core pass on
the compiler. Any pointers for where I have to look at?
Just wondering a couple of things
Hi all,
Just wondering if there could be a typo in section 7.7.2.1 of the GHC manual
(type family declarations)
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html
Specifically, it says
type family F a b :: * - * -- F's arity is 2,
--
Hi Max and Niklas,
Thank you both for your answers. I get it now.
I didn't read carefully enough to note that the explicit type on F a b was the
type of F and the type of F (although, in retrospect, this last interpretation
wouldn't have worked as we would have need at least * - * - *).
On November 15, 2009 07:42:46 Goetz Isenmann wrote:
I am still not sure, but the generated code might be ok
001e5565 __hscore_get_errno:
1e5565: 55 push %ebp
1e5566: 89 e5 mov%esp,%ebp
1e5568: 65 a1 00 00 00 00 mov
On November 15, 2009 07:42:46 Goetz Isenmann wrote:
001e5565 __hscore_get_errno:
1e5565: 55 push %ebp
1e5566: 89 e5 mov%esp,%ebp
1e5568: 65 a1 00 00 00 00 mov%gs:0x0,%eax
1e556e: 8b 15 00 00 00 00 mov
On November 9, 2009 12:39:25 Goetz Isenmann wrote:
On Mon, Nov 09, 2009 at 10:44:47AM +, Simon Marlow wrote:
We should get these patches into GHC. Most of them look
straightforward, but I'm slightly suspicious of this:
-STANDARD_OPTS += -DCOMPILING_RTS
+STANDARD_OPTS +=
I have a program that seems to me to be exhibiting strange behaviour.
Basically, it looks like something somewhere is not being updated, and this is
resulting in (very expensive) computation being repeated.
The program in question goes like so. The results from the expensive
calculation are
On May 20, 2009 05:50:54 Claus Reinke wrote:
I'm not at all sure what you're aiming for (the above doesn't compile),
Yeah. The newtype Step a b was required to break the recursive types, and I
dropped it when performing the various transformations, so they don't type
check. Here it is again
Thanks for all the feedback guys,
I already find it pretty amazing how well simple stuff expressed in a higher
level manner compiles down to something decent, and it seems like the future
is only going to get brighter. I can hardly wait... : )
In the meantime, I'll go back to trying to find
On May 19, 2009 22:17:39 Tyson Whitehead wrote:
2- specialize count for step = iter
snip
3- specializing iter for next = count
snip
I changed this just before sending it and managed to goof step two and three
(the specializations). The whole thing, with the correct steps two and three
On April 21, 2009 04:39:40 Simon Marlow wrote:
These ratios match up like physical constants, or at least invariants of
my Haskell implementation. However, the user time is constant on OS X, so
these ratios reflect the actual parallel speedup on OS X. The user time
climbs steadily on
On April 18, 2009 16:46:44 Daniel Peebles wrote:
That looks great! I wonder what about Mac OS leads to such good
performance...
Now if only we could get a nice x86_64-producing GHC for Mac OS too, I
could use all my RAM and the extra registers my Mac Pro gives me :)
I was a bit surprised
On March 25, 2009 21:38:55 Claus Reinke wrote:
If you don't have that kind of control, and generate code as if
there were no hardware-level optimizations, the resulting
mismatch will manifest in hard-to-predict variations in
performance, making it difficult to see how much or why
speed is
On March 23, 2009 19:46:27 Claus Reinke wrote:
My idea was that case branches correspond to conditional jumps
(though the exact correspondence and optimization has been the
subject of countless papers). If I loop through a very long list,
most of the time the test for (:) will succeed,
I think there might be a difference between C/GHC and the Haskell Standard's
idea of the range of the exponential. Specifically, the comment in gcc's
float.h (i.e., where GHC appears to gets its definition from) says
/* Minimum int x such that FLT_RADIX**(x-1) is a normalized float, emin */
On March 1, 2009 17:31:13 Max Bolingbroke wrote:
I am no assembly guru and haven't seen that last form of leaq either,
but I'm going to guess that:
leaq(%rsi,%rsi,4), %rax
Says that rax is rsi * ((1 + 1) * 2 ^ 4) = rsi * 32
leaq0(,%rax,8), %rsi
If I recall
On February 19, 2009 18:20:33 Krasimir Angelov wrote:
Oh. I looked at the primops.txt.pp for something suspicious but I
didn't checked the actual implementation of quot. I thought that quot
calls quotInt# directly. When I use quotInt in the code I can get the
real idiv assembly instruction.
On February 18, 2009 04:29:42 Max Bolingbroke wrote:
The part of the code under the first lambda in digit is as follows (I
didn't keep the original dump, so the uniques have changed here). It's
the second part of the Int overflow bounds check (i.e., y =
(maxBound-x)`div`10), and, indeed,
On February 18, 2009 12:42:02 Tyson Whitehead wrote:
On February 18, 2009 04:29:42 Max Bolingbroke wrote:
Yes - GHC wants to share the work of (maxBound-x)`div`10 between
several partial applications of digit. This is usually a good idea,
but in this case it sucks because it's resulted
(compiled with ghc 6.10 with options -O2 -ddump-simpl)
I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at
the bottom of this email as that is the only place it is ever referenced.
It also seems the extra levels of indirection are defeating the strictness
analyzer on
On February 17, 2009 19:24:44 Max Bolingbroke wrote:
2009/2/17 Tyson Whitehead twhiteh...@gmail.com:
It also seems the extra levels of indirection are defeating the
strictness analyzer on eta_s1CN in a_s1Gv as all code branches either
directly force it or ultimately pass it to digit_s1l3
On February 17, 2009 19:24:44 Max Bolingbroke wrote:
2009/2/17 Tyson Whitehead twhiteh...@gmail.com:
(compiled with ghc 6.10 with options -O2 -ddump-simpl)
That should have been -ddump-stranal instead of -ddump-simpl.
I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core
On February 2, 2009 14:50:10 Reid Barton wrote:
On Mon, Feb 02, 2009 at 06:03:15PM +0100, Josef Svenningsson wrote:
I also needed something like this a while ago so I knocked up a really
simple module and put it on hackage:
On February 2, 2009 11:26:02 Tyson Whitehead wrote:
The STT type above is a version of ST like the ReaderT, StateT, etc. types.
newtype STT s m a = STT ( State# s - m (STTBox s a) )
data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a
runSTT :: (Monad m) = (forall s. STT s m
On Friday 30 January 2009 04:07:19 you wrote:
This is in uvector, right? Then you should probably forward this to the
maintainer, i.e. Don Stewart d...@galois.com.
Done. Thanks for the follow up.
Cheers! -Tyson
signature.asc
Description: This is a digitally signed message part.
I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four,
and two times, respectively, as much memory as actually required. That is,
newMBU n = ST $ \s1# -
case sizeBU n (undefined::e) of {I# len# -
case newByteArray# len# s1# of {(# s2#, marr# #) -
(# s2#,
I've been looking at uvector and had some questions (hopefully this is the
right mailing list for this, if not, sorry, and please direct me properly).
First, is there any design thing deeper than just supporting things like the
unit and pair arrays for layering UArr on top of the underlying
On Thursday 16 October 2008 14:34:01 Don Stewart wrote:
FWIW, I get much nicer code with uvector (which uses type families
to select monomorphic instances of things, and aggressive inlining, to
yield much better code in practice). The DPH arrays library uses
a similar method.
Thanks for the
On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote:
On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
BUT people who care probably UNPACK their strict fields too, which
is even better. The time you can't do that is for sum types
data T = MkT ![Int]
You also can't do it
Consider the following code
data Data = Data { unData :: !Int }
func :: Data - Int
func x = case unData x of
1 - 2
_ - 0
Compiling with GHC 6.8.2 gives the following stg code
Main.func =
\r [x_slg]
case x_slg of tpl_slx {
Main.Data ipv_slj -
On Wednesday 15 October 2008 10:48:26 you wrote:
Strictness does not imply unboxing.
To see why not, think about the fact that unboxing breaks sharing. By
keeping the pointer-indirection in place, we can share even strict
fields between related values.
I believe I realize that. What I was
What do people think about implicit function argument?
That is, named function arguments, possibly tagged with something special like
a tilde, whereby scoped variables of the same name are automatically passed.
The idea is to avoid the pain of a lots of pass through parameters while make
it
On Friday 20 June 2008 21:34:14 Dan Doel wrote:
On Friday 20 June 2008, Max Bolingbroke wrote:
Of course, if you have any suggestions for good heuristics based on
your benchmarking experience then we would like to hear them! There
was some discussion of this in the original ticket,
main = print $ foldl' (+) 0 [1..]
with
foldl' f y xs = foldl' y xs
where foldl' y [] = y
foldl' y (x:xs) = foldl' (f y x) xs
runs indefinitely with very little memory consumption, while
foldl' f y [] = y
foldl' f y (x:xs) = foldl' f (f y x) xs
rapidly consumes all the
91 matches
Mail list logo
