Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I doubt it's the fusion framework (which does work, just not as well as it used to before the typechecker patch). If the ghc package is getting linked in then that is probably the reason for the binary size. The package is only used for one thing by vector: annotations to drive !SpecConstr. That is, I only use a single data type and no functions from package ghc. Why would GHC link in the entire package in that case? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:13 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] #4370: Bring back monad comprehensions
#4370: Bring back monad comprehensions -+-- Reporter: simonpj |Owner: nsch Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by nsch): * owner: = nsch Comment: Thank you for the detailed reply, Simon. I'm currently working for George and his research group and I'm going to take on this task in the next couple of weeks. Those advices will be a great help. - Nils Schweinsberg -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4370#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Moreover, the annotations stuff, and hence the `ghc` package is only used at ''compile time''. So it should not be linked at run time. There should be literally no references to `ghc` in the `.o` files, so it should not be linked at all. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:14 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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi
-+--
Reporter: mitar |Owner: vivian
Type: feature request | Status: patch
Priority: normal|Milestone: 7.2.1
Component: GHCi | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by vivian):
How does implementing simonmar's suggestion impact upon #3984? It seems
that it renders it obsolete. Should the patch include removing the {{{:{
}:}}} construct?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#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
Re: [GHC] #4346: Behaviour of INLINABLE depends on whether the modules included are already compiled.
#4346: Behaviour of INLINABLE depends on whether the modules included are
already
compiled.
-+--
Reporter: milan |Owner: simonmar
Type: bug | Status: merge
Priority: high |Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by simonmar):
* status: new = merge
Comment:
Fixed - thanks for a great report, and well done for spotting the problem.
{{{
Fri Oct 15 10:48:36 BST 2010 Simon Marlow marlo...@gmail.com
* Fix #4346 (INLINABLE pragma not behaving consistently)
Debugged thanks to lots of help from Simon PJ: we weren't updating the
UnfoldingGuidance when the unfolding changed.
Also, a bit of refactoring and additinoal comments.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4346#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): I don't know how well Haskeline will cope with multi-line input. Ideally you want Haskeline to be able to navigate and edit the complete multi-line expression. Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:17 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
FWIW:
{{{
$ ghc -O2 -package vector-0.7 -package base-4.2.0.2 -o aaa6 aaavec.hs
$ ls -l | grep aaa6
-rwxr-xr-x 1 dafis users 1115927 15. Okt 12:16 aaa6
$ nm aaa6 | wc -l
10110
$ nm aaa6 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O2 --make aaavec.hs -o aaa7
$ ls -l | grep aaa7
-rwxr-xr-x 1 dafis users 29180744 15. Okt 12:17 aaa7
$ nm aaa7 | wc -l
332020
$ nm aaa7 | grep ghc | wc -l
65413
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): What happens with -O0? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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
Re: [GHC] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Not much of a difference:
{{{
$ touch aaavec.hs
$ ghc -O0 -package vector-0.7 -package base-4.2.0.2 -o aaa60 aaavec.hs
$ ls -l | grep aaa60
-rwxr-xr-x 1 dafis users 1207342 15. Okt 13:22 aaa60
$ nm aaa60 | wc -l
11025
$ nm aaa60 | grep ghc | wc -l
65
$ ~/Haskell/Hacking/bin/ghc -O0 --make aaavec.hs -o aaa70
[1 of 1] Compiling Main ( aaavec.hs, aaavec.o )
Linking aaa70 ...
$ ls -l | grep aaa70
-rwxr-xr-x 1 dafis users 29221447 15. Okt 13:23 aaa70
$ nm aaa70 | wc -l
332413
$ nm aaa70 | grep ghc | wc -l
65413
$
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:17
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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Since fusion/inlining doesn't happen with -O0, that pretty much means that it has to be something else. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:18 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] #4401: Functional dependencies regression
#4401: Functional dependencies regression
-+--
Reporter: rl| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Testcase:
{{{
{-# LANGUAGE FlexibleInstances, UndecidableInstances,
MultiParamTypeClasses, FunctionalDependencies #-}
module Foo where
class Mul x y z | x y - z
class IsType a
class IsType a = IsSized a s | a - s
data Array n a = Array
instance IsSized a s = IsType (Array n a)
instance (IsSized a s, Mul n s ns) = IsSized (Array n a) ns
}}}
ghc-7.0.0.20101014 rejects this with:
{{{
Couldn't match type `s' with `s1'
because this skolem type variable would escape: `s1'
This skolem is bound by the instance declaration
In the instance declaration for `IsSized (Array n a) ns'
}}}
ghc-7.0.0.20101005 and all previous versions accept it. This is from the
llvm package, so is fairly critical.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4401
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] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD --+- Reporter: daniel.is.fischer |Owner: Type: bug| Status: new Priority: normal |Milestone: Component: Compiler | Version: 7.1 Keywords: RULES, classes | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug --+- Comment(by simonpj): Ah yes I see. Thanks for identifying this flaw. It's all in `Rules.isMoreSpecific`, which looks wrong to me. I'll validate a fix. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by daniel.is.fischer): I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:19 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonmar): One way to track it down would be to issue the link command manually with the GHC package removed, and see what symbols are missing and where they are referred to from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by igloo):
Hmm, with
{{{
$ cat h.hs
import SpecConstr
main = return ()
}}}
I get:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
59049
$ ls -lh h
-rwxr-xr-x 1 ian ian 32M Oct 15 13:29 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 21M Oct 15 13:29 h
}}}
and:
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.1.20101014
$ ghc --make h -package ghc
[1 of 1] Compiling Main ( h.hs, h.o )
Linking h ...
$ nm h | grep ghc | wc -l
66744
$ ls -lh h
-rwxr-xr-x 1 ian ian 45M Oct 15 13:30 h
$ strip h
$ ls -lh h
-rwxr-xr-x 1 ian ian 29M Oct 15 13:30 h
}}}
i.e. it looks like it never worked for me.
What does
{{{
ar t `ghc --print-libdir`/ghc-6.12.3/libHSghc-6.12.3.a | wc -l
}}}
say for you?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4318: Crash while building HEAD on OS X
#4318: Crash while building HEAD on OS X ---+ Reporter: gwright |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler| Version: 6.13 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Building GHC failed ---+ Comment(by gwright): Now I know what the bug is: relocations of type `X86_64_RELOC_GOT` and `X86_64_RELOC_GOT_LOAD` are not handled by the Mach-O linker. There is a stub of code for these cases, but it does something nonsensical. I'm guessing it was simply never finished. This doesn't seem too hard to fix, but it's fiddly. If I'm lucky and my current hunch works, maybe a patch in a couple of days. Otherwise, I'll need to try to understand Apple's ld64 code to understand these relocations in more detail. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4318#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Replying to [comment:19 daniel.is.fischer]: I've narrowed it down a bit. Importing Data.Vector.Fusion.Util and Data.Vector.Fusion.Stream.Size gives small executables, importing Data.Vector.Fusion.Stream.Monadic a large one. So something in there triggers it. Stream.Monadic contains annotations, the others don't (they are also rather small). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:22 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by igloo): Oh, never mind, I can reproduce it if I use your testcase above. Curious. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:23 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by simonpj): Ah.. light dawns. Every module has a module-initialisation routine. Apart from initialising the module, it calls the module-initialisation routine for each imported module. So if M imports module `SpecConstr` from package `ghc`, then the module-initialisatin routine for M will call the initialisation routine for `SpecConstr`. Even though nothing from `SpecConstr` is ultimately used. Hmm. That is bad. I'm not sure what to do about it. The obvious alternative is to call the module-init routine for each `Id` mentioned in the final executable for M. That would solve the problem, but at a cost: every module will call zillions of module initialisers. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:24 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7
--+-
Reporter: daniel.is.fischer |Owner: igloo
Type: bug| Status: new
Priority: highest|Milestone: 7.0.1
Component: Compiler | Version: 7.1
Keywords: executable size| Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86| Failure: Other
--+-
Comment(by daniel.is.fischer):
Yeah, seems that's it,
{{{
#if __GLASGOW_HASKELL__ = 613
import SpecConstr ( SpecConstrAnnotation(..) )
#endif
}}}
means !SpecConstr isn't actually imported with 6.12.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by josef): It seems to me that what is really needed is a form of compile time imports. Some way to indicate that an imported module will only be used at compile time, for instance to use annotations or to generate code using Template Haskell. Jonas Almström Duregård bumped in to the same problem when using Template Haskell. He needed to import modules for use only at compile time but they where also linked in when the binary was created. Link to email: http://www.haskell.org/pipermail/glasgow-haskell- users/2010-September/019211.html -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:26 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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: highest|Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): Could we just use `collect2` to collect and execute all initialisers that are linked in? GCC already solves this problem for C++ so perhaps we could simply reuse their mechanism. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Changes (by igloo): * priority: highest = normal Comment: Aha, not a regression, then, so downgrading priority. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:28 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] #4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587
#4393: GHCi says: ghc: internal error: evacuate: strange closure type 63587 --+- Reporter: chrisdone |Owner: Type: bug| Status: new Priority: normal |Milestone: 7.0.2 Component: GHCi | Version: 6.12.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: GHCi crash --+- Changes (by igloo): * milestone: = 7.0.2 Comment: So am I right in thinking you just have 1 long-running ghci process (inside emacs)? The best first step is probably to see if it still happens with 7.0.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4393#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] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by igloo): Replying to [comment:17 simonmar]: Also I'm not sure how layout should behave with the prompt, because the first line is already indented: should subsequent lines be indented by the width of the prompt, or should there be a special multi-line continuation prompt? multi-line continuation prompt sounds best to me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:18 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] #4401: Functional dependencies regression
#4401: Functional dependencies regression -+-- Reporter: rl|Owner: simonpj Type: bug | Status: new Priority: highest |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * owner: = simonpj * priority: normal = highest * milestone: = 7.0.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4401#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch -+-- Reporter: dieterle | Owner: Type: bug | Status: merge Priority: normal| Component: Build System Version: 6.12.3|Keywords: Testcase:| Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dieterle): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch ---+ Reporter: dieterle | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Build System |Version: 6.12.3 Resolution:| Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: merge = new -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4402: Ticket #4252 not fixed for 6.12 branch
#4402: Ticket #4252 not fixed for 6.12 branch ---+ Reporter: dieterle | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Build System |Version: 6.12.3 Resolution: wontfix | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: The 6.12 branch is no longer being developed; only the HEAD and 7.0 branches are. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4402#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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by rl): I thought that `collect2` automates this. IIRC, it ploughs through all object files looking for specific constructor symbols and then generates and links in an additional module which calls those symbols and is, in turn, called at start up. Wouldn't it be enough to simply make sure that module initialiser symbols look like constructors and link with `collect2`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:30 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
unused record fields
Simon P. Jones wrote recently about that ghc-6.12 takes in
account the elliplis in MkT {t1 = x, ..} when reporting about
unused bindings.
Now, here is the example:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
And forf (T {t1 = x, ..}) = x,
it does not warn about this.
Is this a bug?
I use
extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns
ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-O0
,
but the options can be simplified, of course.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by nominolo):
Benchmarks checking whether changing associativity of () in `pretty`
would lead to performance issues:
{{{
import Text.PrettyPrint
import Data.List
import Criterion.Main
f_left :: Int - Doc
f_left n = foldl' () empty (map (text . show) [10001..1+n])
f_right :: Int - Doc
f_right n = foldr () empty (map (text . show) [10001..1+n])
main =
defaultMain $
[ bench left $ nf (length . render . f_left) 1
, bench right$ nf (length . render . f_right) 1
, bench left20k $ nf (length . render . f_left) 2
, bench right20k $ nf (length . render . f_right) 2
, bench left30k $ nf (length . render . f_left) 3
, bench right30k $ nf (length . render . f_right) 3
]
}}}
Results (lower numbers are better):
{{{
Iterations
_10K__20K__30K
Left 10.1 (0.5) 24.4 (0.6) 40.0 (1.3)
Right 8.9 (0.2) 22.7 (3.1) 31.2 (4.6)
Format: runtime (stddev) all in milliseconds
}}}
So switching to right-associativity may actually increase performance
slightly. Scaling doesn't seem to be quite linear, but that could be due
to cache effects or suchlike; and it's also outside the scope of this
proposal.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#comment:22
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] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD
--+-
Reporter: daniel.is.fischer |Owner:
Type: bug| Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 7.1
Keywords: RULES, classes | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
--+-
Comment(by simonpj):
Fixed by
{{{
Fri Oct 15 14:18:14 BST 2010 simo...@microsoft.com
* Give user-defined rules precedence over built-in rules
This fixes Trac #4397. See comments with 'isMoreSpecific'.
}}}
Try now.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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] #4346: Behaviour of INLINABLE depends on whether the modules included are already compiled.
#4346: Behaviour of INLINABLE depends on whether the modules included are already compiled. ---+ Reporter: milan | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: Compiler |Version: 7.1 Resolution: fixed | Keywords: Testcase:| Blockedby: Difficulty:| Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Changes (by igloo): * status: merge = closed * resolution: = fixed Comment: Merged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4346#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] #3651: GADT type checking too liberal
#3651: GADT type checking too liberal +--- Reporter: MartijnVanSteenbergen|Owner: igloo Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler (Type checker) | Version: 6.10.4 Keywords: | Testcase: Blockedby: | Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown +--- Comment(by michalt): Replying to [comment:4 simonpj]: I've noticed that only one of the three errors is reported, at a time. I'll fix that. You're right! I have absolutely no idea why I've tested them one at a time. Sorry if that caused any confusion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3651#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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by jeltsch):
It was also suggested to make {{{()}}} a method of {{{Monoid}}} and
insert the following default definitions:
{{{
() = mappend
mappend = ()
}}}
Any objections against this?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#comment:23
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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend
-+--
Reporter: bos | Owner:
Type: proposal| Status: new
Priority: normal | Milestone: Not GHC
Component: libraries/base |Version: 6.10.3
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Comment(by jeltsch):
In the long run, we should probably get rid of {{{mappend}}} altogether.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#comment:24
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] #4387: Huge executables with GHC 7
#4387: Huge executables with GHC 7 --+- Reporter: daniel.is.fischer |Owner: igloo Type: bug| Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords: executable size| Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86| Failure: Other --+- Comment(by batterseapower): Having a better solution for compile time imports would also prevent GHC from linking in modules that are import only for their type information (e.g. a type-level natural numbers package). We could also extend it so we get a better solution to the outstanding annoying problem where you have to remember to call `hs_init` and `hs_add_root` when building a C program that links in some Haskell. We can just arrange that hs_init is marked as a constructor for collect2's purposes. This will cause libgcc library to call hs_init for you (via __main), along with the module initialisers. This means that if you build your Haskell-importing C program using the GNU toolchain, then you don't have to worry about starting up the Haskell RTS at all. In particular this means you could write a Haskell library that behaves as a drop-in replacement for a C library. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4387#comment:31 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] #3339: Data.Monoid: Add () as a synonym for mappend
#3339: Data.Monoid: Add () as a synonym for mappend -+-- Reporter: bos | Owner: Type: proposal| Status: new Priority: normal | Milestone: Not GHC Component: libraries/base |Version: 6.10.3 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Comment(by nominolo): Getting rid of `mappend` would break a ''lot'' of packages, so that will take a while. Also, what should happen to `mconcat`? The naming of `mappend` makes somewhat sense, because `[a]` is the free Monoid, so `mconcat` is just the extension of that naming strategy. Should `mconcat` stay as is, or can anyone think of a better name? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3339#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] #1634: Type signature normalization
#1634: Type signature normalization -+-- Reporter: kfr...@…| Owner: igloo Type: bug | Status: closed Priority: low | Milestone: 7.0.1 Component: Compiler (Type checker) |Version: 6.6.1 Resolution: fixed | Keywords: Testcase: typecheck/should_compile/T1634 | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: x86 Failure: None/Unknown| -+-- Changes (by igloo): * status: patch = closed * resolution: = fixed Comment: Applied to HEAD and 7.0, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1634#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] #4163: Make cross-compilation work
#4163: Make cross-compilation work -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: high |Milestone: 7.0.2 Component: Build System | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Difficult (2-5 days) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4163#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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: igloo Type: feature request | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler | Version: Keywords: 64bit| Testcase: Blockedby: | Difficulty: Unknown Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Installing GHC failed +--- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:67 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] #4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
#4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
--+-
Reporter: milan | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler
Version: 7.0.1 RC1 |Keywords: code bloat
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86| Failure: Other
--+-
When benchmarking Containers, I came over some suspicious increase of code
size. I reduced the test case to the following:
Compile the following trivial benchmark:
{{{
import Data.Set
import Criterion.Main
main = defaultMain [bench set (whnf (length . toList . fromList . concat
. replicate 10) [1..1000])]
}}}
The size of a stripped binary produced by ghc --make -O:
{{{
ghc-6.12.1: 2414128
ghc-7.0.0.20100930: 22572260
ghc-7.1.20101010: 21417316
}}}
That is nearly 10-times increase of code size. I could not figure out why.
When using only 'base' package, there is nearly no increase in code size.
The ghc-bundled libraries use -split-objs, the libraries compiled by
cabal-install are not using -split-objs in any ghc version.
I used I386. The ghc-6.12.1 is precompiled binary, ghc-7.0.0 is compiled
by ghc-6.12.1 by using default build system (configure make, no
build.mk), ghc-7.1 is compiled by ghc-6.12.1 by using custom build.mk (but
it only sets !GhcLibWays=v).
The criterion package was compiled using 'cabal install criterion'. Latest
version 0.5.0.4 was used (vector 0.7, vector-algorithms 0.3.3, statistics
0.8.0.1). For ghc-7.0 and ghc-7.1 some minor changes to the latest hackage
versions of the deepseq, parallel, syb and vector-algorithms packages had
to be made (trivial dependency changes, code that does not type check).
!SimonMar said some of that is already corrected in darcs repos.
Can anyone reproduce this behaviour? If so, it is horrible.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4403
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] #3472: Porting through .hc files broken
#3472: Porting through .hc files broken -+-- Reporter: pumpkin | Type: bug Status: new | Priority: high Milestone: 7.0.2 |Component: Build System Version: 6.12.1 RC1| Resolution: Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tedm): * cc: middleton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3472#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] #4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head
#4403: Huge (10 times) increase of binaries produced by GHC 7.0.0 and GHC head +--- Reporter: milan | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 RC1 Resolution: duplicate | Keywords: code bloat Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86 Failure: Other | +--- Changes (by igloo): * status: new = closed * resolution: = duplicate Comment: This is because the `ghc` packages is used, and thus linked in, with ghc 7. See #4387 for more discussion. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4403#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4404: RecordWildCards
#4404: RecordWildCards
+---
Reporter: igloo|Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.2.1
Component: Compiler (Type checker) | Version: 6.12.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
+---
With this module:
{{{
{-# LANGUAGE RecordWildCards #-}
module TT where
data T = T {t1, t2 :: Int}
f :: T - Int
f d = x
where T {t1 = x, ..} = d
g :: T - Int
g (T {t1 = x, ..}) = x
}}}
`f` gives warnings about t2 being unused:
{{{
$ ghc -Wall -c n.hs
n.hs:9:11: Warning: Defined but not used: `t2'
}}}
which is probably not what we want for variables bound by a wildcard.
Reported by Serge here:
http://www.haskell.org/pipermail/glasgow-haskell-
bugs/2010-October/025858.html
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4404
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] #4318: Crash while building HEAD on OS X
#4318: Crash while building HEAD on OS X ---+ Reporter: gwright |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.0.1 Component: Compiler| Version: 6.13 Keywords: | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: Building GHC failed ---+ Comment(by gwright): I have ghci from HEAD working, built 64 bit on OS X 10.6. At least it works well enough to define `fact` and `fib` at the prompt and get the right answers. (Certainly an improvement over a segfault or abort trap!) I'll resync with HEAD and apply my patches, then run the testsuite. There may still be some other problems with the linker lurking, since there have clearly been paths through the code that were never exercised in the 64 bit Mach-O case. The final change to fix the crash wasn't much; better to be lucky than smart. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4318#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: unused record fields
On Fri, Oct 15, 2010 at 09:04:20PM +0400, Serge D. Mechveliani wrote:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
Thanks for the report; filed as:
http://hackage.haskell.org/trac/ghc/ticket/4404
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4388: Unexpected failures, too much allocation
#4388: Unexpected failures, too much allocation
---+
Reporter: daniel.is.fischer |Owner:
Type: bug | Status: new
Priority: high|Milestone: 7.2.1
Component: Test Suite | Version: 7.1
Keywords: test suite, allocation | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple| Blocking:
Architecture: Unknown/Multiple| Failure: None/Unknown
---+
Comment(by daniel.is.fischer):
My latest HEAD just made it for T1969:
{{{
/home/dafis/Haskell/Hacking/ratstuff/bindisttest/install
dir/lib/ghc-7.1.20101015/ghc
-B/home/dafis/Haskell/Hacking/ratstuff/bindisttest/install
dir/lib/ghc-7.1.20101015
-pgmc /usr/bin/gcc -pgma /usr/bin/gcc -pgml /usr/bin/gcc -pgmP
/usr/bin/gcc -E
-undef -traditional -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-
output
-no-user-package-conf -rtsopts -c T1969.hs +RTS -V0 -tT1969.comp.stats
--machine-readable
[(bytes allocated, 269780444)
,(num_GCs, 386)
,(average_bytes_used, 3472012)
,(max_bytes_used, 5944572)
,(num_byte_usage_samples, 8)
,(peak_megabytes_allocated, 19)
,(init_cpu_seconds, 0.01)
,(init_wall_seconds, 0.00)
,(mutator_cpu_seconds, 1.31)
,(mutator_wall_seconds, 1.62)
,(GC_cpu_seconds, 0.78)
,(GC_wall_seconds, 0.81)
]
}}}
close shave, though.
T3294 got better too:
{{{
bytes allocated 912566272 is more than maximum allowed 85000
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4388#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] #4405: tcfail138 compiles but shouldn't
#4405: tcfail138 compiles but shouldn't --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal | Component: Test Suite Version: 7.1|Keywords: Testcase: | Blockedby: Os: Unknown/Multiple |Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by daniel.is.fischer): * version: 6.12.3 = 7.1 * component: Compiler = Test Suite -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4405#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] #2271: floor, ceiling, round :: Double - Int are awesomely slow
#2271: floor, ceiling, round :: Double - Int are awesomely slow --+- Reporter: dons |Owner: daniel.is.fischer Type: bug| Status: patch Priority: low|Milestone: 7.0.1 Component: libraries/base | Version: 7.1 Keywords: performance, math, double | Testcase: Blockedby: | Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by daniel.is.fischer): * status: new = patch Comment: Works now :) Please test on 64 bits to make sure I haven't bungled the CPP stuff. I also have a lot of rewrite rules for !IntN and !WordN, but I'm not sure where to put them. Probably GHC.Int and GHC.Word, but we'd have to import GHC.Float and perhaps GHC.Float.RealFracMethods then. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2271#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
Re: [GHC] #4397: RULES for Class ops don't fire in HEAD
#4397: RULES for Class ops don't fire in HEAD --+- Reporter: daniel.is.fischer| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.1 Resolution: fixed| Keywords: RULES, classes Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Changes (by daniel.is.fischer): * status: new = closed * resolution: = fixed Comment: Yes, works now. Muchas Gracias. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4397#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] #4406: Spurious Haddock links
#4406: Spurious Haddock links
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal | Component: Build System
Version: 7.1|Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: Documentation bug
--+-
GHC builds haddock docs for packages it doesn't install and includes the
modules in the library index. The haddock docs for these packages are
however not copied to share/doc/ghc/... (the latter is okay, since the
packages are not installed).
Affected are:
{{{
dph-*
haskeline
mtl
primitive
terminfo
utf8-string
vector
xhtml
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4406
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] #836: rebindable if-then-else syntax
#836: rebindable if-then-else syntax --+- Reporter: nibro |Owner: SamAnklesaria Type: feature request| Status: new Priority: normal |Milestone: _|_ Component: Compiler (Parser) | Version: 6.13 Keywords: | Testcase: N/A Blockedby: | Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Comment(by SamAnklesaria): I've come across a problem with making `if` syntax into a function. Many uses from GHC's base library are for branches with kind # that don't match the * kind expected by my polymorphic `ifThenElse` function. I could switch all such occurrences to `case` statements, but that wouldn't prevent other libraries from having the same problems. Is there any way to make polymorphic (Bool - a - a - a) functions handle things like Int#? I'm kinda stuck. Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/836#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: un-used record wildcards
Thank you.
This was with ghc-6.12.2 and
RecordWildCards
TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances,
-fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports
-fno-warn-overlapping-patterns
1) Then, I dropped `,..' in the places where I do not really need other
fields, and it has improved.
2) Now, after reading your letter, I tried your example with MkT, and
it is all right. Then, I returned `,..' to my code (still the precise
initial code is lost, too many changes done), and I cannot obtain now
these messages about unused binds.
Most probably, this was some other effect with the variables.
The program is complex, and I have lost the initial code due to
`successfull' attempt with omitting elliplis. I also have to see how the
result program will work, this is my first attempt with RecordWildCards,
and now, also with NamedFieldPuns.
---
Mechveliani
On Thu, Oct 14, 2010 at 10:06:49PM +, Simon Peyton-Jones wrote:
Which version of GHC are you using? GHC 6.12 does not complain about unused
variables bound by ... Try this, which complains about y, but not g.
Simon
{-# LANGUAGE RecordWildCards #-}
module Test where
data T = MkT { f,g :: Int }
p (MkT { .. }) y = f
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 14 October 2010 11:01
| To: Antoine Latter
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: un-used record wildcards
|
| On Wed, Oct 13, 2010 at 01:47:11PM -0500, Antoine Latter wrote:
| On Wed, Oct 13, 2010 at 1:02 PM, Serge D. Mechveliani mech...@botik.ru
| wrote:
|Dear GHC developers,
|
|I use the language extension of RecordWildcards, for example,
| f (Foo {foo1 = n, foo2 = m, ..}) = ...
|
|But the complier warns about un-used values of foo3, foo4,
|probably, due to the extension of
| Foo {foo1 = n, foo2 = m, foo3 = foo3, foo4 = foo4}.
|
|In such cases, these warnings look as unneeded.
|Is it possible to have an un-used binding warnings with exception for
|wildcards in records?
|If not, then has it sense to introduce an option?
|
|
| If you're not using foo3 and foo4, can you not put it the ellipsis?
| that won't cover every case (such as where you're using foo3 but not
| foo4).
|
| Antoine
|
|
| Indeed, thank you.
| It occurs that under RecordWildcards the compiler allows to skip some
| record fields in a pattern.
| ___
| 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
ghc-6.12.3 package base - build failure on ubuntu10.10 (works with 10.4)
Hi,
I'm getting a build failure when I try to compile ghc-6.12 from the
http://darcs.haskell.org/ghc-6.12 repo.
ghc-cabal: Missing dependency on a foreign library:
* Missing C library: iconv
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.
make[1]: *** [libraries/base/dist-install/package-data.mk] Error 1
make: *** [all] Error 2
I'm using a ubuntu 10.10-64 bit system with libc-bin and libc-dev-bin
installed. I don't think the problem is a missing iconv library. Maybe
the problem is in the generated configure script by the new autoconf
version (autoconf version is 2.67).
Maybe someone can help.
Cheers,
Mischa
Stderr output of ./configure on base module is:
./configure: line 8709: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8735: ac_cv_search_iconv_t_cd_: command not found
./configure: line 8736: __cd___iconv_open_:
command not found
./configure: line 8737:
__iconv_cd_NULL_NULL_NULL_NULL__: command not found
./configure: line 8742: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8742: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8746: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8746: ac_cv_search_iconv_t_cd_: command not found
./configure: line 8747: __cd___iconv_open_:
command not found
./configure: line 8748:
__iconv_cd_NULL_NULL_NULL_NULL__: command not found
./configure: line 8751: __cd___iconv_open_:
command not found
./configure: line 8709: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8735: ac_cv_search_iconv_t_cd_: command not found
./configure: line 8736: __cd___iconv_open_: command not
found
./configure: line 8737: __iconv_cd_NULL_NULL_NULL_NULL__:
command not found
./configure: line 8742: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8742: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8746: ${ac_cv_search_iconv_t_cd_
__cd___iconv_open_
__iconv_cd_NULL_NULL_NULL_NULL__
__iconv_close_cd__+set}: bad substitution
./configure: line 8746: ac_cv_search_iconv_t_cd_: command not found
./configure: line 8747: __cd___iconv_open_: command not
found
./configure: line 8748: __iconv_cd_NULL_NULL_NULL_NULL__:
command not found
./configure: line 8751: __cd___iconv_open_: command not
found
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc7 typing problem
Hi,
I've looked at:
http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
but still have a problem with the attached program that fails with:
GHCi, version 7.1.20101010: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( HasKey.hs, interpreted )
HasKey.hs:17:10:
Couldn't match type `key' with `key1'
because this skolem type variable would escape: `key1'
This skolem is bound by the instance declaration
In the instance declaration for `Ord (Keyed x)'
at the final instance for Ord.
The original code comes from
http://hackage.haskell.org/packages/archive/uni-util/2.2.0.0/doc/html/Util-VariableSet.html
Cheers Christian
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}
class Ord key = HasKey x key | x - key where
toKey :: x - key
newtype Keyed x = Keyed { unKey :: x }
lift :: (HasKey x1 key1,HasKey x2 key2)
= (key1 - key2 - a) - (Keyed x1 - Keyed x2 - a)
lift f x1 x2 = f (toKey . unKey $ x1) (toKey . unKey $ x2)
instance HasKey x key = Eq (Keyed x) where
(==) = lift (==)
instance HasKey x key = Ord (Keyed x)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unused record fields
Simon P. Jones wrote recently about that ghc-6.12 takes in
account the elliplis in MkT {t1 = x, ..} when reporting about
unused bindings.
Now, here is the example:
module TT where
data T = T {t1, t2 :: Int}
f d = x where
T {t1 = x, ..} = d
ghc-6.12.2 warns about unused value of t2.
And forf (T {t1 = x, ..}) = x,
it does not warn about this.
Is this a bug?
I use
extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts
FlexibleInstances MultiParamTypeClasses OverlappingInstances
RecordWildCards NamedFieldPuns
ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches -fwarn-unused-imports
-O0
,
but the options can be simplified, of course.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Implicit 'forall' in data declarations
Hello,
GHC 6.12.3 allows to omit the explicit quantification of
higher-rank type variables using 'forall' in data types if they
appear in a type class context
{-# LANGUAGE RankNTypes #-}
data Foo = Foo (Eq a = a)
Is this implicit introduction of 'forall' intended? If it is, why
does it not work in function types? The following is not accepted
by my GHC:
bar :: Eq b = (Eq a = a) - b
bar x = x
The error message is
All of the type variables in the constraint `Eq a'
are already in scope (at least one must be universally quantified
here)
(Use -XFlexibleContexts to lift this restriction)
Using `FlexibleContexts` the signature of `bar` seems to be
interpreted as
bar :: (Eq b, Eq a) = a - b
because then the error becomes
Couldn't match expected type `b' against inferred type `a'
So unlike in data-type declarations, a 'forall' in a function type
must be written explicitly even if the quantified variable appears in
a local type class constraint.
bar :: Eq b = (forall a . Eq a = a) - b
bar x = x
I have not yet installed GHC 7. Is this inconsistency between data and
function declarations intended or has it been changed in the new type
checker?
Sebastian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] New blog on Disciple/DDC development
The blog is at: http://disciple-devel.blogspot.com/ more about the project here: http://trac.haskell.org/ddc/ Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Thunks
On 15 October 2010 07:53, Mihai Maruseac mihai.marus...@gmail.com wrote: Hi, Is there a way to determine the order in which thunks are created and expanded/evaluated in Haskell (GHC)? I'm looking mainly at some existing interface but if there is only something in the GHC source it will suffice. You can use side effects to observe the order of evaluation, by wrapping observed expressions (thunks) with some IO computation inside unsafePerformIO. This is roughly what HOOD does, and it can be used to provide some clues about evaluation order, and maybe even GHood can help you visualise it. I've no idea if they work at the moment, but Hood and GHood are available on Hackage. You have to be careful of observer effects whereby the observation wrappers change the evaluation order of the observed code. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MonadCatchIO, finally and the error monad
Michael Snoyman wrote: I have a recommendation of how to fix this: the MonadCatchIO typeclass should be extended to include finally, onException and everything else. We can provide default definitions which will work for most monads, and short-circuiting monads like ErrorT (and I imagine ContT as well) will need to override them. It seems that `finally' can be fixed without all these proposed additions. The method catch is the only necessary method of the class. The subject of catching errors in non-IO monads has a long history, some of which is documented at http://okmij.org/ftp/Haskell/index.html#catch-MonadIO The page points out to an old CaughtMonadIO file. I have just updated it for new Exceptions, and added the final test: test3c go = runErrorT $ go `gfinally` (liftIO $ putStrLn sequel called) test31 = test3c (return return :: ErrorT String IO String) *CaughtMonadIO test31 sequel called Right return test32 = test3c (error error :: ErrorT String IO String) *CaughtMonadIO test32 sequel called *** Exception: error test33 = test3c (throwError throwError :: ErrorT String IO String) *CaughtMonadIO test33 sequel called *** Exception: ErrorException \throwError\ As we can see, sequel is always called. Here is the updated file: http://okmij.org/ftp/Haskell/CaughtMonadIO.lhs Incidentally, one should be very careful of using `finally' with the continuation monad. The Cont monad lets us ``enter the room once, and exit many times''. So, finally may be called more than once. We need the ugly dynamic-wind -- or try to use less powerful monads if they suffice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MonadCatchIO, finally and the error monad
On Fri, Oct 15, 2010 at 9:35 AM, o...@okmij.org wrote: Michael Snoyman wrote: I have a recommendation of how to fix this: the MonadCatchIO typeclass should be extended to include finally, onException and everything else. We can provide default definitions which will work for most monads, and short-circuiting monads like ErrorT (and I imagine ContT as well) will need to override them. It seems that `finally' can be fixed without all these proposed additions. The method catch is the only necessary method of the class. The subject of catching errors in non-IO monads has a long history, some of which is documented at http://okmij.org/ftp/Haskell/index.html#catch-MonadIO The page points out to an old CaughtMonadIO file. I have just updated it for new Exceptions, and added the final test: test3c go = runErrorT $ go `gfinally` (liftIO $ putStrLn sequel called) test31 = test3c (return return :: ErrorT String IO String) *CaughtMonadIO test31 sequel called Right return test32 = test3c (error error :: ErrorT String IO String) *CaughtMonadIO test32 sequel called *** Exception: error test33 = test3c (throwError throwError :: ErrorT String IO String) *CaughtMonadIO test33 sequel called *** Exception: ErrorException \throwError\ As we can see, sequel is always called. Here is the updated file: http://okmij.org/ftp/Haskell/CaughtMonadIO.lhs Incidentally, one should be very careful of using `finally' with the continuation monad. The Cont monad lets us ``enter the room once, and exit many times''. So, finally may be called more than once. We need the ugly dynamic-wind -- or try to use less powerful monads if they suffice. Perhaps I'm misunderstanding your code, but it seems like it's not really respecting the ErrorT monad at all. Instead, it's converting the error type to a runtime exception, which often times is not at all what we want. A pertinent example: in Yesod, I use a modified ErrorT to allow short-circuiting handler functions to perform special responses such as redirects. Using your code, I believe that such code on my part would result in a 500 server error every time, quite the opposite of what I wanted. I would prefer if the test read as: test33 = fmap (== Left throwError) $ test3c (throwError throwError :: ErrorT String IO String) Which never in fact returns True. Or, more to the point, the test is never even called, since the runtime exception prevents it. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] allocation for pure FFI functions
On Thu, 2010-10-14 at 17:45 +, Johannes Waldmann wrote: Hi. I wonder how to do the following properly. I have one (large) C type, let's call it T, and I want to sell it as an abstract type in Haskell. I want to use C functions as if they were of type T - T (pure function, returns a modified copy of the input) and the question is, how to do the memory allocation for that, in particular, how to avoid IO showing up in the (visible) types on the Haskell side: I don't want IO because I don't want to declare some artificial order of execution - instead I want lazy evaluation. E.g., I might have some Haskell record with a T component which may or may not be evaluated (accessed) at all. It is exactly for this purpose that the Haskell FFI library includes unsafePerformIO. This is basically *the* legitimate use case for it, so you don't need to feel bad about it. The FFI spec says: Sometimes an external entity is a pure function, except that it passes arguments and/or results via pointers. To permit the packaging of such entities as pure functions, Foreign provides the following primitive: unsafePerformIO :: IO a - a http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-240005.1 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MonadCatchIO, finally and the error monad
Michael Snoyman wrote: I would prefer if the test read as: test33 = fmap (== Left throwError) $ test3c (throwError throwError :: ErrorT String IO String) Which never in fact returns True. Or, more to the point, the test is never even called, since the runtime exception prevents it. If you prefer the raised exception to be reflected back into the monad it came from, that can be arranged. I have updated http://okmij.org/ftp/Haskell/CaughtMonadIO.lhs to use your test: test331 = fmap (== Left (show throwError)) $ test3c (throwError throwError :: ErrorT String IO String) *CaughtMonadIO test331 sequel called True The `show' is the artifact of `reconciling' Error and Exception classes. The class Error doesn't seem very informative; one may wonder if it is needed given that we already have Exception. If in your real code, the argument of throwError is actually an Exception, the show hack can be eliminated, where it is mentioned in the instance CaughtMonadIO (ErrorT e m). I can do the adjustment if you post more details about the desired functionality. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MonadCatchIO, finally and the error monad
On Fri, Oct 15, 2010 at 10:22 AM, o...@okmij.org wrote: Michael Snoyman wrote: I would prefer if the test read as: test33 = fmap (== Left throwError) $ test3c (throwError throwError :: ErrorT String IO String) Which never in fact returns True. Or, more to the point, the test is never even called, since the runtime exception prevents it. If you prefer the raised exception to be reflected back into the monad it came from, that can be arranged. I have updated http://okmij.org/ftp/Haskell/CaughtMonadIO.lhs to use your test: test331 = fmap (== Left (show throwError)) $ test3c (throwError throwError :: ErrorT String IO String) *CaughtMonadIO test331 sequel called True The `show' is the artifact of `reconciling' Error and Exception classes. The class Error doesn't seem very informative; one may wonder if it is needed given that we already have Exception. If in your real code, the argument of throwError is actually an Exception, the show hack can be eliminated, where it is mentioned in the instance CaughtMonadIO (ErrorT e m). I can do the adjustment if you post more details about the desired functionality. By the way, I completely agree that the Error typeclass is not very useful, and I wish it would just disappear. I wrote the neither package[1]- the modified error monad I keep mentioning- in large part to avoid the Error typeclass. The other reason was the oprhan Monad Either instance. To the point at hand: I'm aware that you can promote the Error monad's error type into a runtime exception, catch it, and pull it back down. My point is that you shouldn't have to: there are perfectly valid definitions of finally for the error monad that don't require any of this trickery. Additionally, sometimes the error type cannot (reasonably) be promoted to an exception, eg ErrorT (a - b) m. We'd have to start mucking around with dummy Show instances/blind wrappers. I just finished writing up a post describing the MonadInvertIO approach[2], which I think is a more appropriate solution to the problem. It doesn't involve any runtime exception trickery, and works for a number of other use cases, including memory allocation. I would appreciate any critiques of my ideas. Michael [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/neither [2] http://docs.yesodweb.com/blog/invertible-monads-exceptions-allocations/#monadinvertio (links straight to the appropriate section, skips the long buildup) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] downloading GHC
I needed GHC on a new machine, and went to download a binary tarball. First, I go to http://haskell.org/ghc/download_ghc_6_12_3.html, which kindly suggests to get the Haskell Platform instead. Then, at http://hackage.haskell.org/platform/linux.html, I'm told that I first need GHC, and pointed back to the GHC download page. I'll manage, of course - but I think this is a bit more confusing than it need be. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thunks
Bernie Pope florbit...@gmail.com writes:
You can use side effects to observe the order of evaluation, by
wrapping observed expressions (thunks) with some IO computation inside
unsafePerformIO.
Not what OP asks for, but I've used a variant of this as a rather
hackish to provide progress reporting. I take a list that is lazily
generated, and wrap the elements with an IO action that outputs the
count every 'step' elements. When the list is evaluated, the IO actions
are executed. Code below.
-k
-- | Output (to stderr) progress while evaluating a lazy list.
-- Useful for generating output while (conceptually, at least) in pure code
countIO :: String - String - Int - [a] - IO [a]
countIO msg post step xs = sequence' $ map unsafeInterleaveIO ((blank outmsg
(0::Int) c):cs)
where (c:cs) = ct 0 xs
output = hPutStr stderr
blank= output ('\r':take 70 (repeat ' '))
outmsg x = output ('\r':msg++show x) hFlush stderr
ct s ys = let (a,b) = splitAt (step-1) ys
next = s+step
in case b of [b1] - map return a ++ [outmsg (s+step)
hPutStr stderr post return b1]
[] - map return (init a) ++ [outmsg
(s+length a) hPutStr stderr post return (last a)]
_ - map return a ++ [outmsg s return (head
b)] ++ ct next (tail b)
-- | A lazier version of 'Control.Monad.sequence' in Control.Monad, needed by
'countIO' above.
sequence' :: [IO a] - IO [a]
sequence' ms = foldr k (return []) ms
where k m m' = do { x - m; xs - unsafeInterleaveIO m'; return (x:xs) }
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: allocation for quot;purequot; FFI functions
Duncan Coutts duncan.coutts at googlemail.com writes: It is exactly for this purpose that the Haskell FFI library includes unsafePerformIO. This is basically *the* legitimate use case for it, so you don't need to feel bad about it. OK, thanks. Then this means my C type is a ForeignPtr, and each time I use it (even read-only) it looks like unsafePerformIO $ withForeignPtr $ \ p - ... Meanwhile I think I found a nice example and explanation here: http://en.wikibooks.org/wiki/Haskell/FFI#Self-Deallocating_Pointers J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Increasing number of parameters
Thanks Brandon! I really like the addParam utility, value val prompt = Question prompt (show val) (readCheck val) addParam :: (Show a) = (funTy - String - qty) - (a - funTy) - String - (a - qty) addParam qmakr fun string v = qmakr (fun v) (string++ ++show v) prefix1 = addParam value prefix2 = addParam prefix1 prefix3 = addParam prefix2 but my crusty and sleep-deprived brain is not really grokking the internal plumbing. So I'm trying to get to grips with a simpler variation on the same theme, and I'm still failing. I'm trying to write something along the lines of addArg :: nArgFn - a - nPlus1ArgFn addArg fn a = (a+) fn where = something which applies its right parameter to however many arguments it needs and feeds the result to the left parameter in order to allow me to say sum2 = (+) sum3 = addArg sum2 sum4 = addArg sum3 etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Who is afraid of arrows, was Re: ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Uwe Schmidt wrote: In HXT, the concept of a filter is the most important one. This concept is a natural generalisation of a function (and that's what arrows are). A user has to grasp this idea of a filter. And he/she can do this even without knowing anything about arrows or monads. People knowing a little bit of Unix pipes and filter will become easily familiar with the simple parts of this DSL. [...] The intention with HXT was not to build a general purpose languages, where you can do any kind of complex things. The intention was to build a (rather) simple and and powerful language for processing XML, nothing more. You may of course argue, whether we've found the right set of combinators, but that's another story. As Sebasiaan wrote in this reply, when processing XML, the cases for higher order computations are not very frequent. The few combinators available for this are, from a Real World Haskell point of view, sufficient. To sum it up, I think, from an implementers point of view for this eDSL, we agree that both ways arrows/monads are possible and rather similar. From a users point of view, I prefer a simple and specialised DSL, you would prefer a more general one. The question is indeed whether HXT offers the right set of combinators. Gregory and I are inclined to assert that monad combinators are most suitable. Sebastiaan and you prefer the arrow combinators. But I think that *neither* of these two options satisfies the worthwhile simple and specialised DSL criterion. You already entertain the notion that this is the case for the monad combinators, so I'll focus on the arrow case. The problem with the arrow combinators is that HXT does not use them in their full generality. Taking chapter 3 of Manuel Ohlendorfs' thesis as representative example, it is telling that: * The combinators first, second, (***) and () are completely unused, even though they are the core arrow combinators that can plumb multiple arguments. * Multiple arguments are handled with ($), which is not a general arrow combinator, but specific to kleisli arrows, i.e. those coming from a monad. That's why I don't like the slogan HXT = XML transformations with arrows: it suggests that the defining property of arrows - not being able to do currying while still being able to plumb multiple arguments - is used in an essential way, but this is actually not the case. Like monads, I think that arrows are not the right abstraction for HXT. (This reasoning is why I even thought that HXT were poorly designed and that's why, personally, I avoided using HXT and opted for HaXmL instead.) Personally, I would be much happier with the slogan HXT = XML transformations with filters. Browsing through Manuel's thesis, I discover that your combinators are quite slick ( , choiceA , when, guards ), it's just that they are a very specialized subset of the general arrow combinators. I think that dropping the arrows and rebranding your nice set of combinators as filter combinators would greatly improve the library. In particular, mastering arrows, like Manuel does in chapter 2 of this thesis, would become superfluous; an advantage that is similar to the advantage of not using monads, as you note. PS: Interestingly, this whole discussion is caused by just a small technical restriction of type classes: XMLArrow has to be a newtype because a - [b] cannot be made an instance of Arrow . You can make it either an arrow or a monad, but not both; even though it actually is both. PSS: By the way, the reason why I was preferring monad combinators is that they are a natural extension of lists. For instance, we have deep :: (XmlTree - XmlTree) - XmlTree - XmlTree deep f xml = [y | x - children xml, y - f x `orElse` deep f x] where [] `orElse` ys = ys xs `orElse` _ = xs which can also be written as deep f xml = do x - children xml f x `orElse` deep f x Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Increasing number of parameters
Jacek, I haven't been following this thread in any detail, so I apologise if I misunderstand your goal, but the ctm function in the polyToMonoid library (which maps its parameters to any specified monoid) appears to work in just this way. It keeps consuming parameters until you hand it to the trm function to deliver the final result. More documentation here: http://hackage.haskell.org/packages/archive/polyToMonoid/0.1/doc/html/Data-PolyToMonoid.html Kevin On Oct 15, 11:38 am, Jacek Generowicz jacek.generow...@cern.ch wrote: Thanks Brandon! I really like the addParam utility, value val prompt = Question prompt (show val) (readCheck val) addParam :: (Show a) = (funTy - String - qty) - (a - funTy) - String - (a - qty) addParam qmakr fun string v = qmakr (fun v) (string++ ++show v) prefix1 = addParam value prefix2 = addParam prefix1 prefix3 = addParam prefix2 but my crusty and sleep-deprived brain is not really grokking the internal plumbing. So I'm trying to get to grips with a simpler variation on the same theme, and I'm still failing. I'm trying to write something along the lines of addArg :: nArgFn - a - nPlus1ArgFn addArg fn a = (a+) fn where = something which applies its right parameter to however many arguments it needs and feeds the result to the left parameter in order to allow me to say sum2 = (+) sum3 = addArg sum2 sum4 = addArg sum3 etc. ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://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] Re: Increasing number of parameters
On 2010 Oct 15, at 11:53, Kevin Jardine wrote:
Jacek,
I haven't been following this thread in any detail, so I apologise if
I misunderstand your goal,
My goal (in this thread, at least) is to become a better Haskell
programmer, rather than to actually write any specific program. Yes,
there are specific goals cited as examples, but the overall purpose is
the journey, rather than the destination: I want to learn to walk and
to run, rather than to get anywhere, just yet.
but the ctm function in the polyToMonoid
library (which maps its parameters to any specified monoid) appears to
work in just this way.
Yes, I noticed your earlier announcement. Yes, I recognized that it's
pertinent to my last message. Yes, I've stored it in my (rapidly
growing) list of things that Haskell Cafe has thrown at me that I
should look into more deeply :-)
But my current short-term goal is to understand the plumbing in a
function that Brandon supplied, and to acquire the ability to write
this kind of function myself in my sleep, with my hands tied behind my
back, while the walls are falling all around me. At the moment I'm not
managing to write it at all :-(
It keeps consuming parameters until you hand it to the trm function to
deliver the final result. More documentation here:
Sounds a bit like the scheme I use for curried functions in Python.
Though in Python I also have the option of calling the function with
zero arguments to indicate termination, rather than terminating more
explicitly by giving it to a terminate function.
(Curried functions in Python? Can you tell that there's a Haskell
programmer dying to get out ? :-)
I've thrown in an example at the end, in case anybody is interested.
http://hackage.haskell.org/packages/archive/polyToMonoid/0.1/doc/html/Data-PolyToMonoid.html
It's already in my bookmarks, but thanks for taking the time to bring
it to my attention.
===
from functools import partial
def curry(fn):
Function decorator. Curries its argument. The curried version
collects all positional and keyword arguments it is given, until
it is called with an empty argument list, at which point it
applies the function to all the collected arguments.
def curried_function(*args, **kwds):
if not (args or kwds):
return fn()
else:
it = partial(fn, *args, **kwds)
try:
it.__name__ = fn.__name__
except AttributeError:
pass
return curry(it)
try:
curried_function.__name__ = fn.__name__ + ' (curried)'
except AttributeError:
pass
curried_function.fn = fn
return curried_function
@curry
def collect(*args, **kwds):
return I've collected: %s %s % (args, kwds)
print collect# function collect (curried) at 0x712db0
print collect(1) # function collect (curried) at 0x712d30
print collect(1)(2,3,c=4)# function collect (curried) at 0x712bf0
print collect(1)(2,3,c=4)() # I've collected: (1, 2, 3) {'c': 4}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Who is afraid of arrows, was Re: ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On 15 Oct 2010, at 10:44, Heinrich Apfelmus wrote: Personally, I would be much happier with the slogan HXT = XML transformations with filters. Browsing through Manuel's thesis, I discover that your combinators are quite slick ( , choiceA , when, guards ), it's just that they are a very specialized subset of the general arrow combinators. I think that dropping the arrows and rebranding your nice set of combinators as filter combinators would greatly improve the library. But then, HXT's filter combinators would return to being rather like HaXml's filter combinators, where the concept was first introduced. Personally, I'm very happy that customers avoid HXT (due to the complexity of the arrow interface), because that means more customers for HaXml... :-) Regards, Malcolm P.S. Coming soon in the next release of HaXml: full support for xmlns namespaces, and an XSDToHaskell translator. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types (Duck-typed variadic functions?)
Using Brandon's code as a starting point (as it's far neater than
mine), let's try asking some questions about fractions (I've included
the whole program at the end).
questions = [ addition 1 2, addition (1%2) (1%3) ]
This works, but the the fractions are shown as 1 % 2 and to make it
presentable to non-Haskellers, we have to change that to 1/2.
In order to do this, I tried to replace show with my own version which
I call view (in type class View). At this point I get
../arithmetic/hackBrandon.hs:63:23:
Ambiguous type variable `t' in the constraints:
`Num t'
arising from the literal `1'
at ../arithmetic/hackBrandon.hs:63:23
`View t'
arising from a use of `addition'
at ../arithmetic/hackBrandon.hs:63:14-25
`Read t'
arising from a use of `addition'
at ../arithmetic/hackBrandon.hs:63:14-25
Probable fix: add a type signature that fixes these type
variable(s)
My problem is that I don't see where I could add a type signature, but
still keep
addition :: a - a - Question
polymorphic.
=== Here's the code demonstrating the problem =
{-# LANGUAGE NoMonomorphismRestriction #-}
import System.IO (hFlush, stdout)
import Data.Ratio
data Result = Correct | Improve String | Huh String | Incorrect String
deriving Show
data Question = Question { ask:: String
, answer :: String
, check :: String - Result }
bool2result True = Correct
bool2result False = Incorrect
readCheckBy :: (Read a) = (a - Bool) - String - Result
readCheckBy pred str =
case reads str of [(val,)] - bool2result (pred val)
_ - Huh
readCheck :: (Read a, Eq a) = a - String - Result
readCheck v s = readCheckBy (==v) s
-- customized show
class View a where
view :: a - String
instance View Int where
view = show
instance (Integral n) = View (Ratio n) where
view = show
-- helpers
value val prompt = Question prompt (view val) (readCheck val)
infix2 op symbol a b = value (op a b) (unwords [view a, symbol, view b])
addParam :: (View a) = (funTy - String - qty) - (a - funTy) -
String - (a - qty)
addParam qmakr fun string v = qmakr (fun v) (string++ ++view v)
prefix1 = addParam value
prefix2 = addParam prefix1
prefix3 = addParam prefix2
-- question 'types'
addition = infix2 (+) +
questions = [ addition 1 2
, addition (1%2) (1%3)
]
test :: Question - IO ()
test q = do
putStr $ ask q ++ =
hFlush stdout
reply - getLine
putStrLn $ show $ check q reply
main = mapM_ test questions
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types (Duck-typed variadic functions?)
On 2010 Oct 15, at 13:32, Jacek Generowicz wrote: questions = [ addition 1 2, addition (1%2) (1%3) ] My problem is that I don't see where I could add a type signature, but still keep addition :: a - a - Question polymorphic. Well, OK, I could write addition 1 (2 :: Int) inside the question list, but that's rather ugly, and it would be immensely annoying to have to do this for every specific question. Is there anywhere else it could go ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] deploying applications that use plugins
hi all, i am working on an application that evaluates haskell code entered by the user using the plugins package [1]; now i want to deploy the application as a self-contained .app bundle on OSX, i.e. the end user should not have to install anything in addition. what do i need to bundle in order for plugins to work on a vanilla machine? i suppose i need ghc in PATH and have to ship modified versions of the package.conf files that point to the corresponding libraries within the application bundle? is there a parser for package.conf files? any pointers would be greatly appreciated! thanks, sk [1] http://hackage.haskell.org/package/plugins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] All binary strings of a given length
Hi - How can I generate all binary string of a given length? The type signature would something like - genbin :: Int - [String] For example genbin 2 would give [00,11,01,10] and genbin 3 would give [000,001,010,011,100,101,110,111] etc.. thanks.. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] All binary strings of a given length
genbin = flip replicateM 01 2010/10/15 rgowka1 rgow...@gmail.com: Hi - How can I generate all binary string of a given length? The type signature would something like - genbin :: Int - [String] For example genbin 2 would give [00,11,01,10] and genbin 3 would give [000,001,010,011,100,101,110,111] etc.. thanks.. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] All binary strings of a given length
Here's why it works: genbin 3 = replicateM 3 01 = (unfold replicateM) do x1 - 01; x2 - 01 ; x3 - 01; return [x1,x2,x3] = your desired result (enumerate all combinations of x1,x2,x3 with each being 0 or 1). 2010/10/15 Eugene Kirpichov ekirpic...@gmail.com: genbin = flip replicateM 01 2010/10/15 rgowka1 rgow...@gmail.com: Hi - How can I generate all binary string of a given length? The type signature would something like - genbin :: Int - [String] For example genbin 2 would give [00,11,01,10] and genbin 3 would give [000,001,010,011,100,101,110,111] etc.. thanks.. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] allocation for pure FFI functions
On Fri, 15 Oct 2010 09:07:22 +0100, Duncan Coutts duncan.cou...@googlemail.com wrote: On Thu, 2010-10-14 at 17:45 +, Johannes Waldmann wrote: Hi. I wonder how to do the following properly. I have one (large) C type, let's call it T, and I want to sell it as an abstract type in Haskell. I want to use C functions as if they were of type T - T (pure function, returns a modified copy of the input) and the question is, how to do the memory allocation for that, in particular, how to avoid IO showing up in the (visible) types on the Haskell side: I don't want IO because I don't want to declare some artificial order of execution - instead I want lazy evaluation. E.g., I might have some Haskell record with a T component which may or may not be evaluated (accessed) at all. It is exactly for this purpose that the Haskell FFI library includes unsafePerformIO. This is basically *the* legitimate use case for it, so you don't need to feel bad about it. I still feel bad about it. Its so easy to turn unsafePerformIO into unsafeCoerce, that I can well happen by mistake. I would like to have an unsafePerformIO that is only unsafe w.r.t. performing effects, not breaking the type-system. Here is a suggestion, it may be not new but I never seen it on unsafePerformIO: unsafePerformIO :: Typeable a = IO a - a unsafePerformIO = ... same code ... Provided that Typeable instance are all generated by the compiler this has the desired effect of preventing generalization of mutable data. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] All binary strings of a given length
Not the most efficient, but easy to understand:
genbin 0 = []
genbin 1 = [0, 1]
genbin i =
map ('0' :) x ++ map ('1' :) x
where
x = genbin $ i - 1
On Fri, Oct 15, 2010 at 2:21 PM, rgowka1 rgow...@gmail.com wrote:
Hi -
How can I generate all binary string of a given length? The type
signature would something like -
genbin :: Int - [String]
For example genbin 2 would give [00,11,01,10] and genbin 3
would give [000,001,010,011,100,101,110,111] etc..
thanks..
___
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] Re: All binary strings of a given length
Amazing, will never find this in any other languagw. But ghci crashes for bigger input. Like genbin 20. How to scale this function? On 10/15/10, Eugene Kirpichov ekirpic...@gmail.com wrote: Here's why it works: genbin 3 = replicateM 3 01 = (unfold replicateM) do x1 - 01; x2 - 01 ; x3 - 01; return [x1,x2,x3] = your desired result (enumerate all combinations of x1,x2,x3 with each being 0 or 1). 2010/10/15 Eugene Kirpichov ekirpic...@gmail.com: genbin = flip replicateM 01 2010/10/15 rgowka1 rgow...@gmail.com: Hi - How can I generate all binary string of a given length? The type signature would something like - genbin :: Int - [String] For example genbin 2 would give [00,11,01,10] and genbin 3 would give [000,001,010,011,100,101,110,111] etc.. thanks.. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: All binary strings of a given length
On Fri, 15 Oct 2010 14:34:42 +0200, rgowka1 rgow...@gmail.com wrote:
Amazing, will never find this in any other languagw. But ghci crashes
for bigger input. Like genbin 20. How to scale this function?
Well, scaling this isn't really possible, because of its complexity. It
generates all permutations of a given string with two states for each
position. In regular languages, this is the language {1,0}^n, n being the
length of the string. This means that there are 2^n different strings in
the language. For 20, that's already 1048576 different Strings! Strings
are furthermore not really the best way to encode your output. Numbers
(i.e. bytes) would be much better. You could generate them, and only
translate into strings when needed.
HTH,
Aleks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: All binary strings of a given length
Actually my ghci doesn't crash for genbin 25 (haven't tried further),
though it eats quite a bit of memory.
How are you going to use these bit strings? Do you need all of them at once?
2010/10/15 Aleksandar Dimitrov aleks.dimit...@googlemail.com:
On Fri, 15 Oct 2010 14:34:42 +0200, rgowka1 rgow...@gmail.com wrote:
Amazing, will never find this in any other languagw. But ghci crashes
for bigger input. Like genbin 20. How to scale this function?
Well, scaling this isn't really possible, because of its complexity. It
generates all permutations of a given string with two states for each
position. In regular languages, this is the language {1,0}^n, n being the
length of the string. This means that there are 2^n different strings in the
language. For 20, that's already 1048576 different Strings! Strings are
furthermore not really the best way to encode your output. Numbers (i.e.
bytes) would be much better. You could generate them, and only translate
into strings when needed.
HTH,
Aleks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] dph question
I trying to learn a bit about data parallel haskell, and started from the wiki page here: http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell. Two questions: The examples express the dot product as: dotp_double xs ys = sumP [:x * http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. y | x - xs | y - ys:] Unless I'm missing something, shouldn't this actually be: dotp_double xs ys = sumP [:x * http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. y | x - xs, y - ys:] Second, when I run Main with the prescribed 1 element array, everything seems to work quite nicely. The task takes about 2 seconds on my 4 processor x86_64, and threadscope shows all processors nicely utilized. However, when bumping this to 10 elements, rather than taking 10x longer as I expected, the process never terminates. During one run I even lost control of my machine and needed to do a hard reset. Are there known limits to the array sizes that can be handled with dph, or can someone suggest what might be going wrong here? Thanks, Warren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Fuzzy time deltas
Michael, The package Workflow has persistent timeouts (can wait for years and restart on system failure if embedded in the workflow monad, although it can run in the IO monad, with no recovery). They are composable with any action in the STM monad with orElse: flag - getTimeoutFlag $ 5*24*60 * 60-- wait exactly 5 days. even -- if the program restart ap - step . atomically $ readSomewhere return False `orElse` waitUntilSTM flag return True case ap of False - print something received True - print timeout step lift it from the IO to the workflow monad, and gives it persistence and recovery. without step, it runs in the IO monad (No recovery on system failure): flag - transientTimeout $ 5*24*60 * 60-- wait 5 days, timeout -- restarts in case of failure ap - atomically $ readSomewhere return False `orElse` waitUntilSTM flag return True case ap of False - print something received True - print timeout -- transientTimeout t= do flag - atomically $ newTVar False forkIO $ threadDelay(t * 100) atomically (writeTVar flag True) myThreadId = killThread return flag 2010/10/14 Michael Snoyman mich...@snoyman.com: Hey all, Is there a library that supports fuzzy time deltas? For example, given two UTCTimes (or something like that) it could produce: 43 seconds 13 minutes 17 hours 4 days 8 months I want to use it for the news feature on Haskellers. It's not that hard to write, just wondering if it's already been done. Michael ___ 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] Re: All binary strings of a given length
I expect this one to run in constant space:
import Data.Bits
genbin :: Int - [String]
genbin n = map (showFixed n) [0..2^n-1::Int]
where showFixed n i = map (bool '1' '0' . testBit i) [n-1,n-2..0]
bool t f b = if b then t else f
Daniel
On Oct 15, 2010, at 9:43 AM, Eugene Kirpichov wrote:
Actually my ghci doesn't crash for genbin 25 (haven't tried further),
though it eats quite a bit of memory.
How are you going to use these bit strings? Do you need all of them at once?
2010/10/15 Aleksandar Dimitrov aleks.dimit...@googlemail.com:
On Fri, 15 Oct 2010 14:34:42 +0200, rgowka1 rgow...@gmail.com wrote:
Amazing, will never find this in any other languagw. But ghci crashes
for bigger input. Like genbin 20. How to scale this function?
Well, scaling this isn't really possible, because of its complexity. It
generates all permutations of a given string with two states for each
position. In regular languages, this is the language {1,0}^n, n being the
length of the string. This means that there are 2^n different strings in the
language. For 20, that's already 1048576 different Strings! Strings are
furthermore not really the best way to encode your output. Numbers (i.e.
bytes) would be much better. You could generate them, and only translate
into strings when needed.
HTH,
Aleks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
___
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] Re: All binary strings of a given length
Thanks Daniel.
But genbin 32 gives an empty list.. works till 31.
On Fri, Oct 15, 2010 at 9:05 AM, Daniel Gorín dgo...@dc.uba.ar wrote:
I expect this one to run in constant space:
import Data.Bits
genbin :: Int - [String]
genbin n = map (showFixed n) [0..2^n-1::Int]
where showFixed n i = map (bool '1' '0' . testBit i) [n-1,n-2..0]
bool t f b = if b then t else f
Daniel
On Oct 15, 2010, at 9:43 AM, Eugene Kirpichov wrote:
Actually my ghci doesn't crash for genbin 25 (haven't tried further),
though it eats quite a bit of memory.
How are you going to use these bit strings? Do you need all of them at once?
2010/10/15 Aleksandar Dimitrov aleks.dimit...@googlemail.com:
On Fri, 15 Oct 2010 14:34:42 +0200, rgowka1 rgow...@gmail.com wrote:
Amazing, will never find this in any other languagw. But ghci crashes
for bigger input. Like genbin 20. How to scale this function?
Well, scaling this isn't really possible, because of its complexity. It
generates all permutations of a given string with two states for each
position. In regular languages, this is the language {1,0}^n, n being the
length of the string. This means that there are 2^n different strings in the
language. For 20, that's already 1048576 different Strings! Strings are
furthermore not really the best way to encode your output. Numbers (i.e.
bytes) would be much better. You could generate them, and only translate
into strings when needed.
HTH,
Aleks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
___
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] Re: All binary strings of a given length
On Fri, 15 Oct 2010 09:16:58 -0400, rgowka1 rgow...@gmail.com wrote: But genbin 32 gives an empty list.. works till 31. That's because Daniel uses values of type Int as intermediate storage during the computation, and Int values are only 32 bits long. By replacing Int with Integer (which does not have that limitation), you can make it work for larger numbers/longer strings: genbin n = map (showFixed n) [0..2^n-1::Integer] -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: dph question
I trying to learn a bit about data parallel haskell, and started from the wiki page here:http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell. Two questions: The examples express the dot product as: dotp_double xs ys = sumP [:x * http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. y | x - xs | y - ys:] Unless I'm missing something, shouldn't this actually be: dotp_double xs ys = sumP [:x * http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. y | x - xs, y - ys:] No, array comprehension desugaring works the same way as for list comprehension. So this correct: dotp_double xs ys = sumP [:x * y | x - xs | y - ys:] After desugaring this will be translated into (simplified): dotp_double xs ys = sumP (zipWithP (*) xs ys) which will multiply the arrays element wise and sum the result. The other definition dotp_double xs ys = sumP [:x * y | x - xs, y - ys:] will be translated into (something equivalent): dotp_double xs ys = sumP (concatMapP (\x - mapP (\y - x * y)) xs ys) which definitely is not the dot product. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dph question
On Friday 15 October 2010 14:59:18, Warren Harris wrote:
I trying to learn a bit about data parallel haskell, and started from
the wiki page here:
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell. Two
questions:
The examples express the dot product as:
dotp_double xs ys = sumP [:x *
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.
y | x - xs | y - ys:]
Unless I'm missing something, shouldn't this actually be:
dotp_double xs ys = sumP [:x *
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.
y | x - xs, y - ys:]
No, it's supposed to be a parallel list comprehension, the dot product is
sum $ zipWith (*) xs ys
and the
{ blah x y | x - xs | y - ys }
syntax (where {, } stand in for [, ] in parallel list comprehensions and
for [:, :] in parallel array comprehensions) means
{ blah x y | (x,y) - zip xs ys }
Second, when I run Main with the prescribed 1 element array,
everything seems to work quite nicely. The task takes about 2 seconds on
my 4 processor x86_64, and threadscope shows all processors nicely
utilized. However, when bumping this to 10 elements, rather than
taking 10x longer as I expected, the process never terminates. During
one run I even lost control of my machine and needed to do a hard reset.
Are there known limits to the array sizes that can be handled with dph,
or can someone suggest what might be going wrong here? Thanks,
Warren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dph question
Got it - thanks. Any idea about the run-away process problem? Thanks,
Warren
On Fri, Oct 15, 2010 at 9:32 AM, Daniel Fischer daniel.is.fisc...@web.dewrote:
On Friday 15 October 2010 14:59:18, Warren Harris wrote:
I trying to learn a bit about data parallel haskell, and started from
the wiki page here:
http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell. Two
questions:
The examples express the dot product as:
dotp_double xs ys = sumP [:x *
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.
y | x - xs | y - ys:]
Unless I'm missing something, shouldn't this actually be:
dotp_double xs ys = sumP [:x *
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.
y | x - xs, y - ys:]
No, it's supposed to be a parallel list comprehension, the dot product is
sum $ zipWith (*) xs ys
and the
{ blah x y | x - xs | y - ys }
syntax (where {, } stand in for [, ] in parallel list comprehensions and
for [:, :] in parallel array comprehensions) means
{ blah x y | (x,y) - zip xs ys }
Second, when I run Main with the prescribed 1 element array,
everything seems to work quite nicely. The task takes about 2 seconds on
my 4 processor x86_64, and threadscope shows all processors nicely
utilized. However, when bumping this to 10 elements, rather than
taking 10x longer as I expected, the process never terminates. During
one run I even lost control of my machine and needed to do a hard reset.
Are there known limits to the array sizes that can be handled with dph,
or can someone suggest what might be going wrong here? Thanks,
Warren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Increasing number of parameters
On 2010 Oct 15, at 11:38, Jacek Generowicz wrote:
[...]
So I'm trying to get to grips with a simpler variation on the same
theme, and I'm still failing. I'm trying to write something along
the lines of
addArg :: nArgFn - a - nPlus1ArgFn
addArg fn a = (a+) fn where
= something which applies its right parameter to however
many arguments it needs and feeds the result to the left parameter
in order to allow me to say
sum2 = (+)
sum3 = addArg sum2
sum4 = addArg sum3
etc.
-- OK, I've understood.
-- You use an accumulator to keep track of what has been done with the
-- arguments that have been seen so far, and addArg takes one more
-- argument, each time, and mixes it in with what is already there.
-- I smell a monad.
addArgSum :: (Num a) = (a - t) - a - a - t
addArgSum fn acc arg = fn (acc + arg)
sum1' = id
sum2' = addArgSum sum1'
sum3' = addArgSum sum2'
-- And here's a more general version.
addArg combine fn acc arg = fn (combine arg acc)
sum1 = id
sum2 = addArg (+) sum1
sum3 = addArg (+) sum2
sum4 = addArg (+) sum3
-- But I don't really get why the following leads to complaints about
-- infinite types.
-- sumN n = iterate (addArg (+)) id
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: darcs 2.5 release candidate 1
The darcs team would like to announce the immediate availability of darcs 2.5 release candidate 1 (also known as darcs 2.4.99.1 due to Cabal restrictions). If no blocking issues are found in the coming week, we will finally releease darcs 2.5. Important changes since darcs 2.4.4 are: * trackdown can now do binary search with the --bisect option * darcs always stores patch metadata encoded with UTF-8 * diff now supports the --index option * amend-record now supports the --ask-deps option * apply now supports the --match option * amend-record has a new --keep-date option * inventory-changing commands (like record and pull) now operate in constant time with respect to the number of patches in the repository * the push, pull, send and fetch commands no longer set the default repository by default * the --edit-description option is now on by default for the send command Changes since the last beta release are: * Fix a bug that let users add files outside the working copy directory * Fix excessive network usage when pulling from an old-fashioned repository * Make sure darcs builds on Windows with Haskell Platform 2010.2.0.0 If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.4.99.1.tar.gz and build it by hand as explained in the README file. Kind Regards, the darcs release manager, Reinier Lamers signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] downloading GHC
ketil: I needed GHC on a new machine, and went to download a binary tarball. First, I go to http://haskell.org/ghc/download_ghc_6_12_3.html, which kindly suggests to get the Haskell Platform instead. Then, at http://hackage.haskell.org/platform/linux.html, I'm told that I first need GHC, and pointed back to the GHC download page. I'll manage, of course - but I think this is a bit more confusing than it need be. Linux users don't have easy binary installers, usually. What can we do about this bootstrapping problem? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bulletproof resource management
* Henning Thielemann: Some open/close pairs have corresponding 'with' functions, that are implemented using Exception.bracket. You can also use them within GHCi. I think using both manual resource deallocation and finalizers makes everything more complicated and more unreliable. It seems that Exception.bracket does not work in all cases, see the recent MonadCatchIO, finally and the error monad thread. Anyway, the ability of closures (and threads) means that something like Exception.bracket does not prevent access to closed handles, so I still need an additional safety net. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Who is afraid of arrows, was Re: ANNOUNCE: Haskell XML Toolbox Version 9.0.0
15.10.2010 15:03, Malcolm Wallace пишет: On 15 Oct 2010, at 10:44, Heinrich Apfelmus wrote: Personally, I would be much happier with the slogan HXT = XML transformations with filters. Browsing through Manuel's thesis, I discover that your combinators are quite slick ( , choiceA , when, guards ), it's just that they are a very specialized subset of the general arrow combinators. I think that dropping the arrows and rebranding your nice set of combinators as filter combinators would greatly improve the library. But then, HXT's filter combinators would return to being rather like HaXml's filter combinators, where the concept was first introduced. Personally, I'm very happy that customers avoid HXT (due to the complexity of the arrow interface), because that means more customers for HaXml... :-) Regards, Malcolm P.S. Coming soon in the next release of HaXml: full support for xmlns namespaces, and an XSDToHaskell translator. Sorry, for offtopic. But how in HaXml will look equivalent this filter: data MyAttr = MyAttr String String getAttrs = deep (isElem hasName SomeTag) proc x - do aname - getAttrValue Name - x atype - getAttrValue Type - x returnA - MyAttr aname atype I personally have swithed to HaXml because they have less memory consumption, but for extracting attributes from nodes haven't found standart method. Regards, Dmitriy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IORef memory leak
The latter. atomicModifyIORef is harder though still, since it is a primop with the same properties as modifyIORef :/ So would it make sense to create a strict modifyIORef' function? Very much so. In fact, I'd argue the vast majority of uses are for the WHNF-strict version. I just fixed a leak with atomicModifyIORef that was exactly this problem. If it had at least been documented I wouldn't have had to do that. So I'm going to submit a library proposal to either 1) strictify atomicModifyIORef, 2) add atomicModifyIORef', or at the least 3) add documentation that says this function leaks. Same story for modifyIORef of course. The only workaround I could find is to immediately read the value back out and 'seq' on it, but it's ugly. So two questions: writeIORef doesn't have this problem. If I am just writing a simple value, is writeIORef atomic? In other words, can I replace 'atomicModifyIORef r (const (x, ())' with 'writeIORef r x'? Any reason to not do solution 1 above? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bulletproof resource management
On Fri, Oct 15, 2010 at 11:09 AM, Florian Weimer f...@deneb.enyo.de wrote: * Henning Thielemann: Some open/close pairs have corresponding 'with' functions, that are implemented using Exception.bracket. You can also use them within GHCi. I think using both manual resource deallocation and finalizers makes everything more complicated and more unreliable. It seems that Exception.bracket does not work in all cases, see the recent MonadCatchIO, finally and the error monad thread. Anyway, the ability of closures (and threads) means that something like Exception.bracket does not prevent access to closed handles, so I still need an additional safety net. That thread is for the function bracket provided by the package MonadCatchIO. Control.Exception.bracket should work fine as far as I know. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
