Re: [GHC] #5417: GHCi browse gets type families wrong

2011-08-16 Thread GHC 
#5417: GHCi browse gets type families wrong
-+--
Reporter:  simonpj   |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonpj):

 Original email thread here http://www.haskell.org/pipermail/glasgow-
 haskell-users/2011-August/020733.html and http://www.haskell.org/pipermail
 /glasgow-haskell-users/2011-August/020739.html

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5417: GHCi browse gets type families wrong

2011-08-16 Thread GHC 
#5417: GHCi browse gets type families wrong
-+--
Reporter:  simonpj   |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
 Reported by Luite Stegeman
 {{{
 - A.hs
 module A where
   import B

 - B.hs
 {-# LANGUAGE TypeFamilies #-}
 module B where
   import qualified C

   data B1 a = B1 a

   instance C.C1 (B1 a) where
 data C.F (B1 a) = B2 a

   data family D a

 -- C.hs
 {-# LANGUAGE TypeFamilies #-}
 module C where

   class C1 a where
 data F a :: *
 }}}
 Nnw use ghci 7.2.1:
 {{{
 ghci A
 *A> :info F
 data family F a -- Defined at C.hs:6:8

 ghci B
 *B> :browse
 data B1 a = B1 a
 data instance B.R:FB1 (B1 a) = B2 a
 data family D a
 data family F a
-- Why is F displayed here?
-- What is B.R:FB1?

 *B> :info F
 Top level: Not in scope: data constructor `F'

 *B> :info C.F
 data family C.F a   -- Defined at C.hs:6:8
 }}}
 But with ghci 7.0.4:
 {{{
 ghci A
 *A> :info F
 Top level: Not in scope: data constructor `F'
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2965: GHC on OS X does not compile 64-bit

2011-08-16 Thread GHC 
#2965: GHC on OS X does not compile 64-bit
+---
  Reporter:  Axman6 |  Owner:  igloo 
  Type:  feature request| Status:  closed
  Priority:  normal |  Milestone:  7.0.1 
 Component:  Compiler   |Version:
Resolution:  fixed  |   Keywords:  64bit 
  Testcase: |  Blockedby:
Difficulty:  Unknown| Os:  MacOS X   
  Blocking: |   Architecture:  x86_64 (amd64)
   Failure:  Installing GHC failed  |  
+---

Comment(by Syzygies):

 A word of gratitude for this closed thread, and everyone who helped make
 64-bit OS X GHC possible.

 This wasn't simply about memory. Some things have historically been hard
 to install on Mac OS X, typically depending on gtk. The package manager
 Homebrew for OS X builds 64 bit binaries (because that is OS X's native
 tongue) and in my experience, everything that was hard before "just works"
 with Homebrew. In particular, I now for the first time have threadscope up
 on a Mac. Thanks to 64-bit GHC, and its increased compatibility with
 third-party efforts. As word gets out that Homebrew should be the default
 choice for cabal prerequisites, more Mac users will be installing 64-bit
 GHC, whatever their installed memory.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4385: Type-level natural numbers

2011-08-16 Thread GHC 
#4385: Type-level natural numbers
+---
Reporter:  diatchki |Owner:  diatchki
Type:  feature request  |   Status:  new 
Priority:  normal   |Milestone:  7.4.1   
   Component:  Compiler (Type checker)  |  Version:  
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Unknown/Multiple | Blocking:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---
Changes (by acfoltzer):

 * cc: acfoltzer@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5396: rare segfault in a terminal game

2011-08-16 Thread GHC 
#5396: rare segfault in a terminal game
+---
Reporter:  MikolajKonarski  |   Owner:   
Type:  bug  |  Status:  new  
Priority:  normal   |   Component:  libraries/base   
 Version:  7.3  |Keywords:   
Testcase:   |   Blockedby:   
  Os:  Linux|Blocking:   
Architecture:  x86_64 (amd64)   | Failure:  Documentation bug
+---
Changes (by MikolajKonarski):

  * failure:  Runtime crash => Documentation bug
  * component:  Compiler => libraries/base


Comment:

 OK, so I'm now as certain, as a newbie debugging an indeterministic
 segfault can be, about where the bug is. The comment for

 
http://hackage.haskell.org/packages/archive/base/4.4.0.0/doc/html/src/Foreign-C-String.html#withCWStringLen

 is wrong, it should start with

 -- | Marshal a Haskell string into a C wide string

 -- in temporary storage, with explicit length information.

 The rest of the comment is OK and the code agrees with the other comments
 (for the CWStringLen type, etc.). This means the vty code, which seems to
 be based on the wrong comment, is wrong. I've already submitted a pull
 request for vty.

 If the segfault ever returns, I will let you know.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5413: Add population count primop

2011-08-16 Thread GHC 
#5413: Add population count primop
-+--
Reporter:  tibbe |Owner:  simonmar
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by tibbe):

 * cc: johan.tibell@… (added)


Comment:

 Replying to [comment:3 simonmar]:
 > Shouldn't `-msse4.2`  imply `-msse2`?

 Yes and I think it does. Check the helpers in the native code gen.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5413: Add population count primop

2011-08-16 Thread GHC 
#5413: Add population count primop
-+--
Reporter:  tibbe |Owner:  simonmar
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 Shouldn't `-msse4.2`  imply `-msse2`?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5416: Local modules and Template Haskell declaration splices

2011-08-16 Thread GHC 
#5416: Local modules and Template Haskell declaration splices
-+--
Reporter:  simonpj   |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  _|_ 
   Component:  Compiler  |  Version:  7.2.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
 Sometimes you want a Template Haskell splice to expand to a bunch of
 declarations, ''some of which are not visible to the context''.  A trivial
 example might be
 {{{
 module M where
  $(f 4)

 > expands to
 module M where
  helper = ...blah...
  real_fun = ...helper
 }}}
 But `helper` is only a helper function for `real_fun` and should not be
 exported by M, nor should it conflict with other definitions in M.

 See #5398 for a more concrete example, and (at the end) a speculative
 suggestion for "local modules" that might be a good design.

 Another thing you might want is for a splice to expand into some import
 declarations that bring some new stuff into scope.  That too might be
 possible using this design.

 Prioity uncertain, details very uncertain.  I'm just making the ticket to
 keep track of the idea.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5398: Multiple declarations of uniquely generated name

2011-08-16 Thread GHC 
#5398: Multiple declarations of uniquely generated name
---+
  Reporter:  basvandijk|  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  
 Component:  Template Haskell  |Version:  7.0.4   
Resolution:  invalid   |   Keywords:  
  Testcase:|  Blockedby:  
Difficulty:| Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+
Changes (by simonpj):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 We had a discussion at !CamHac which concluded that PLAN B is indeed the
 right one.  A principled reason for this is the identity
 {{{
$[| e |] = e
 }}}
 For this to hold we need that
 {{{
$[| \x -> $(return (VarE (mkName "x"))) |]
 =
\x -> $(return (VarE (mkName "x")))
 }}}
 In the latter, the `(mkName "x")` must clearly bind to the lambda.  And so
 it must do so in the former too.

 Concerning the SYB story, you just have to generate fresh names for the
 top level bindings.  You can do that by name-mangling the type involved
 (which is I believe how you fixed it) -- but it's also possible to write a
 function
 {{{
 mangleName :: Name -> Name
 mangleName name@(Name occ fl)
   = case fl of
   NameU u -> Name (mangle_occ occ u) fl
   _   -> name
   where
 mangle_occ :: OccName -> Int# -> OccName
 mangle_occ occ uniq = mkOccName (occNameString occ ++ "-" ++ show (I#
 uniq))
 }}}
 This will take a `Name` built with `newName` (which generates a `NameU`),
 and incorporate the unique in the string-name of the `Name`.

 It might even be worth adding this to TH's API, but I'll wait to see how
 useful it is first.

 It's also worth noting that what you ''really'' wanted for SYB was a kind
 of anonymous local module.  You really want your splice to expand thus:
 {{{
   $(derive 'T)
 ===>  expands to
   module () where
  constr = ...
  dataType  ...
  instance (..blah..) => Data ctx ByteString where
  ...constr...dataType...
 }}}
 so that the definitions of `constr` and `dataType` are not visible in the
 outer scope.

 But that is another story!  I'll open a ticket for it, and close this as
 invalid.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
-+--
  Reporter:  simonmar|  Owner:  
  Type:  task| Status:  closed  
  Priority:  high|  Milestone:  7.4.1   
 Component:  Compiler (Type checker) |Version:  6.8.2   
Resolution:  fixed   |   Keywords:  
  Testcase:  typecheck/should_compile/T2357  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--

Comment(by MartijnVanSteenbergen):

 Awesome! Will do.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
-+--
  Reporter:  simonmar|  Owner:  
  Type:  task| Status:  closed  
  Priority:  high|  Milestone:  7.4.1   
 Component:  Compiler (Type checker) |Version:  6.8.2   
Resolution:  fixed   |   Keywords:  
  Testcase:  typecheck/should_compile/T2357  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by simonpj):

  * testcase:  typecheck/should_compile/T1897a,
   indexed_types/should_compile/T1897b =>
   typecheck/should_compile/T2357


Comment:

 Works in HEAD!

 Incidentally, always use `-dcore-lint` when you get weird crashes.  It
 often picks up the error earlier.

 If you make other test cases we can add them too.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
---+
  Reporter:  simonmar   
   |  Owner:  
  Type:  task   
   | Status:  closed  
  Priority:  high   
   |  Milestone:  7.4.1   
 Component:  Compiler (Type checker)
   |Version:  6.8.2   
Resolution:  fixed  
   |   Keywords:  
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:  
Difficulty:  Unknown
   | Os:  Unknown/Multiple
  Blocking: 
   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   
   |  
---+

Comment(by MartijnVanSteenbergen):

 It also panicks in 7.2.1. Here are the error messages:

 {{{
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.0.3 for i386-apple-darwin):
 applyTypeToArgs
 f{v ait} [lid] $dShow{v aiz} [lid]
 a{tv aiy} [sk]
 }}}

 {{{
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.2.1 for x86_64-apple-darwin):
 applyTypeToArgs
 f{v ahK} [lid] $dShow{v ahQ} [lid]
 a{tv ahP} [sk]
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
---+
  Reporter:  simonmar   
   |  Owner:  
  Type:  task   
   | Status:  closed  
  Priority:  high   
   |  Milestone:  7.4.1   
 Component:  Compiler (Type checker)
   |Version:  6.8.2   
Resolution:  fixed  
   |   Keywords:  
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:  
Difficulty:  Unknown
   | Os:  Unknown/Multiple
  Blocking: 
   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   
   |  
---+

Comment(by MartijnVanSteenbergen):

 Thank you, that's great news!

 Just yesterday I wrote three programs which used -XNoMonoPatBinds and
 respectively caused the type-checker to hang, to panic and compiled fine
 but (seemed to) have wrong behaviour, using GHC 7.0.3.

 I've made the panic program as small as I could:

 {{{
 {-# LANGUAGE NoMonoPatBinds #-}

 f :: Show a => a
 (f, _) = undefined

 g :: Show a => a
 g = f
 }}}

 Perhaps you can use it as a test case for the new algorithm.

 If I manage to make the other programs smaller too, I'll post them here.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
---+
  Reporter:  simonmar   
   |  Owner:  
  Type:  task   
   | Status:  closed  
  Priority:  high   
   |  Milestone:  7.4.1   
 Component:  Compiler (Type checker)
   |Version:  6.8.2   
Resolution:  fixed  
   |   Keywords:  
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:  
Difficulty:  Unknown
   | Os:  Unknown/Multiple
  Blocking: 
   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   
   |  
---+

Comment(by simonmar):

 Great, thanks Simon!

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4940: Bad error message using poly pat bind with MonoPatBinds

2011-08-16 Thread GHC 
#4940: Bad error message using poly pat bind with MonoPatBinds
+---
  Reporter:  batterseapower |  Owner:   
   
  Type:  feature request| Status:  closed   
   
  Priority:  normal |  Milestone:  7.2.1
   
 Component:  Compiler (Type checker)|Version:  7.0.1
   
Resolution:  fixed  |   Keywords:   
   
  Testcase:  typecheck/should_compile/T5302 |  Blockedby:   
   
Difficulty: | Os:  
Unknown/Multiple
  Blocking: |   Architecture:  
Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
+---
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => typecheck/should_compile/T5302
  * resolution:  => fixed


Comment:

 Fixed by (a) above!  I think you'll be happy.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
---+
  Reporter:  simonmar   
   |  Owner:  
  Type:  task   
   | Status:  closed  
  Priority:  high   
   |  Milestone:  7.4.1   
 Component:  Compiler (Type checker)
   |Version:  6.8.2   
Resolution:  fixed  
   |   Keywords:  
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:  
Difficulty:  Unknown
   | Os:  Unknown/Multiple
  Blocking: 
   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   
   |  
---+

Comment(by simonpj):

 Concerning (c) see http://www.haskell.org/pipermail/glasgow-haskell-
 users/2011-June/020489.html

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5032: putting left equation sides in parantheses causes GHC.Prim.Any specialization

2011-08-16 Thread GHC 
#5032: putting left equation sides in parantheses causes GHC.Prim.Any
specialization
-+--
  Reporter:  jeltsch |  Owner:
  Type:  bug | Status:  closed
  Priority:  normal  |  Milestone:
 Component:  Compiler|Version:  6.12.1
Resolution:  wontfix |   Keywords:
  Testcase:  typecheck/should_compile/T5032  |  Blockedby:
Difficulty:  | Os:  Linux 
  Blocking:  |   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown|  
-+--
Changes (by simonpj):

  * testcase:  => typecheck/should_compile/T5032


Comment:

 I've fixed this as part of (a) above; see #2357.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5032: putting left equation sides in parantheses causes GHC.Prim.Any specialization

2011-08-16 Thread GHC 
#5032: putting left equation sides in parantheses causes GHC.Prim.Any
specialization
---+
  Reporter:  jeltsch   |  Owner:
  Type:  bug   | Status:  closed
  Priority:  normal|  Milestone:
 Component:  Compiler  |Version:  6.12.1
Resolution:  wontfix   |   Keywords:
  Testcase:|  Blockedby:
Difficulty:| Os:  Linux 
  Blocking:|   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown  |  
---+

Comment(by simonpj):

 commit 49dbe60558deee5ea6cd2c7730b7c591d15559c8
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Aug 16 10:23:52 2011 +0100

 Major improvement to pattern bindings

 This patch makes a number of related improvements

 a) Implements the Haskell Prime semantics for pattern bindings
(Trac #2357).  That is, a pattern binding p = e is typed
just as if it had been written
 t = e
 f = case t of p -> f
 g = case t of p -> g
 ... etc ...
where f,g are the variables bound by p. In paricular it's
ok to say
   (f,g) = (\x -> x, \y -> True)
and f and g will get propertly inferred types
   f :: a -> a
   g :: a -> Int

 b) Eliminates the MonoPatBinds flag altogether.  (For the moment
it is deprecated and has no effect.)  Pattern bindings are now
generalised as per (a).  Fixes Trac #2187 and #4940, in the
way the users wanted!

 c) Improves the OutsideIn algorithm generalisation decision.
Given a definition without a type signature (implying "infer
the type"), the published algorithm rule is this:
   - generalise *top-level* functions, and
   - do not generalise *nested* functions
The new rule is
   - generalise a binding whose free variables have
 Guaranteed Closed Types
   - do not generalise other bindings

Generally, a top-level let-bound function has a Guaranteed
Closed Type, and so does a nested function whose free vaiables
are top-level functions, and so on. (However a top-level
function that is bitten by the Monomorphism Restriction does
not have a GCT.)

Example:
  f x = let { foo y = y } in ...
Here 'foo' has no free variables, so it is generalised despite
being nested.

 d) When inferring a type f :: ty for a definition f = e, check that
the compiler would accept f :: ty as a type signature for that
same definition.  The type is rejected precisely when the type
is ambiguous.

Example:
   class Wob a b where
 to :: a -> b
 from :: b -> a

   foo x = [x, to (from x)]
GHC 7.0 would infer the ambiguous type
   foo :: forall a b. Wob a b => b -> [b]
but that type would give an error whenever it is called; and
GHC 7.0 would reject that signature if given by the
programmer.  The new type checker rejects it up front.

Similarly, with the advent of type families, ambiguous types are
easy to write by mistake.  See Trac #1897 and linked tickets for
many examples.  Eg
   type family F a :: *
   f ::: F a -> Int
   f x = 3
This is rejected because (F a ~ F b) does not imply a~b.
 Previously
GHC would *infer* the above type for f, but was unable to check it.
Now even the inferred type is rejected -- correctly.

 The main implemenation mechanism is to generalise the abe_wrap
 field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
 beautiful generalisation turned out to make everything work nicely
 with minimal programming effort.  All the work was fiddling around
 the edges; the core change was easy!

  compiler/deSugar/DsBinds.lhs|   62 +++-
  compiler/deSugar/DsExpr.lhs |6 +-
  compiler/hsSyn/HsBinds.lhs  |   28 +++-
  compiler/hsSyn/HsUtils.lhs  |   32 +++--
  compiler/main/DynFlags.hs   |   13 +-
  compiler/rename/RnBinds.lhs |6 +-
  compiler/typecheck/TcBinds.lhs  |  282
 --
  compiler/typecheck/TcClassDcl.lhs   |   12 +-
  compiler/typecheck/TcEnv.lhs|  117 +--
  compiler/typecheck/TcErrors.lhs |   32 +++--
  compiler/typecheck/TcHsSyn.lhs  |   14 +-
  compiler/typecheck/TcInstDcls.lhs   |   19 ++-
  compiler/typecheck/TcMType.lhs  |6 +-
  compiler/typecheck/TcRnDriver.lhs   |   14 +-
  compiler/typecheck/TcRnMonad.lhs|2 +-
  compiler/typecheck/TcRnTypes.lhs|   11 +-
  compiler/typecheck/TcSimplify.lhs   |   5

Re: [GHC] #2187: Top-level bindings are broken for polymorphic values

2011-08-16 Thread GHC 
#2187: Top-level bindings are broken for polymorphic values
---+
  Reporter:  yallop|  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  6.10 branch 
 Component:  Compiler  |Version:  6.8.2   
Resolution:  wontfix   |   Keywords:  
  Testcase:|  Blockedby:  
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+

Comment(by simonpj):

 OK we're good.  Pattern bindings are now generalised as specified in the
 Haskell Prime spec (see #2357) which is what you originally asked for.
 `-XMonoPatBinds` is dead.  Everyone is happy.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1897: Ambiguous types and rejected type signatures

2011-08-16 Thread GHC 
#1897: Ambiguous types and rejected  type signatures
---+
  Reporter:  guest  
   |  Owner:  chak  
  Type:  bug
   | Status:  closed
  Priority:  low
   |  Milestone:  7.2.1 
 Component:  Compiler (Type checker)
   |Version:  6.9   
Resolution:  fixed  
   |   Keywords:
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:
Difficulty:  Unknown
   | Os:  Linux 
  Blocking:  5296   
   |   Architecture:  x86   
   Failure:  None/Unknown   
   |  
---+
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => typecheck/should_compile/T1897a,
   indexed_types/should_compile/T1897b
  * resolution:  => fixed


Comment:

 Done!  See (d) in the commit message.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
---+
  Reporter:  simonmar   
   |  Owner:  
  Type:  task   
   | Status:  closed  
  Priority:  high   
   |  Milestone:  7.4.1   
 Component:  Compiler (Type checker)
   |Version:  6.8.2   
Resolution:  fixed  
   |   Keywords:  
  Testcase:  typecheck/should_compile/T1897a, 
indexed_types/should_compile/T1897b  |  Blockedby:  
Difficulty:  Unknown
   | Os:  Unknown/Multiple
  Blocking: 
   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown   
   |  
---+
Changes (by simonpj):

  * status:  new => closed
  * testcase:  => typecheck/should_compile/T1897a,
   indexed_types/should_compile/T1897b
  * resolution:  => fixed


Comment:

 Free at last, free at last.  This long standing change is finally done!

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1897: Ambiguous types and rejected type signatures

2011-08-16 Thread GHC 
#1897: Ambiguous types and rejected  type signatures
--+-
  Reporter:  guest|  Owner:  chak 
  Type:  bug  | Status:  new  
  Priority:  low  |  Milestone:  7.2.1
 Component:  Compiler (Type checker)  |Version:  6.9  
Resolution:   |   Keywords:   
  Testcase:   |  Blockedby:   
Difficulty:  Unknown  | Os:  Linux
  Blocking:  5296 |   Architecture:  x86  
   Failure:  None/Unknown |  
--+-

Comment(by simonpj@…):

 commit 49dbe60558deee5ea6cd2c7730b7c591d15559c8
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Aug 16 10:23:52 2011 +0100

 Major improvement to pattern bindings

 This patch makes a number of related improvements

 a) Implements the Haskell Prime semantics for pattern bindings
(Trac #2357).  That is, a pattern binding p = e is typed
just as if it had been written
 t = e
 f = case t of p -> f
 g = case t of p -> g
 ... etc ...
where f,g are the variables bound by p. In paricular it's
ok to say
   (f,g) = (\x -> x, \y -> True)
and f and g will get propertly inferred types
   f :: a -> a
   g :: a -> Int

 b) Eliminates the MonoPatBinds flag altogether.  (For the moment
it is deprecated and has no effect.)  Pattern bindings are now
generalised as per (a).  Fixes Trac #2187 and #4940, in the
way the users wanted!

 c) Improves the OutsideIn algorithm generalisation decision.
Given a definition without a type signature (implying "infer
the type"), the published algorithm rule is this:
   - generalise *top-level* functions, and
   - do not generalise *nested* functions
The new rule is
   - generalise a binding whose free variables have
 Guaranteed Closed Types
   - do not generalise other bindings

Generally, a top-level let-bound function has a Guaranteed
Closed Type, and so does a nested function whose free vaiables
are top-level functions, and so on. (However a top-level
function that is bitten by the Monomorphism Restriction does
not have a GCT.)

Example:
  f x = let { foo y = y } in ...
Here 'foo' has no free variables, so it is generalised despite
being nested.

 d) When inferring a type f :: ty for a definition f = e, check that
the compiler would accept f :: ty as a type signature for that
same definition.  The type is rejected precisely when the type
is ambiguous.

Example:
   class Wob a b where
 to :: a -> b
 from :: b -> a

   foo x = [x, to (from x)]
GHC 7.0 would infer the ambiguous type
   foo :: forall a b. Wob a b => b -> [b]
but that type would give an error whenever it is called; and
GHC 7.0 would reject that signature if given by the
programmer.  The new type checker rejects it up front.

Similarly, with the advent of type families, ambiguous types are
easy to write by mistake.  See Trac #1897 and linked tickets for
many examples.  Eg
   type family F a :: *
   f ::: F a -> Int
   f x = 3
This is rejected because (F a ~ F b) does not imply a~b.
 Previously
GHC would *infer* the above type for f, but was unable to check it.
Now even the inferred type is rejected -- correctly.

 The main implemenation mechanism is to generalise the abe_wrap
 field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
 beautiful generalisation turned out to make everything work nicely
 with minimal programming effort.  All the work was fiddling around
 the edges; the core change was easy!

  compiler/deSugar/DsBinds.lhs|   62 +++-
  compiler/deSugar/DsExpr.lhs |6 +-
  compiler/hsSyn/HsBinds.lhs  |   28 +++-
  compiler/hsSyn/HsUtils.lhs  |   32 +++--
  compiler/main/DynFlags.hs   |   13 +-
  compiler/rename/RnBinds.lhs |6 +-
  compiler/typecheck/TcBinds.lhs  |  282
 --
  compiler/typecheck/TcClassDcl.lhs   |   12 +-
  compiler/typecheck/TcEnv.lhs|  117 +--
  compiler/typecheck/TcErrors.lhs |   32 +++--
  compiler/typecheck/TcHsSyn.lhs  |   14 +-
  compiler/typecheck/TcInstDcls.lhs   |   19 ++-
  compiler/typecheck/TcMType.lhs  |6 +-
  compiler/typecheck/TcRnDriver.lhs   |   14 +-
  compiler/typecheck/TcRnMonad.lhs|2 +-
  compiler/typecheck/TcRnTypes.lhs|   11 +-
  compiler/typecheck/TcSimplify.lhs   |   57 +

Re: [GHC] #4940: Bad error message using poly pat bind with MonoPatBinds

2011-08-16 Thread GHC 
#4940: Bad error message using poly pat bind with MonoPatBinds
+---
  Reporter:  batterseapower |  Owner:   
   
  Type:  feature request| Status:  new  
   
  Priority:  normal |  Milestone:  7.2.1
   
 Component:  Compiler (Type checker)|Version:  7.0.1
   
Resolution: |   Keywords:   
   
  Testcase: |  Blockedby:   
   
Difficulty: | Os:  
Unknown/Multiple
  Blocking: |   Architecture:  
Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
+---

Comment(by simonpj@…):

 commit 49dbe60558deee5ea6cd2c7730b7c591d15559c8
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Aug 16 10:23:52 2011 +0100

 Major improvement to pattern bindings

 This patch makes a number of related improvements

 a) Implements the Haskell Prime semantics for pattern bindings
(Trac #2357).  That is, a pattern binding p = e is typed
just as if it had been written
 t = e
 f = case t of p -> f
 g = case t of p -> g
 ... etc ...
where f,g are the variables bound by p. In paricular it's
ok to say
   (f,g) = (\x -> x, \y -> True)
and f and g will get propertly inferred types
   f :: a -> a
   g :: a -> Int

 b) Eliminates the MonoPatBinds flag altogether.  (For the moment
it is deprecated and has no effect.)  Pattern bindings are now
generalised as per (a).  Fixes Trac #2187 and #4940, in the
way the users wanted!

 c) Improves the OutsideIn algorithm generalisation decision.
Given a definition without a type signature (implying "infer
the type"), the published algorithm rule is this:
   - generalise *top-level* functions, and
   - do not generalise *nested* functions
The new rule is
   - generalise a binding whose free variables have
 Guaranteed Closed Types
   - do not generalise other bindings

Generally, a top-level let-bound function has a Guaranteed
Closed Type, and so does a nested function whose free vaiables
are top-level functions, and so on. (However a top-level
function that is bitten by the Monomorphism Restriction does
not have a GCT.)

Example:
  f x = let { foo y = y } in ...
Here 'foo' has no free variables, so it is generalised despite
being nested.

 d) When inferring a type f :: ty for a definition f = e, check that
the compiler would accept f :: ty as a type signature for that
same definition.  The type is rejected precisely when the type
is ambiguous.

Example:
   class Wob a b where
 to :: a -> b
 from :: b -> a

   foo x = [x, to (from x)]
GHC 7.0 would infer the ambiguous type
   foo :: forall a b. Wob a b => b -> [b]
but that type would give an error whenever it is called; and
GHC 7.0 would reject that signature if given by the
programmer.  The new type checker rejects it up front.

Similarly, with the advent of type families, ambiguous types are
easy to write by mistake.  See Trac #1897 and linked tickets for
many examples.  Eg
   type family F a :: *
   f ::: F a -> Int
   f x = 3
This is rejected because (F a ~ F b) does not imply a~b.
 Previously
GHC would *infer* the above type for f, but was unable to check it.
Now even the inferred type is rejected -- correctly.

 The main implemenation mechanism is to generalise the abe_wrap
 field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
 beautiful generalisation turned out to make everything work nicely
 with minimal programming effort.  All the work was fiddling around
 the edges; the core change was easy!

  compiler/deSugar/DsBinds.lhs|   62 +++-
  compiler/deSugar/DsExpr.lhs |6 +-
  compiler/hsSyn/HsBinds.lhs  |   28 +++-
  compiler/hsSyn/HsUtils.lhs  |   32 +++--
  compiler/main/DynFlags.hs   |   13 +-
  compiler/rename/RnBinds.lhs |6 +-
  compiler/typecheck/TcBinds.lhs  |  282
 --
  compiler/typecheck/TcClassDcl.lhs   |   12 +-
  compiler/typecheck/TcEnv.lhs|  117 +--
  compiler/typecheck/TcErrors.lhs |   32 +++--
  compiler/typecheck/TcHsSyn.lhs  |   14 +-
  compiler/typecheck/TcInstDcls.lhs   |   19 ++-
  compiler/typecheck/TcMType.lhs  |

Re: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings

2011-08-16 Thread GHC 
#2357: Implement the Haskell' proposal for polymorphic pattern bindings
+---
Reporter:  simonmar |Owner:  
Type:  task |   Status:  new 
Priority:  high |Milestone:  7.4.1   
   Component:  Compiler (Type checker)  |  Version:  6.8.2   
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  Unknown 
  Os:  Unknown/Multiple | Blocking:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---

Comment(by simonpj@…):

 commit 49dbe60558deee5ea6cd2c7730b7c591d15559c8
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Aug 16 10:23:52 2011 +0100

 Major improvement to pattern bindings

 This patch makes a number of related improvements

 a) Implements the Haskell Prime semantics for pattern bindings
