On Thu, Jun 28, 2012 at 10:47 AM, Simon Peyton-Jones
wrote:
> | > Has maintainer's not being responsive been a problem for GHC in the
> | > past?
> |
> | Yes. Some of the upstreams respond so fast that it makes my head spin,
> | while others often either don't respond or continually promise to
Hi Ian,
On Thu, Jun 28, 2012 at 6:26 AM, Ian Lynagh wrote:
> You didn't give a clear answer to my question. Am I right in thinking
> that your answer would be "Yes, the GHC release should be delayed
> indefinitely"?
I did answer it, just not with a "yes" or "no" as it's a false
dichotomy. I gave
| > Has maintainer's not being responsive been a problem for GHC in the
| > past?
|
| Yes. Some of the upstreams respond so fast that it makes my head spin,
| while others often either don't respond or continually promise to get to
| things soon. (again, these are good, well-meaning people,
I'm using StableNames to recover sharing in abstract syntax trees of
an embedded DSL, and I'm kind of following the approach of accelerate
[1]. I was expecting the stable name comparison to be slightly more
reliable. I'm pondering the alternatives.
Many thanks for the replies.
Facundo
[1] http://
Hi Johan,
On Wed, Jun 27, 2012 at 03:06:39PM -0700, Johan Tibell wrote:
>
> On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh wrote:
> > If a GHC release needs an unreleased change in one of the libraries, and
> > the maintainer (for whatever reason) is not responding to e-mails,
> > should the GHC
Dear Simon, et al,
Thank you very much for your reply. Some of the pointers you gave, I wouldn't
have come across, for not knowing to have to browse through the module Inst,
for example.
I read the OutsideIn paper (JFP), but that's a fair while back. I was pointed
to Thijs's work in progress a
You are, in effect, doing pointer equality here, which is certain to be
fragile, ESPECIALLY if you are not optimising the code (as is the case in
GHCi). I'd be inclined to seek a more robust way to solve whatever problem you
started with
Simon
| -Original Message-
| From: glasgow-ha
Philip
| What I'm looking for is a function
|
| fitsInto :: TermType -> HoleType -> Maybe [(TyVar,Type)]
Happily there is such a function, but you will need to become quite familiar
with GHC's type inference engine.
We need to tighten up the specification first. I believe that you have
fu
