[GHC] #5636: LLVM: popcnt instruction doesn't compile in LLVM 3.0
#5636: LLVM: popcnt instruction doesn't compile in LLVM 3.0 -+-- Reporter: dterei| Owner: dterei Type: bug | Status: new Priority: normal| Component: Compiler (LLVM) Version: 7.2.1 |Keywords: Testcase:| Blockedby: Os: MacOS X |Blocking: Architecture: Unknown/Multiple | Failure: Compile-time crash -+-- LLVM 3.0 compiles the popcnt instruction in a way unsupported by the Mac OSX system assembler. After talking to the LLVM folks it seems that they don't support the OSX system assembler anymore and suggested I use clang. So this ticket is to track changing over to clang. Clang is included with OSX 10.6 and later. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5636 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] #5626: Miscompilation, exception omitted with -O
#5626: Miscompilation, exception omitted with -O ---+ Reporter: michal.palka|Owner: simonpj Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: Compiler| Version: 7.3 Keywords: strictness strict exception miscompilation | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple| Blocking: Architecture: Unknown/Multiple| Failure: Incorrect result at runtime ---+ Comment(by simonmar): Not reproducible with either 7.2.1 or 7.3.2014 (last night's build), but a slightly older build I had does exhibit the bug (7.3.2009). I suspect this was fixed by #5475. I'll add a test and close. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5626#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] #5626: Miscompilation, exception omitted with -O
#5626: Miscompilation, exception omitted with -O --+- Reporter: michal.palka | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler |Version: 7.3 Resolution: fixed| Keywords: strictness strict exception miscompilation Testcase: codeGen/should_run/5626 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | --+- Changes (by simonmar): * status: new = closed * testcase: = codeGen/should_run/5626 * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5626#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] #5223: Make interruptProcessGroupOf interrupt the current process group
#5223: Make interruptProcessGroupOf interrupt the current process group
+---
Reporter: Favonia| Owner: simonmar
Type: feature request| Status: closed
Priority: high | Milestone: 7.4.1
Component: libraries/process |Version: 7.0.3
Resolution: fixed | Keywords: interrupt process group
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
Done:
{{{
commit fdd02c6464cd73b15195f166377675c9aecf052e
Author: Simon Marlow marlo...@gmail.com
Date: Mon Nov 14 15:47:21 2011 +
Make interruptProcessGroupOf interrupt the current process group
(#5223)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5223#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] #5505: Program runs faster with profiling than without
#5505: Program runs faster with profiling than without
-+--
Reporter: simonpj |Owner: simonmar
Type: bug | Status: new
Priority: high |Milestone: 7.4.1
Component: Compiler | Version: 7.0.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by marlowsd@…):
commit b04cc4c7b192a50885871d8ec71c25b6b6475d67
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Nov 15 11:38:23 2011 +
Avoid generating chains of indirections in stack squeezing (#5505)
rts/ThreadPaused.c | 133
---
1 files changed, 73 insertions(+), 60 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5505#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] #5505: Program runs faster with profiling than without
#5505: Program runs faster with profiling than without
---+
Reporter: simonpj | Owner: simonmar
Type: bug | Status: closed
Priority: high | Milestone: 7.4.1
Component: Compiler |Version: 7.0.3
Resolution: fixed | Keywords:
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
Results for the original `UULib` test program after the above patch:
{{{
./UULib +RTS -s
138000
101,854,752 bytes allocated in the heap
38,063,512 bytes copied during GC
9,955,944 bytes maximum residency (5 sample(s))
2,221,040 bytes maximum slop
24 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max
pause
Gen 0 191 colls, 0 par0.04s0.04s 0.0002s
0.0011s
Gen 1 5 colls, 0 par0.05s0.05s 0.0098s
0.0254s
INITtime0.00s ( 0.00s elapsed)
MUT time0.10s ( 0.10s elapsed)
GC time0.09s ( 0.09s elapsed)
EXITtime0.00s ( 0.00s elapsed)
Total time0.20s ( 0.19s elapsed)
%GC time 45.5% (46.1% elapsed)
Alloc rate952,278,461 bytes per MUT second
Productivity 54.3% of total user, 54.9% of total elapsed
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5505#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] #5445: programatica package compilation fails
#5445: programatica package compilation fails +--- Reporter: maeder | Owner: Type: bug| Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler |Version: 7.2.1 Resolution: fixed | Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | +--- Comment(by maeder): I've managed to change the code http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src- distribution/programatica-1.0.0.3.tar.gz -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5445#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
[GHC] #5637: runhaskell ghc panic running netwire 2 demo
#5637: runhaskell ghc panic running netwire 2 demo
+---
Reporter: gareth.rowlands | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.3|Keywords:
Testcase: | Blockedby:
Os: Windows |Blocking:
Architecture: x86 | Failure: None/Unknown
+---
Running the netwire 2 demo at the URL below with runhaskell gives a ghc
panic.
Steps to reproduce:
1 cabal update; cabal install netwire-2.0.1
...
2 get http://hpaste.org/54025 into demo.hs
3 runhaskell .\demo.hs
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
addTickHsExpr
(|/\(@ a{tv a1hy} [sk]).
(netwire-2.0.1:Control.Wire.Trans.Sample.sample{v reZ} [gid])
@ a{tv a1hy} [sk]
@ ghc-prim:GHC.Types.Double{(w) tc 3u}
@ ghc-prim:GHC.Unit.(){(w) tc 40}
@ ghc-prim:GHC.Types.Double{(w) tc 3u}
@ (base:Control.Arrow.Kleisli{tc rcq}
ntghc-prim:GHC.Types.IO{tc 32I})
$dArrowChoice{v a1l8} [lid]
$dArrowClock{v a1l9} [lid]
$dNum{v a1la} [lid]
$dOrd{v a1lb} [lid]
co{tv a1lc} [co]
(((netwire-2.0.1:Control.Wire.Prefab.Random.noise{v rey} [gid])
@ (base:Control.Arrow.Kleisli{tc rcq}
ntghc-prim:GHC.Types.IO{tc 32I})
@ ghc-prim:GHC.Types.Double{(w) tc 3u}
@ ghc-prim:GHC.Unit.(){(w) tc 40}
@ ghc-prim:GHC.Unit.(){(w) tc 40}
$dArrowRandom{v a1or} [lid]
$dRandom{v a1os} [lid] - ghc-prim:GHC.Unit.(){(w) v 71}
[gid[DataCon]]))|)
In contrast, compiling normally and running works fine:
ghc --make demo.hs; .\demo
24 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
OS: Windows 7 x64 SP1
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5637
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] #5505: Program runs faster with profiling than without
#5505: Program runs faster with profiling than without
---+
Reporter: simonpj | Owner: simonmar
Type: bug | Status: closed
Priority: high | Milestone: 7.4.1
Component: Compiler |Version: 7.0.3
Resolution: fixed | Keywords:
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Comment(by marlowsd@…):
commit 9562f18769b18cd44290d14628dd8d9a45e7d898
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Tue Nov 15 15:44:53 2011 +
further fixes to the #5505 fix.
rts/ThreadPaused.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5505#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] #5630: External Core needs love (was: panic! (the 'impossible' happened) with GADT with -fext-core)
#5630: External Core needs love ---+ Reporter: quux|Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.2.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Windows | Blocking: Architecture: x86_64 (amd64) | Failure: Compile-time crash ---+ Comment(by simonpj): External Core is defined by a data type in `coreSyn/ExternalCore.lhs`. This data type has received No Love for years. As a result, it is lagging way behind Core, as is External Core's concrete syntax. For example it does not accommodate GADTs at all, I think. In this particular ticket, we are trying to convert a Coercion from Core to `ExtenalCore.Exp`, but there ''are'' no coercions (yet) in `Exp`. In short, External Core needs some love and attention. (I suspect it's ended up in this state because most people are using the GHC API instead, but the idea of giving Core a proper, printable external realisation remains a good one..) If anyone feels able to draft it into the 21st century I'd be happy to advise. For what it's worth, I think that a promising approach might be to abolish the `ExternalCore` data types in favour of those in `IfaceSyn`, which serve a very similar purpose. The `IfaceSyn` types didn't exist when External Core was first implemented, but they very much do now, and they *cannot* lag. So I suggest that we abandon `ExtCore` as it is, and instead write a printer and parser for `IfaceSyn`. But it needs a volunteer. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5630#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] #5373: -rtsopts is not respected with -dynamic on Windows
#5373: -rtsopts is not respected with -dynamic on Windows -+-- Reporter: simonmar |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.4.1 Component: Compiler | Version: 7.0.4 Keywords:| Testcase: T5373 Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5373#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] #5633: TypeFamilies don't seem to play with LIberalTypeSynonyms
#5633: TypeFamilies don't seem to play with LIberalTypeSynonyms
+---
Reporter: ocharles | Owner:
Type: bug| Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.0.4
Resolution: invalid| Keywords: TypeFamilies
LiberalTypeSynonyms
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: x86
Failure: GHC rejects valid program |
+---
Changes (by simonpj):
* status: new = closed
* resolution: = invalid
Comment:
The first program works because of a non-Haskell98 feature of GHC.
Fundamentally,
type synonyms, and type families, must be fully applied. However with
LiberalTypeSynonyms, GHC fully expands outer type synonyms before
checking for the full application of inner ones. In this example, we
start
with
{{{
foo : Generic Int Id
}}}
where `Id` is not fully applied. However, if `Generic` is a type synonym
we expand it before making the check, so it's now like
{{{
foo :: Id Int
}}}
and lo, `Id` is fully applies.
Now, type synonyms are easy to apply on the fly; it's another thing
entirely with type families, which can get stuck (ie not reduce)
if their arguments are no sufficiently informative Moreover, you can
pattern match on their arguments. For example, if you wrote
{{{
type instance Generic Int Maybe = Bool
}}}
would you expect that to work, with `Maybe` not matching against `Id`?
Presumably not.
The pure type synonyms can always reduce, and never do pattern
matching, so these issue do not arise. I can't see an easy way to
lift the restriction.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5633#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] #5616: TH type quotes cannot contain free type variables
#5616: TH type quotes cannot contain free type variables
---+
Reporter: Lennart | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Template Haskell |Version: 7.2.1
Resolution: invalid | Keywords:
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Comment(by simonpj):
I asked in email: Can’t you pass the whole type?
{{{
inst t = [d| instance $t |]
}}}
You replied. No, you can’t. Both of those give you the error Malformed
instance header.
Indeed! How could we possibly type check the declaration in
{{{
inst t = [d| instance $t where
op x = x+2
|]
}}}
All the usual stuff for type checking instance declarations assumes that
we know the class, and indeed the instantiating types, of an instance
declaration. Else how would we know whether ‘op` came from the right
class, or `op x = x+2` has the right type.
I think the real answer here is in my
[http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal
blog post about Template Haskell].
We can’t reasonably typecheck such declarations, but it is very convenient
to use the quotation syntax. So support the quotation syntax, but don’t
typecheck it. Restrict typechecking of Template Haskell to
''expressions'', and do the Full Job a la !MetaMl. See my blog post.
Here’s another example, even more extreme:
{{{
foo :: Name - Q [Dec]
foo t = [d| $t = MkT Int |]
}}}
Here I want to splice in the ''name'' of the type to be declared.
Reasonable enough, and you can do it if you use explicit constructors, but
totally impossible using quotation syntax.
Do you like the blog post ideas? How much does it matter to you?
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5616#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] #5616: TH type quotes cannot contain free type variables
#5616: TH type quotes cannot contain free type variables ---+ Reporter: Lennart | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Template Haskell |Version: 7.2.1 Resolution: invalid | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by augustss): I like your proposal in the blog post. That said, it doesn't matter to me at all really. I hardly ever use TH, and the one time I used it I pretty quickly came to the conclusion that quotations where pretty much useless for my purposes, so I switched to using Exp. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5616#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] #5628: Deriving Eq on bottom types breaks reflexivity of (==)
#5628: Deriving Eq on bottom types breaks reflexivity of (==)
-+--
Reporter: tinctorius| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.2.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
-+--
Comment(by simonpj@…):
commit 078b891f9d64c70cc72637be9e6a274275244990
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue Nov 15 17:17:28 2011 +
Fix Trac #5628: equality on data types with no constructors
compiler/typecheck/TcGenDeriv.lhs | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5628#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] #5623: GHC 7.2.1 Performance Regression: Vector
#5623: GHC 7.2.1 Performance Regression: Vector
-+--
Reporter: dterei|Owner: simonpj
Type: bug | Status: new
Priority: high |Milestone: 7.4.1
Component: Compiler | Version: 7.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by simonpj@…):
commit 479504030370947ff3e8d62adb193dd492cf5725
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Nov 11 22:04:20 2011 +
Make certainlyWillInline more conservative, so that it is never true
of thunks. Otherwise the worker-wrapper phase can make a thunk into an
unconditionally inline UnfWhen thing, which is Very Bad Thing. Shown up
by Trac #5623.
See Note [certainlyWillInline: be caseful of thunks].
compiler/coreSyn/CoreUnfold.lhs | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5623#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] #5603: Impossible case alternative
#5603: Impossible case alternative
-+--
Reporter: igloo |Owner: simonpj
Type: bug | Status: new
Priority: highest |Milestone: 7.4.1
Component: Compiler | Version: 7.3
Keywords:| Testcase: T5603
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonpj@…):
commit f96db3ca8a7c83cc3da242fad761fb05543068f6
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Wed Nov 9 23:32:20 2011 +
Establish the invariant that (LitAlt l) is always unlifted
...and make sure it is, esp in the call to findAlt in
the mighty Simplifier. Failing to check this led to
searching a bunch of DataAlts for a LitAlt Integer.
Naughty. See Trac #5603 for a case in point.
compiler/basicTypes/Literal.lhs|6 +-
compiler/coreSyn/CoreLint.lhs | 13 ++---
compiler/coreSyn/CoreSyn.lhs | 30 +-
compiler/deSugar/DsUtils.lhs |8 +---
compiler/prelude/PrelRules.lhs |3 +++
compiler/simplCore/Simplify.lhs|2 ++
compiler/specialise/SpecConstr.lhs |4 +++-
7 files changed, 49 insertions(+), 17 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5603#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] #5625: Code using seq has wrong strictness when unoptimised (too lazy)
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
---+
Reporter: michal.palka|Owner: simonpj
Type: bug | Status: new
Priority: high|Milestone: 7.4.1
Component: Compiler| Version: 7.3
Keywords: seq strictness strict lazy | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple| Blocking:
Architecture: Unknown/Multiple| Failure: Incorrect result at
runtime
---+
Comment(by simonpj@…):
commit a522c3b25eea1fe40edae7052335acce75e8a1c3
{{{
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Nov 11 20:08:42 2011 +
Tighten up the definition of arityType a bit further,
to make Trac #5625 work. The main change is that
we eta-expand (case x of p - \y. blah) only if the
case-expression is in the context of a \x. That is still
technically unsound, but it makes a big difference to
performance; and the change narrows the unsound cases
a lot.
compiler/coreSyn/CoreArity.lhs | 140
+++-
1 files changed, 80 insertions(+), 60 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5625#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] #5595: Unification under a forall doesn't allow full constraint solving (was: Type error: expected type = actual type ???)
#5595: Unification under a forall doesn't allow full constraint solving -+-- Reporter: basvandijk|Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5595#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] #5595: Unification under a forall doesn't allow full constraint solving
#5595: Unification under a forall doesn't allow full constraint solving -+-- Reporter: basvandijk|Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by simonpj): See also #4310 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5595#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] #5628: Deriving Eq on bottom types breaks reflexivity of (==)
#5628: Deriving Eq on bottom types breaks reflexivity of (==) -+-- Reporter: tinctorius|Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.2.1 Keywords:| Testcase: deriving/should_run/T5628 Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Incorrect result at runtime -+-- Changes (by simonpj): * testcase: = deriving/should_run/T5628 Comment: Good point, thank you. Fixed as above. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5628#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] #5495: simple program fails with -shared on mac
#5495: simple program fails with -shared on mac
---+
Reporter: mwotton |Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.4.1
Component: Compiler| Version: 7.2.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Compile-time crash
---+
Changes (by igloo):
* owner: igloo =
* priority: high = normal
Comment:
Ah, I hadn't noticed it was ld segfaulting. Here's a cut-down case:
{{{
$ cat h2.s
.text
.globl _Main_main_info
_Main_main_info:
leaq _ghczmprim_GHCziUnit_Z0T_closure(%rip),%rax
jmp _base_GHCziBase_return_info
$ gcc -m64 -fno-stack-protector -c h2.s -o h2.o
$ gcc -m64 -fno-stack-protector -dynamiclib -o h h2.o -undefined
dynamic_lookup
collect2: ld terminated with signal 11 [Segmentation fault: 11]
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
}}}
Interestingly, in 32bit mode we get an error when assembling:
{{{
$ gcc -m32 -fno-stack-protector -c h2.s -o h2.o
h2.s:4:`_ghczmprim_GHCziUnit_Z0T_closure(%rip)' is not a valid base/index
expression
}}}
when compiling with an i386 compiler we instead generate:
{{{
movl $_ghczmprim_GHCziUnit_Z0T_closure+1,-12(%ebp)
}}}
Does anyone know if this is our bug or Apple's?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5495#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] #4310: Deferred equalities and forall types
#4310: Deferred equalities and forall types -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by basvandijk): * cc: v.dijk.bas@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4310#comment:9 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] #5630: External Core needs love
#5630: External Core needs love ---+ Reporter: quux|Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Compiler| Version: 7.2.1 Keywords: | Testcase: Blockedby: | Difficulty: Os: Windows | Blocking: Architecture: x86_64 (amd64) | Failure: Compile-time crash ---+ Comment(by tim): The reason for having the ExternalCore data types is that External Core has a semantics (through the ext-core typechecker and interpreter), and I'm not sure whether IfaceSyn does (though I'm not really familiar with it). (Of course, the semantics probably doesn't reflect GADTs right now...) I'm not really sure I'm up for giving ext-core more love at this point, but I wanted to recommend some caution... Tim -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5630#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] #5635: compiling iteratee with llvm backend fails with panic
#5635: compiling iteratee with llvm backend fails with panic -+-- Reporter: jwlato| Owner: dterei Type: bug | Status: infoneeded Priority: normal| Component: Compiler (LLVM) Version: 7.2.1 |Keywords: llvm, LlvmMangler, panic Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Compile-time crash -+-- Changes (by dterei): * status: new = infoneeded -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5635#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] #5635: compiling iteratee with llvm backend fails with panic
#5635: compiling iteratee with llvm backend fails with panic
-+--
Reporter: jwlato| Owner: dterei
Type: bug | Status: new
Priority: normal| Component: Compiler (LLVM)
Version: 7.2.1 |Keywords: llvm, LlvmMangler, panic
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Compile-time crash
-+--
Changes (by jwlato):
* status: infoneeded = new
Comment:
The .ll file is too big to attach, but I've put it at
http://www.tiresiaspress.us/other/Char.ll
I haven't changed the iteratee source; I just tried building from a fresh
cabal unpack.
I've double-check the ghc version (7.2.1 x64 and 7.2.2 x64), but is there
a good way to check the llvm version? I should only have 2.9 installed,
and e.g. llvm-ld --version shows
{{{
$ llvm-ld --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.9
Optimized build.
Built Nov 15 2011 (03:37:10).
Host: x86_64-apple-darwin11
Host CPU: i686
Registered Targets:
(none)
}}}
Also, the panic only happens when building with profiling enabled.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5635#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] #5635: compiling iteratee with llvm backend fails with panic
#5635: compiling iteratee with llvm backend fails with panic -+-- Reporter: jwlato| Owner: dterei Type: bug | Status: new Priority: normal| Component: Compiler (LLVM) Version: 7.2.1 |Keywords: llvm, LlvmMangler, panic Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: Compile-time crash -+-- Comment(by dterei): Oh ok, the fact that profiling is enabled is probably what stopped me being able to reproduce. Thanks, I'll check again. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5635#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] #5622: Out of memory in such a simple case
#5622: Out of memory in such a simple case
-+--
Reporter: quux| Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|Version: 7.2.1
Resolution: invalid | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Windows
Blocking: | Architecture: x86_64 (amd64)
Failure: Compile-time crash |
-+--
Changes (by simonpj):
* status: new = closed
* resolution: = invalid
Comment:
It is well known that Hindley-Milner type inference has worst-case
exponential time and space, and I think this is one such example.
Remember that GHC fills in the missing type arguments. So if you write
{{{
id True
}}}
GHC translates it to
{{{
id @Bool True
}}}
because we are instantiating id's type with `Bool`. Even compilers that
don't genreate the elaborated program do something internally in the type
inference engine that is more or less the same thing.
Now consider your example, with the type arguments filled in.
{{{
id id True
== id @(Bool - Bool) (id @Bool) True
id id id True
== id @((Bool-Bool) - (Bool-Bool)) (id @(Bool - Bool)) (id @Bool)
True
...and so on
}}}
You can see that the types get big fast. As you add each new `id` the
size of the type doubles; hence the exponential.
Happily type inference is usually fine in practice. But its worst case is
Bad.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5622#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] #5550: GHC infinite loop when compiling vector
#5550: GHC infinite loop when compiling vector -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): I understand the current behaviour. I am proposing a different behaviour! The bit I didn't realise is this: '''We can't mark the types that we actually want to specialise on because they are supplied by the user and might be defined by the user'''. I thought that the loops we wanted to specialise were stream-fusion loops; and they are all generated by library code; and their State types are all known to the library code. So could we not annotate these types as ones we want to specialise away; as I understand it, if the loop state type is (say) `Either` we'd like to generate two mutually recursive functions, one for `Left` states and one for `Right`. (Admittedly with my proposal you could not use `Either`; you'd have to declare a new type so that you could annotate it to be specialised away.) Would that not work? It would have the advantage of avoiding the need for the SPEC argument altogether. I'm sure there's a fatal flaw, but I'm not seeing it yet. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5550#comment:16 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
source/build separation
I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildtrees mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Rusi [ghc noob here: Please tell me if this is the wrong list to ask this kind of question :-) ] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
Empty record patterns {} are permitted, even for types
that are not declared with named fields.
So I don't see why an empty record update should
require the type to be declared with named fields either.
Yes. The translation of record updates given in the Report
makes perfect sense for {}. It is only forbidden by
n = 1, but no reason is given for that restriction.
According to that translation, the type of x {} is
the type of the case expression it translates to.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
On Tue, Nov 15, 2011 at 08:34:01AM +, Malcolm Wallace wrote:
On 14 Nov 2011, at 22:09, Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
f :: a - a
That wouldn't help the original poster, as it is incompatible with
f :: Foo Clean - Foo Dirty
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Why not allow empty record updates?
Hmm yes. Fair enough. Does anyone care enough? I can see (now) that it
wouldn't really be hard.
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Yitzchak Gale
| Sent: 15 November 2011 11:16
| To: Malcolm Wallace
| Cc: GHC-users List
| Subject: Re: Why not allow empty record updates?
|
| Simon Peyton-Jones wrote:
| Trouble is, what type does this have?
| f x = x {}
|
| Malcolm Wallace wrote:
| Empty record patterns {} are permitted, even for types
| that are not declared with named fields.
| So I don't see why an empty record update should
| require the type to be declared with named fields either.
|
| Yes. The translation of record updates given in the Report
| makes perfect sense for {}. It is only forbidden by
| n = 1, but no reason is given for that restriction.
|
| According to that translation, the type of x {} is
| the type of the case expression it translates to.
|
| Thanks,
| Yitz
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Why not allow empty record updates?
| Trouble is, what type does this have?
|
| f x = x {}
|
| f :: a - a
|
| That wouldn't help the original poster, as it is incompatible with
| f :: Foo Clean - Foo Dirty
Ah! *That* is why I said it was awkward. Thanks Ian.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: source/build separation
On 15/11/2011 10:21, Rustom Mody wrote: I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildtrees mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Sure. It's just $ mkdir build $ cd build $ lndir source but lndir is not a standard tool (any more), so you might have to build it yourself. There are sources in the GHC source tree in utils/lndir. Note the GHC build works perfectly well without a separate build tree, and I think that's the way most people do it. Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Right - arguably you can just clone a new source tree for each build that you want. I use separate build trees for two reasons: - my source trees are on a backed-up network file system, but the build trees are on fast local disk. - I can have several builds on different machines all using the same source tree. On my laptop the situation is similar, but my source trees are in my home dir which is an ecryptfs and the build trees are outside on the unencrypted partition. Not only is ecryptfs too slow for building on, it also doesn't work properly (there's some bug related to time stamps that I never managed to narrow down, it results in unnecessary rebuilding). You could do all this with git clones, but it would mean extra shuffling of patches around. If you're happy with that, then that's fine - use whatever scheme you're more comfortable with. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: source/build separation
On Tue, Nov 15, 2011 at 04:47:18PM +, Simon Marlow wrote: You could do all this with git clones, but it would mean extra shuffling of patches around. If you're happy with that, then that's fine - use whatever scheme you're more comfortable with. There's a script in git's contrib directory called 'git-new-workdir'. You can use it to have multiple working directories that share the same git back end. I'll typically do something like: git clone ... mainsrc git new-workdir mainsrc worksrc cd worksrc git checkout -b work .. hack .. git add; git commit cd ../mainsrc git merge work # or cherry-pick or whatever test away I find it helps when making multiple patches to be able to test that the intermediate versions work, without having to mess up my main working tree. To install the script, just copy it somewhere into your path, and make it executable. Or make an executable script in your path like this: #!/bin/sh exec sh /usr/share/doc/git/contrib/workdir/git-new-workdir $@ David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
f :: a - a
Ian Lynagh wrote:
That wouldn't help the original poster, as it is incompatible with
f :: Foo Clean - Foo Dirty
Only because in that expression the type of x is not known.
...the whole feature of type-changing update is (as you know)
a bit obscure and not widely used, so it'd be adding
complexity to an already-dark corner.
To me, at least, that is surprising. The report implies that
record updates are just sugar for the given case expression.
Whether or not it changes a type parameter seems
unimportant.
In fact, I would even advocate adding a line of explanation
in the Report that this is a convenient way of copying
a value from an ADT to itself with a different type
as its parameter. I agree with Malcolm that this is
analogous to using empty record syntax in a pattern
to avoid hard-coding the number of parameter to
a constructor.
I usually avoid using the combination of type parameters and
record syntax altogether, mainly because this obvious syntax
doesn't work. Perhaps that's the reason why type-changing
update is not widely used.
(Admittedly, I didn't think of Herbert's trick. But doesn't
that seem like somewhat of an ugly hack?)
Are you hesitant because of implementation difficulty,
or only because you are worried about the semantics
being confusing? In my opinion, it's more confusing
the way it is now.
Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Quoting Yitzchak Gale g...@sefer.org:
Yes. The translation of record updates given in the Report
makes perfect sense for {}. It is only forbidden by
n = 1, but no reason is given for that restriction.
It doesn't make sense to me. The translation explodes a value into a
case statement over its constructors; what constructors do you use
when you don't know the type of the value?
When n = 1, you know the type of the value by looking where the field
came from, and hence which constructors to use in the case statement.
~d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: instance union proposal
Serge
I'm afraid I don't really follow your proposal in detail, but I think it may be
a version of the proposal described here
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
Perhaps you could see if the design there would meet your goals.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 12 November 2011 10:51
| To: glasgow-haskell-users@haskell.org
| Subject: instance union proposal
|
| Dear Haskell implementors,
|
| I suggest the following small extension to the instance declaration in
| the language. So far -- for Haskell + glasgow-ext.
| I think that they are easy to implement.
| This is the instance union proposal.
| It is needed to write shorter several `old' instance declarations.
| This will make programs easier to read.
| It suggests the so-called
| inherited decl and, more general, union decl.
|
| Inherited instance decl proposal
|
|
| Union several instance declarations with the same condition part and such
| that among the conclusion classes there exists some which inherits all
| others.
| Example 1. My program uses the class tower
|
| Field a Picture 1.
| |
| ERing
| |
| CRing a
| |
| Ring a
|/\
| AddGroup a MulSemigroup a
| | |
| AddSemigroup a |
| \ /
|Set a
|
| -- | means that the upper inherits from the lower.
| Now, by the application meaning, I need to write
|
|instance (Show a, CRing a) = CRing (Pol a)
| where
| implement operations of Set
| implement operations of AddGroup
| ...
| implement operations of CRing
|
| From the class decls it is clear to the compiler that CRing inherits
| all that is lower on the picture. Therefore, the conditional
| `instance (Show a, CRing a) =' and 'where'
| is written only once.
| In the existing language, I need to write this conditional 6 times.
|
|
| Union instance decl proposal
|
|
| It is a generalization for inhereted decl.
|
| instances (cond_1, ..., cond_n) -- of the type parameters a_1 ... a_m
|=
|typeTuple (params) has {conclInstList}
|where
|implement operations for each member of conclInstList.
|
| It differs from the old instance declaration in that
| 1) it unions several old declarations having the same conditional part,
| 2) each member of conclInstList can be conditional,
| 3) in conclInstList it can be skipped any instance which is inherited
| by some other member in this list.
|
| params is a subset of {a_1 ... a_m},
| typeTuple (params)
| is a tuple of type expressions, as in old declaration,
| for example, `(a, b)', `Vector a', `[(a,b), Vector a]'.
| It is the argument for the conclusion instance declarations.
|
| conclInstList is a list of inst-members separated by comma.
| Each member of conclInstList is either an
| old conclusion instance declaration
| or a conditional declaration.
|
| Example.
| In the situtation of Picture 1, I need to declare
|
|instance (Show a, CRing a) =
| (Pol a) has { CRing, if (has a Field) then ERing }
| where
| define operations for Set (Pol a)
| define operations for AddSemigroup (Pol a)
| ...
| define operations for CRing (Polynomial a)
|
| define operations for ERing (Pol a) -- this part has the
|-- additional condition (Field a)
|
| Its meaning is that the complier extends this into several `old'
| instance declarations:
|instance (Show a, CRing a) = Set (Pol a) where
| define operations for Set (Pol a)
|...
|instance (Show a, CRing a) = CRing (Pol a) where
| define operations for Set (Pol a)
|
|instance (Show a, Field a) = ERing (Pol a) where
|define operations for ERing (Pol a)
|
| (in the last decl `Field a' has been moved to LHS).
|
| In this example typeTuple === (Pol a).
| For bi-parametric instances, the concusion part may be, for example
|=
|[a, Pol a] has {Foo1, Foo2} ...
|
| This means the two instance assertions Foo1 a (Pol a), Foo a (Pol a),
| and `[a, Pol a]' is the agrument tuple for the instance conclusions.
|
|
| This is a draft proposal. If the idea is accepted, some generalizations
| and
Re: Why not allow empty record updates?
On 11/15/11 12:33 PM, Yitzchak Gale wrote:
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
f :: a - a
Ian Lynagh wrote:
That wouldn't help the original poster, as it is incompatible with
f :: Foo Clean - Foo Dirty
Only because in that expression the type of x is not known.
...the whole feature of type-changing update is (as you know)
a bit obscure and not widely used, so it'd be adding
complexity to an already-dark corner.
To me, at least, that is surprising. The report implies that
record updates are just sugar for the given case expression.
Whether or not it changes a type parameter seems
unimportant.
In fact, I would even advocate adding a line of explanation
in the Report that this is a convenient way of copying
a value from an ADT to itself with a different type
as its parameter. I agree with Malcolm that this is
analogous to using empty record syntax in a pattern
to avoid hard-coding the number of parameter to
a constructor.
I usually avoid using the combination of type parameters and
record syntax altogether, mainly because this obvious syntax
doesn't work. Perhaps that's the reason why type-changing
update is not widely used.
(Admittedly, I didn't think of Herbert's trick. But doesn't
that seem like somewhat of an ugly hack?)
Are you hesitant because of implementation difficulty,
or only because you are worried about the semantics
being confusing? In my opinion, it's more confusing
the way it is now.
For what it's worth, I do the exact same thing in the project I've been
working on. The phantom type is a clean/dirty bit even :)
It's an incredibly helpful thing to have for records. Especially for the
context I'm in: I'm generating summary data over gobs of input, but the
input can come incrementally. So long as the core of the summary is
correct, then I don't care about maintaining the cache fields while I'm
just shoveling data in; but I do want to make sure the caches are valid
before I try to get any information out. This is exactly the sort of
type-level hackery which makes Haskell a joy to work in and other
languages such a pain.
So far I've just defined helper functions to adjust the phantom type[1],
each of which is implemented by (\x - x { foo = foo x }). It's a
horrible hack, but at least it's hidden away in library functions
instead of something I have to look at. The annoying part is that when I
adjust the members of the records, if I remove or rename foo then I have
to fix all those coercion functions too.
[1] set bit to Clean, set bit to Dirty, and unsafe set bit to 'a'.
--
Live well,
~wren
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why not allow empty record updates?
Sent from my iPad
On Nov 15, 2011, at 7:18 PM, wren ng thornton w...@freegeek.org wrote:
On 11/15/11 12:33 PM, Yitzchak Gale wrote:
Simon Peyton-Jones wrote:
Trouble is, what type does this have?
f x = x {}
Malcolm Wallace wrote:
f :: a - a
Ian Lynagh wrote:
That wouldn't help the original poster, as it is incompatible with
f :: Foo Clean - Foo Dirty
Only because in that expression the type of x is not known.
...the whole feature of type-changing update is (as you know)
a bit obscure and not widely used, so it'd be adding
complexity to an already-dark corner.
To me, at least, that is surprising. The report implies that
record updates are just sugar for the given case expression.
Whether or not it changes a type parameter seems
unimportant.
In fact, I would even advocate adding a line of explanation
in the Report that this is a convenient way of copying
a value from an ADT to itself with a different type
as its parameter. I agree with Malcolm that this is
analogous to using empty record syntax in a pattern
to avoid hard-coding the number of parameter to
a constructor.
I usually avoid using the combination of type parameters and
record syntax altogether, mainly because this obvious syntax
doesn't work. Perhaps that's the reason why type-changing
update is not widely used.
(Admittedly, I didn't think of Herbert's trick. But doesn't
that seem like somewhat of an ugly hack?)
Are you hesitant because of implementation difficulty,
or only because you are worried about the semantics
being confusing? In my opinion, it's more confusing
the way it is now.
For what it's worth, I do the exact same thing in the project I've been
working on. The phantom type is a clean/dirty bit even :)
It's an incredibly helpful thing to have for records. Especially for the
context I'm in: I'm generating summary data over gobs of input, but the input
can come incrementally. So long as the core of the summary is correct, then I
don't care about maintaining the cache fields while I'm just shoveling data
in; but I do want to make sure the caches are valid before I try to get any
information out. This is exactly the sort of type-level hackery which makes
Haskell a joy to work in and other languages such a pain.
So far I've just defined helper functions to adjust the phantom type[1], each
of which is implemented by (\x - x { foo = foo x }). It's a horrible hack,
but at least it's hidden away in library functions instead of something I
have to look at. The annoying part is that when I adjust the members of the
records, if I remove or rename foo then I have to fix all those coercion
functions too.
My biggest issue is loss of sharing, but you could always use
castFoo = asTypeOf unsafeCoerce $ \x - x { foo = foo x }
to maximize sharing, but that doesn't help with the code rewriting,
Or less horrifically just carry the phantom in a newtype wrapper wrapped around
your record, and cast by putting it on and taking it off, which also maximizes
sharing in exchange for newtype noise on access.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] (no subject)
http://poorogies.com/wp-content/plugins/scan.php ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] (no subject)
http://www.myvisionview.com/images/scan.php ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] 1p function for NonEmpty
Hi Edward, I started @telling you on #haskell, but it has become too long for that. :) The following functions would be nice additions to Data.List.NonEmpty in the semigroups package: replicate1p :: Whole n = n - a - NonEmpty a take1p :: Whole n = n - NonEmpty a - NonEmpty a splitAt1p :: Whole n = n - NonEmpty a - (NonEmpty a, [a]) Also, your warnings in the haddocks about blowing up on negative arguments don't seem to be needed for take, drop, and splitAt. We could avoid the problem with negative arguments for (!!) too by providing an alternative for Whole numbers. But in that case the function would still be partial, so I'm not sure if it's worth it. I wish there were some way to get Whole to default to Natural. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1p function for NonEmpty
I wrote: The following functions would be nice additions to Data.List.NonEmpty in the semigroups package... Here are two more requests: maximum, minimum :: Ord a = NonEmpty a - a Two more unsafe Prelude functions become safe! Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problems with installing the correct version of process. Help?
Hi everyone. I'm new to haskell (venturing over from python land); i can't figure this one problem out. This has been incredibly difficult to solve, and it is quite discouraging! i'm trying to get berp up and running ( https://github.com/bjpop/berp/). berp-libs installed fine, berp-compiler is hanging up: From what I can tell, the only hangup I have is that the process package depends on the wrong version of directory. [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 15] 75$ cabal configure Resolving dependencies... Configuring berpcompiler-0.0.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. *package process-1.0.1.3 requires directory-1.0.1.0* package cpphs-1.13.2 requires directory-1.1.0.1 package berplibs-0.0.3 requires directory-1.1.0.1 package berpcompiler-0.0.3 requires directory-1.1.0.1 OK so I need to rebuild process so it uses the newest version of directory like the rest of them (I have no idea if this is the right thing to do, but this is what i did with cpphs and it worked). But when I try and build process, it can't find a header on my file that does exist. I also did successfully install from source package manually (using these instructionshttp://www.haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_packageon the package downloaded from here http://hackage.haskell.org/package/process-1.0.1.3, which worked fine, but didn't seem update the dependency to rely on the newest version of directory (aka still can't configure berp). I don't know where to go from here. Please note: I have installed from source package, so even if I fix this cabal issue I'm not sure it will fix the dependency issue (but who knows, maybe it will). I'm having a hard time scaring up internet resources on where to proceed. What am I doing wrong? Thanks so much in advance, Blaine Reference: 22$ uname -a Linux macbook 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011 x86_64 GNU/Linux (Here I am trying to force include the directory where the missing header file lives. It does exist but cabal won't have it) [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 08] 92$ sudo cabal --extra-include-dirs=/usr/lib/ghc-6.12.1/process-1.0.1.2/include/ install process Resolving dependencies... Configuring process-1.1.0.0... configure: WARNING: unrecognized options: --with-compiler checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for setitimer,... no checking for sysconf... yes checking value of SIG_DFL... -1 checking value of SIG_IGN... -1 configure: creating ./config.status config.status: creating include/HsProcessConfig.h config.status: include/HsProcessConfig.h is unchanged configure: WARNING: unrecognized options: --with-compiler cabal: Missing dependency on a foreign library: ** Missing header file: runProcess.h* This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: process-1.1.0.0 failed during the configure step. The exception was: ExitFailure 1 [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 08] 93$ ls /usr/lib/ghc-6.12.1/process-1.0.1.2/include/ HsProcessConfig.h *runProcess.h* Blaine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
On Tue, Nov 15, 2011 at 14:56, Blaine frik...@gmail.com wrote: ** Missing header file: runProcess.h* [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 08] 93$ ls /usr/lib/ghc-6.12.1/process-1.0.1.2/include/ HsProcessConfig.h *runProcess.h* Notice it's found in the files for the other install of process. This is in fact a bug in the process package on Hackage, which is fixed in its repo but no new release has been made yet. So build it from its repo ( http://darcs.haskell.org/packages/process.git/ per Hackage page) instead. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ST not strict enough?
Hi All, I'm having some trouble with memory usage in rebuilding a ByteString with some sequences escaped. I thought I'd try vectors. However, it seems that even a relatively simple function, one that places all the bytes of a ByteString in to a vector, uses a great deal of memory. I've pulled this function out into a mini-module for testing: https://github.com/solidsnack/arx/blob/ST/Rebuild.hs#L37 On a one megabyte input, it peaks at ~38M of memory: :; dd if=/dev/zero bs=1M count=1 | ./rebuildprof +RTS -s ... 38,724,208 bytes maximum residency (5 sample(s)) 1,983,720 bytes maximum slop 76 MB total memory in use (0 MB lost due to fragmentation) ... %GC time 61.3% (61.5% elapsed) A heap profile by type, with -hy, shows a linear rise in ST items -- up to ~26M -- and then a linear decrease. It would stand to reason that, with sufficient strictness, the memory allocated to ST would stay constant and small. Should I be annotating my functions with strictness, for the vector reference, for example? Should I be using STUArrays, instead? -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
On Tue, Nov 15, 2011 at 1:56 PM, Blaine frik...@gmail.com wrote: Hi everyone. I'm new to haskell (venturing over from python land); i can't figure this one problem out. This has been incredibly difficult to solve, and it is quite discouraging! i'm trying to get berp up and running (https://github.com/bjpop/berp/). berp-libs installed fine, berp-compiler is hanging up: From what I can tell, the only hangup I have is that the process package depends on the wrong version of directory. [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 15] 75$ cabal configure Resolving dependencies... Configuring berpcompiler-0.0.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package process-1.0.1.3 requires directory-1.0.1.0 package cpphs-1.13.2 requires directory-1.1.0.1 package berplibs-0.0.3 requires directory-1.1.0.1 package berpcompiler-0.0.3 requires directory-1.1.0.1 What happens if you ignore this warning? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST not strict enough?
* Jason Dusek jason.du...@gmail.com [2011-11-15 20:08:48+] I'm having some trouble with memory usage in rebuilding a ByteString with some sequences escaped. I thought I'd try vectors. However, it seems that even a relatively simple function, one that places all the bytes of a ByteString in to a vector, uses a great deal of memory. Should I be annotating my functions with strictness, for the vector reference, for example? Should I be using STUArrays, instead? Hi Jason, I think what's happening here is ByteString's strictness makes things actually lazy on your side. Namely, unpack function produces its result strictly, whole list at once. As a result, the resulting list cannot be consumed one-by-one, so it takes memory. You see ST thunks because mapM_ f as = sequence_ (map f as) and that map probably gets fused with unpack. I guess the proper solution here is to use lazy bytestring and make sure the chunks are not very big. -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST not strict enough?
Hi Jason, On Tue, Nov 15, 2011 at 12:08 PM, Jason Dusek jason.du...@gmail.com wrote: Should I be annotating my functions with strictness, for the vector reference, for example? Should I be using STUArrays, instead? From http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.1.0/Control-Monad-ST-Safe.html The = and operations are strict in the state (though not in values stored in the state). which implies that modifySTRef counter (+1) is too lazy. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
Great question. How does one ignore the warning? Blaine On Tue, Nov 15, 2011 at 4:02 PM, Antoine Latter aslat...@gmail.com wrote: On Tue, Nov 15, 2011 at 1:56 PM, Blaine frik...@gmail.com wrote: Hi everyone. I'm new to haskell (venturing over from python land); i can't figure this one problem out. This has been incredibly difficult to solve, and it is quite discouraging! i'm trying to get berp up and running (https://github.com/bjpop/berp/). berp-libs installed fine, berp-compiler is hanging up: From what I can tell, the only hangup I have is that the process package depends on the wrong version of directory. [blaine@macbook:~/Dropbox/src/berp/compiler Tue Nov 15] 75$ cabal configure Resolving dependencies... Configuring berpcompiler-0.0.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package process-1.0.1.3 requires directory-1.0.1.0 package cpphs-1.13.2 requires directory-1.1.0.1 package berplibs-0.0.3 requires directory-1.1.0.1 package berpcompiler-0.0.3 requires directory-1.1.0.1 What happens if you ignore this warning? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
On Tue, Nov 15, 2011 at 3:34 PM, Blaine frik...@gmail.com wrote: Great question. How does one ignore the warning? By doing whatever you would have done next had you not received the warning :-) Such as cabal build or the like. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
On Tuesday 15 November 2011, 22:34:17, Blaine wrote: Great question. How does one ignore the warning? Not. process and directory are boot packages, required by ghc and indirectly by many of the packages you install(ed). Having multiple versions of these spells trouble and breakage. Read http://www.vex.net/~trebla/haskell/sicp.xhtml for more. You already have two versions of directory, the one ghc was built with and 1.1.0.1. It's not unlikely that you already have some unusable packages due to that. $ ghc-pkg check should tell you about such. You should unregister the duplicate directory (1.1.0.1, *keep the one ghc was built with*) and all packages depending on it. Then you can try to reinstall those packages, before cabal installing anything, you should check with --dry-run whether it would install a new version of any of the boot packages (basically everything coming with ghc itself, but having a newer version of Cabal is okay). If it would, stop. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
Dear Group, Today I tried to compile snap 0.6 with ghc 7.2, (using virthualenv, which is GREAT by the way) and got the following error somewhere along the way got a message about aeson-native requires deepseq-1.1.0.2 but I had deepseq-1.2.0.1 installed. So I unpacked aeson-native-0.3.3.1 in my virthualenv and changed the build-depends to just deepseq which caused: Configuring aeson-native-0.3.3.1... Preprocessing library aeson-native-0.3.3.1... Building aeson-native-0.3.3.1... [2 of 6] Compiling Data.Aeson.Types ( Data/Aeson/Types.hs, dist/build/Data/Aeson/Types.o ) Data/Aeson/Types.hs:196:22: No instance for (NFData Object) arising from a use of `rnf' Possible fix: add an instance declaration for (NFData Object) In the expression: rnf o In an equation for `rnf': rnf (Object o) = rnf o In the instance declaration for `NFData Value' cabal: Error: some packages failed to install: aeson-native-0.3.3.1 failed during the building phase. The exception was: ExitFailure 1 A little investigating and I discovered that instance (NFData k, NFData a) = NFData (Data.Map.Map k a) where rnf = rnf . Data.Map.toList is in deepseq-1.1.0.2 but not in deepseq-1.2.0.1. Adding it back got aeson-native-0.3.3.1 and later snap-0.6 to compile just fine. So I guess my question is: Is there a reason that the map instance was removed from deepseq-1.2.0.1, and can we please put it back in? Thanks. Best wishes, Henry Laxen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
Hello Henry I think it is a case of the dependency changing recently from deepseq depending on containers to containers depending on deepseq. Thus you want to check you are using compatible versions of deepseq and containers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
On Tuesday 15 November 2011, 23:26:04, Henry Laxen wrote: So I guess my question is: Is there a reason that the map instance was removed from deepseq-1.2.0.1, Yes. and can we please put it back in? No. The NFData instance has been moved to the containers package, where it can be more efficiently done. The change is already in the latest released deepseq version, but will only be in the containers version to be released with ghc-7.4. For your unfortunate combination, consider reverting to a prior deepseq version, or manually provide the instance where needed (I recommend the former). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with installing the correct version of process. Help?
So this is hilarious. This whole time I thought 'warning' meant 'error'. I rebuilt all of ghc and the platform with 7.0.3, and did it again. Now it complains about containers. Went ahead and installed anyway (duh!). Now it looks like it worked. I'll check back if it didn't work. I can't believe I never tried to just install the darn thing... Blaine On Tue, Nov 15, 2011 at 5:04 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Tuesday 15 November 2011, 22:34:17, Blaine wrote: Great question. How does one ignore the warning? Not. process and directory are boot packages, required by ghc and indirectly by many of the packages you install(ed). Having multiple versions of these spells trouble and breakage. Read http://www.vex.net/~trebla/haskell/sicp.xhtml for more. You already have two versions of directory, the one ghc was built with and 1.1.0.1. It's not unlikely that you already have some unusable packages due to that. $ ghc-pkg check should tell you about such. You should unregister the duplicate directory (1.1.0.1, *keep the one ghc was built with*) and all packages depending on it. Then you can try to reinstall those packages, before cabal installing anything, you should check with --dry-run whether it would install a new version of any of the boot packages (basically everything coming with ghc itself, but having a newer version of Cabal is okay). If it would, stop. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
Daniel Fischer daniel.is.fischer at googlemail.com writes: For your unfortunate combination, consider reverting to a prior deepseq version, or manually provide the instance where needed (I recommend the former). Thank you Daniel, for clearing that up. Best wishes, Henry Laxen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
On 15 November 2011 23:50, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: The change is already in the latest released deepseq version, but will only be in the containers version to be released with ghc-7.4. The change is already in the released containers-0.4.2.0. So the only thing Henry needs to do is install that version and rebuild his libraries against that version. Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepseq-1.2.0.1 missing Data.Map instance
On 16 November 2011 10:23, Bas van Dijk v.dijk@gmail.com wrote: On 15 November 2011 23:50, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: The change is already in the latest released deepseq version, but will only be in the containers version to be released with ghc-7.4. The change is already in the released containers-0.4.2.0. So the only thing Henry needs to do is install that version and rebuild his libraries against that version. Except that it is usually recommended you _don't_ upgrade the version of containers that comes with GHC, as it will lead to diamond dependency problems down the line. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Build error with network/snap w/win7 haskell platform
I'm trying to build snap-0.6 on win7/x64 with the current 64-bit haskell platform. I have the mingw compilers from the platform in $PATH, and I can get the network and snap-server modules to build. But snap-0.6 fails: [18 of 31] Compiling Snap.Snaplet.Internal.Types ( src\Snap\Snaplet\Internal\Types.hs, dist\build\Snap\Snaplet\Internal\Types.o ) Loading package ghc-prim ... linking ... done. ... Loading package murmur-hash-0.1.0.4 ... linking ... done. Loading package parsec-3.1.2 ... linking ... done. Loading package network-2.3.0.7 ... linking ... ghc.exe: unable to load package `network-2.3.0.7' ghc.exe: C:\Users\aturoff\AppData\Roaming\cabal\network-2.3.0.7\ghc-7.0.3\HSnetwork-2.3.0.7.o: unknown symbol `_acceptNewSock' cabal.exe: Error: some packages failed to install: snap-0.6.0.2 failed during the building phase. The exception was: ExitFailure 1 Any ideas? The platform comes with network-2.3.0.2, but cabal insists on upgrading it. Is there some way to force cabal to use the version that came with the platform instead? Specifying network==2.3.0.2 as a dependency just rebuilds it as a user package. Thanks, -- Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is SmallCheck maintained?
On 11/14/11 12:54 PM, Roman Cheplyaka wrote: Hi Cafe, Does anyone currently work on Test.SmallCheck? I see the following problems: 1. SC doesn't have a repository, issue tracker etc. 2. It is not integrated with popular test frameworks 3. API should be better documented I'm willing to work on the above problems, but wanted to check first if someone's already working on them or at least has a repository. I already wrote to Colin Runciman but got no response. I don't know whether it's being maintained either, but I'm willing to help with the janitorial work since I use smallcheck and lazy-smallcheck quite a lot and think they should be better advertised/used. Last I heard there was some work on integrating the strict and lazy versions, but that was years ago... so it'd be nice if we could obtain the repo for the beginning of that work, since really they should be integrated. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A Mascot
I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png What do you think? -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 16 November 2011 12:01, heathmatlock heathmatl...@gmail.com wrote: I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png What do you think? Um do we _really_ need a mascot? And no offence to your artistic abilities, but even if we did, I don't see how a lamb relates to Haskell :/ -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
I don't see how a lamb relates to Haskell :/ The lamb is named Da. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On Tue, Nov 15, 2011 at 20:06, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Um do we _really_ need a mascot? And no offence to your artistic abilities, but even if we did, I don't see how a lamb relates to Haskell :/ Lamb-da, obviously. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Second CfP: International Conference on Test and Proofs (TAP 2012), Next Deadline: 2011-12-14
(Apologies for duplicates)
*
Less than one month until the deadline ***
for submitting abstract to TAP 2012***
*
CALL FOR PAPERS
Full and short Research Paper, Industrial Expierence Papers, Tool Papers
Abstract submission: Dec 14, 2011, Paper submission Dec 21, 2012
6th INTERNATIONAL CONFERENCE ON TEST AND PROOFS (TAP 2012)
http://lifc.univ-fcomte.fr/tap2012/
May 31 - June 1, 2012, Prague, Czech Republic
Part of the TOOLS Federated Conferences 2012
http://tools2012.fit.cvut.cz/
The TAP conference is devoted to the convergence of proofs and tests,
to the application of techniques from both sides and their combination
for the advancement of software quality. Test and Proof seem to be
contradictory techniques: if you have proved your program to be
correct, it is fruitless to comb it for bugs; and if you are testing
it, that is surely a sign that you have given up on any hope to prove
its correctness. Accordingly, proofs and tests have, since the onset
of software engineering research, been pursued by distinct
communities.
However, the development of both approaches lead to the discovery of
common issues and to the realization that each may need the other. The
emergence of model checking has been one of the first signs that
contradiction may yield to complementarity. Further evidence give test
data generation techniques from models or programs which boil down to
constraint resolution techniques for relatively large formula; the
advent of powerful SMT solvers have therefore powered new testing
techniques. Finally, since formal, proof-based verification is
costly, testing invariants and background theories can be helpful to
detect errors early and to improve cost effectivity. Summing up, in
the past few years an increasing number of research efforts have
encountered the need for combining proofs and tests, dropping earlier
dogmatic views of incompatibility and taking instead the best of what
each of these software engineering domains has to offer.
The TAP conference aims to bring together researchers and practitioners
working in the converging fields of testing and proving, and will offer
a generous allocation of papers, panels and informal discussions.
Topics of interest cover theory definitions, tool constructions and
experimentations and include (other topics related to TAP are welcome):
- Transfer of concepts from testing to proving (e.g., coverage criteria)
and from proving to testing
- Program proving with the aid of testing techniques
- New problematics in automated reasoning emerging from specificities
of test generation
- Verification and testing techniques combining proofs and tests
- Generation of test data, oracles, or preambles by deductive
techniques such as: theorem proving, model checking, symbolic
execution, constraint logic programming
- Model-based testing and verification
- Generation of specifications by deduction
- Automatic bug finding
- Debugging of programs combining static and dynamic analysis
- Formal frameworks
- Tool descriptions and experience reports
- Case studies combining tests and proofs
- Applying combination of test and proof techniques to new application
domains such as validating security procotols or vulnerability
detection of programs
Important Dates:
Abstract submission:December 14, 2011
Paper submission: December 21, 2011
Notification: March 2, 2012
Camera ready version: March 19, 2012
TAP conference: May 31 - June 1, 2012 (to be confirmed)
TOOLS conferences (TOOLS, ICMT, SC, TAP): May 29 - June 01, 2012
Conference Chairs: Bertrand Meyer
Program Chairs:Achim D. Brucker and Jacques Julliand
Program Committee (to be extended):
===
Nazareno Aguirre, Bernhard K. Aichernig, Paul Ammann, Dirk Beyer,
Nikolaj Bjorner, Robert Clarisó, Marco Comini, Catherine Dubois,
Gordon Fraser, Angelo Gargantini, Alain Giorgetti, Patrice Godefroid,
Martin Gogolla, Arnaud Gotlieb, Reiner Hähnle, Bart Jacobs, Thierry Jéron,
Gregory Kapfhammer, Nikolai Kosmatov, Victor Kuliamin, Karl Meinke, Jeff
Offutt, Holger Schlingloff, T.H. Tse, Margus Veanes, Luca Viganò, Burkhart
Wolff, Fatiha Zaidi
Submission:
===
Please submit your papers via http://lifc.univ-fcomte.fr/tap2012/.
TAP 2012 will accept two types of papers:
- Research papers: full papers with at most 16 pages in LNCS format
(pdf), which have to be original, unpublished and not submitted
elsewhere.
- Short contributions: work in progress, (industrial) experience
reports or tool demonstrations, position statements; an extended
abstract with at most 6 pages in LNCS format (pdf) is expected.
Accepted papers will be published in the Springer LNCS series and
Re: [Haskell-cafe] A Mascot
On Tue, Nov 15, 2011 at 7:06 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Um do we _really_ need a mascot? I don't think a programming community every really needs a mascot, just nice to have. And no offence to your artistic abilities, but even if we did, I don't see how a lamb relates to Haskell :/ The lamb is a play on lambda calculus. -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On Tue, Nov 15, 2011 at 7:39 PM, Diego Olivier Fernandez Pons dofp.hask...@gmail.com wrote: I don't see how a lamb relates to Haskell :/ The lamb is named Da. That works too. I couldn't resist: http://i.imgur.com/5222B.png See http://en.wikipedia.org/wiki/Knights_of_the_Lambda_Calculus for reference. -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
I thought we already had a mascot? http://www.haskell.org/pipermail/haskell/attachments/20090401/9fb8fa05/haskell-mascot.jpg :p - jeremy On Tue, Nov 15, 2011 at 7:01 PM, heathmatlock heathmatl...@gmail.com wrote: I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png What do you think? -- Heath Matlock +1 256 274 4225 ___ 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] A Mascot
People tend to concentrate on the lambda which cooresponds to the functional aspect of haskell when designing logos. Not nearly enough attention is paid to the other striking feature, the laziness. The 'bottom' symbol _|_ should feature prominently. The two most defining features of haskell are that it is purely functional and _|_ inhabits every type. The combination of which is very powerful. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 11-11-15 08:01 PM, heathmatlock wrote: http://i.imgur.com/Mib6Q.png Curry had a little lamb, little lamb, little lamb... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On Tue, Nov 15, 2011 at 10:18 PM, John Meacham j...@repetae.net wrote: People tend to concentrate on the lambda which cooresponds to the functional aspect of haskell when designing logos. Not nearly enough attention is paid to the other striking feature, the laziness. The 'bottom' symbol _|_ should feature prominently. The two most defining features of haskell are that it is purely functional and _|_ inhabits every type. The combination of which is very powerful. John I would have to think about this a bit longer, but here's the symbol reworked onto the helmet: http://i.imgur.com/ZziGQ.png -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
http://elikat.com/blogs/wp-content/plugins/index1.php ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
Da the lamb, I like that. -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
Last image for the night, http://i.imgur.com/CE9Tk.png On Tue, Nov 15, 2011 at 11:03 PM, heathmatlock heathmatl...@gmail.comwrote: Da the lamb, I like that. -- Heath Matlock +1 256 274 4225 -- Heath Matlock +1 256 274 4225 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
2011/11/16 heathmatlock heathmatl...@gmail.com: Last image for the night, http://i.imgur.com/CE9Tk.png Great! I like it very much. Best, Karol Samborski ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to Create Programming Language with Haskell?
Hi,Cafe. I want to create my own Programming Language with Haskell, and I learn how to do it. I read: WikiBooks of Write Yourself a Scheme in 48 Hours, Real World Haskell of Chapter Using Parsec, Source of HJS, Book of Introduction of Functional Programming Using Haskell. Ok,What is another good source creating my own Programming Language with Haskell? Thanks :) esehara ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
In general, I like the idea of having a mascot, and think that something along these lines will be great. Cheers, Pedro On Wed, Nov 16, 2011 at 01:01, heathmatlock heathmatl...@gmail.com wrote: I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png What do you think? -- Heath Matlock +1 256 274 4225 ___ 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] A Mascot
I vote for an invisible mascot, all there is to see is the orange speech bubble with smart code ;-) Liebe Grüße ben On 16 Nov 2011, at 08:45, José Pedro Magalhães j...@cs.uu.nl wrote: In general, I like the idea of having a mascot, and think that something along these lines will be great. Cheers, Pedro On Wed, Nov 16, 2011 at 01:01, heathmatlock heathmatl...@gmail.com wrote: I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png What do you think? -- Heath Matlock +1 256 274 4225 ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