(Trac #2357).  That is, a pattern binding p = e is typed
just as if it had been written
 t = e
 f = case t of p -> f
 g = case t of p -> g
 ... etc ...
where f,g are the variables bound by p. In paricular it's
ok to say
   (f,g) = (\x -> x, \y -> True)
and f and g will get propertly inferred types
   f :: a -> a
   g :: a -> Int

 b) Eliminates the MonoPatBinds flag altogether.  (For the moment
it is deprecated and has no effect.)  Pattern bindings are now
generalised as per (a).  Fixes Trac #2187 and #4940, in the
way the users wanted!

 c) Improves the OutsideIn algorithm generalisation decision.
Given a definition without a type signature (implying "infer
the type"), the published algorithm rule is this:
   - generalise *top-level* functions, and
   - do not generalise *nested* functions
The new rule is
   - generalise a binding whose free variables have
 Guaranteed Closed Types
   - do not generalise other bindings

Generally, a top-level let-bound function has a Guaranteed
Closed Type, and so does a nested function whose free vaiables
are top-level functions, and so on. (However a top-level
function that is bitten by the Monomorphism Restriction does
not have a GCT.)

Example:
  f x = let { foo y = y } in ...
Here 'foo' has no free variables, so it is generalised despite
being nested.

 d) When inferring a type f :: ty for a definition f = e, check that
