On 6 December 2012 10:05, Max Bolingbroke wrote:
> I've tested this by hand and it seems like it works: the absolute
> paths you hack into the import library are not messed with by the
> later link step. The resulting executables run flawlessly. Job done.
To continue spamming the
On 6 December 2012 09:27, Max Bolingbroke wrote:
> I'm not sure how to convince GNU ld to link us such a DLL, though. It
> might be possible to hack it in by linking against
> "verylongdummydllname.dll" and then having GHC search for that string
> in DLL/EXE returned
On 27 November 2012 17:00, Ian Lynagh wrote:
> We would love for Windows to be one of the platforms, but currently we
> can't do it on Windows. So unless that changes, Windows will not be one
> of the platforms, correct.
So if I understand correctly, the problem here arises because you
can't impo
On 10 November 2011 14:35, Simon Marlow wrote:
> Agreed.
Committed.
>> I'm wondering if we should also have hSetLocaleEncoding,
>> hSetFileSystemEncoding :: TextEncoding -> IO () and change
>> localeEncoding, fileSystemEncoding :: IO TextEncoding.
>> hSetFileSystemEncoding in particular would l
On 9 November 2011 16:29, Simon Marlow wrote:
> Ok, so since we need something like
>
> makePrintable :: FilePath -> String
>
> arguably we might as well make that do the locale decoding. That's
> certainly a good point...
You could, but getArgs :: IO [String], not :: IO [FilePath]. And
locale-
On 10 November 2011 00:17, Ian Lynagh wrote:
> On Wed, Nov 09, 2011 at 03:58:47PM +0000, Max Bolingbroke wrote:
>>
>> (Note that the above outlined problems are problems in the current
>> implementation too
>
> Then the proposal seems to me to be strictly better than
On 9 November 2011 11:02, Simon Marlow wrote:
> The performance overhead of all this worries me. withCString has taken a
> huge performance hit, and I think there are people who wnat to know that
> there aren't several complex encoding/decoding passes between their Haskell
> code and the POSIX AP
On 9 November 2011 13:11, Ian Lynagh wrote:
> If we aren't going to guarantee that the encoded string is unicode, then
> is there any benefit to encoding it in the first place?
(I think you mean decoded here - my understanding is that decode ::
ByteString -> String, encode :: String -> ByteString
On 7 November 2011 17:32, John Millikin wrote:
> I am also not convinced that it is possible to correctly implement
> either of these functions if their behavior is dependent on the user's
> locale.
FWIW it's only dependent on the users locale because whether glibc
iconv detects errors in the *fr
On 8 November 2011 11:43, Simon Marlow wrote:
> Don't you mean 1 is what we have?
Yes, sorry!
> Failing to roundtrip in some cases, and doing so silently, seems highly
> suboptimal to me. I'm sorry I didn't pick up on this at the time (Unicode
> is a swamp :).
I *can* change the implementation
On 6 November 2011 04:14, John Millikin wrote:
> For what it's worth, on my Ubuntu system, Nautilus ignores the locale
> and just treats all paths as either UTF8 or invalid.
> To me, this seems like the most reasonable option; the concept of
> "locale encoding" is entirely vestigal, and should onl
On 2 November 2011 21:46, Ganesh Sittampalam wrote:
> The workaround you propose seems a little complex and it might be a bit
> problematic that 100% roundtripping can't be guaranteed even once your
> fix is applied.
I can understand this perspective, although the roundtripping as
implemented wil
On 2 November 2011 20:16, Ian Lynagh wrote:
> Are you saying there's a bug that should be fixed?
You can choose between two options:
1. Failing to roundtrip some strings (in our case, those containing
the 0xEFNN byte sequences)
2. Having GHC's decoding functions return strings including
codepo
On 2 November 2011 19:13, Ian Lynagh wrote:
> [snip some stuff I didn't understand. I think I made the mistake of
> entering a Unicode discussion]
Sorry, perhaps that was too opaque! The problem is that if we commit
to support occurrences of the private-use codepoint 0xEF80 then what
happens if w
On 2 November 2011 16:29, Ian Lynagh wrote:
> If I understand correctly, you use U+EF00-U+EFFF to encode the
> characters 0-255 when they are not a valid part of the UTF8 stream.
Yes.
> So why not encode U+EF00 (which in UTF8 is 0xEE 0xBC 0x80) as
> U+EFEE U+EFBC U+EF80, and so on? Doesn't it th
On 2 November 2011 17:15, John Millikin wrote:
> What package does this patch -- "unix", "directory", something else?
The "base" package. The problem lay in the implementation of
GHC.IO.Encoding.fileSystemEncoding on non-Windows OSes.
> Maybe I'm misunderstanding, but it sounds like you're still
On 2 November 2011 13:53, Max Bolingbroke wrote:
> I think the only way to fix this last case in general is to fix iconv
> itself, so I'm going to see if I can get a patch upstream. Fixing it
> for people with UTF-8 locales should be enough for 99% of users,
> though.
One la
On 2 November 2011 09:37, Max Bolingbroke wrote:
> On 1 November 2011 20:13, John Millikin wrote:
>> $ ghci-7.2.1
>> GHC> import System.Directory
>> GHC> getDirectoryContents "path-test"
>> ["\161\165","\61345\61349",".."
On 2 November 2011 10:03, Jean-Marie Gaillourdet wrote:
> As far as I know, not all encodings are reversable. I.e. there are byte
> sequences which are invalid utf-8. Therefore, decoding and re-encoding might
> not return the exact same byte sequence.
The PEP 383 mechanism explicitly recognises
On 1 November 2011 20:13, John Millikin wrote:
> $ ghci-7.2.1
> GHC> import System.Directory
> GHC> getDirectoryContents "path-test"
> ["\161\165","\61345\61349","..","."]
> GHC> readFile "path-test/\161\165"
> "world\n"
> GHC> readFile "path-test/\61345\61349"
> *** Exception: path-test/: openF
Hi John,
On 1 November 2011 17:14, John Millikin wrote:
> GHC 7.2 assumes Linux/BSD paths are text, which 1) silently breaks all
> existing code and 2) makes it impossible to fix within the given API.
Please can you give an example of code that is broken with the new
behaviour? The PEP 383 mecha
Hi Ganesh,
On 1 November 2011 07:16, Ganesh Sittampalam wrote:
> Can anyone point me at the rationale and details of the change and/or
> suggest workarounds?
This is my implementation of Python's PEP 383 [1] for Haskell.
IMHO this behaviour is much closer to what users expect.For example,
getDi
On 20 October 2011 19:51, bob zhang wrote:
> That would be great.
> Would you mind send me a patch, or commit it to the source tree.
I've made this change in commit
5ff06e90f56b7da00f4fec74358b2e736133c263. Hope that helps.
Max
___
Glasgow-haskell-use
On 18 October 2011 13:49, bob zhang wrote:
> In my contrived example the definition of class C is like this
> class C c where { foo :: c Int => }
> class C B => B a where { ...}
> will this pass under your proposal?
Yes I would allow this to pass.
If this would be eno
On 18 October 2011 02:25, bob zhang wrote:
> take a contrived example,
> class C B => B a where
> here B :: * -> Constraint, I think this definition is reasonable,
> since B does not appears in the
> first position of the context.
I think you are getting an error where GHC co
On 27 August 2011 09:00, Evan Laforge wrote:
> Right, that's probably the one I mentioned. And I think he was trying
> to parallelize ghc internally, so even compiling one file could
> parallelize. That would be cool and all, but seems like a lot of work
> compared to just parallelizing at the f
On 26 August 2011 09:22, Simon Peyton-Jones wrote:
> The underlying issue is that before type checking GHC (obviously) doesn't
> know the types of things, while afterwards it does. The whole HsSyn tree is
> parameterised over the types of identifiers:
>
> Parsed: HsExpr RdrNames
> Renam
On 23 August 2011 10:27, Johan Tibell wrote:
> but I don't know if I can get enough parallelism out of GHC's build to
> use all 4 cores in the 15" model.
You can. On my Mac Pro I build with -j12 and regularly see all 8 cores
pegged at 100%.
Max
___
Gl
On 21 August 2011 19:20, Edward Z. Yang wrote:
> And no sooner do I send this email do I realize we have 'inline' built-in,
> so I can probably experiment with this right now...
You may be interested in my related ticket #5029:
http://hackage.haskell.org/trac/ghc/ticket/5059
I don't think this i
On 21 August 2011 21:03, Alexey Khudyakov wrote:
> I don't completely understant how does it work. Does client need to enable
> language extension to get default instances?
I think that the extension would only be required to *define them*,
not for them to be generated. The more conservative choi
On 14 June 2011 14:28, Simon Peyton-Jones wrote:
> I must say I'm inclined to adopt this idea. Any comments from others?
This is something I suggested at the time you submitted "let should
not be generalised". I'm in favour of it, and from personal experience
believe that this will reduce the nu
On 6 April 2011 12:04, Edward Z. Yang wrote:
> The ill fated commit I made yesterday was a partial attempt to
> address some of the problems: basically, it boils down to DEBUG
> blocks that induce extra debugging output that the test framework
> doesn't know about.
You didn't used to get so many
On 26 March 2011 21:02, Henning Thielemann wrote:
> to the mentioned module, but GHC rejects this, because the profiler options
> are not allowed in the OPTIONS pragma. According to
According to
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/flag-reference.html
-prof is static but -auto-
On 20 March 2011 19:01, wren ng thornton wrote:
> Are these
> warnings I should be concerned about?
No.
These warnings just tell you explicitly that SpecConstr has exceeded
the limit of specialisations that GHC is happy to generate. They are
totally harmless and just mean that the output code is
On 31 January 2011 16:54, Simon Marlow wrote:
> On 31/01/2011 16:45, Claus Reinke wrote:
Is there any way to have a "moderate first comment by new submitter"
policy for trac, to avoid the kind of ticket spam we have at the moment?
They seem to have started commenting on ex
On 10 March 2011 17:51, Christian Maeder wrote:
> Why does the base package depend on iconv only on macs? iconv is not
> needed under linux or solaris (unless you install haskeline, which is
> not in the platform.
I don't have access to a Linux box to check, but according to the
source code iconv
On 21 February 2011 11:50, Christian Maeder wrote:
> The problem (below) is caused by the new flags
> -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
> inside hsc2hs that have been added to fix
> http://hackage.haskell.org/trac/ghc/ticket/4860.
>
> ./configure for the network p
On 18 February 2011 01:18, Johan Tibell wrote:
> C compilers, like gcc, go to great lengths making memcpy fast and I
> was thinking that we might be able to steal a trick or two from them.
> I'd like some feedback on these ideas:
It seems like a sufficient solution for your needs would be for us
On 4 February 2011 05:03, Michael Snoyman wrote:
> My guess (a complete guess) is that the deliterate step is creating a
> temporary .hs file elsewhere on your filesystem, which is why the CPP
> step can't find B.hs without a fully-qualified path.
That is what is happening (you can confirm with "
On 25 January 2011 09:35, Lars Viklund wrote:
> A subtree seems to be a way of getting the
> contents of a branch merged at a non-root location. It might be a
> relevant read and something to evaluate.
There is also the git-subtree project
(https://github.com/apenwarr/git-subtree). They explain t
On 24 January 2011 17:20, Jane Ren wrote:
> When I try this, I get
> "AstWalker: panic! (the 'impossible' happened)
> (GHC version 7.0.1 for x86_64-apple-darwin):
> lexical error at character 'i'
It looks like you need to add the CPP extension to the DynFlags:
setSessionDynFlags dflags
On 23 January 2011 00:31, austin seipp wrote:
> or what the current state of dynamic linking on
> windows is.
AFAIK it is meant to work. What I'm not sure about is whether any of
the plugins code will have to be modified to make use of it. I suspect
it won't since IIRC I went through the GHCi sym
On 21 January 2011 23:59, austin seipp wrote:
> Perhaps Max can
> elaborate on why this design was rejected in favor of the current one,
> so we can see how and where it falls down, and what we really want.
The only reason really is that it added a lot of mechanism. From the
top of my head:
* Pa
On 20 January 2011 16:57, austin seipp wrote:
> It would be nice to have this in GHC 7.2, but I was thinking of
> eventually extending the scope of compiler plugins to allow users to
> write Cmm optimisations as well.
This would be particularly cool because Cmm optimisations in the new
Hoopl fram
On 20 January 2011 02:47, John Meacham wrote:
> Allowing this was a specific feature that was included in ghc on
> purpose (as well as the relaxed if/then layout rule in do statements)
> So this is definitely a regression.
Ian split this out in this patch:
http://darcs.haskell.org/cgi-bin/darcswe
On 18 January 2011 22:18, Johan Tibell wrote:
> Why is the size in bytes?
I think the docs are wrong. The code for newArray# (in PrimOps.cmm)
interprets n as a size in words:
{{{
stg_newArrayzh
{
W_ words, n, init, arr, p, size;
/* Args: R1 = words, R2 = initialisation value */
n =
On 12 January 2011 22:13, Claus Reinke wrote:
>> You can emulate darcs's patch re-ordering in git if you put each
>> independent sequence of patches on a separate branch. Then you can
>> re-merge the branches in whatever order you want. This is a fairly
>> common git workflow.
>
> What happens aft
On 10 January 2011 11:19, Simon Marlow wrote:
> Let us know what you think - would this make life
> harder or easier for you? Would it make you less likely or more likely to
> contribute?
Well, as a sometime-contributor I would certainly be happier hacking
on GHC if it were git based. When worki
On 8 December 2010 08:28, Magicloud Magiclouds
wrote:
> I am using debian 32bit system, llvm 2.6.
I haven't seen your particular error before, but AFAIK -fllvm won't
work with LLVM < 2.7 because it depends on the GHC calling convention
that is only present from that release onwards. Try upgradin
On 7 December 2010 08:54, John Smith wrote:
> Gold in an incremental and multi-threaded linker, but can only output ELF
> (not Windows). Is there a cross-platform solution suitable for GHC?
Not AFAIK. One thing that would probably help a lot is if
GHC-generated code stopped causing the linker to
Hi,
On 6 December 2010 01:57, Iavor Diatchki wrote:
> I am doing some work on a GHC branch and I am having a lot of troubles
> (and spending a lot of time) trying to keep my branch up to date with HEAD,
> so I would be very grateful for any suggestions by fellow developers of how
> I might improv
On 9 November 2010 07:58, Duncan Coutts wrote:
> This proposal is mentioned favourably by Jörgen Gustavsson David Sands
> in [1] (see section 6, case study 6). They mention that there is a
> formalisation in Gustavsson's thesis [2]. That may say something about
> inlining, since that's just the ki
On 6 November 2010 04:47, David Peixotto wrote:
>> Are you sure about R1 aliasing Sp? AFAIK, R1 points to a closure on the
>> heap, not to a stack location. That is, it can alias pointers on the stack
>> or Hp but it can't alias the Sp itself. I don't think Sp can be aliased by
>> anything outs
On 2 November 2010 21:05, David Sankel wrote:
> Is there a ghc "wontfix" bug ticket for this? Perhaps we can make a small C
> test case and send it to the Microsoft people. Some[1] are reporting success
> with Unicode console output.
I confirmed that I can output Chinese unicode from Haskell. You
HI Antoine,
I didn't know UHC already had this - thanks for the pointer! It seems
they have read about implicit configurations too, as the example they
use is very similar to the paper.
In fact, they also have another extension to the concept that I was
intentionally avoiding mentioning - they en
Hi GHC users,
Now that the Glorious New type checker can handle local evidence
seamlessly, is it a big implementation burden to extend it to deal
with local *type class instances* in addition to local *equality
constraints*?
For example, you could write this:
"""
f :: Bool
f = id < id
where
On 7 October 2010 12:04, Sebastiaan Visser wrote:
> What exactly are the benefits of Monad comprehensions over, for example, the
> do-notation or idioms?
List comprehensions are just a specialisation of the do-notation for lists.
Monad comprehensions are a generalisation for arbitrary monads of
On 5 October 2010 15:41, George Giorgidze wrote:
> One can also look at how recently introduced 'order by' and 'group by'
> constructs generalise to monad comprehensions. If that works, one could
> implement even more "stylish" monad comprehension notation.
They do: see the comments by MichaelAda
On 13 August 2010 00:13, John Lask wrote:
> I have wondered and perhaps someone can explain: what are the issues in
> explicit control of instance export and import? (apart from defining an
> appropriate syntax)
IMHO main problem with this (and related feature requests like local
instance definit
On 12 August 2010 20:31, Johan Tibell wrote:
> Yes and dead code elimination should also be able to get rid of much of the
> code duplication even before it reaches the linker.
I don't think dead code elimination will help, because presumably you
want to generate specialisations on demand. This m
On 12 August 2010 12:28, Johan Tibell wrote:
> As I understand it the generated code is not exported from the translation
> unit so there are no collisions at link time. We could do the same if we
> could force the generated type class instance to not be exported from the
> module.
Minor point: I
On 28 July 2010 13:57, Sebastian Fischer wrote:
> In my case, I don't want to put everything in a single module because I
> cannot know what other B-like modules people will implement.Are they bound
> to use `f` unspecialized for their types?
Yes. GHC might inline "f" into the call site and achie
On 8 June 2010 22:03, Axel Simon wrote:
> The offsets that hsc2hs calculates are too large, so it is probably in
> x86_64 mode.
Is it just this problem: http://hackage.haskell.org/trac/ghc/ticket/3400
If you use an older GHC you will need to manually patch the hsc2hs
script to pass the right com
On 26 April 2010 13:42, Simon Marlow wrote:
> comments welcome!
This is great news. However, I had some problems:
1) darcs-all does not add --lazy by default, which contradicts the wiki:
"""
$ ./darcs-all --testsuite get
warning: adding --partial, to override use --complete
warning: . already
The flag -fext-core is a red herring. GHC assumes any module with no
"module" declaration is actually called Main and hence insists on a
main declaration.
mbolingbr...@perihelion ~/tmp
$ ghc -c Hal.hs
Hal.hs:1:0: The function `main' is not defined in module `Main'
"""
Compile this instead:
On 11 April 2010 22:11, Johannes Waldmann wrote:
> Louis Wasserman gmail.com> writes:
>
>> I compiled my code with -fdicts-strict.
>
> What is this actually supposed to do? It seems the documentation is missing:
> http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html#optio
On 7 April 2010 00:23, Louis Wasserman wrote:
> biggest sources of angst!) Looking at ghc-core, my code appears to
> always give the exception "Oops! Entered absent arg ww_s9eC{v} [lid]
> main:Data.Algebra.Ring.Ring{tc r2tU} c{tv a8Os} [tv]"
> Is this typical? Where should I send this?
This is
On 12 March 2010 13:13, Roman Beslik wrote:
> Thanks for the answer. Sorry, I can not follow all of your thoughts because
> my knowledge of strictness analysis and GHC optimizations are very basic. :(
> I looked into GHC code once several years ago. BTW there are a lot of papers
> about strictness
On 11 March 2010 12:50, Roman Beslik wrote:
> I also can force the analyzer to think that "x1" and "x0" are strict by
> eta-expanding "f3":
There seem to be two issues here.
1) GHC only figures out and records strictness information on lambdas
that are syntactically together. I'm not sure how ha
Hi Tyson,
This blog post
(http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/)
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_LIBRAR
On 3 February 2010 14:07, Sebastian Fischer wrote:
> With a class-based approach only one parser that creates values of the same
> type could be used in a program. It would not be possible to embed multiple
> languages that create TH.Exp to be spliced into a single program. With the
> current synt
2010/2/2 Twan van Laarhoven :
> class Quoted a where
> parseQuote :: String -> a
> -- for performance reasons:
> parseQuote' :: Ghc.PackedString -> a
Great idea!
Thinking about it, you can use type classes to dispose of the
QuasiQuote record entirely. Instead, have:
class
2010/2/2 Isaac Dupree :
> I'm concerned in both your proposals, that single-letter names like "t" and
> "d" are common function parameters, thus possibly producing
> - shadowing warnings for all such functions in modules that happen to use TH
> - errors, I think, for some uses of TH inside such fun
(Sorry if you see this twice, Simon - I didn't reply to the list)
2010/2/2 Simon Marlow :
> Can you say precisely what it means to be "in an Exp context"?
In a Type context == a HsSpliceTy constructor in the existing GHC AST
In an Exp context == a HsSpliceE constructor in the existing GHC AST
In
Dominic Orchard and I have come up with a rather radical proposal for
a redesign of the syntax. There are two principal options:
OPTION 1 (preferred)
===
Advantages:
1) QuasiQuotes are revealed as they really are - as splices. In my
opinion this is much less confusing, because a "quas
2010/1/28 José Pedro Magalhães :
> Yes, that helped quite a lot. One last thing: currently it takes me about 6
> minutes to rebuild the compiler after I change the core pass. Are there any
> tricks of the build system I can use to speed this up? I'm already using a
> fast build without optimization
2010/1/27 José Pedro Magalhães :
> 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?
I recommend you look at compiler/simplCore/CSE.lhs. It
Hi José,
The patch implementing GHC plugins is with Simon PJ and awaiting merge
into GHC (and has been for some time - he's a busy guy and its a big
patch). However, even once it's merged some more work will need to be
done to make sure that it plays nicely with the shared library support
(now tha
Hi Tyson,
I don't think this is a bug.
> type family F a b :: * -> * -- F's arity is 2,
> -- although its overall kind is * -> * -> * -> *
> F Char [Int] -- OK! Kind: * -> *
Char :: *
[Int] :: *
So we can "fill" in the first two * in the kind * -> * -> * ->
2009/11/3 Daniel Fischer :
> Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller:
>> Hi,
>>
>> Compiling
>>
>> > class WithT a where
>> > type T a
>> >
>> > f :: T a -> a -> T a
>> > f = undefined
>> >
>> > g x = f x 42
>>
>> with -XTypeFamilies -fwarn-missing-signatures gives:
>>
>>
(Moving to ghc-users)
I'd never seen V in nm output before:
"""
The symbol is a weak object. When a weak defined symbol is linked
with a normal defined symbol, the normal defined symbol is used with
no error. When a weak undefined symbol is linked and the symbol is
not defined, the value of the
Hi,
I agree this is annoying. It was hard to find syntax which was both
meaningful and currently unused, so we settled on this instead. As
Simon says, suggestions are welcome!
Note that group *should* be parsed as a special id, so you can still
import D.L qualified and then use dot notation to ac
2009/6/3 Niklas Broberg :
> First there's the constructor called TransformListComp, which should
> really be named GeneralizedListComp, since the constructor should
> describe the extension and not the implementation scheme.
It's called TransformListComp because the "then f" syntax transforms a
li
2009/5/20 Claus Reinke :
> Work is underway to make library-specified optimizations
> more expressive (as core2core pass plugins), though I don't know the status
> of either that (Max?-)
I submitted a final version of the plugins patch to Simon some time
ago - it's waiting for him to find some ti
2009/5/20 Tyson Whitehead :
> 1- avoid forming the (iter xs) and (count i+1) closures by passing the
> function and the arguments instead of the function bound to the argument
>
> iter [] next i done = done
> iter (x:xs) next i done = next i x iter xs
You have already specialised at this poi
2009/4/28 Scott Michel :
> This got me to thinking that either ghc has issues or I have some
> fundamental misunderstanding of Haskell syntax. Or, maybe I should use
> someone else's grammar.
GHC's parser is over-generous by design. See
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/
2009/4/1 Colin Paul Adams :
> Between 6.8 and 6.11, function doCorePass in module SimplCore has changed
> types from:
>
> CoreToDo -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount,
> ModGuts)
>
> to:
>
> CorePass (== CoreToDo) -> ModGuts -> CoreM ModGuts
The file to look at is C
2009/3/27 Simon Marlow :
> I have a fix for num012 (the test is broken), but I still don't know what's
> going on with num009.
num009 has been broken on OS X for as long as I can remember :-). I
opened a ticket about it on Trac way back:
http://hackage.haskell.org/trac/ghc/ticket/2370 (not that th
2009/3/26 Jason Dusek :
> I was reading the stream fusion code today and came across a comment stating
> that single element dictionaries interacted poorly with GHC's optimizer:
>
> class Unlifted a where
>
> [...]
> expose [...]
>
> -- | This makes GHC's optimiser happier; it s
2009/3/24 Colin Adams :
> UI.hs:625:45: Not in scope: type constructor or class `Move.Move'
>
> If I then comment-out the type signature for run_ai, it compiles fine
> with the following warning message:
>
> UI.hs:626:0:
> Warning: Definition but no type signature for `run_ai'
> Infe
2009/3/23 Claus Reinke :
> I just noticed that GHC (6.11.20090320) seems to compile both
>
> f (a:b:c) =
> f (a:[]) = f [] =
> and
> f [] = f (a:[]) = f (a:b:c) =
>
> to something like (looking at Core, but writing source)
>
> f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}}
2009/3/22 Colin Paul Adams :
>>>>>> "Max" == Max Bolingbroke writes:
>
> Max> It moved to MkCore
>
> Thanks.
>
> What about mkWildId from Id.lhs? That one seems to have vanished.
Looks that might be the same deal (moved to MkCore), assumin
It moved to MkCore:
mkIfThenElse :: CoreExpr -> CoreExpr -> CoreExpr -> CoreExpr
mkIfThenElse guard then_expr else_expr
-- Not going to be refining, so okay to take the type of the "then" clause
= mkWildCase guard boolTy (exprType then_expr)
[ (DataAlt falseDataCon, [], else_expr),
2009/3/19 Claus Reinke :
> Recursion unfolding spec, 2nd attempt.
>
>
>
> If this is an improvement on the first version, and after correcting any
> obvious issues, I should put it on the ghc trac wiki somewhere, and create a
> feature request ticket.
I can't see any issues with this version
2009/3/19 Claus Reinke :
> If the map, filter, fold, etc can be unrolled, then the unrolled
> definitions would be fused, right? So what is missing is fine
> control ("how much to unroll this particular call to map here").
The issues is that In stream fusion the combinators like "map" are all
non-
2009/3/9 Claus Reinke :
But if you annotate all your unrolled and peeled new definitions as
> NOINLINE, do you still get the optimizations you want? There are probably a
> few GHC optimizations that can "look through" non-recursive
> lets, but RULES are not among those.
The benefit that comes imm
2009/3/9 Claus Reinke :
>>> let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}..
>
>> Probably what you intend here is that you create one copy of the
>> definition every round rather than one per call site, is that right?
>
> I don't think so - ultimately, the point of both peeling and un
2009/3/9 Roman Leshchinskiy :
> The problem here is that this only works for directly recursive functions
> which I, for instance, don't normally use in high-performance code. Most of
> my loops are pipelines of collective combinators like map, filter, fold etc.
> because these are the ones that ca
2009/3/7 Claus Reinke :
> hmm, "appropriate" is one of those words that shouldn't occur in specs,
> not even rough ones, so let's flesh this out a bit, by abstract example.
>
> let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}..
Probably what you intend here is that you create one copy o
2009/3/1 Claus Reinke :
> What is the issue with concatMap?
ConcatMap doesn't usually fuse under stream fusion - see
http://www.cse.unsw.edu.au/~dons/papers/stream-fusion.pdf for the gory
details.
> It sounds like your specialization
> is based on the recursion equivalent to loop peeling (unrolli
1 - 100 of 123 matches
Mail list logo
