On Thu, Sep 15, 2011 at 10:46 PM, Ganesh Sittampalam wrote:
> One benefit of TDNR is to replicate the discoverability of APIs that
> OO programming has - if x :: Foo then typing "x." in an IDE gives you
> a list of things you can do with a Foo. (Obviously it's not a complete
> lis for various reas
The difficulty here is that the TH library, by design, doesn't depend on GHC.
So we can't have a TH function
getFlags :: Q DynFlags
or (as you suggest, more or less)
runTc :: TcM a -> Q a
because to write those type signatures in Language.Haskell.TH.Syntax you'd need
to import GH
| > If you get it to work, I'd appreciate detailed (Windows is so far utterly
| > incomprehensible to me, so they'd better be very explicit) instructions.
| >
|
| I feel your pain. The Windows instructions could definately use some
| updating. :)
|
| I ended up getting an error during stage 2 abo
Would making a template-haskell-ghc package make sense? Might be
overkill just for my requirement but there could be other things like
support for GHC-specific language extensions that might also logically
belong there.
On 16/09/2011 08:21, Simon Peyton-Jones wrote:
> The difficulty here is that t
| Would making a template-haskell-ghc package make sense? Might be
| overkill just for my requirement but there could be other things like
| support for GHC-specific language extensions that might also logically
| belong there.
I don't know -- I don't know what it would look like. By all means ha
On Fri, Sep 16, 2011 at 06:46:35AM +0100, Ganesh Sittampalam wrote:
> On 15/09/2011 15:43, Ian Lynagh wrote:
> > On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
> >>
> > Re TypeDirectedNameResolution, I would actually prefer it if it were
> > less general. i.e. if you were to wr
On 15/09/2011 14:03, Barney Hilken wrote:
As formulated on the wiki page, the "narrow issue" is a problem without a good
solution. The reason the community rejected TDNR is because it's basically polymorphism
done wrong. Since we already have polymorphism done right, why would we want it?
I t
I have added my proposal to the wiki.The only downsides to it that I can see
are:
1. If the types can be resolved at compile time, the compiler needs to optimise
away the dictionaries, otherwise there will be a performance cost. Since this
is always the case for type classes, I assume this is a
On Thu, Sep 15, 2011 at 8:11 AM, Neil Davies
wrote:
> Hi
>
> I have some long running (multi-gigabit, multi-cpu hour) programs and as
> part of trying to speed up I thought I would set the -V0 flag - when I did
> this there was a slow space leak that caused it to blow the heap.
>
> Anyone out ther
>> One benefit of TDNR is to replicate the discoverability of APIs that OO
>> programming has - if x :: Foo then typing "x." in an IDE gives you a
>> list of things you can do with a Foo. (Obviously it's not a complete lis
>> for various reasons, but it does allow the author of Foo and others to
>>
I'm thinking that I want to modify libraries/base/configure.ac to
implement this pseudo-code:
"YES" or --with-iconv-libraries was specified then>:
FP_SEARCH_LIBS_PROTO(iconv, <...>)
That way the GHC binary on Windows doesn't grow a dependency on the
mingw iconv goo that would require followup
After I made this change I got the following results from ghc-HEAD
with the newer mingw and bootstrapping from 7.0.2.
The only worrying failures were the rts/5250 (esp alignment) and the
simplCore/should_compile cases. I'm hoping the simplCore cases should
be related to those Integer changes folks
12 matches
Mail list logo