the compiler would accept f :: ty as a type signature for that
same definition.  The type is rejected precisely when the type
is ambiguous.

Example:
   class Wob a b where
 to :: a -> b
 from :: b -> a

   foo x = [x, to (from x)]
GHC 7.0 would infer the ambiguous type
   foo :: forall a b. Wob a b => b -> [b]
but that type would give an error whenever it is called; and
GHC 7.0 would reject that signature if given by the
programmer.  The new type checker rejects it up front.

Similarly, with the advent of type families, ambiguous types are
easy to write by mistake.  See Trac #1897 and linked tickets for
many examples.  Eg
   type family F a :: *
   f ::: F a -> Int
   f x = 3
This is rejected because (F a ~ F b) does not imply a~b.
 Previously
GHC would *infer* the above type for f, but was unable to check it.
Now even the inferred type is rejected -- correctly.

 The main implemenation mechanism is to generalise the abe_wrap
 field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
 beautiful generalisation turned out to make everything work nicely
 with minimal programming effort.  All the work was fiddling around
 the edges; the core change was easy!

  compiler/deSugar/DsBinds.lhs|   62 +++-
  compiler/deSugar/DsExpr.lhs |6 +-
  compiler/hsSyn/HsBinds.lhs  |   28 +++-
  compiler/hsSyn/HsUtils.lhs  |   32 +++--
  compiler/main/DynFlags.hs   |   13 +-
  compiler/rename/RnBinds.lhs |6 +-
  compiler/typecheck/TcBinds.lhs  |  282
 --
  compiler/typecheck/TcClassDcl.lhs   |   12 +-
  compiler/typecheck/TcEnv.lhs|  117 +--
  compiler/typecheck/TcErrors.lhs |   32 +++--
  compiler/typecheck/TcHsSyn.lhs  |   14 +-
  compiler/typecheck/TcInstDcls.lhs   |   19 ++-
  compiler/typecheck/TcMType.lhs  |6 +-
  compiler/typecheck/TcRnDriver.lhs   |   14 +-
  compiler/typecheck/TcRnMonad.lhs|2 +-
  compiler/typecheck/TcRnTypes.lhs|   11 +-
  compiler/ty

