[GHC] #7423: panic on typo in deriving clause
#7423: panic on typo in deriving clause
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.1 | Keywords:
Os: Linux | Architecture: Other
Failure: None/Unknown | Blockedby:
Blocking:|Related:
-+--
Consider the following:
data T = T deriving (eq)
Note the misspelled lower-case capital - Eq was intended instead. Rather
than reporting a syntax error, GHC panics:
mnykanen@localhost$ ghc -v -dcore-lint extest.hs
Glasgow Haskell Compiler, Version 7.4.1, stage 2 booted by GHC version
7.0.2
Using binary package database:
/home/mnykanen/bin/ghc-7.4.1/lib/ghc-7.4.1/package.conf.d/package.cache
Using binary package database:
/home/mnykanen/.ghc/x86_64-linux-7.4.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-
prim-0.2.0.0-c2ff696e5b8ec4d4b2bc2e42085fe471
wired-in package integer-gmp mapped to integer-
gmp-0.4.0.0-3cccac07aef8e27023f605c1f45bdf74
wired-in package base mapped to
base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-
haskell-2.7.0.0-133c0fdb189e05de22bd926d39f99fe3
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *extest.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Sat Nov 17 10:05:25 EET 2012
ms_mod = main:Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file extest.hs
Created temporary directory: /tmp/ghc2802_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( extest.hs, extest.o )
*** Parser:
*** Renamer/typechecker:
*** Deleting temp files:
Deleting: /tmp/ghc2802_0/ghc2802_0.s
Warning: deleting non-existent /tmp/ghc2802_0/ghc2802_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc2802_0
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
nameModule eq{tv a9I}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7423
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] #7423: panic on typo in deriving clause
#7423: panic on typo in deriving clause ---+ Reporter: guest |Owner: Type: bug | Status: closed Priority: normal |Component: Compiler Version: 7.4.1 | Resolution: duplicate Keywords: | Os: Linux Architecture: Other | Failure: None/Unknown Blockedby: | Blocking: Related: | ---+ Changes (by guest): * status: new = closed * resolution: = duplicate Comment: Thanks for the report, but it's already fixed in GHC 7.6.1, bug #5961. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7423#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] #7267: linux-ppc64: Segfault during stage2 build
#7267: linux-ppc64: Segfault during stage2 build
-+--
Reporter: erikd| Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords:
Os: Linux| Architecture: powerpc64
Failure: Building GHC failed | Testcase:
Blockedby: | Blocking:
Related: |
-+--
Comment(by erikd):
Back to debugging this one. Noticed things like:
{{{
/tmp/ghc16063_0/ghc16063_0.hc:3204:2:
warning: conflicting types for built-in function 'memcpy' [enabled by
default]
}}}
resulting from `compiler/utils/StringBuffer.lhs` which generates
`compiler/utils/StringBuffer.hc` containing:
{{{
ghcFunPtr = ((void * (*)(void *, void *, W_))memcpy);
}}}
however, `memcpy` really has a type:
{{{
void *memcpy(void *dest, const void *src, size_t n);
}}}
with a `const` on the `src` parameter. Pretty sure this is not relevant to
this problem.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7267#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] #7342: Bug in System.Posix.Env.putEnv
#7342: Bug in System.Posix.Env.putEnv -+-- Reporter: SimonHengel | Owner: Type: bug | Status: patch Priority: normal | Component: libraries/unix Version: 7.4.2| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Testcase: Blockedby: | Blocking: Related: | -+-- Changes (by SimonHengel): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7342#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] #7226: bytestring changes in 7.6 branch
#7226: bytestring changes in 7.6 branch --+- Reporter: igloo | Owner: igloo Type: bug| Status: new Priority: highest| Milestone: 7.6.2 Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7226#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] #7342: Memory violation bug in System.Posix.Env.putEnv (was: Bug in System.Posix.Env.putEnv)
#7342: Memory violation bug in System.Posix.Env.putEnv -+-- Reporter: SimonHengel | Owner: Type: bug | Status: patch Priority: normal | Component: libraries/unix Version: 7.4.2| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Testcase: Blockedby: | Blocking: Related: | -+-- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7342#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] #3103: Compiling base with cabal fails.
#3103: Compiling base with cabal fails. -+-- Reporter: Lemmih| Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.10.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: T3103 Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3103#comment:15 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] #3831: SpecConstr should exploit cases where there is exactly one call pattern
#3831: SpecConstr should exploit cases where there is exactly one call pattern -+-- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.13 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time performance bug Difficulty: Unknown |Testcase: simplCore/should_compile/T3831 Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3831#comment:10 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] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate
#3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 6.12.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related: #4139 | -+-- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3927#comment:27 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] #4012: Compilation results are not deterministic
#4012: Compilation results are not deterministic ---+ Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Difficult (2-5 days) Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by igloo): Hmm, OK. I was going to suggest a final renaming pass (in which only generated names get renamed) and ''not'' throwing the result away, so that it's easier to understand when the hash is or isn't changing. But I think that would be worse, because then the -ddump-simpl etc names wouldn't match the final names. So your !DeBruijn idea sounds best to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4012#comment:35 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] #4321: Unexpected stack overflow prevented by superfluous type annotation
#4321: Unexpected stack overflow prevented by superfluous type annotation ---+ Reporter: bjpop | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler |Version: 7.5 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: T4321 | Blockedby: Blocking:|Related: ---+ Changes (by igloo): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4321#comment:20 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] #5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64
#5019: OS X: ld: warning: could not create compact unwind for _ffi_call_unix64 ---+ Reporter: altaic | Owner: Type: bug | Status: new Priority: high| Milestone: 7.8.1 Component: Compiler| Version: 7.1 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Incorrect warning at compile-time Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: = Unknown * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5019#comment:21 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] #5407: ghc-7.2.1 build failed on sparc solaris with non-GNU linker
#5407: ghc-7.2.1 build failed on sparc solaris with non-GNU linker -+-- Reporter: maeder| Owner: igloo Type: bug | Status: patch Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Keywords:| Os: Solaris Architecture: sparc | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5407#comment:11 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] #5442: ghc-pkg unregister --user/--global/--package-conf not normative
#5442: ghc-pkg unregister --user/--global/--package-conf not normative -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: ghc-pkg | Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5442#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] #5780: -faggressive-primops change caused a failure in perf/compiler/parsing001
#5780: -faggressive-primops change caused a failure in perf/compiler/parsing001 -+-- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.2.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5780#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
[GHC] #7424: Add Data.Bits instance for Bool
#7424: Add Data.Bits instance for Bool -+-- Reporter: Aninhumer | Owner: Type: feature request | Status: new Priority: normal| Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea. I have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7424 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] #7425: Add method to Data.Bits for creating zeroed values.
#7425: Add method to Data.Bits for creating zeroed values. -+-- Reporter: Aninhumer | Owner: Type: feature request | Status: new Priority: normal| Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking:|Related: -+-- The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission. The new method could be given an implementation in terms of the existing ones for backwards compatibility. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7425 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] #6022: GHC infers over-general types
#6022: GHC infers over-general types -+-- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: = simonpj * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6022#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
Re: [GHC] #5831: space_leak_001(ghci) segfaults on OS X x86_64
#5831: space_leak_001(ghci) segfaults on OS X x86_64 ---+ Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Compiler |Version: 7.5 Resolution: worksforme| Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = worksforme Comment: I was going to test whether dynamic-by-default fixed this, but now I can't reproduce it all. I'll close the ticket, but if the problem re-emerges I'll look into it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5831#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] #6098: debugger does not know the correct type for a newtype field
#6098: debugger does not know the correct type for a newtype field --+- Reporter: phercek| Owner: Type: bug| Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.5 Keywords: debugger bindings | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6098#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] #7056: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve'
#7056: GHCi loadArchive libiconv.a:failed Unknown PEi386 section name `.drectve' ---+ Reporter: songpp | Owner: Type: bug | Status: new Priority: high| Milestone: 7.6.2 Component: GHCi| Version: 7.4.1 Keywords: loadArchive Unknown PEi386 | Os: Windows Architecture: x86 | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: 3658|Blocking: Related: #2487, #7103| ---+ Changes (by igloo): * blockedby: = 3658 Comment: This would be fixed by dynamic-by-default. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7056#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] #7062: Spurious undefined reference to `openpty'
#7062: Spurious undefined reference to `openpty' ---+ Reporter: simonmar | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.6.2 Component: Compiler |Version: 7.4.2 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = infoneeded Comment: The test is passing in HEAD for me, and isn't listed as a failure in http://www.haskell.org/pipermail/cvs-ghc/2012-November/078417.html Can you tell me how I can reproduce a problem, please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7062#comment:25 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] #7103: Compiler panic, when loading wxc in GHCi
#7103: Compiler panic, when loading wxc in GHCi
-+--
Reporter: Henk-Jan | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.6.2
Component: GHCi | Version: 7.4.2
Keywords:| Os: Windows
Architecture: Unknown/Multiple | Failure: GHCi crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Description changed by igloo:
Old description:
Loading package wxc-0.90.0.4 ... interactive: Unknown PEi386 section
name `.idata$4' (while processing:
C:\Programs\wxWidgets-2.9.3\lib\gcc_dll\libwxmsw29u_xrc.a)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
loadArchive
C:\\Programs\\wxWidgets-2.9.3\\lib\\gcc_dll\\libwxmsw29u_xrc.a: failed
New description:
{{{
Loading package wxc-0.90.0.4 ... interactive: Unknown PEi386 section
name `.idata$4' (while processing:
C:\Programs\wxWidgets-2.9.3\lib\gcc_dll\libwxmsw29u_xrc.a)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
loadArchive
C:\\Programs\\wxWidgets-2.9.3\\lib\\gcc_dll\\libwxmsw29u_xrc.a: failed
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7103#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] #7103: Compiler panic, when loading wxc in GHCi
#7103: Compiler panic, when loading wxc in GHCi -+-- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.2 Keywords:| Os: Windows Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: 3658 |Blocking: Related:| -+-- Changes (by igloo): * blockedby: = 3658 Comment: This would be fixed by dynamic-by-default. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7103#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
Re: [GHC] #7108: Link to haskell report in prelude
#7108: Link to haskell report in prelude -+-- Reporter: JonasDuregard | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: libraries/base| Version: 7.4.2 Keywords: documentation | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7108#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
Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
#7229: Detecting if a process was killed by a signal is impossible --+- Reporter: benmachine | Owner: Type: bug| Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * milestone: 7.6.2 = 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7229#comment:12 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] #7043: 32-bit GHC ceiling of negative float SEGFAULT: 11
#7043: 32-bit GHC ceiling of negative float SEGFAULT: 11 --+- Reporter: DrGodCarl | Owner: igloo Type: bug| Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: Segfault, ceiling, segmentation fault | Os: MacOS X Architecture: Other | Failure: GHCi crash Difficulty: Unknown|Testcase: ceiling (-0.8) Blockedby: 3658 |Blocking: Related: | --+- Changes (by igloo): * blockedby: = 3658 Comment: This doesn't happen if dynamic-by-default is enabled. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7043#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] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17
---+
Reporter: PaulJohnson | Owner:
Type: bug | Status: new
Priority: high| Milestone: 7.6.2
Component: Compiler| Version: 7.4.2
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Building GHC failed
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Description changed by igloo:
Old description:
On Fedora 17 the build fails when attempting to run configure. The
relevant section says:
checking for ncurses.h... yes
checking for setupterm in -lncursesw... no
checking for setupterm in -lncurses... no
checking for setupterm in -lcurses... no
configure: error: in `/home/paj/packages/ghc-7.4.2/libraries/terminfo':
configure: error: curses library not found, so this package cannot be
built
The relevant section from config.log says:
configure~:3285: gcc -o conftest -g -O2 conftest.c -lncursesw 5
/usr/bin/ld: /tmp/cc1CCCaI.o: undefined reference to symbol 'setupterm'
/usr/bin/ld: note: 'setupterm' is defined in DSO /lib64/libtinfo.so.5 so
try adding it to the linker command line
/lib64/libtinfo.so.5: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
I've set the architecture to x86_64 because thats what I run, but I
expect it would happen on other Fedora 17s as well.
New description:
On Fedora 17 the build fails when attempting to run configure. The
relevant section says:
{{{
checking for ncurses.h... yes
checking for setupterm in -lncursesw... no
checking for setupterm in -lncurses... no
checking for setupterm in -lcurses... no
configure: error: in `/home/paj/packages/ghc-7.4.2/libraries/terminfo':
configure: error: curses library not found, so this package cannot be
built
}}}
The relevant section from config.log says:
{{{
configure~:3285: gcc -o conftest -g -O2 conftest.c -lncursesw 5
/usr/bin/ld: /tmp/cc1CCCaI.o: undefined reference to symbol 'setupterm'
/usr/bin/ld: note: 'setupterm' is defined in DSO /lib64/libtinfo.so.5 so
try adding it to the linker command line
/lib64/libtinfo.so.5: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
}}}
I've set the architecture to x86_64 because thats what I run, but I expect
it would happen on other Fedora 17s as well.
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#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] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17 ---+ Reporter: PaulJohnson | Owner: judah.jacobson@… Type: bug | Status: new Priority: high| Milestone: 7.6.2 Component: Compiler| Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * owner: = judah.jacobson@… Comment: Hmm, the nightly builders have libtinfo, so odd that they didn't run into this. Judah, this looks like a bug in the terminfo configure script; could you take a look please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#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
[GHC] #7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo
#7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo --+- Reporter: luqui | Owner: Type: bug| Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: module, import Os: MacOS X| Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Blockedby: Blocking: |Related: --+- We recently got into a situation on a team where two developers had two different versions of a module with many exports installed, and we were using a compatible subset of both versions. I then introduced a symbol (say X) with the same name as an export from one of the versions. Because GHC raises a fatal error on import Foo hiding (X) when X is not exported by Foo, we had no way to have X refer to the local definition -- since if hiding (X) was present, my GHC would error, and if it wasn't, he would get ambiguous reference errors. The alternative would be to list all symbols except X in the import list (there were a good couple hundred). But isn't that what hiding (X) is supposed to be short for anyway? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7426 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] #7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo
#7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo ---+ Reporter: luqui | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler| Version: 7.4.1 Keywords: module, import | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: = Unknown Comment: FWIW, one option is to use a qualified name for `X`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7426#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] #7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo
#7426: import Foo hiding (X) should not be a fatal error when X is not exported by Foo ---+ Reporter: luqui | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler| Version: 7.4.1 Keywords: module, import | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by guest): Isn't this a dup of #7167, which is fixed in 7.6.1? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7426#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] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17 ---+ Reporter: PaulJohnson | Owner: judah.jacobson@… Type: bug | Status: new Priority: high| Milestone: 7.6.2 Component: Compiler| Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by judahj): It seems that ncurses was changed recently (?) to allow splitting off the terminfo-specific functionality into a separate library. The fix should be pretty simple; just edit configure.ac and change AC_CHECK_LIB(ncursesw, setupterm, HaveLibCurses=YES; LibCurses=ncursesw, [AC_CHECK_LIB(ncurses, setupterm, HaveLibCurses=YES; LibCurses=ncurses, [AC_CHECK_LIB(curses, setupterm, HaveLibCurses=YES; LibCurses=curses, HaveLibCurses=NO; LibCurses=not-installed)])]) adding an extra line to try tinfo first, and otherwise fall back to the above curses variants. Unfortunately, I don't have a system with libtinfo to test this on. Can someone please confirm whether that fixes the problem? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#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] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17
---+
Reporter: PaulJohnson | Owner: judah.jacobson@…
Type: bug | Status: new
Priority: high| Milestone: 7.6.2
Component: Compiler| Version: 7.4.2
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Building GHC failed
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by judahj):
Replying to [comment:4 judahj]:
Sorry, messed up the formatting:
{{{
AC_CHECK_LIB(ncursesw, setupterm, HaveLibCurses=YES; LibCurses=ncursesw,
[AC_CHECK_LIB(ncurses, setupterm, HaveLibCurses=YES; LibCurses=ncurses,
[AC_CHECK_LIB(curses, setupterm, HaveLibCurses=YES; LibCurses=curses,
HaveLibCurses=NO; LibCurses=not-installed)])])
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#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
Re: [GHC] #7108: Link to haskell report in prelude
#7108: Link to haskell report in prelude
+---
Reporter: JonasDuregard | Owner: igloo
Type: bug| Status: closed
Priority: high | Milestone: 7.6.2
Component: libraries/base |Version: 7.4.2
Resolution: fixed | Keywords: documentation
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Documentation bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Changes (by igloo):
* status: new = closed
* resolution: = fixed
Comment:
The one in this ticket is fixed by
{{{
commit df39704e33c0f1cf6101daab79c573f354e38a6a
Author: Ian Lynagh i...@well-typed.com
Date: Sat Nov 17 20:02:37 2012 +
Improve the Prelude doc header; part of #7108
It no longer refers to a particular version of the language standard.
It now includes a note about how it is implicitly imported, and
it looks like the other documentation from the language report
is already included in the haddock docs.
}}}
The others I found are ''comparing'' to H98/H2010, so changing them to
refer to generic standard Haskell may be confusing if the comparison
isn't true for future versions. I've updated the ones I found to refer to
H2010, though.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7108#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] #7421: Data.List.insert / insertBy do not match the documentation
#7421: Data.List.insert / insertBy do not match the documentation +--- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: |Related: +--- Comment(by Bart Massey): Probably should add or at the end if no such position exists. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7421#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: Generating random type-level naturals
Wren, Nicolas, Edward, I'm grateful for your input. I'll sit down soon to take
a closer look at your suggestions and code, and at the papers you've
recommended.
My thanks,
Eric
On Nov 16, 2012, at 15:08 , Edward Kmett ekm...@gmail.com wrote:
In
https://github.com/ekmett/rounded/blob/master/src/Numeric/Rounded/Precision.hs
I borrow GHC's type level naturals for use directly as the reflection of a
number of bits of precision.
That lets you work with `Rounded TowardZero Double` for the type of a number
that offers 53 bits of mantissa and a known rounding mode or `Rounded
TowardZero 512` to get a number with 512 bits of mantissa or you can use
reifyPrecision :: Int - (forall (p :: *). Precision p = Proxy p - a) - a
to constructo a type p that you can use for `Rounded TowardZero p`.
This is how I piggyback on GHC's type-nats support. It'll get nicer once the
actual solver is available and you can compute meaningfully with type level
naturals.
-Edward
On Fri, Nov 16, 2012 at 12:33 PM, Nicolas Frisby nicolas.fri...@gmail.com
wrote:
When wren's email moved this thread to the top of my inbox, I noticed that I
never sent this draft I wrote. It gives some concrete code along the line of
Wren's suggestion.
-
The included code uses a little of this (singleton types) and a little of
that (implicit configurations).
http://www.cis.upenn.edu/~eir/papers/2012/singletons/paper.pdf
http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf
As is so often the case with Haskell discussions, I'm not sure if this is
overkill for your actual needs. There might be simpler possible solutions,
but this idea at least matches my rather literal interpretation of your
email.
Also, I apologize if this approach is what you meant by (Or, more or less
equivalently, one can't write dependently typed functions, and trying to fake
it at the type-level leads to the original problem.)
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE Rank2Types #-}
module STandIC where
A data type for naturals; I'm assuming you have something like a useful
Arbitrary instance for these.
data Nat = Z | S Nat
The corresponding singleton type.
data Nat1 :: Nat - * where
Z1 :: Nat1 Z
S1 :: Nat1 n - Nat1 (S n)
Reification of a Nat; cf implicit configurations (ie prepose.pdf).
reifyNat :: Nat - (forall n. Nat1 n - a) - a
reifyNat Z k = k Z1
reifyNat (S n) k = reifyNat n $ k . S1
Here's my questionable assumption:
If the code you want to use arbitrary type-level naturals with
works for all type-level naturals, then it should be possible to
wrap it in a function that fits as the second argument to reifyNat.
That may be tricky to do. I'm not sure it's necessarily always possible in
general; hence questionable assumption. But maybe it'll work for you.
HTH. And I apologize if it's overkill; as Pedro was suggesting, there might
be simpler ways.
On Fri, Nov 16, 2012 at 12:52 AM, wren ng thornton w...@freegeek.org wrote:
On 11/5/12 6:23 PM, Eric M. Pashman wrote:
I've been playing around with the idea of writing a genetic programming
implementation based on the ideas behind HList. Using type-level programming,
it's fairly straighforward to put together a program representation that's
strongly typed, that supports polymorphism, and that permits only well-typed
programs by construction. This has obvious advantages over vanilla GP
implementations. But it's impossible to generate arbitrary programs in such a
representation using standard Haskell.
Imagine that you have an HList-style heterogenous list of arbitrarily typed
Haskell values. It would be nice to be able to pull values from this
collection at random and use them to build up random programs. But that's not
possible because one can't write a function that outputs a value of arbitrary
type. (Or, more or less equivalently, one can't write dependently typed
functions, and trying to fake it at the type-level leads to the original
problem.)
Actually, you can write functions with the necessary dependent types using
an old trick from Chung-chieh Shan and Oleg Kiselyov:
http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf
The first trick is to reify runtime values at the type level, which the above
paper explains how to do, namely: type class hackery.
The second trick is to overcome the issue you raised about not actually
having dependent types in Haskell. The answer to this is also given in the
paper, but I'll cut to the chase. The basic idea is that we just need to be
able to hide our dependent types from the compiler. That is, we can't define:
reifyInt :: (n::Int) - ...n...
but only because we're not allowed to see that pesky n. And the reason we're
not allowed to see it is that it must be some particular fixed value only we
don't know which one. But, if we
[Haskell] ANNOUNCE: Haskell Communities and Activities Report (23rd ed., November 2012)
On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (23rd edition, November 2012) is now available in PDF and HTML formats: http://haskell.org/communities/11-2012/report.pdf http://haskell.org/communities/11-2012/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2013: target deadline for contributions to the May 2013 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Haskell Communities and Activities Report (23rd ed., November 2012)
Dear Janis, thanks for your great work in preparing the report. David Am 17.11.2012 22:03, schrieb Janis Voigtländer: On behalf of all the contributors, I am pleased to announce that the Haskell Communities and Activities Report (23rd edition, November 2012) is now available in PDF and HTML formats: http://haskell.org/communities/11-2012/report.pdf http://haskell.org/communities/11-2012/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2013: target deadline for contributions to the May 2013 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in April (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] need help with understanding expression
Отправлено с iPhone 17.11.2012, в 11:19, damodar kulkarni kdamodar2...@gmail.com написал(а): In the second case, why the GHC doesn't give something like? ([Char] (a - t), Num a) = t Because Num is a class of types, while String is a type. In other words, in the expression 3 a ghc doesn't know, what type 3 belongs to, it just knows that it should be of class Num. In particular, it could be of type String - t for some t, ghc wouldn't go over all possible types to see that there is no such instance of Num. On the other hand, in a 3 it knows exactly what type a is, strings are always of one type, String (which is an alias for [Char]). You can enable OverloadedStrings extension, which makes string literals polymorphic; then you'll have your type, which would be something like (IsString (a - b), Num a) = b. Now let's consider the evaluation scenario: Prelude 3 2 interactive:1:0: No instance for (Num (t - t1)) arising from the literal `3' at interactive:1:0-2 Possible fix: add an instance declaration for (Num (t - t1)) In the expression: 3 2 In the definition of `it': it = 3 2 Note, how the GHC suggests us this strange constraint as a possible fix BUT see this: Prelude a 2 interactive:1:0: Couldn't match expected type `t1 - t' against inferred type `[Char]' In the expression: a 2 In the definition of `it': it = a 2 In this case the GHC doesn't even allow us to add any possible fix. Same thing. String is NOT a functional type, and it would never be, while it's possible (and sometimes reasonable) to have a functional type of class Num. Enable OverloadedStrings, and you'll see your desired possible fix.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I killed performance of my code with Eval and Strategies
Just another definition of calculateSeq:
calculateSeq = zipWith ($) (cycle [sin,cos]) . map sqrt
This is just slightly slower than my implementation.
I came up with a better implementation of parallel function:
calculatePar2 :: [Double] - [Double]
calculatePar2 xss = runEval $
concat `fmap` parList (rdeepseq . calculateSeq) (chunk 2048 xss)
chunk :: Int - [a] - [[a]]
chunk _ [] = []
chunk n xs = as : chunk n bs where !(as, bs) = splitAt n xs
This mimics behaviour of parListChunk method. It is faster than my original
calculatePar, but
still 3-4 times slower than sequential version.
Janek
2012/11/15 Janek S. fremenz...@poczta.onet.pl
Do you really mean to calculate the 'sin . sqrt' of just the head of
the
list, or do you mean:
calculateSeq = map (sin . sqrt) ?
Argh.. of course not! That's what you get when you code in the middle of
a night. But in my code I
will not be able to use map because elements will be processed in pairs,
so let's say that my
sequential function looks like this:
calculateSeq :: [Double] - [Double]
calculateSeq [] = []
calculateSeq [x] = [sin . sqrt $ x]
calculateSeq (x:y:xs) = (sin . sqrt $ x) : (cos . sqrt $ y) :
calculateSeq xs
I don't think there's a memory leak. It looks more like you're just
allocating much more than is sane for such a simple function.
On a recent processor, sin . sqrt is two instructions. Meanwhile, you
have
a list of (boxed?) integers being split up, then recombined. That's
bound to hurt the GC.
I am not entirely convinced that my idea of using eval+strategies is
bound to be slow, because
there are functions like parListChunk that do exactly this: split the
list into chunks, process
them in parallel and then concatenate the result. Functions in
Control.Parallel.Strategies were
designed to deal with list so I assume it is possible to process lists in
parallel without GC
problems. However I do not see a way to apply these functions in my
setting where elements of
lists are processed in pairs, not one at a time (parList and parMap will
not do). Also, working
on a list of tuples will not do.
Also, you might want to configure criterion to GC between
runs. That might help.
The -g flag passed to criterion executable does that.
What I'd suggest doing instead, is breaking the input into chucks of,
say,
1024, and representing it with a [Vector]. Then, run your sin.sqrt's on
each vector in parallel. Finally, use Data.Vector.concat to combine
your result.
As stated in my post scriptum I am aware of that solution :) Here I'm
trying to figure what am I
doing wrong with Eval.
Thanks!
Janek
Hope that helps,
- Clark
On Wed, Nov 14, 2012 at 4:43 PM, Janek S. fremenz...@poczta.onet.pl
wrote:
Dear Haskellers,
I am reading Simon Marlow's tutorial on parallelism and I have
problems with correctly using Eval
monad and Strategies. I *thought* I understand them but after writing
some code it turns out that
obviously I don't because parallelized code is about 20 times slower.
Here's a short example
(code + criterion benchmarks):
{-# LANGUAGE BangPatterns #-}
module Main where
import Control.Parallel.Strategies
import Criterion.Main
main :: IO ()
main = defaultMain [
bench Seq $ nf calculateSeq xs
, bench Par $ nf calculatePar xs ]
where xs = [1..16384]
calculateSeq :: [Double] - [Double]
calculateSeq [] = []
calculateSeq (x:xs) = (sin . sqrt $ x) : xs
calculatePar :: [Double] - [Double]
calculatePar xss = runEval $ go xss
where
go :: Strategy [Double]
go [] = return []
go xs = do
lsh - (rpar `dot` rdeepseq) $ calculateSeq as
lst - go bs
return (lsh ++ lst)
where
!(as, bs) = splitAt 8192 xs
Compiling and running with:
ghc -O2 -Wall -threaded -rtsopts -fforce-recomp -eventlog evalleak.hs
./evalleak -oreport.html -g +RTS -N2 -ls -s
I get:
benchmarking Seq
mean: 100.5990 us, lb 100.1937 us, ub 101.1521 us, ci 0.950
std dev: 2.395003 us, lb 1.860923 us, ub 3.169562 us, ci 0.950
benchmarking Par
mean: 2.233127 ms, lb 2.169669 ms, ub 2.296155 ms, ci 0.950
std dev: 323.5201 us, lb 310.2844 us, ub 344.8252 us, ci 0.950
That's a hopeless result. Looking at the spark allocation everything
looks fine:
SPARKS: 202 (202 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
But analyzing eventlog with ThreadScope I see that parallel function
spends most of the time doing
garbage collection, which suggests that I have a memory leak
somewhere. I
suspected that problem
might be caused by appending two lists together in the parallel
implementation, but replacing
this with difference
[Haskell-cafe] List all multiply/add combinations
Given a list of numbers of fixed length I need to list all possible values (and the associated computation) you get by inserting +,-,*,/ between the numbers, and also set parentheses where you please. It shouldn't list computations with unnecessary parentheses. Example list of length 3 [a,b,c] and only with + and *: a*b+c, a*(b+c),a*b*c,a+b*c,(a+b)*c,a+b+c What would be a good way to do this, and a good representation in Haskell? Best, Rune ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Custom Enum instance with non-consecutive indices
All, I've been working on a server implementation of an existing networking protocol. The protocol uses magic constants in some places (e.g. to tag message types), as well as bitfields, or a combination of both packed in a single value. I created data types for both the identifiers as well as the bitfield masks, e.g. import Data.Bits data MessageType = Message1 | Message2 | Message5 data MessageFlag = Flag1 | Flag2 Since I need to be able to get a numeric representation of them, I thought making a custom Enum instance would make sense: instance Enum MessageType where fromEnum a = case a of Message1 - 1 Message2 - 2 Message5 - 5 toEnum n | n == 1 = Message1 | n == 2 = Message2 | n == 5 = Message5 instance Enum MessageFlag where fromEnum a = case a of Flag1 - 1 `shiftL` 0 Flag2 - 1 `shiftL` 1 toEnum n | n == 1 `shiftL` 0 = Flag1 | n == 1 `shiftL` 1 = Flag2 This is not a complete definition (not to mention non-exhaustive pattern matches), so I was wondering what the best practices are to extend this so these instances are 'correct'? I've been trying several approaches, but all of them failed on code like getFlags :: Int - [MessageFlag] getFlags i = filter (\v - (i .. fromEnum v) /= 0) [Flag1 ..] Unless I hard-code all options in the last list, of course, but this is obviously not the intention. Any help or pointers (including This is not how Enum is intended to be used) would be appreciated! Thanks, Nicolas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices
Hi Nicolas, The simplest approach would be to use the standard (derived) Enum instance that would be used for enumerations (like [Flag1..]), and have your own functions to convert to/from magic constants. Roman * Nicolas Trangez nico...@incubaid.com [2012-11-17 15:44:57+0100] All, I've been working on a server implementation of an existing networking protocol. The protocol uses magic constants in some places (e.g. to tag message types), as well as bitfields, or a combination of both packed in a single value. I created data types for both the identifiers as well as the bitfield masks, e.g. import Data.Bits data MessageType = Message1 | Message2 | Message5 data MessageFlag = Flag1 | Flag2 Since I need to be able to get a numeric representation of them, I thought making a custom Enum instance would make sense: instance Enum MessageType where fromEnum a = case a of Message1 - 1 Message2 - 2 Message5 - 5 toEnum n | n == 1 = Message1 | n == 2 = Message2 | n == 5 = Message5 instance Enum MessageFlag where fromEnum a = case a of Flag1 - 1 `shiftL` 0 Flag2 - 1 `shiftL` 1 toEnum n | n == 1 `shiftL` 0 = Flag1 | n == 1 `shiftL` 1 = Flag2 This is not a complete definition (not to mention non-exhaustive pattern matches), so I was wondering what the best practices are to extend this so these instances are 'correct'? I've been trying several approaches, but all of them failed on code like getFlags :: Int - [MessageFlag] getFlags i = filter (\v - (i .. fromEnum v) /= 0) [Flag1 ..] Unless I hard-code all options in the last list, of course, but this is obviously not the intention. Any help or pointers (including This is not how Enum is intended to be used) would be appreciated! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsing different types, same typeclass
Hello everyone, I was wondering if you could help me! So, I have a typeclass Action which defines method run: class Action a where run :: a - Int and two data types that are instances of this typeclass: data A = A Int deriving (Read, Show) instance Action A where run (A n) = n data B = B Int deriving (Read, Show) instance Action B where run (B n) = n Now, I want to parse either A or B from a String. I was thinking about something like this... parseAction :: (Action a, Read a) = String - a parseAction str | (A `isPrefixOf` str = (read :: String - A) str | (B `isPrefixOf` str = (read :: String - B) str The problem is that when calling parseAction I get ambiguous type constraints. How to implement a parse function for two distinct types that share the same typeclass Action. Because after calling parseAction I don't whether A or B was returned: I only care that they are Action instances so I can call run. Best regards, José ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
This smells like homework to me, which isn't a bad thing, it will however change the way I answer you. Please look at http://hackage.haskell.org/packages/archive/base/latest/doc/ html/Data-List.html#v:permutations and show us your attempts to use this function. Timothy -- Původní zpráva -- Od: Rune Harder Bak r...@bak.dk Datum: 17. 11. 2012 Předmět: [Haskell-cafe] List all multiply/add combinations Given a list of numbers of fixed length I need to list all possible values (and the associated computation) you get by inserting +,-,*,/ between the numbers, and also set parentheses where you please. It shouldn't list computations with unnecessary parentheses. Example list of length 3 [a,b,c] and only with + and *: a*b+c, a*(b+c),a*b*c,a+b*c,(a+b)*c,a+b+c What would be a good way to do this, and a good representation in Haskell? Best, Rune ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe (http://www.haskell.org/mailman/listinfo/haskell-cafe)___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices
On Sat, 2012-11-17 at 16:52 +0200, Roman Cheplyaka wrote: Hi Nicolas, The simplest approach would be to use the standard (derived) Enum instance that would be used for enumerations (like [Flag1..]), and have your own functions to convert to/from magic constants. Sure, but that kind-of defeats the purpose... fromEnum/toEnum would then return some nonsensical integer value. Nicolas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices
Nicolas Trangez nico...@incubaid.com writes: On Sat, 2012-11-17 at 16:52 +0200, Roman Cheplyaka wrote: Hi Nicolas, The simplest approach would be to use the standard (derived) Enum instance that would be used for enumerations (like [Flag1..]), and have your own functions to convert to/from magic constants. Sure, but that kind-of defeats the purpose... fromEnum/toEnum would then return some nonsensical integer value. ...then don't derive an 'Enum' instance for that :-) what do you hope to gain from making your flags type an instance of the Enum class? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices
On Sat, 2012-11-17 at 16:27 +0100, Herbert Valerio Riedel wrote: what do you hope to gain from making your flags type an instance of the Enum class? Among others, the ability to list all flags using [Flag1 ..] How is this handled for libraries wrapping C libs which use some bitset structure? Nicolas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices
* Nicolas Trangez nico...@incubaid.com [2012-11-17 16:23:28+0100] On Sat, 2012-11-17 at 16:52 +0200, Roman Cheplyaka wrote: Hi Nicolas, The simplest approach would be to use the standard (derived) Enum instance that would be used for enumerations (like [Flag1..]), and have your own functions to convert to/from magic constants. Sure, but that kind-of defeats the purpose... fromEnum/toEnum would then return some nonsensical integer value. What's your purpose, exactly? I see two of them — being able to use enumerations, and converting from/to magical constants. If you want to use toEnum/fromEnum for conversions so badly, you can leave them as you defined them, but redefine the enumFrom* methods from the Enum class. But I'd still advise that you do your conversion outside of the Enum class, since such instance would be very unintuitive to someone who reads or uses your code. BTW, the value of the derived fromEnum is not nonsensical — it determines where in the [Flag1..] list a particular flag would appear. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Participation: Programming Languages Mentoring Workshop - a POPL workshop.
Apologies for any duplicates: CALL FOR PARTICIPATION SIGPLAN Programming Languages Mentoring Workshop, Rome Tuesday January 22, 2013 Co-located with POPL 2013 PLMW web page: http://www.doc.ic.ac.uk/~gds/PLMW/index.html After the resounding success of the first Programming Languages Mentoring Workshop at POPL 2012, we proudly announce the 2nd SIGPLAN Programming Languages Mentoring Workshop (PLMW), co-located with POPL 2013 and organised by Nate Foster, Philippa Gardner, Alan Schmitt, Gareth Smith, Peter Thieman and Tobias Wrigstad. The purpose of this mentoring workshop is to encourage graduate students and senior undergraduate students to pursue careers in programming language research. This workshop will provide technical sessions on cutting-edge research in programming languages, and mentoring sessions on how to prepare for a research career. We will bring together leaders in programming language research from academia and industry to give talks on their research areas. The workshop will engage students in a process of imagining how they might contribute to our research community. We especially encourage women and underrepresented minority students to attend PLMW. Since PLMW will be in Rome this year, we particularly look forward to seeing Eastern European students at the workshop. This workshop is part of the activities surrounding POPL, the Symposium on Principles of Programming Languages, and takes place the day before the main conference. One goal of the workshop is to make the POPL conference more accessible to newcomers. We hope that participants will stay through the entire conference, and will also attend the POPL tutorials on Monday 21st January which are free to PLMW registered attendees. Through the generous donation of our sponsors, we are able to provide scholarships to fund student participation. These scholarships will cover reasonable expenses (airfare, hotel and registration fees) for attendance at both the workshop and the POPL conference. Students attending this year will get one year free student membership of SIGPLAN The workshop registration is open to all. Students with alternative sources of funding are welcome. APPLICATION for PLMW scholarship: The scholarship application can be accessed from the workshop web site (http://www.doc.ic.ac.uk/~gds/PLMW/index.html). The deadline for full consideration of funding is 9th December, 2012. Selected participants will be notified from Friday 14th December, and will need to register for the workshop by December 24th. SPONSORS: Imperial College London Jane Street Monoidics NSF Resource Reasoning SIGPLAN vmware ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
It might be rare that a real world problem can be formulated as such a simple mathematical challenge, so I can't blame you for thinking about home work. I did too. Actually it's part of a logic puzzle I'm implementing. Attacking the problem textually, I can treat the list of infix operators as char, and insert parentheses in all possible configurations. Then remove the illegal and unnecessary one. To get the result, I then need to parse the string. That seems slow, and awkward. I need to do hundreds of thousands of these calculations. I could then work directly with parsing trees, and generate all binary trees of fixed lengths. But most of them would be unnecessary, so it seems like I'm attacking it from the wrong angle. I get that using permutations you can get rid of the need for parentheses, but you also get a lot of impossible calculations (like a*c+b in the example before). It's also not straight forward to go back to the original representation with parentheses. But maybe I'm missing something obvious here? On Sat, Nov 17, 2012 at 4:18 PM, timothyho...@seznam.cz wrote: This smells like homework to me, which isn't a bad thing, it will however change the way I answer you. Please look at http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-List.html#v:permutations and show us your attempts to use this function. Timothy -- Původní zpráva -- Od: Rune Harder Bak r...@bak.dk Datum: 17. 11. 2012 Předmět: [Haskell-cafe] List all multiply/add combinations Given a list of numbers of fixed length I need to list all possible values (and the associated computation) you get by inserting +,-,*,/ between the numbers, and also set parentheses where you please. It shouldn't list computations with unnecessary parentheses. Example list of length 3 [a,b,c] and only with + and *: a*b+c, a*(b+c),a*b*c,a+b*c,(a+b)*c,a+b+c What would be a good way to do this, and a good representation in Haskell? Best, Rune ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
Instead of attacking the problem textually, try to create a datatype which would describe your expressions, then generate all values of this datatype, filter those you don’t need, and convert the rest into Strings. Currently your expressions are represented by “String” — conversion is very cheap, but filtering is “hard” (since it boils down to parsing). Binary trees would suit you better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
Sorry! I replied without reading your message properly. I could then work directly with parsing trees, and generate all binary trees of fixed lengths. But most of them would be unnecessary, so it seems like I'm attacking it from the wrong angle. They won’t be unnecessary if you generate them in a right way. I will think about it and reply with a detailed answer as soon as possible. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On 09/11/2012 18:35, Clark Gaebel wrote: I think we just use dependencies different things. This is a problem inherent in cabal. When I (and others) specify a dependency, I'm saying My package will work with these packages. I promise. When you (and others) specify a dependency, you're saying If you use a version outside of these bounds, my package will break. I promise. They're similar, but subtly different. There are merits to both of these strategies, and it's unfortunate that this isn't specified in the PVP [1]. I always understood that the policy was the former, i.e. allowing a version means you positively expect it to work. Otherwise, why does the PVP insist on upper bounds? You can't in general know that the package will break with a version that doesn't exist yet. As this thread and others show, there is of course a substantial set of people that would prefer the policy to be the latter. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
The following algorithm generates all possible expressions and throws away most of unnecessary duplicates. import qualified Data.Map as M data Expr = Num Int | Add Expr Expr | Sub Expr Expr | Mul Expr Expr | Div Expr Expr Rendering function is highly imperfect. Either write one yourself, or change the definition of Expr to something like “Num Int | App Op [Expr]” — this way rendering would become much easier. render :: Expr - String render (Num n) = show n render (Add a b) = ( ++ render a ++ + ++ render b ++ ) render (Sub a b) = ( ++ render a ++ - ++ render b ++ ) render (Mul a b) = ( ++ render a ++ * ++ render b ++ ) render (Div a b) = ( ++ render a ++ / ++ render b ++ ) Let’s assume that we have lN numbers. nums = [1, 2, 3] lN = length nums Our goal is to build table of all possible expressions, which can be build using numbers from i-th to j-th, where i, j are in range from 0 to lN-1. We have to fill the table in the following order: numbers themselves, expressions consisting of two numbers, three, four, … N. table :: M.Map (Int, Int) [Expr] table = M.fromList $ [((i, i), [Num n] ) | (i, n) - zip [0..lN-1] nums] ++ [((i, j), calc i j) | i - [0..lN-1], j - [i+1,i+2..lN-1]] answer = table M.! (0, lN-1) Our next goal is a function which fills this table: calc :: Int - Int - [Expr] calc i j = do --elements from i to k will form one branch, k+1 to j — another k - [i,i+1..j-1] le - table M.! (i, k) re - table M.! (k+1, j) We don’t want to generate both (a+b)+c and a+(b+c), or (a+b)-c and a+(b-c), or (a-b)-c and a-(b+c), or (a-b)+c and a-(b-c), so we’re eliminating the second variant in each pair. Multiplication and division follow the same pattern. case re of Add _ _ - [Mul le re, Div le re] Sub _ _ - [Mul le re, Div le re] Mul _ _ - [Add le re, Sub le re] Div _ _ - [Add le re, Sub le re] otherwise - [Add le re, Sub le re, Mul le re, Div le re] Here are generated expressions: 1*(2+3) 1/(2+3) 1*(2-3) 1/(2-3) 1+(2*3) 1-(2*3) 1+(2/3) 1-(2/3) (1+2)+3 (1+2)-3 (1+2)*3 (1+2)/3 (1-2)+3 (1-2)-3 (1-2)*3 (1-2)/3 (1*2)+3 (1*2)-3 (1*2)*3 (1*2)/3 (1/2)+3 (1/2)-3 (1/2)*3 (1/2)/3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List all multiply/add combinations
Indentation messed up… I have pasted the code here: http://hpaste.org/77864 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing different types, same typeclass
Being concrete, all you can do is: parseAction :: String - Either A B parseAction str | (A `isPrefixOf` str = Left $ read str | (B `isPrefixOf` str = Right $ read str parseAction :: String - Int parseAction str | (A `isPrefixOf` str = run $ (read str :: A) | (B `isPrefixOf` str = run $ (read str :: B) As you can't return a polymorphic /a/ when you have typed the cases to A or B. Being less concrete, no doubt you can use existentials, but at this point I'd recommend you re-evaluate what you are trying to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing different types, same typeclass
Hey Stephen, Thank you for the reply! Can you elaborate on how I can use existentials? I always up for learning new (Haskell) stuff :) Cheers, José On 18-11-2012 00:19, Stephen Tetley wrote: Being concrete, all you can do is: parseAction :: String - Either A B parseAction str | (A `isPrefixOf` str = Left $ read str | (B `isPrefixOf` str = Right $ read str parseAction :: String - Int parseAction str | (A `isPrefixOf` str = run $ (read str :: A) | (B `isPrefixOf` str = run $ (read str :: B) As you can't return a polymorphic /a/ when you have typed the cases to A or B. Being less concrete, no doubt you can use existentials, but at this point I'd recommend you re-evaluate what you are trying to do. -- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Replying somewhere random in the thread. Linux distributions have to solve this same problem. We first need to decide what Hackage's function is supposed to be: (1) A dumb repository to host Haskell code (2) A collection of Haskell packages that work together In reality it's (1), but the existence of cabal-install supposes (2). The way that distributions handle this is to assign maintainers to each and every package in the distro, and require them all to be actively maintained. Packages that don't build or have unresponsive upstreams are removed. Maintainers who don't do their jobs are removed after a while, too. The end result is that there are somewhat fewer packages /visible/ to the user, but a comparable amount /available/, since what's in the distro is what actually would have worked if the user tried to build it himself. I think there's value to having (1), but that we shouldn't expect (2) at the same time. Tons of work goes into QA'ing packages to work together. Someone needs to be responsible for making sure that things work; right now no one is, so they don't. Running a Haskell distro on a parallel Hackage would be a lot of work but Arch, Debian, Gentoo, etc. already have to do essentially that. It may make sense to either consolidate the effort, or reuse what work is already being done. The gentoo-haskell[1] project already keeps a list of packages that are known to build from source together. Something like prefix[2] for example could be used to install packages that have been vetted rather than just pulling a tarball with the right name directly from Hackage. Or if that's too much trouble, we could write a reverse hackport[3] that creates a second Hackage full of stuff known to work in the various distributions. No solution will be great at first, but we have the benefit that it doesn't work right now either so maybe nobody will notice. Without everyone duplicating the QA effort, I think things would shape up quickly. [1] https://github.com/gentoo-haskell/gentoo-haskell [2] http://www.gentoo.org/proj/en/gentoo-alt/prefix/ [3] http://hackage.haskell.org/package/hackport ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I killed performance of my code with Eval and Strategies
Dear Janek, I am reading Simon Marlow's tutorial on parallelism and I have problems with correctly using Eval monad and Strategies. I *thought* I understand them but after writing some code it turns out that obviously I don't because parallelized code is about 20 times slower. Here's a short example (code + criterion benchmarks): Actually, (sin . sqrt) is simply too cheap. The overhead of constructing chunks (which have to be constructed on the heap) and concatenating the results far outweighs the cost of computing the list elements. If, for example, you replace sin . sqrt by f defined by f :: Double - Double f x | x 10 = x*x | otherwise = sin x * f (x-100) the picture will change. The loss also becomes far less dramatic if you construct the chunks outside of the benchmark: main :: IO () main = defaultMain [ bench Seq $ nf (map calculateSeq) xs , bench Par $ nf calculatePar xs ] where xs = chunk 2048 [1..16384] f, f' :: Double - Double f x = sqrt (sin x) f' x | x 10 = x*x | otherwise = sin x * f' (x-100) calculateSeq :: [Double] - [Double] calculateSeq [] = [] calculateSeq (x:xs) = f x : calculateSeq xs calculatePar :: [[Double]] - [[Double]] calculatePar xss = runEval $ parList (rdeepseq . calculateSeq) xss chunk :: Int - [a] - [[a]] chunk _ [] = [] chunk n xs = as : chunk n bs where !(as, bs) = splitAt n xs The parallel version (with f = sqrt . sin) is still somewhat slower than the sequential version with -N1 -- probably due to rdeepseq. Best regards, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] need help with understanding expression
On 12-11-17 02:19 AM, damodar kulkarni wrote: Let's see tthis: Prelude :t 3 a 3 a :: (Num ([Char] - t)) = t No complaint from GHC; but now see this: Prelude :t a 3 interactive:1:0: Couldn't match expected type `t1 - t' against inferred type `[Char]' In the expression: a 3 Why does it not fail for (:t 3 a) but does fail for (:t a 3)? 3 is polymorphic, a is monomorphic (exactly [Char]). To make a polymorphic, turn on OverloadedStrings: :set -XOverloadedStrings :type a a :: Data.String.IsString a = a :type a 3 a 3 :: (Num a, Data.String.IsString (a - t)) = t Success! This is clearly depravity. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing different types, same typeclass
Hello José, So, I have a typeclass Action which defines method run: class Action a where run :: a - Int (snipped) Now, I want to parse either A or B from a String. I was thinking about something like this... parseAction :: (Action a, Read a) = String - a parseAction str | (A `isPrefixOf` str = (read :: String - A) str | (B `isPrefixOf` str = (read :: String - B) str The problem is that when calling parseAction I get ambiguous type constraints. How to implement a parse function for two distinct types that share the same typeclass Action. Because after calling parseAction I don't whether A or B was returned: I only care that they are Action instances so I can call run. The problem with your current type: (Action a, Read a) = String - a is that it actually means: For any type that implements Action and Read, I can convert a string to that type. This is wrong because if a user of your module added another type C, your function wouldn't be able to handle it -- it only knows about A and B. That is what GHC is trying to tell you. How you can solve this problem depends on what you're trying to do. If there is a finite number of actions, you can merge them into a single type and remove the type class altogether: data Action = A Int | B Int deriving (Read, Show) run :: Action - Int run (A x) = x run (B x) = x parse :: String - Action parse = read If you have a possibly unlimited number of possible actions, there are many approaches to this -- including, as Stephen said, existential types. However, it's hard to decide on a proper solution without knowing what you're actually trying to do. Chris Best regards, José ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
