I remember doing some work on the “floating of constant lists” question.
First, [1..n] turns into (enumFromTo 1 n), and if enumFromTo was expensive,
then sharing it might be a good plan. So GHC would have to know that it was
cheap.
I did experiment with “cheapBuild” see
Oh, now I understand. In
loop g = sum . map g $ [1..100]
GHC can share [1..10] across all calls to loop, although that nixes fusion.
Because each call of loop may have a different g.
But in
loop' = sum . map (+1) $ [1..100]
GHC can share (sum . map (+1) $ [1..1000]) across
I've just pushed a bunch of Core-to-Core optimisation changes that have been
sitting in my tree for ages. The aggregate effect on nofib is very modest, but
they are mostly aimed at corner cases, and consolidation.
Program SizeAllocs Runtime Elapsed TotalMem
Now that the landmines have hopefully been cleared from the AST via [1] I
would like to propose changing the location information in the AST.
Right now the locations of syntactic markers such as do/let/where/in/of in
the source are discarded from the AST, although they are retained in the
rich
Actually the CONLIKE thing still allows them to float, but makes RULES continue
to work even though they’ve been floated. See the user manual.
From: Dan Doel [mailto:dan.d...@gmail.com]
Sent: 28 August 2014 16:48
To: Simon Peyton Jones
Cc: John Lato; David Feuer; ghc-devs
Subject: Re: Why
In general I’m fine with this direction of travel. Some specifics:
·You’d have to be careful to document, for every data constructor in
HsSyn, what the association between the [SrcSpan] in the SrcSpanInfo and the
“sub-entities”
·Many of the sub-entities will have their own
Phab that I may have committed something that makes haddock fail to build
(will teach me, again, to do a completely clean validate!)
I'll look into this . Sorry
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
Speaking of CONLIKE, I'd have expected (.) to be CONLIKE, since it looks
much like a constructor. Would that be bad for some reason? Or is it
already treated well enough not to need that?
On Aug 28, 2014 11:56 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Actually the CONLIKE thing still
I've pushed a temporary fix
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton
Jones
Sent: 28 August 2014 17:35
To: ghc-devs
Subject: Haddock build fails
Phab that I may have committed something that makes haddock fail to build
(will teach me, again, to do a
For what it's worth, my thought is not to use SrcSpanInfo (which, to me, is the
wrong way to slice the abstraction) but instead to add SrcSpan fields to the
relevant nodes. For example:
| HsDoSrcSpan -- of the word do
BlockSrcSpans
This does have the advantage of being explicit. I modelled the initial
proposal on HSE as a proven solution, and I think that they were trying to
keep it non-invasive, to allow both an annotated and non-annoted AST.
I thiink the key question is whether it is acceptable to sprinkle this kind
of
Hi list,
you might know that was I talked into^W^Wvolunteered to holding the
“Contributing to GHC”¹ talk at HIW in 9 days. I’ll do it, but for some
of the intended topics, I don’t feel like the best person to do it on my
own.
In particular, I was wondering if any of the active Phabricator
I have started capturing the discussion here
https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations.
On Thu, Aug 28, 2014 at 8:34 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
This does have the advantage of being explicit. I modelled the initial
proposal on HSE as a proven solution,
I thiink the key question is whether it is acceptable to sprinkle this kind of
information throughout the AST. For someone interested in source-to-source
conversions (like me) this is great, others may find it intrusive.
It’s probably not too bad if you use record syntax; thus
| HsDo {
Maybe. But to use on the LHS of a rule (which would be the motivation, I
assume) you’d also need to make sure it was not inlined in phase 2.
Perhaps do-able, but you’d need some compelling examples to motivate
Simon
From: David Feuer [mailto:david.fe...@gmail.com]
Sent: 28 August 2014 17:51
Devs,
I have built an UNREGISTERISED GHC, and the C-compiler used behind the
scenes is clang. Now I get literally millions of warnings of the below
kind:
+/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhmgq/T/ghc11601_0/ghc11601_4.hc:688:1:
+ warning: attribute declaration must precede
On Thu, Aug 28, 2014 at 8:00 AM, simonpj wrote
I've just pushed a bunch of Core-to-Core optimisation changes that have been
sitting in my tree for ages. The aggregate effect on nofib is very modest,
but they are mostly aimed at corner cases, and consolidation.
Thanks for trying to do
On Fri, 29 Aug 2014 02:56:01 +0200
Gabor Greif ggr...@gmail.com wrote:
Devs,
I have built an UNREGISTERISED GHC, and the C-compiler used behind the
scenes is clang. Now I get literally millions of warnings of the below
kind:
18 matches
Mail list logo