Re: [GHC] #2187: Top-level bindings are broken for polymorphic values

2011-08-16 Thread GHC 
#2187: Top-level bindings are broken for polymorphic values
---+
  Reporter:  yallop|  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  6.10 branch 
 Component:  Compiler  |Version:  6.8.2   
Resolution:  wontfix   |   Keywords:  
  Testcase:|  Blockedby:  
Difficulty:  Unknown   | Os:  Unknown/Multiple
  Blocking:|   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  |  
---+

Comment(by simonpj@…):

 commit 49dbe60558deee5ea6cd2c7730b7c591d15559c8
 {{{
 Author: Simon Peyton Jones 
 Date:   Tue Aug 16 10:23:52 2011 +0100

 Major improvement to pattern bindings

 This patch makes a number of related improvements

 a) Implements the Haskell Prime semantics for pattern bindings
(Trac #2357).  That is, a pattern binding p = e is typed
just as if it had been written
 t = e
 f = case t of p -> f
 g = case t of p -> g
 ... etc ...
where f,g are the variables bound by p. In paricular it's
ok to say
   (f,g) = (\x -> x, \y -> True)
and f and g will get propertly inferred types
   f :: a -> a
   g :: a -> Int

 b) Eliminates the MonoPatBinds flag altogether.  (For the moment
it is deprecated and has no effect.)  Pattern bindings are now
generalised as per (a).  Fixes Trac #2187 and #4940, in the
way the users wanted!

 c) Improves the OutsideIn algorithm generalisation decision.
Given a definition without a type signature (implying "infer
the type"), the published algorithm rule is this:
   - generalise *top-level* functions, and
   - do not generalise *nested* functions
The new rule is
   - generalise a binding whose free variables have
 Guaranteed Closed Types
   - do not generalise other bindings

Generally, a top-level let-bound function has a Guaranteed
Closed Type, and so does a nested function whose free vaiables
are top-level functions, and so on. (However a top-level
function that is bitten by the Monomorphism Restriction does
not have a GCT.)

Example:
  f x = let { foo y = y } in ...
Here 'foo' has no free variables, so it is generalised despite
being nested.

 d) When inferring a type f :: ty for a definition f = e, check that
the compiler would accept f :: ty as a type signature for that
same definition.  The type is rejected precisely when the type
is ambiguous.

Example:
   class Wob a b where
 to :: a -> b
 from :: b -> a

   foo x = [x, to (from x)]
GHC 7.0 would infer the ambiguous type
   foo :: forall a b. Wob a b => b -> [b]
but that type would give an error whenever it is called; and
GHC 7.0 would reject that signature if given by the
programmer.  The new type checker rejects it up front.

Similarly, with the advent of type families, ambiguous types are
easy to write by mistake.  See Trac #1897 and linked tickets for
many examples.  Eg
   type family F a :: *
   f ::: F a -> Int
   f x = 3
This is rejected because (F a ~ F b) does not imply a~b.
 Previously
GHC would *infer* the above type for f, but was unable to check it.
Now even the inferred type is rejected -- correctly.

 The main implemenation mechanism is to generalise the abe_wrap
 field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
 beautiful generalisation turned out to make everything work nicely
 with minimal programming effort.  All the work was fiddling around
 the edges; the core change was easy!

  compiler/deSugar/DsBinds.lhs|   62 +++-
  compiler/deSugar/DsExpr.lhs |6 +-
  compiler/hsSyn/HsBinds.lhs  |   28 +++-
  compiler/hsSyn/HsUtils.lhs  |   32 +++--
  compiler/main/DynFlags.hs   |   13 +-
  compiler/rename/RnBinds.lhs |6 +-
  compiler/typecheck/TcBinds.lhs  |  282
 --
  compiler/typecheck/TcClassDcl.lhs   |   12 +-
  compiler/typecheck/TcEnv.lhs|  117 +--
  compiler/typecheck/TcErrors.lhs |   32 +++--
  compiler/typecheck/TcHsSyn.lhs  |   14 +-
  compiler/typecheck/TcInstDcls.lhs   |   19 ++-
  compiler/typecheck/TcMType.lhs  |6 +-
  compiler/typecheck/TcRnDriver.lhs   |   14 +-
  compiler/typecheck/TcRnMonad.lhs|2 +-
  compiler/typecheck/TcRnTypes.lhs|   11 +-
  compiler/typecheck/TcSimplify.lhs   |   57 +

Re: [GHC] #3339: Data.Monoid: Add (<>) as a synonym for mappend

2011-08-16 Thread GHC 
#3339: Data.Monoid: Add (<>) as a synonym for mappend
--+-
  Reporter:  bos  |  Owner:  
  Type:  feature request  | Status:  patch   
  Priority:  normal   |  Milestone:  Not GHC 
 Component:  libraries/base   |Version:  6.10.3  
Resolution:   |   Keywords:  
  Testcase:   |  Blockedby:  
Difficulty:  Unknown  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by tibbe):

  * status:  new => patch
  * type:  proposal => feature request


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3339: Data.Monoid: Add (<>) as a synonym for mappend

