Re: [GHC] #1308: Type signature in warning is wrong

[GHC]

#1308: Type signature in warning is wrong
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.7
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Windows   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by Isaac Dupree):

 Given inferred monomorphic type `Inferred type: autoChart :: t View`,

 I think it would be desirable to (additionally) report the type as if the
 M-R didn't apply, to be informative and in case this is the signature that
 the user wants to add.

 Also it would be helpful to report the actual type GHC decides upon
 (unless there's a type error?). I assume that GHC knows what 't' becomes
 after applying M-R.

 Now, is it useful to report `autoChart :: monomorphic t. t View`?  As far
 as I know, it is easy to see what this could be, just based on the fully
 polymorphic type,  especially if a specific example - the actual
 monomorphic type GHC has chosen - is shown as well.

 Hmm... is it even possible to pretend that one thing (e.g. `autochart`) is
 polymorphic (as suggested above), in the presence of other things falling
 under the monomorphism restriction?  Or are there some cases where it
 still might not be clear what to report?

-- 
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] #1204: Associated types don't work with record updates

[GHC]

#1204: Associated types don't work with record updates
+---
Reporter:  [EMAIL PROTECTED]   |Owner:
Type:  bug  |   Status:  closed
Priority:  normal   |Milestone:  6.8   
   Component:  Compiler (Type checker)  |  Version:  6.7   
Severity:  normal   |   Resolution:  fixed 
Keywords:   |   Difficulty:  Unknown   
  Os:  Unknown  | Testcase:  Records.hs
Architecture:  Unknown  |  
+---
Changes (by simonpj):

  * resolution:  => fixed
  * testcase:  => Records.hs
  * status:  new => closed

Comment:

 Good bug repoort.  I have finally found a moment to fix it.  Should work
 now.

 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] #1310: confusing error message when trying to give a type-signature to an imported symbol

[GHC]

#1310: confusing error message when trying to give a type-signature to an 
imported
symbol
-+--
Reporter:  Isaac Dupree  |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.6.1  
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
  Os:  Unknown   | Testcase: 
Architecture:  Unknown   |  
-+--
Changes (by simonpj):

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

Comment:

 Good point. I've improved the error messages. For imports:
 {{{
 Foo.hs:4:11:
 Misplaced type signature: putStrLn :: String -> IO ()
 You cannot give a type signature for an imported value
 }}}
 For locals:
 {{{
 Foo.hs:4:11:
 Misplaced type signature: p :: String -> IO ()
 The type signature must be given where `p' is declared
 }}}

 Thanks for the suggestion

 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] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request

[GHC]

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature
request
+---
Reporter:  Isaac Dupree |Owner: 
Type:  feature request  |   Status:  new
Priority:  low  |Milestone:  _|_
   Component:  Compiler |  Version:  6.6.1  
Severity:  normal   |   Resolution: 
Keywords:   |   Difficulty:  Unknown
  Os:  Unknown  | Testcase: 
Architecture:  Unknown  |  
+---
Changes (by simonpj):

  * milestone:  => _|_
  * priority:  normal => low
  * type:  bug => feature request

Comment:

 I can't see any reason this would be impossible in principle, but my brain
 is too small to figure out all the ramifications of dropping the "newtypes
 are always boxed" assumption that GHC currently makes.

 So for now I have simply added the restriction to the user manual, and
 I'll leave this suggestion as a feature request.

 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] #1256: GHC warns about omitting type signatures; would be more helpful if it supplied inferred type signature

[GHC]

#1256: GHC warns about omitting type signatures; would be more helpful if it
supplied inferred type signature
+---
Reporter:  guest|Owner: 
Type:  feature request  |   Status:  closed 
Priority:  low  |Milestone:  6.8
   Component:  Compiler |  Version:  6.6
Severity:  minor|   Resolution:  fixed  
Keywords:   |   Difficulty:  Unknown
  Os:  Unknown  | Testcase: 
Architecture:  Unknown  |  
+---
Comment (by simonpj):

 See #1308 for why omitting the `forall` is far from a no-brainer.

 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] #1308: Type signature in warning is wrong

[GHC]

#1308: Type signature in warning is wrong
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.7
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
  Os:  Windows   | Testcase: 
Architecture:  Unknown   |  
-+--
Comment (by simonpj):

 Not obviously. `autoChart` falls under the Dreaded Monomorphism
 Restriction, so its inferred type is ''not'' `forall t. Monad t => ...`.

 It's not obvious what to report here.  I originally added a remark to
 highlight the MR point.  Would that help?  Something like:
 {{{
   Warning: Definition but no type signature for `autoChart'
  Inferred type: autoChart :: t View
NB: autoChart is monomorphic in type variable t
 }}}
 In Trac #1256 Isaac wants to omit the `forall` in the displayed inferred
 type; but that would mean there was no way to distinguish `autoChart :: t
 View` from `autoChard :: forall t. t View`, which is presumably the way
 Lennart read it.

 Advice welcome.  The issue is what is most comprehensible; implementing it
 is probably easy!

 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] #1306: GHC generates warning about internally generated functions

[GHC]

#1306: GHC generates warning about internally generated functions
-+--
Reporter:  guest |Owner: 
Type:  bug   |   Status:  closed 
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.7
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
  Os:  Windows   | Testcase: 
Architecture:  Unknown   |  
-+--
Changes (by simonpj):

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

Comment:

 Dup of #1313 (well, to be fair, #1313 is dup of this).


 Anyway, it's fixed.

 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] #1313: HEAD gives warnings about code that it generates itself

[GHC]

#1313: HEAD gives warnings about code that it generates itself
+---
Reporter:  igloo|Owner:  simonpj
Type:  bug  |   Status:  closed 
Priority:  normal   |Milestone:  6.8
   Component:  Compiler (Type checker)  |  Version:  6.7
Severity:  normal   |   Resolution:  fixed  
Keywords:   |   Difficulty:  Unknown
  Os:  Unknown  | Testcase: 
Architecture:  Unknown  |  
+---
Changes (by simonpj):

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

Comment:

 I believe I have fixed this.

 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] #1317: add warning for the Prelude being imported implicitly

[GHC]

#1317: add warning for the Prelude being imported implicitly
+---
Reporter:  Isaac Dupree |Owner: 
Type:  feature request  |   Status:  new
Priority:  normal   |Milestone: 
   Component:  Compiler |  Version:  6.6.1  
Severity:  normal   |   Resolution: 
Keywords:   |   Difficulty:  Unknown
  Os:  Unknown  | Testcase: 
Architecture:  Unknown  |  
+---
Comment (by simonpj):

 Seems plausible to me, and should be easy to implement, so feel free to
 submit a patch.  The guidelines are here;
 
http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions#Howtosubmitapatchforanewfeature.

 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] #1320: FAQ item for running GHCi on WinXP x64 using DEP

[GHC]

#1320: FAQ item for running GHCi on WinXP x64 using DEP
-+--
Reporter:  guest |Owner:   
Type:  task  |   Status:  closed   
Priority:  low   |Milestone:   
   Component:  GHCi  |  Version:  6.6.1
Severity:  normal|   Resolution:  duplicate
Keywords:  DEP, XP, x64, amd64, windows  |   Difficulty:  Unknown  
  Os:  Windows   | Testcase:   
Architecture:  x86_64 (amd64)|  
-+--
Changes (by simonmar):

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

Comment:

 I'm assuming this is a duplicate of #885, which is fixed in 6.6.1.  I'm
 also guessing that you marked the bug as 6.6.1 because that's the default,
 not that it actually happens on 6.6.1.  If this is wrong and you still see
 the bug with 6.6.1, please re-open this ticket.

-- 
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] #1321: GHCi stdout bug when base package is not optimised

[GHC]

#1321: GHCi stdout bug when base package is not optimised
---+
  Reporter:  simonmar  |  Owner: 
  Type:  bug   | Status:  new
  Priority:  normal|  Milestone:  6.8
 Component:  Compiler  |Version:  6.7
  Severity:  normal|   Keywords: 
Difficulty:  Unknown   | Os:  Unknown
  Testcase:|   Architecture:  Unknown
---+
Reported by Igloo:

 The problem from a couple of weeks ago, where ghci's hFlush command
 seems to be flushing a different stdout to the one that expressions
 evaluated by ghci write to, happens with a "quickest" build:

 {{{
 SRC_HC_OPTS = -H64m -Onot -fasm
 GhcStage1HcOpts = -O -fasm
 GhcStage2HcOpts = -Onot -fasm
 GhcLibHcOpts= -Onot -fasm
 GhcLibWays  =
 SplitObjs   = NO
 }}}

 but not if libraries are optimised:

 {{{
 SRC_HC_OPTS = -H64m -Onot -fasm
 GhcStage1HcOpts = -O -fasm
 GhcStage2HcOpts = -Onot -fasm
 GhcLibHcOpts= -O -fasm
 GhcLibWays  =
 SplitObjs   = NO
 }}}
 ghci004 is an example of a failing test (no output is printed if
 libraries are not optimised).

 This seems completely illogical to me. I'd have expected such a bug
 would be caused by optimisation meaning stdout gets inlined somewhere or
 something. Very curious!

-- 
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] #1320: FAQ item for running GHCi on WinXP x64 using DEP

[GHC]

#1320: FAQ item for running GHCi on WinXP x64 using DEP
--+-
  Reporter:  guest|  Owner:  
  Type:  task | Status:  new 
  Priority:  low  |  Milestone:  
 Component:  GHCi |Version:  6.6.1   
  Severity:  normal   |   Keywords:  DEP, XP, x64, amd64, windows
Difficulty:  Unknown  | Os:  Windows 
  Testcase:   |   Architecture:  x86_64 (amd64)  
--+-
Hi,

 I don't know if this is a bug or not, but here is what I have witnessed:

 In order to get ghci to run on Windows XP x64, I needed to add ghci.exe to
 the "data execution prevention" exception list. Before making this
 exception, running ghci.exe would pop open my debugger with an access
 violation.

 Data Execution Prevention restricts the OS from executing any code that
 has been marked in memory as 'data'. I presume that the interpreter is
 taking in some strings, doing some processing on that data; then treating
 it as executable code and trying to run it. That sounds like a reasonable
 thing to do, and I don't know if there is a way to prevent it from
 triggering DEP.

 If this isn't a bug, perhaps you will consider this exception as a FAQ
 entry.

 -- Chris Messer
 ([EMAIL PROTECTED])

-- 
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