| So the 'where' binding in the following does not get generalized
| because it could not have been written at the top level, correct?
The other way round. 'where' bindings that could have been written at top
level *are* generalised; ones that could not are *not* generalised. See Which
:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Unit unboxed tuples
|
| On 23/12/2011 13:46, Ian Lynagh wrote:
| On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote:
|
| Arguments Boxed Unboxed
| 3 ( , , )(# , , #)
| 2
To: Simon Peyton-Jones
Cc: Bas van Dijk; glasgow-haskell-users@haskell.org
Subject: Re: ConstraintKinds and default associated empty constraints
On Fri, Dec 23, 2011 at 10:17 AM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Right now it seems it is either
?
Volunteers, stand forth!
Simon
From: Greg Weber [mailto:g...@gregweber.info]
Sent: 09 December 2011 19:38
To: Simon Peyton-Jones
Cc: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
Are Records stalled out again? I am perfectly willing to leave the fate
| 2011/12/22 Edward Kmett ekm...@gmail.com:
| The change, however, was a deliberate _break_ with the standard that
| passed through the library review process a few months ago, and is now
| making its way out into the wild.
|
| Is it reasonable to enquire how many standard-compliant
| Am Montag, den 12.12.2011, 15:37 -0500 schrieb wren ng thornton:
| I've noticed that take and filter are good producers (and consumers)
| for list fusion, but takeWhile, drop, and dropWhile are not. Is there
| any reason for this discrepancy?
|
| If not, would I need to go through the
GHCi does this somehow, so it's definitely possible; Simon M will know.
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of wren ng thornton
| Sent: 06 December 2011 17:49
| To: GHC-users List
|
| Trouble is, what type does this have?
|f x = x {}
|
| Malcolm Wallace wrote:
| f :: a - a
|
| Ian Lynagh wrote:
| That wouldn't help the original poster, as it is incompatible with
| f :: Foo Clean - Foo Dirty
There are several different things going on in this thread.
1.
| To: Malcolm Wallace
| Cc: GHC-users List
| Subject: Re: Why not allow empty record updates?
|
| Simon Peyton-Jones wrote:
| Trouble is, what type does this have?
| f x = x {}
|
| Malcolm Wallace wrote:
| Empty record patterns {} are permitted, even for types
| that are not declared with named
| Trouble is, what type does this have?
|
| f x = x {}
|
| f :: a - a
|
| That wouldn't help the original poster, as it is incompatible with
| f :: Foo Clean - Foo Dirty
Ah! *That* is why I said it was awkward. Thanks Ian.
Simon
___
Serge
I'm afraid I don't really follow your proposal in detail, but I think it may be
a version of the proposal described here
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
Perhaps you could see if the design there would meet your goals.
Simon
| -Original
Trouble is, what type does this have?
f x = x {}
In your example the type annotations give the clue, but Haskell is mainly
designed for type annotations to be optional. We require at least one field so
we can figure out, from the field name, which type is being updated.
Yes,
Wolfgang
Is there a wiki page giving a specific, concrete design for the proposal you
advocate? Something at the level of detail of
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields?
I am unsure whether you regard it as an alternative to the above, or something
that
Wolfgang
Dimitrios, Stephanie and I spent a long time trying to come up with a decent
story for impredicative polymorphism (which would let you use types like
[forlall a. a-a]), wrote several papers about it, and even implemented one
version in GHC (hence -XImpredicativeTypes).
However the
Thanks; fixed
From: sean.leat...@gmail.com [mailto:sean.leat...@gmail.com] On Behalf Of Sean
Leather
Sent: 22 October 2011 16:24
To: GHC Users List
Cc: Simon Peyton-Jones
Subject: :kind broken in HEAD
It seems like :kind is broken in the HEAD ghci:
*Main :kind Maybe
Top level:
Expecting
| Subject: Re: Records in Haskell
|
| I have added my proposal to the wiki.The only downsides to it that I can see
are:
Thanks to Barney for articulating a proposal for records in Haskell. Over
various plane rides and ICFP chats I've worked out some more details. It's not
as simple as I'd
a function exported by
Data.List, and I don't think the benefit justifies the cost.
Simon
From: George Giorgidze [mailto:giorgi...@gmail.com]
Sent: 10 October 2011 23:22
To: Simon Peyton-Jones; GHC Users List; Philip Wadler
Subject: Re: Two Proposals
A quick thought that came to me after hoogling
Paul
Always switch on -dcore-lint; it's a self-checker for types, and usually nails
an error much closer to the source.
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Paul Monday
Sent: 16 October 2011 16:54
To:
Did you try 7.2? As I mentioned, the issue should have gone away entirely
because there is no shared cache any more
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Jean-Marie
Gaillourdet
Sent: 12 October 2011 07:19
To:
Roman, Jan-Willem
I'm maxed out at the moment, and will be so for at least a week.
If you think there is something mysterious and J-W agrees, could you create a
ticket, with the smallest example you can, and instructions to reproduce?
That'd be brilliant.
Of course, Jan-Willem, if you have
Thank you for the detailed investigation. I have not followed all the details
of this thread, but I think that it may (happily) represent a bug in generating
TypeReps that is already fixed.
· We used to have a global cache from which we generated unique Int
keys corresponding to type
Greg
In GHC, big cases are done as tables (if dense) or trees (if sparse). If you
have some examples where things go bad, do submit a bug report.
For big dispatches on strings, I'm pretty sure we do something linear, top to
bottom. I'd be strongly inclined to use a proper Map structure if
is not great, but it's the best I could think of.
Improvements welcome.
Simon
| -Original Message-
| From: Philip Wadler [mailto:wad...@inf.ed.ac.uk]
| Sent: 04 October 2011 18:15
| To: Simon Peyton-Jones; George Giorgidze
| Subject: Re: FW: Two Proposals
|
| George,
|
| Nice
| In the spirit of don't let the perfect be the enemy of the good
| though, I'm solidly in favor of the original proposal as it is.
This is my thought too. George is proposing to extend Haskell's existing
mechanism for numeric literals (namely, replace 4 by (fromInteger
(4::Integer))), so
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
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: mkTopLevEnv: not interpreted main:Main
|
| Thanks, Simon.
|
| 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
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
I don't have a good answer here. FWIW
* I believe that the only call to mkTopLevEnv is in
InteractiveEval.findGlobalRdrEnv,
which in turn only calls mkTopLev on imports which are specified by an
IIModule
specification (see HscTypes.InteractiveImport).
* I think that IIModule things should
| With regard to [1], default superclass instances, is there already a plan to
| implement them? And if so, when is it expected to be finished?
|
| [1] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
It definitely won't be in 7.4 I'm afraid.
One thing that would be
Yes, it expands type synonyms too
S
From: sean.leat...@gmail.com [mailto:sean.leat...@gmail.com] On Behalf Of Sean
Leather
Sent: 23 September 2011 13:43
To: Simon Peyton-Jones
Cc: GHC Users List
Subject: Re: Evaluating type expressions in GHCi
Hi Simon,
*TF :kind F Int
F Int :: *
*TF :kind! F
Sean
Yes, this has been asked for before, and it wouldn't be hard to implement.
What should the GHCi command be *called*?
We already have :kind, which displays the kind of a type. Maybe :kind! should
evaluate the type as well? Or perhaps :kind should evaluate anyway (although
that would be
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
| 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 about
have a go!
S
|
| On 16/09/2011 08:21, Simon Peyton-Jones wrote:
| 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
Friends
Provoked the (very constructive) Yesod blog post on Limitations of Haskell,
and the follow up discussion, I've started a wiki page to collect whatever
ideas we have about the name spacing issue for record fields.
http://hackage.haskell.org/trac/ghc/wiki/Records
As
J Garrett Morris asked me
| I also rather like the TDNR proposal, as it's rather similar to the
| approach we're taking in Habit (our pet language at Portland State).
| However, I'm curious as to why you don't want to quantify over name
| resolution constraints. For example, why shouldn't:
|
|
| Yeah. I would expect this to work:
|
| inferBar2 :: Name - Q [Dec]
| inferBar2 typeName =
|[d| instance Bar $(conT typeName) where
| bar _ = sucker
| |]
|
| But I get the same error:
|
| inferBar2 'Bool
|==
| show-test.hs:4:3-18
| instance Bar Bool
Too many words! I'm losing track. What I'm proposing is Option 2 under The
design of the opt-out mechanism on
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
I believe that meets everyone's goals:
* A warning encourages you to fix the client code
* But you can turn it
...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Sebastian Fischer
| Sent: 30 August 2011 03:49
| To: Bas van Dijk
| Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones
| Subject: Re: Superclass defaults
|
| On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk
Feel free to propose better solutions.
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
Renamed: HsExpr Name
| 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 choice would
| indeed be to require the
My guess is that you have not updated compiler/prelude/PrelNames, which
contains wired-in knowledge of which modules certain functions and data types
live in. Check the ones you've moved!
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
| I shouldn't have to modify PrelNames since I kept GHC.Integer.Type,
| no? Or does PrelNames have to contain the name of the module that
| originally defined the type?
Yes, exactly!
Simon
___
Glasgow-haskell-users mailing list
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users
| Subject: Re: Can't find interface-file declaration for type constructor or
class
| integer-gmp:GHC.Integer.Type.Integer
|
| On Thu, Aug 18, 2011 at 7:07 PM, Simon Peyton-Jones
| simo...@microsoft.com wrote:
| | I shouldn't have to modify
It's wrong. Thank you for pointing this out. I'll investigate.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Luite Stegeman
| Sent: 16 August 2011 16:57
| To:
(Adding GHC users, and changing title.)
| Conor McBride wrote:
| http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
| I don't know if it's likely to be implemented in GHC anytime soon,..
| So things are looking up. It should soon be technically feasible to
| separate the
| If someone felt able to act as moderator for the discussion, willing
| to summarise conclusions, open questions, and so on, on the wiki
| page, that would be enormously helpful.
|
| I'm up for that role, if that's appropriate.
I'll take you up on that, thank you! I've added some SLPJ note
No, it's more #5375 and #5307. Email coming
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Sergei Trofimovich
| Sent: 09 August 2011 14:15
| To: Bas van Dijk
| Cc:
In TH code you now need to use mkName at variable uses instead of the names
created directly with newName. Repa had a similar problem.
Eh? I don't understand that. Can you give a small example?
Simon
From: glasgow-haskell-users-boun...@haskell.org
Sigh. See http://hackage.haskell.org/trac/ghc/ticket/5398#comment:1
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Bas van Dijk
| Sent: 09 August 2011 13:47
| To:
| I had a bit of fun recently tracking down quoting issues with the
| system command in Windows. For the examples below, I'll consistently
| use Windows as the beginning of some text sent to the Windows
| command prompt cmd.exe, and use GHC as the beginning of some text
| sent to a ghci session
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to control the desugaring of literals. Why
literals? And why is literals enough?
| But
| So then parseDynamicFlags should be split into two layers, the lower
| layer returning unused flags, and the upper layer generating errors.
|
| It's not that simple. In
| ghcjs -O -someflag something -Wall
| is something an argument to someflag, or a file to be compiled?
It think it
Victor
GHC is supposed to be extensible, via its API, so your questions are good ones.
However, there are things that that the API doesn't support, or supports
badly, so it is not cast in stone. Please suggest improvements -- and better
still implement them. GHC evolves largely in response
Dear Template Haskell users
There was a little exchange about TH quasiquotes a few weeks back (see below).
I've made a ticket and some concrete proposals here
http://hackage.haskell.org/trac/ghc/ticket/5348
Do take a look, if you care about TH quasiquotes.
Simon
| -Original
:07
To: Simon Peyton-Jones
Cc: Gábor Lehel; glasgow-haskell-users@haskell.org
Subject: Re: Superclass Cycle via Associated Type
2011/7/22 Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive superclasses, albeit we have a bit more work to do on the type
inference engine first.
The situation we think we can handle ok is stuff like Edward wants (I've
removed all the methods):
class LeftModule
You point is that the (C Int) dictionary has (C String) as a superclass, and (C
String) has (C Int) as a superclass. So the two instances are mutually
recursive, but that's ok.
That is not unreasonable. But it is dangerous. Consider
class C [a] = C a
Then any dictionary for (C a) would
| iterIO uses mkTyCon for the simple reason that ((Typeable t, Typeable
| m) = Iter t m) is Typeable1 and there is no automatic way of deriving
| Typeable1.
This email is triggered by a thread on Haskell Cafe about changes to the
Typeable class
important to you.
There is a ticket about it: http://hackage.haskell.org/trac/ghc/ticket/4310, so
add yourself to the cc list if you care about it.
Simon
| -Original Message-
| From: Stefan Holdermans [mailto:ste...@vectorfabrics.com]
| Sent: 21 June 2011 10:51
| To: Simon Peyton-Jones; Tom
I believe that's right.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 23 June 2011 11:03
| To: glasgow-haskell-b...@haskell.org
| Cc:
Friends
I have long advertised a plan to allow so-called superclass equalities. I've
just pushed patches to implement them. So now you can write
class (F a ~ b) = C a b where { ... }
This email is just to encourage you to try them out.
Currently this is just in the HEAD git
Friends, this is to ask your opinion about a possible change in GHC 7.2. The
current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for
us, but I think it may be a bit draconian, and therefore propose Plan B as an
alternative. Opinions?
Simon
Following Bryan's suggestion I've improved GHC's error message when there's a
module cycle:
Module imports form a cycle:
module `Foo4' imports `Foo'
which imports `Foo2'
which imports `Foo3'
which imports `Foo4'
Simon
|
?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 14 June 2011 14:04
| To: glasgow-haskell-users; Simon Peyton-Jones
| Subject: Re: MonoLocalBinds and hoopl
|
| I ran into some more code like this, and I realized there was something
| pretty important
-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 09 June 2011 12:06
| To: Simon Peyton-Jones
| Subject: The role of INLINE and INLINABLE on recursive functions
|
| Hi,
|
| This comment on Trac got me curious:
|
| Ok, we looked at this, and it turns out that 6.12.3 desugars `forever
Great, thanks. I've added that link to the user-documentation page for the GHC
API, here
http://haskell.org/haskellwiki/GHC/As_a_library#Links
Please do elaborate that page, which is a bit thin at the moment. It should be
easier to find supporting info about the GHC API.
Simon
|
| tcRnExpr :: HscEnv
| - InteractiveContext
| - LHsExpr RdrName
| - IO (Messages, Maybe Type)
|
| from TcRnDriver?
|
|
| This is pretty close to what I need. Unfortunately, I have
| LhsExpr Id not RdrName.
Just to be clear
LHsExpr RdrNameis just after parsing
Maybe you want
tcRnExpr :: HscEnv
- InteractiveContext
- LHsExpr RdrName
- IO (Messages, Maybe Type)
from TcRnDriver?
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of
Dear haskell.org committee
Great stuff. Thanks for getting this together.
Things I wondered about are:
- who will run the haskell.org entity?
- how are they chosen? do they have fixed terms?
- how are they accountable to the Haskell Community
(eg an a brief
| cmm/CmmLex.x) to understand textual C--. Note that there is also a new C--
| representation hanging around that is not too interesting for you, since we
don't
| use it at all without the flag -fnew-codegen.
Although ultimately we hope to move to the new rep and abandon the old one.
Simon
| To: Simon Peyton-Jones; Daniel Peebles; Thomas Schilling
| Cc: ghc-users
| Subject: Re: parsing types
|
| Dear Simon, Daniel and Thomas,
|
| thanks for your help with this! I managed to get what I
| want by writing something like so:
|
| tcExpr :: FilePath - String - IO Type
| tcExpr f s
It's hard to say much without a particular program to look at. But when type
families or functional dependencies are involved you can certainly get
situations where
f :: ty
but if you write
g ::ty
g = f
the program is rejected. Sounds similar to what you are seeing.
Ranjit
[NB: all of this is based on a quick look at the source code; I'm not that
familiar with the GHC API, so others may correct me.]
A good entry point to the GHC API is InteractiveEval.hs. You'll see that all
its functions are parameterised over a simple state monad (GhcMonad m), which
Can you give an example of what you'd like to write, but can't?
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of José Pedro
Magalhães
Sent: 04 April 2011 10:53
To: GHC users
Cc: Steven Keuchel
Subject: Re: [Haskell]
I don't think anyone has really looked at those SrcSpans before. I'm fixing...
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of JP Moresmau
| Sent: 18 March 2011 13:52
| To:
| class Monoid (GeneratorOf a) = Generable a where
| type GeneratorOf a :: * - *
| construct :: GeneratorOf a - a
|
| Now, it seems I need FlexibleInstances to do this when I'm using an
| associated type synonym, but I don't need the flexibility when using a
| multiparameter type class.
You are doing something very delicate here, akin to overlapping instances.
You have an instance
instance PatchInspect (PrimOf p)) = Conflict p
and a function
clever :: (Conflict (OnPrim p), ..) = ...
So if a constraint (Conflict blah) arises in the RHS of clever,
I think the missing piece was Opt_Cpp. Data.List uses the C preprocessor
S
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
| Behalf Of Ian Lynagh
| Sent: 22 February 2011 15:09
| To: Jane Ren
| Cc: cvs-...@haskell.org;
shouldn't the check go the other way? (i.e., if the RHSs unify, then the LHS
must be the same). Here is an example:
-- This function is not injective.
type instance F a = Int
type instance F b = Int
Yes, you’re right.
Still, Conal's example would not work if we just added support for
Pavel
Concerning Another one, the problem is that with BangPatterns enabled, GHC
understands
vs ! i = ...
to mean
vs (!i) = ...
with a bang-pattern, thus defining vs rather than (!). Reason: the common case
of saying
f !x !y = e
is so convenient that we didn't
Injective type families are a perfectly reasonable idea, but we have not
implemented them (yet). The idea would be:
* You declare the family to be injective
injective type family T a :: *
* At every type instance, injectivity is checked. That is, if you say
type instance T (a,Int) = Either a
Friends
Just a heads-up. Pedro is working on implementing Generic Defaults, as
described in his Haskell Symposium 2010 paper
www.dreixel.net/research/pdf/gdmh_nocolor.pdf
It will replace (and improve on) the Derivable type classes stuff in GHC at
the moment, which was originally presented in
]
Sent: 09 February 2011 12:20
To: Simon Peyton-Jones
Cc: GHC users
Subject: Re: Deriviable type classes
Hi,
2011/2/9 Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com
Friends
Just a heads-up. Pedro is working on implementing Generic Defaults, as
described in his Haskell Symposium
In general it's quite hard to solve this problem without risking losing sharing.
However in this case I added a simple arity analyser after the 7.0.1 release
which solves the problem. It'll be in 7.0.2.
Try with HEAD and check it does what you expect.
Simon
| -Original Message-
|
.
Well that's the intent anyway!
Simon
| -Original Message-
| From: ezyang [mailto:ezy...@mit.edu]
| Sent: 02 February 2011 23:12
| To: Simon Marlow; Simon Peyton-Jones
| Cc: glasgow-haskell-users
| Subject: Re: 4221 on new codegen
|
| Simon Peyton Jones, I have a question about
A panic is always a bug. Thanks for the test case. I've created a ticket
http://hackage.haskell.org/trac/ghc/ticket/4939
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Daniel Gorín
| Sent:
You are misunderstanding what 'undecidable instances' does.
GHC wants to solve the constraint (D Foo beta) where beta is
as-yet-unconstrained type variable. It finds that one instance *matches* (by
instantiating only the instance declaration, not the constraint we are solving):
D a b
that's necesary.)
Simon
-Original Message-
From: Tim Sheard [mailto:she...@cs.pdx.edu]
Sent: 28 January 2011 22:48
To: Simon Peyton-Jones
Subject: Problems with the directory package on windows
Simon,
I have been wrestling with following problem. I cannot get the Directory
package
Right; it's a bug all right. Happily, I committed a major patch two weeks ago,
which cures the bug (I checked). The fix will be in 7.0.2. Meanwhile, if you
can build the HEAD or get a development snapshot, you should be good to do.
Thanks for reporting this
Simon
From:
Thanks, Simon!
Is the patch in the STABLE snapshot now?
pavel
On 26.01.2011, at 13:57, Simon Peyton-Jones wrote:
Right; it's a bug all right. Happily, I committed a major patch two weeks ago,
which cures the bug (I checked). The fix will be in 7.0.2. Meanwhile, if you
can build the HEAD or get
...@ucsd.edu]
| Sent: 24 January 2011 17:20
| To: Simon Peyton-Jones; glasgow-haskell-users@haskell.org
| Subject: RE: Question about Haskell AST
|
| Hi Simon,
|
| That is exactly what I needed. However, although I was able to get the
| patterns from the parse tree for test modules that I wrote, I
| So, again, for this particular extension I suggest that the layout
| rule in the standard(s) should be revised
Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell
Prime pocess. Or if it isn't it could be is if someone proposed it. That's
the process we have in
Austin
| So, given that 7.2 will be released much earlier than the normal
| release cycle, is there any room for anything else to get into HEAD
| for the 7.2 release before everything is switched? In particular I
| fixed up Max Bolingbroke's old compiler plugin work to be usable with
| the latest
| You've convinced me. The benefit from fixing GHC in this case is
| outweighed by the cost, I think we should revert the change (or at least
| enable RelaxedLayout by default), and propose the change for Haskell
| 2011/2012. Ian, Simon, what do you think?
I'm ok with that
desugarModule returns a GHC.DesugaredModule
Inside a DesugaredModule is a field dm_core_module :: HscTypes.ModGuts
Inside a ModGuts is a field mg_binds :: [CoreSyn.CoreBind]
And there are your bindings! Does that tell you what you wanted to know?
Simon
PS: When you have it clear, would you
Yes, I think type families are here to stay.
There is no formal policy about GHC extensions. Generally speaking, I regard
GHC as a laboratory in which to test ideas, which militates in favour of
putting things in so that people can try them. Once in they are hard to take
out again (linear
Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 09 December 2010 15:28
| To: glasgow-haskell-users; Simon Peyton-Jones
| Subject: MonoLocalBinds and hoopl
|
| Hello all,
|
| Here's an experience report for porting hoopl to manage MonoLocalBinds. The
| Compiler.Hoop.XUtil module
| thoroughly exhausted. Even when Darcs was in a far
| less advanced state than it is in now, the conclusion seemed
| to be that the best interests of the Haskell community at
| large are served by remaining with Darcs. So it would be a bit
| strange if this branching issue, which is a serious
| known problem with darcs with no obvious solution. For me, switching
| GHC to git would certainly be a win.
I have personal experience of git, because I co-author papers with git users. I
am not very technologically savvy, but my failure rate with git is close to
100%. Ie I can do the
301 - 400 of 1383 matches
Mail list logo
