[GHC] #7071: Refactoring arrows
#7071: Refactoring arrows -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- At the moment arrow commands re-use `HsExpr` for Proc expressions. But with Dan Winograd-Cort I concluded that the best thing by far would be to separate the data type of HsExpr from that of arrow commands. I think that would lead to a substantial tidy up. There is also a nasty lurking bug in the type checking of commands; see line 290 of TcArrows. Here we call the unifier, but do not do anything with the coercion it returns. This is plainly wrong and will bite eventually. But I don't understand this code well enough to fix it. In short, I am not confident of the arrows implementation at the moment. Several tickets are blocked on this * #5022 (which is marked as fixed but is a pretty tricky case) * #5267 * #5777 * #4359 proposal for `proc case` and multi-branch if -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7071 GHC http://www.haskell.org/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] #7071: Refactoring arrows
#7071: Refactoring arrows -+-- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Description changed by simonpj: Old description: At the moment arrow commands re-use `HsExpr` for Proc expressions. But with Dan Winograd-Cort I concluded that the best thing by far would be to separate the data type of HsExpr from that of arrow commands. I think that would lead to a substantial tidy up. There is also a nasty lurking bug in the type checking of commands; see line 290 of TcArrows. Here we call the unifier, but do not do anything with the coercion it returns. This is plainly wrong and will bite eventually. But I don't understand this code well enough to fix it. In short, I am not confident of the arrows implementation at the moment. Several tickets are blocked on this * #5022 (which is marked as fixed but is a pretty tricky case) * #5267 * #5777 * #4359 proposal for `proc case` and multi-branch if New description: At the moment arrow commands re-use `HsExpr` for Proc expressions. But with Dan Winograd-Cort I concluded that the best thing by far would be to separate the data type of HsExpr from that of arrow commands. I think that would lead to a substantial tidy up. There is also a nasty lurking bug in the type checking of commands; see line 290 of TcArrows. Here we call the unifier, but do not do anything with the coercion it returns. This is plainly wrong and will bite eventually. But I don't understand this code well enough to fix it. In short, I am not confident of the arrows implementation at the moment. Several tickets are blocked on this * #5022 (which is marked as fixed but is a pretty tricky case) * #5267 * #5777 * #5609 * #344 * #4359 proposal for `proc case` and multi-branch if -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7071#comment:1 GHC http://www.haskell.org/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] #7060: Option -ddump-rule-rewrites doesn't dump to a file
#7060: Option -ddump-rule-rewrites doesn't dump to a file ---+ Reporter: erikd | Owner: pcapriotti Type: bug | Status: closed Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.5 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by pcapriotti): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7060#comment:3 GHC http://www.haskell.org/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] #7067: Add alignment-restricted ForeignPtr allocation actions
#7067: Add alignment-restricted ForeignPtr allocation actions -+-- Reporter: nicolast | Owner: simonmar Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: libraries/base| Version: Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * owner: = simonmar * difficulty: = Unknown * milestone: = 7.6.1 Comment: Patch looks good to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7067#comment:2 GHC http://www.haskell.org/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] #7068: Extensive Memory usage (regression)
#7068: Extensive Memory usage (regression) -+-- Reporter: waldheinz | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * priority: normal = high * difficulty: = Unknown * milestone: = 7.6.1 Comment: We should at least look into this and decide whether there's something suspicious going on or not. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7068#comment:1 GHC http://www.haskell.org/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] #7072: GHC interpreter does not find stat64 symbol on Linux
#7072: GHC interpreter does not find stat64 symbol on Linux
+---
Reporter: snoyberg| Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 7.4.2 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Mailing list discussion available at: [http://www.haskell.org/pipermail
/haskell-cafe/2012-July/102253.html]. The issue is that, when using runghc
against a library using the sqlite3 C library (persistent-sqlite), the
stat64 symbol is not resolved. After some research, I came up with the
following minimal reproducing C code:
{{{
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include stdio.h
typedef int stat_func(const char*, struct stat*);
stat_func *foo = stat;
void stat_test(void)
{
struct stat buf;
printf(About to stat-test.c\n);
foo(stat-test.c, buf);
printf(Done\n);
}
}}}
When using stat directly, gcc inlines the call and produces assembly which
simply makes a system call, thereby avoiding the need for the stat symbol.
However, when using a function pointer (as sqlite3 does), the symbol is
retained, and then runghc does not resolve it.
In the linked mailing list discussion, Tristan Ravitch found a Stack
Overflow thread ([http://stackoverflow.com/questions/5478780/c-and-ld-
preload-open-and-open64-calls-intercepted-but-not-stat64]) which explains
that the GNU linker has special handling for the stat, stat64, and a few
other library functions. glibc itself does not provide those symbols
directly, relying on the linker to fix the references. (I could not find
reference to this in any official documentation.)
As a workaround, I declared some local functions which call stat and
stat64 (patch available at
[https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601]).
So there is a workaround available, and therefore this isn't high priority
for me. But I do think it's worth some kind of fix.
Without having a good understanding of the GHC interpreter, my guess would
be that it needs to replicate the stat/stat64/etc hack that the GNU linker
is performing. Of course, this guess may be incorrect.
Tested on Ubuntu 12.04 64-bit, though I believe it will affect any recent
version of Linux, whether 32- or 64-bit.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7072
GHC http://www.haskell.org/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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms ---+ Reporter: shahn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.4.2 Keywords: Float Double 32 precision rounding | Os: Unknown/Multiple Architecture: x86 | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * owner: = simonmar * difficulty: = Unknown * milestone: = 7.6.1 Comment: I will document this bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#comment:1 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by mikhail.vorozhtsov): Replying to [comment:72 simonmar]: I think it might be better to implement `\case` using a lexer state rather than tracking the previous token in the monad as the patch currently does. But it's hard to say for sure without trying it. I'm no alex expert, so I don't see how it can be implemented with states. The logic here seems to be: 1. On `\`, return `ITlam` and enter a new state, let's say, AFTER_LAM. 2. Skip whitespace/comments (works for all states). 3. If the next token is `case`, then return `ITlcase` and start a new layout. 4. If the next token is not `case`/whitespace/comments, then switch to state `0` and return the token. How to implement (4)? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:74 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by jeltsch):
Replying to [comment:73 simonpj]:
Concerning arrows, I do agree that (`proc case` ''alts'') as syntactic
sugar for (`prox x - case x of` ''alts'') would be consistent. I don't
know the arrow equivalent of multi-branch if would look like. Want to
flesh it out?
And example using it would look like this:
{{{
proc x - if | x 0- f - -1
| x == 0- g - 0
| otherwise - h - 1
}}}
'''However''' I am deeply reluctant to fiddle with the arrow code at
all; there's a long-standing plan to refactor the arrow-handling code
which is currently complex and crufy. If anyone arrow-keen person is
willing to undertake this, I am happy to help. The ticket is #7071.
I can imagine to help here, but I would like to be permitted to add
support for arrow versions of lambda case and multi-branch if.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:75
GHC http://www.haskell.org/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] #7014: RULES for bitwise logic and shift primops
#7014: RULES for bitwise logic and shift primops -+-- Reporter: akio | Owner: pcapriotti Type: feature request | Status: patch Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by pcapriotti): Is the rightIdentity rule for IntRemOp wrong? Yes, thanks for catching that. I updated the patch and added some more tests. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7014#comment:8 GHC http://www.haskell.org/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] #5962: Data.Typeable: types which should compare equal don't
#5962: Data.Typeable: types which should compare equal don't --+- Reporter: NickSmallbone| Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: 7.4.3 Component: libraries/base |Version: 7.4.1 Resolution: fixed| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: base/tests/T5962 | Blockedby: Blocking: |Related: --+- Changes (by simonmar): * status: closed = merge * milestone: = 7.4.3 Comment: We really should have merged this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5962#comment:4 GHC http://www.haskell.org/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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms ---+ Reporter: shahn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.4.2 Keywords: Float Double 32 precision rounding | Os: Unknown/Multiple Architecture: x86 | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by Khudyakov): * cc: alexey.skladnoy@… (added) Comment: I think it's duplicate of #5165 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#comment:2 GHC http://www.haskell.org/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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms
---+
Reporter: shahn | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler| Version: 7.4.2
Keywords: Float Double 32 precision rounding | Os:
Unknown/Multiple
Architecture: x86 | Failure: Incorrect
result at runtime
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by marlowsd@…):
commit 43405edbe91d16b289948b9cf442e0bd1b33abdf
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Fri Jul 13 10:23:12 2012 +0100
Document bug in the x86 NCG w.r.t. -fexcess-precision (#7069)
docs/users_guide/bugs.xml | 30 ++
docs/users_guide/using.xml |8
2 files changed, 38 insertions(+), 0 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#comment:3
GHC http://www.haskell.org/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] #7067: Add alignment-restricted ForeignPtr allocation actions
#7067: Add alignment-restricted ForeignPtr allocation actions ---+ Reporter: nicolast | Owner: simonmar Type: feature request | Status: closed Priority: normal| Milestone: 7.6.1 Component: libraries/base|Version: Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by simonmar): * status: patch = closed * resolution: = fixed Comment: Applied, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7067#comment:3 GHC http://www.haskell.org/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] #7069: precision/rounding bug with floating point numbers on 32-bit-platforms
#7069: precision/rounding bug with floating point numbers on 32-bit-platforms --+- Reporter: shahn| Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler |Version: 7.4.2 Resolution: wontfix | Keywords: Float Double 32 precision rounding Os: Unknown/Multiple | Architecture: x86 Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonmar): * status: new = closed * resolution: = wontfix Comment: Documented as a known bug, thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7069#comment:4 GHC http://www.haskell.org/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] #5165: GHC doesn't optimize FP excess precision properly
#5165: GHC doesn't optimize FP excess precision properly
--+-
Reporter: ezyang | Owner:
Type: bug | Status: closed
Priority: low | Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution: duplicate| Keywords:
Os: Linux| Architecture: x86
Failure: Incorrect result at runtime | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: new = closed
* difficulty: = Unknown
* resolution: = duplicate
Comment:
Closing as a dup of #7069; we now document this as a known bug.
Note that the particular example in this ticket also involves constant
folding, which we have to be careful to do at the correct precision. We
do make an attempt to do this properly, although it's not clear to me that
it really does the right thing, since we're relying on
{{{
toRational (fromRational (a `op` b))
}}}
being the same as
{{{
toRational (fromRational a `op` fromRational b)
}}}
which I rather doubt is the case. Here's the code from `PrelRules`:
{{{
-- When excess precision is not requested, cut down the precision of the
-- Rational value to that of Float/Double. We confuse host architecture
-- and target architecture here, but it's convenient (and wrong :-).
convFloating :: Literal - Literal
convFloating (MachFloat f) | not opt_SimplExcessPrecision =
MachFloat (toRational ((fromRational f) :: Float ))
convFloating (MachDouble d) | not opt_SimplExcessPrecision =
MachDouble (toRational ((fromRational d) :: Double))
convFloating l = l
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5165#comment:6
GHC http://www.haskell.org/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] #7070: DataKinds and package boundaries: the 'impossible' happened
#7070: DataKinds and package boundaries: the 'impossible' happened -+-- Reporter: aristidb| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.4.2 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by aristidb): OK, I guess I need to implement the ugly solution to my problem that doesn't require DataKinds. For an unadvertised feature, word spread pretty quickly, perhaps you should have include a few big red warning texts to tell people that it's considered highly experimental in 7.4. I should note by the way that no problem was caused as long as the DataKinds code was loaded as source modules, not as package modules. If that helps pin down a cause for a possible regression text. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7070#comment:7 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by igloo): The lexer complexity is only an issue with the `\ case` syntax, not with either `\ of` or `case of`, right? So given opinion seems to be divided on which is aesthetically nicer, which don't we implement one of the syntaxes that gives a simpler, cleaner specification and implementation? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:78 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by jeltsch):
Replying to [comment:78 igloo]:
The lexer complexity is only an issue with the `\ case` syntax, not with
either `\ of` or `case of`, right?
So given opinion seems to be divided on which is aesthetically nicer,
which don't we implement one of the syntaxes that gives a simpler, cleaner
specification and implementation?
It’s not just about aesthetics, specification, and implementation. The
{{{case of}}} solution has the problem that it cannot be carried over to
arrow expressions. So we have the following situation:
{{{case of}}}::
no analog for arrow expressions
{{{\case}}}::
lexer complexity
{{{\of}}}::
not immediately visible that it is about case distinction
I tend to prefer {{{\of}}}.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:79
GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by igloo): I don't see a major problem with `case of` / `proc of`, although personally I would also prefer `\ of` / `proc of`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:80 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by mikhail.vorozhtsov):
I almost got lexer state working, but then I found that it gets in the way
of layout handling. Assuming we have
{{{
after_lambda {
@varid/ { isCaseKeyword } { lambda_case }
(){ pop }
}
}}}
the following code will not be parsed correctly
{{{
f3 = \ -- comment
case 1 - 1
2 - 2
}}}
because there is a newline between `\` and `case`. And newline handling
depends on the previous lexer state in the stack. I probably could write a
lexer action that checks it (whether we are in do-expression/etc) and does
the right thing (check offsets, insert `;`, ...), but IMO it would be much
uglier and error-prone than keeping track of the last non-comment token.
Any thoughts?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:81
GHC http://www.haskell.org/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] #7073: Kind variable problem when declaring associated type family
#7073: Kind variable problem when declaring associated type family
--+-
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler (Type checker)
Version: 7.5 | Keywords: PolyKinds TypeFamilies
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
The following code fails to compile:
{{{
{-# LANGUAGE PolyKinds, TypeFamilies #-}
class Foo a where
type Bar a
type Bar a = Int
}}}
The error I get is
{{{
Type indexes must match class instance head
Found `k' but expected `k'
In the type synonym instance default declaration for `Bar'
In the class declaration for `Foo'
}}}
When I remove {{{-XPolyKinds}}}, the code compiles without a hiccup.
This was tested on 7.5.2012.0710
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7073
GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): Ok, I guess we have to keep track of the previous token. Thanks for trying it anyway. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:82 GHC http://www.haskell.org/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] #7062: Spurious undefined reference to `openpty'
#7062: Spurious undefined reference to `openpty' -+-- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.4.3 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by trommler): * cc: ptrommler@… (added) Comment: I came across the --as-needed issue when preparing packages for openSUSE's Build Service, where it is set by default. The problem is that shared libraries that do not contain symbols that are undefined in any object (library or object file) up to the point in the command line where the library is mentioned (-l) will not be included in the ELF info and especially an Rpath will not be recorded. If the shared library is not installed in a standard directory, and Haskell libraries will not be in most Linux distributions, then it will not be found. If you symlinked those libraries from one of the standard directories then all works fine again. As a temporary fix I put --no-as-needed into ghc's settings in a patch for openSUSE's ghc package. To fix the --as-needed issue properly all libraries need to be linked to before libraries they depend on and for cycles one library needs to be linked twice. For Haskell packages dependency information in the packaging system could be used, for system libraries the the correct linking order would have to be specified in the extra-libraries field. AFAIK Gentoo uses or at least recommends using --as-needed, too. Should we deal with this as a feature request in a different ticket? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7062#comment:6 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if
---+
Reporter: batterseapower| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 7.6.1
Component: Compiler |Version: 7.1
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by jeltsch):
Replying to [comment:80 igloo]:
I don't see a major problem with `case of` / `proc of`, although
personally I would also prefer `\ of` / `proc of`.
Since {{{proc}}} is the arrow analog of {{{\}}}, I think we should use a
syntax that uses {{{\}}} in the notation for ordinary lambda case and uses
{{{proc}}} instead of {{{\}}} for the arrow lambda case.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:83
GHC http://www.haskell.org/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] #6166: Performance regression in mwc-random since 7.0.x
#6166: Performance regression in mwc-random since 7.0.x ---+ Reporter: bos | Owner: Type: bug | Status: new Priority: high| Milestone: 7.6.1 Component: Compiler| Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by Dzhus): * cc: dima@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6166#comment:3 GHC http://www.haskell.org/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] #4359: Implement lambda-case/lambda-if
#4359: Implement lambda-case/lambda-if ---+ Reporter: batterseapower| Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler |Version: 7.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by mikhail.vorozhtsov): Ok, here is the latest version of the `\case` patch. I added Template Haskell support and a few boring tests for the testsuite. The only remaining issue is `addTickHsExpr`, I think my naive version doesn't do exactly the right thing with `TickAllFunctions`. Could someone take a look? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4359#comment:84 GHC http://www.haskell.org/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] #7074: Way too long, and unhelpful, error message
#7074: Way too long, and unhelpful, error message
--+-
Reporter: ksf | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
GHC is repeating this nice ~140 line mdo-expression, twice, leading to
annoying scrolling:
http://hpaste.org/71415
The error message
{{{
Frisby.hs:142:5:
Couldn't match expected type `[Char]' with actual type `()'
Expected type: P s0 [Char]
Actual type: P s0 ()
}}}
could also be more helpful, it appears to always point to the last binding
statement of the block.
NB: The code is probably *very* incorrect, I just hand-translated it from
another grammar format and was hunting down errors when coming across this
one.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7074
GHC http://www.haskell.org/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] #7062: Spurious undefined reference to `openpty'
#7062: Spurious undefined reference to `openpty'
-+--
Reporter: simonmar | Owner:
Type: bug | Status: merge
Priority: high | Milestone: 7.4.3
Component: Compiler | Version: 7.4.2
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by simonmar):
@trommler does the patch fix it for you?
I still don't understand what was going wrong, and I'm afraid your
explanation doesn't clarify things for me. The problem I encountered is
that we had a link line like
{{{
... -lHSprocess -lHSunix -lutil ...
}}}
where `libHSprocess` depends on `libHSunix` which depends on `1libutil`.
But the linker reported a missing symbol `openpty` that is undefined in
`libHSunix` and defined in `libutil`.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7062#comment:7
GHC http://www.haskell.org/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] #7041: GHC.Real.gcdInt is no longer optimized.
#7041: GHC.Real.gcdInt is no longer optimized. ---+ Reporter: int-e | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: libraries/base|Version: 7.5 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: I've fixed this, and also checked for other problematic rules. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7041#comment:3 GHC http://www.haskell.org/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] #7041: GHC.Real.gcdInt is no longer optimized.
#7041: GHC.Real.gcdInt is no longer optimized.
---+
Reporter: int-e | Owner: igloo
Type: bug | Status: closed
Priority: high | Milestone: 7.6.1
Component: libraries/base|Version: 7.5
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Comment(by simonpj):
Here's are the commits for this ticket
{{{
commit a07f118c08ac5fd5923b6e0b2c994f4185121604
Author: Ian Lynagh ig...@earth.li
Date: Fri Jul 13 19:51:08 2012 +0100
Tweak RULEs; fixes #7041
In particular, the gcd rule now uses smallInteger rather than S#,
which
means that it actually fires.
Also fixed a bug when the result is minBound :: Int.
---
GHC/Integer/Type.lhs |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/GHC/Integer/Type.lhs b/GHC/Integer/Type.lhs index
be3ebea..a402f37 100644
--- a/GHC/Integer/Type.lhs
+++ b/GHC/Integer/Type.lhs
@@ -135,11 +135,6 @@ int64ToInteger i = if ((i `leInt64#` intToInt64#
0x7FFF#)
integerToInt :: Integer - Int#
{-# NOINLINE integerToInt #-}
-{-# RULES integerToInt forall i. integerToInt (S# i) = i #-}
--- Don't inline integerToInt, because it can't do much unless
--- it sees a (S# i), and inlining just creates fruitless
--- join points. But we do need a RULE to get the constants
--- to work right: 1::Int had better optimise to (I# 1)!
integerToInt (S# i) = i
integerToInt (J# s d) = integer2Int# s d
@@ -287,8 +282,10 @@ lcmInteger a b = if a `eqInteger` S# 0# then S#
0#
where aa = absInteger a
ab = absInteger b
+-- This rule needs to use absInteger so that it works correctly when
+-- the result is minBound :: Int
{-# RULES gcdInteger/Int forall a b.
-gcdInteger (S# a) (S# b) = S# (gcdInt a b)
+gcdInteger (smallInteger a) (smallInteger b) = absInteger
+ (smallInteger (gcdInt a b))
#-}
gcdInt :: Int# - Int# - Int#
gcdInt 0# y = absInt y
}}}
and
{{{
commit 4b780b93beac863b7945d7e050ffa6cdaf256eb7
Author: Ian Lynagh ig...@earth.li
Date: Fri Jul 13 20:04:51 2012 +0100
Add another gcdInteger rule
This one is better when the result is converted to an Int
---
GHC/Integer/Type.lhs | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/GHC/Integer/Type.lhs b/GHC/Integer/Type.lhs index
a402f37..b9d9c3c 100644
--- a/GHC/Integer/Type.lhs
+++ b/GHC/Integer/Type.lhs
@@ -283,9 +283,14 @@ lcmInteger a b = if a `eqInteger` S# 0# then S#
0#
ab = absInteger b
-- This rule needs to use absInteger so that it works correctly when
--- the result is minBound :: Int
-{-# RULES gcdInteger/Int forall a b.
-gcdInteger (smallInteger a) (smallInteger b) = absInteger
(smallInteger (gcdInt a b))
+-- the result is minBound :: Int. But that isn't necessary when the
+-- result is converted to an Int.
+{-# RULES
+gcdInteger/Int forall a b.
+gcdInteger (smallInteger a) (smallInteger b)
+= absInteger (smallInteger (gcdInt a b))
+integerToInt/gcdInteger/Int forall a b.
+integerToInt (gcdInteger (smallInteger a) (smallInteger b)) =
+gcdInt a b
#-}
gcdInt :: Int# - Int# - Int#
gcdInt 0# y = absInt y
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7041#comment:4
GHC http://www.haskell.org/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] #7041: GHC.Real.gcdInt is no longer optimized.
#7041: GHC.Real.gcdInt is no longer optimized.
---+
Reporter: int-e | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.6.1
Component: libraries/base|Version: 7.5
Resolution:| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* owner: igloo =
* status: closed = new
* resolution: fixed =
Comment:
1. There is no mention of `smallInteger` in the wiki page.
[http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries/Integer]
It took me a while, but I got there, and augmented the page. Can you
check I’m right?
2. There are ''some'' rules in `PrelRules` with a (correct) comment saying
{{{
-- These rules below don't actually have to be built in, but if we
-- put them in the Haskell source then we'd have to duplicate them
-- between all Integer implementations
}}}
But then in `integer-gmp:GHC/Integer/Type.hs` we have other RULES that
also should be duplicated in other integer packages (but aren’t). One of
these is the gcd rule altered in this patch. Why did you decide to do one
thing for some rules and another for the others?
3. Also what is special about GCD here? What about
{{{
integerToInt (plusInteger (smallInteger a) (smallInteger b))
}}}
Maybe it’s just that the result of gcd is guaranteed to be small? Even in
the case, presumably integerToInt is undefined if the result doesn’t fit
in an Int, so we could indeed say that
{{{
integerToInt (plusInteger (smallInteger a) (smallInteger b)) = plusInt
a b
}}}
But is this common enough to worry about? It seems most odd to have a
RULE like this for GCD but not for +!!
4. Coming back to this ticket #7041 it seems utterly bonkers that in
`base:GHC.Real` we have
{{{
gcdInt :: Int - Int - Int
gcdInt a b = fromIntegral (gcdInteger (fromIntegral a) (fromIntegral b))
}}}
This is then laboriously converted (by the new RULE ) to, guess what, a
call to
`ghc-integer:GHC.Integer.Type.gcdInt`, which is defined (in that module)
{{{
gcdInt :: Int# - Int# - Int#
gcdInt 0# y = absInt y
gcdInt x 0# = absInt x
gcdInt x y = gcdInt# (absInt x) (absInt y)
}}}
This is madness. Why don’t we define `gcdInt` in that way in
`base:GHC.Real`, and get rid of the bizarre special treatment of GCD.
Which we only needed because its definition in `GHC.Real` stupidly went
via Integer.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7041#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