2011-08-16 Thread GHC 
#3339: Data.Monoid: Add (<>) as a synonym for mappend
-+--
  Reporter:  bos |  Owner:  
  Type:  proposal| Status:  new 
  Priority:  normal  |  Milestone:  Not GHC 
 Component:  libraries/base  |Version:  6.10.3  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Unknown/Multiple
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--
Changes (by tibbe):

  * status:  closed => new
  * resolution:  invalid =>


Comment:

 As per http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11450 we
 now have consensus. Please apply the attached patch.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3231: Permission denied error with runProcess/openFile

2011-08-16 Thread GHC 
#3231: Permission denied error with runProcess/openFile
-+--
  Reporter:  NeilMitchell|  Owner:  simonmar
  Type:  bug | Status:  new 
  Priority:  low |  Milestone:  7.2.1   
 Component:  Runtime System  |Version:  6.10.4  
Resolution:  |   Keywords:  
  Testcase:  |  Blockedby:  
Difficulty:  Unknown | Os:  Windows 
  Blocking:  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown|  
-+--

Comment(by claudio):

 The basic problem is, that you have to deal with fatal and non-fatal
 errors.

 The code in Win32/File.hsc regards non-fatal errors as fatal and the user
 doesn't have any chance to check if the error was indeed fatal because
 there's no way of getting the error code.

 See http://support.microsoft.com/kb/316609

 Here's a patch which fixes this problem for removeFile:

 {{{
 #!diff
  -- File operations
  

 +foreign import stdcall unsafe "windows.h Sleep"
 +  sleep_priv :: DWORD -> IO ()
 +
  deleteFile :: String -> IO ()
  deleteFile name =
withTString name $ \ c_name ->
 -  failIfFalse_ (unwords ["DeleteFile",show name]) $
 -c_DeleteFile c_name
 +let
 +  retries = 20
 +  doDelete = c_DeleteFile c_name
 +  deleteFailed = errorWin (unwords ["DeleteFile",show name])
 +  when p s = if p then s else return ()
 +  unless p s = when (not p) s
 +  retryOrFail :: Int -> IO Bool -> IO ()
 +  retryOrFail times action = do
 +ret <- action
 +unless ret (do
 +   when (times <= 0) deleteFailed
 +   err_code <- getLastError
 +   when (err_code /= (# const ERROR_SHARING_VIOLATION
 )) deleteFailed
 +   sleep_priv 100 >> retryOrFail (times - 1) action)
 +in
 +  retryOrFail retries doDelete
  foreign import stdcall unsafe "windows.h DeleteFileW"
c_DeleteFile :: LPCTSTR -> IO Bool
 }}}

 This made gitit and darcs work under Windows for me.

 Just my 2 cents.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs