Suppose I want a foldl which is evaluated many times on the same
list but with different folding functions.
I would write something like this, to perform pattern-matching on the
list only once:
module F where
myFoldl :: [a] - (b - a - b) - b - b
myFoldl [] = \f a - a
myFoldl
Combining lambdas makes a big difference in GHC. For example
f = \x. let y = E in \z. BODY
The function f takes one argument, and returns a heap-allocated lambda. If E
is cheap (say just a constructor) it might well be more efficient to transform
to
f = \xz. let y = E in BODY
| I will work on building a smaller complete test case that reproduces the
| issue, and I could have done a better job of at least pointing out the
| relevant code for you. Sorry about that.
I'm afraid I still can't guess what's happening. It'd be really helpful if you
could build a smaller
I like both George's proposals.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of George Giorgidze
| Sent: 30 September 2011 18:28
| To: glasgow-haskell-users@haskell.org
| Subject: Two
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that with a modification,
it can not only be improved, but also solve
the problems with the current OverloadedStrings
Hi,
Am Donnerstag, den 29.09.2011, 11:39 +0100 schrieb Simon Marlow:
I’m not sure if I got your conclusion: Do you expect problems if the RTS
and libraries were built against different versions of libffi, or not?
To answer your question: yes I would expect problems.
Thanks for your
George Giorgidze wrote:
This extension could also be used for giving data-parallel array literals
instead of the special syntax used currently.
Unfortunately, it couldn't. DPH array literals don't (and can't really) go
through lists.
In general, if we are going to overload list literals then
Roman Leshchinskiy wrote:
In general, if we are going to overload list literals then forcing the
desugaring to always go through lists seems wrong to me. There are plenty
of data structures where that might result in a significant performance
hit.
These are literals. So the lists will almost
Just anecdotally I remember we had this problem with Accelerate.
Back when we were using it last Spring for some reason we were forced by the
API to at least nominally go through lists on our way to the GPU -- which we
sorely hoped were deforested! At times (and somewhat unpredictably), we'd
be
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale g...@sefer.org wrote:
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that with a modification,
it can not only be
2011/10/4 Gábor Lehel illiss...@gmail.com:
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale g...@sefer.org wrote:
George Giorgidze wrote:
My second proposal is to introduce the
OverloadedLists extension that overloads
list literals...
I am opposed to this proposal as stated.
But I think that
On Fri, Sep 30, 2011 at 7:28 PM, George Giorgidze giorgi...@gmail.com wrote:
GHC Users,
I would like to make to the following two proposals:
* Eliminate the default grouping close from SQL-like comprehensions
* Introduce a GHC extension for list literal overloading
OK, let me start with
Yitzchak Gale wrote:
Roman Leshchinskiy wrote:
In general, if we are going to overload list literals then forcing the
desugaring to always go through lists seems wrong to me. There are
plenty
of data structures where that might result in a significant performance
hit.
These are literals.
Here's a test case: the complete source code is in the following. I
compile it with:
ghc -package ghc --make Test.hs
The GHC version is
cdsmith@godel:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.1
Then run the application several times in a row.
This may have something to do with timestamps on the files. I cannot
reproduce the error with
$ while ./T; do sleep 1; done
...
However, I *am* able to reproduce the error with
$ while ./T ; do sleep 0.9; done
Just 42
Just 42
Just 42
Just 42
Just 42
T: mkTopLevEnv: not
Here's a version with fewer flags/features, that acts the same.
I tried removing the loading of an external module, and that did *not*
exhibit the problem. It also does *not* fail when the file name is
different each time, so the fact that it's the same file, A.hs, each
time is somehow part of
Thanks everyone for the help!
I'm working now on reproducing this with HEAD, and if I do, I'll write a
ticket. On the other hand, it only seems to be an issue when one is
recompiling a file within one second of the first attempt, and Felipe's
workaround of deleting the .hi and .o files fixes it
17 matches
Mail list logo
