[GHC] #7222: The text Possible fix: add an instance declaration for ... is redundant and not usually helpful
#7222: The text Possible fix: add an instance declaration for ... is redundant
and not usually helpful
--+-
Reporter: maltem| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.4.2 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Other | Testcase:
Blockedby:| Blocking:
Related:|
--+-
The current state of affairs: Given a typical type error, for example
{{{
a + b
}}}
we get
{{{
No instance for (Num [Char])
arising from a use of `+'
Possible fix: add an instance declaration for (Num [Char])
In the expression: a + b
In an equation for `it': it = a + b
}}}
I'm concerned with the third line here:
1) It is redundant, for it just repeats information from the first line.
In my experience, the redundancy sometimes hinders usability, namely, when
the types get very long, visually burying the problematic expression.
2) Furthermore it is often misleading: Everyday type errors stem from
incorrect usage of a library, not from missing bits of a library. The line
tends to be confusing especially for new users: the only ones who might
have profited from the redundancy.
3) To expand a bit on (1): An imported bit of information in the type
error is the fact that the type mismatch lies in the application of (+) to
a. The user gains this information by combination of lines 2 and 4. It
is incovenient that line 3 visually seperates those lines.
I propose that the problematic line be simply removed.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7222
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] #7215: miscompilation due to broken interface hash
#7215: miscompilation due to broken interface hash
---+
Reporter: akio| Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.6.2
Component: Compiler| Version: 7.4.2
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by marlowsd@…):
commit 583c87d00d2058b1a073ea1f5d7f4e0d92b7a9a4
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Sep 5 16:38:50 2012 +0100
Fix #7215: we weren't calculating the hashes correctly for sub-binders
compiler/iface/IfaceSyn.lhs | 22 ++
compiler/iface/MkIface.lhs | 17 ++---
compiler/main/HscTypes.lhs | 34 --
3 files changed, 40 insertions(+), 33 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7215#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] #6160: support sub-second resolutions for file timestamps
#6160: support sub-second resolutions for file timestamps
---+
Reporter: redneb| Owner:
Type: feature request | Status: closed
Priority: normal| Milestone: 7.6.1
Component: libraries/unix|Version: 7.4.2
Resolution: fixed | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by pcapriotti):
* status: patch = closed
* resolution: = fixed
Comment:
Thank you for the patch. Applied as:
{{{
commit 62e07b8a423a78556e2f5d86d1affe7cca4c8896
Author: Marios Titas red...@gmx.com
Date: Sun Aug 12 15:46:22 2012 -0400
Add functions for setting file times with high resolution
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6160#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] #7215: miscompilation due to broken interface hash
#7215: miscompilation due to broken interface hash ---+ Reporter: akio| Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 7.6.2 Component: Compiler| Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by simonmar): * status: new = merge -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7215#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] #7218: No type level distinction between BroadcastTChan and TChan
#7218: No type level distinction between BroadcastTChan and TChan
+---
Reporter: timthelion | Owner: simonmar
Type: feature request| Status: closed
Priority: normal | Milestone:
Component: libraries (other) |Version: 7.4.2
Resolution: fixed | Keywords: STM TChan
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
{{{
commit 4965c0139de186c8322cb48b52550acb4b8d9afa
Author: Simon Marlow marlo...@gmail.com
Date: Thu Sep 6 09:46:20 2012 +0100
Throw an exception when reading from a broadcast channel (#7218)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7218#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] #7185: Compiled program crashes
#7185: Compiled program crashes +--- Reporter: waldheinz | Owner: simonmar Type: bug| Status: closed Priority: high | Milestone: 7.6.1 Component: Compiler |Version: 7.4.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as 13a833e51c141165d927325fa0d1bce9ccdab1de. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7185#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7222: The text Possible fix: add an instance declaration for ... is redundant and not usually helpful
#7222: The text Possible fix: add an instance declaration for ... is redundant and not usually helpful --+- Reporter: maltem| Owner: Type: bug | Status: new Priority: normal| Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Testcase: Blockedby:| Blocking: Related:| --+- Comment(by danlewis): As far as (2) goes, one improvement would be to refrain from suggesting adding an instance if that instance would be an orphan. This would suppress the message in errors stemming from library misuse. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7222#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] #7223: Unregisterised and/or via-C compilation broken
#7223: Unregisterised and/or via-C compilation broken -+-- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- The new codegen broke unregisterised and/or via-C compilation. It should be nothing serious. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7223 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] #7223: Unregisterised and/or via-C compilation broken
#7223: Unregisterised and/or via-C compilation broken -+-- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by simonmar): * version: 7.4.2 = 7.7 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7223#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] #7215: miscompilation due to broken interface hash
#7215: miscompilation due to broken interface hash --+- Reporter: akio | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.6.2 Component: Compiler |Version: 7.4.2 Resolution: fixed| Keywords: Os: Linux| Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as 1aa031e7013caf59f3297d29e81ed573eb306356. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7215#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] #7210: Bang in front of type name crashes GHC
#7210: Bang in front of type name crashes GHC
+---
Reporter: tibbe | Owner:
Type: bug | Status: patch
Priority: normal | Component: Compiler
Version: 7.6.1-rc1 | Keywords:
Os: Unknown/Multiple| Architecture: Unknown/Multiple
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by patrick@…):
commit 62da65a6ba728603b0ee4dab31cd9d59123f3135
{{{
Author: Patrick Palka patr...@parcs.ath.cx
Date: Mon Sep 3 10:27:26 2012 -0400
Fail nicely when encountering an invalid bang annotation (#7210)
compiler/typecheck/TcHsType.lhs |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7210#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] #7210: Bang in front of type name crashes GHC
#7210: Bang in front of type name crashes GHC -+-- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.6.1-rc1 Resolution: fixed | Keywords: Os: Unknown/Multiple| Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by pcapriotti): * status: patch = closed * difficulty: = Unknown * resolution: = fixed Comment: Thanks for the patch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7210#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7224: Polymorphic kind annotations on type classes don't always work as expected
#7224: Polymorphic kind annotations on type classes don't always work as
expected
---+
Reporter: slindley | Owner:
Type: bug| Status: new
Priority: normal | Component: Compiler (Type
checker)
Version: 7.6.1-rc1 | Keywords: kind polymorphism
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: GHC rejects valid program | Testcase:
Blockedby: | Blocking:
Related: |
---+
Consider the following code for defining Atkey-style parameterised monads:
{{{
{-# LANGUAGE
PolyKinds
#-}
class PMonad m where
ret :: a - m i i a
bind :: m i j a - (a - m j k b) - m i k b
class PMonad' (m :: i - i - * - *) where
ret' :: a - m i i a
bind' :: m i j a - (a - m j k b) - m i k b
}}}
The following types are inferred for {{{ret}}} and {{{ret'}}}:
{{{
*Main :t ret
ret :: PMonad * m = a - m i i a
*Main :t ret'
ret' :: PMonad' m = a - m BOX BOX a
}}}
But {{{ret'}}} should have the former type.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7224
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] #7225: ghc -C failed
#7225: ghc -C failed +--- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: Os: Windows | Architecture: x86 Failure: Compile-time crash | Testcase: Blockedby: | Blocking: Related: | +--- --- source file --- module Main where main = return () --- command line --- E:\DANE\wisnipr2\Tempghc -C Main.hs addFlag by -C on the commandline: Warning: The -fvia-C flag does nothing; it will be removed in a future GHC release ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-mingw32): pipeLoop: at phase As but I wanted to stop at phase HCc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7225 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] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma
#7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -+-- Reporter: tibbe | Owner: duncan Type: bug | Status: new Priority: normal| Milestone: Component: Template Haskell | Version: 7.0.4 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: igloo = duncan Comment: There are 5 packages to which the compiler is strongly tied: ghc-prim, base, integer-simple, integer-gmp, template-haskell. Currently, cabal-install avoids trying to install new versions of base, but doesn't treat the others specially. I think that the best fix would be to avoid installing any of the 5. What do you think, Duncan? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7200#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5405: Strange closure type crash when using Template Haskell on OS X Lion
#5405: Strange closure type crash when using Template Haskell on OS X Lion ---+ Reporter: AndreasVoellmy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.6.1 Component: GHCi| Version: 7.0.4 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by George): Unable to reproduce bug on Mac OS 10.8.1 (Mountain Lion) with latest 32 bit Haskell platform. I first did cabal install syntax-trees and was then able to compile and load the file (original bug) and evaluate ex1 which gave the expected value of 42 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5405#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7226: bytestring changes in 7.6 branch
#7226: bytestring changes in 7.6 branch --+- Reporter: igloo | Owner: Type: bug| Status: new Priority: highest| Milestone: 7.6.2 Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- There have been some bytestring changes in the 7.6 branch since the 7.6.1 release, including public interface changes. We should take a look and decide whether to go with them or to roll back before making a 7.6.2 release. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7226 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] #1974: length foo doesn't work with -XOverloadedStrings
#1974: length foo doesn't work with -XOverloadedStrings
-+--
Reporter: ganesh| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: _|_
Component: Compiler | Version: 6.8.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by parcs):
Have you considered changing the instance declaration from
{{{
instance IsString String where
}}}
to
{{{
instance (a ~ Char) = IsString [a] where
}}}
This new instance will make `length foo` happily typecheck, but it will
also overlap with other `IsString` instances of the form `[T]`. (Though I
don't think such instances are common in practice.)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1974#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: [Haskell] ANNOUNCE: GHC version 7.6.1
Awesome, I have been playing with GHC 7.6.0 until today and been very happy. Btw. isn't this the version that officially includes -fnew-codegen / HOOPL? Because the new codegen is optimizing the my ADPfusion library nicely. I lost 50% speed with new features, gained 100% with new codegen, meaning new features come for free ;-) Viele Gruesse aus Copenhagen, Christian * Ian Lynagh i...@well-typed.com [06.09.2012 18:09]: = The (Interactive) Glasgow Haskell Compiler -- version 7.6.1 = The GHC Team is pleased to announce a new major release of GHC, 7.6.1. Here are some of the highlights of the 7.6 branch since 7.4: * Polymorphic kinds and data promotion are now fully implemented and supported features. * Windows 64bit is now a supported platform. * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. * The RTS now supports changing the number of capabilities at runtime with Control.Concurrent.setNumCapabilities. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell pgpDi5FAWR2rY.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.6.1
Woho! I love new GHC releases. On Thu, Sep 6, 2012 at 9:05 AM, Ian Lynagh i...@well-typed.com wrote: Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html 1. There are a bunch of TODOs in the release notes. :) 2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On Thu, Sep 6, 2012 at 1:05 PM, Ian Lynagh i...@well-typed.com wrote: * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. I don't remember if this was part of the motivation in creating this feature, but it has a nice use case: asserting on a test suite that something should *not* type check. Cheers, -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On Thu, Sep 6, 2012 at 10:33 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Thu, Sep 6, 2012 at 1:05 PM, Ian Lynagh i...@well-typed.com wrote: * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. I don't remember if this was part of the motivation in creating this feature, but it has a nice use case: asserting on a test suite that something should *not* type check. We're getting more meta than Haskell provides cleanly, but all significant uses I can currently think of for something like that would require universal quantification over types: Forall types t. t `notElem` someTypes -- fails (tyUnification t MyType) I'm curious what your thinking is here. Thomas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
Hi, On 6 September 2012 18:49, Thomas DuBuisson thomas.dubuis...@gmail.comwrote: I don't remember if this was part of the motivation in creating this feature, but it has a nice use case: asserting on a test suite that something should *not* type check. We're getting more meta than Haskell provides cleanly, but all significant uses I can currently think of for something like that would require universal quantification over types: One way could be: import Control.Spoon f = 1 + 'a' test = assertTrue (teaspoon f == Nothing) -- Ozgur Akgun ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On Thu, Sep 6, 2012 at 2:49 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: We're getting more meta than Haskell provides cleanly, but all significant uses I can currently think of for something like that would require universal quantification over types: Forall types t. t `notElem` someTypes -- fails (tyUnification t MyType) I'm curious what your thinking is here. I'm developing a EDSL for SQL queries that I'll properly announce tomorrow. The idea I have in mind is that this code should not typecheck: delete $ from $ \table - set table [] You should not SET something inside a DELETE statement. However, currently that will typecheck---not because I don't know how to fix it, but because the types were already messy enough and I didn't ponder about the tradeoffs. So I would like to put the above snippet on a test suite that says this should not typecheck. It will serve both as a reminder to fix it someday and as a regression test. Of course, I could stick each of these on a separate file and try to compile it, but that would be a PITA to setup. Is this a crazy idea? =P Cheers, =) -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.6.1
On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote: 2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? I've now uploaded those that we maintain. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On Thu, Sep 06, 2012 at 06:32:38PM +0200, Christian Hoener zu Siederdissen wrote: Awesome, I have been playing with GHC 7.6.0 until today and been very happy. Btw. isn't this the version that officially includes -fnew-codegen / HOOPL? Because the new codegen is optimizing the my ADPfusion library nicely. I lost 50% speed with new features, gained 100% with new codegen, meaning new features come for free ;-) I suspect that you'll find that the new codegen doesn't work 100% perfectly in 7.6, although I don't know the details - perhaps it just isn't as fast as it could be. It'll be the default in 7.8, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type operators in GHC
Oh dear. I'm very sorry to have missed this discussion back in January. I'd
be awfully sad to lose pretty infix notation for type variables of kind *
- * - *. I use them extensively in my libraries and projects, and pretty
notation matters.
I'd be okay switching to some convention other than lack of leading ':' for
signaling that a symbol is a type variable rather than constructor, e.g.,
the *presence* of a leading character such as '.'.
Given the increasing use of arrow-ish techniques and of type-level
programming, I would not classify the up-to-7.4 behavior as a foolish
consistency, especially going forward.
-- Conal
On Wed, Jan 18, 2012 at 6:27 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Dear GHC users
As part of beefing up the kind system, we plan to implement the Type
operators proposal for Haskell Prime
http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors
GHC has had type operators for some kind, so you can say
data a :+: b = Left a | Right b
but you can only do that for operators which start with :.
As part of the above wiki page you can see the proposal to broaden this to
ALL operators, allowing
data a + b = Left a | Right b
Although this technically inconsistent the value page (as the wiki page
discussed), I think the payoff is huge. (And A foolish consistency is the
hobgoblin of little minds, Emerson)
This email is (a) to highlight the plan, and (b) to ask about flags. Our
preferred approach is to *change* what -XTypeOperators does, to allow type
operators that do not start with :. But that will mean that *some*
(strange) programs will stop working. The only example I have seen in tc192
of GHC's test suite
{-# LANGUAGE TypeOperators #-}
comp :: Arrow (~) = (b~c, c~d)~(b~d)
comp = arr (uncurry ())
Written more conventionally, the signature would look like
comp :: Arrow arr = arr (arr b c, arr c d) (arr b d)
comp = arr (uncurry ())
or, in infix notation
{-# LANGUAGE TypeOperators #-}
comp :: Arrow arr = (b `arr` c, c `arr` d) `arr` (b `arr` d)
comp = arr (uncurry ())
But tc192 as it stands would become ILLEGAL, because (~) would be a type
*constructor* rather than (as now) a type *variable*. Of course it's
easily fixed, as above, but still a breakage is a breakage.
It would be possible to have two flags, so as to get
- Haskell 98 behaviour
- Current TypeOperator behaviuor
- New TypeOperator behaviour
but it turns out to be Quite Tiresome to do so, and I would much rather
not. Can you live with that?
http://chrisdone.com/posts/2010-10-07-haskelldb-and-typeoperator-madness.html
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On 2012-09-07T09:00+1000, Ivan Lazar Miljenovic wrote: * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. Is this flag reversible in ghci, so I can :set it to check what's going wrong with some code and then :unset it again? As you can see on http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/flag-reference.html -fdefer-type-errors is dynamic, so you can reverse it using -fno-defer-type-errors. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Call for papers: HiPEAC Workshop FD-COMA 2013
=== Call for Papers 2nd Workshop on Feedback-Directed Compiler Optimization for Multi-Core Architectures FD-COMA 2013 Jan 22, 2013 8th HiPEAC Conference Berlin, Germany Jan 21-23, 2013 http://www.project-advance.eu/2012/07/fd-coma-workshop-2013/ http://www.hipeac.net/conference === FD-COMA is a half-day workshop during the 8th HiPEAC Conference in Berlin, January 21-23, 2013. The workshop is loosely connected to the FP-7 project Advance, but we particularly welcome contributions from outside the project consortium. === Mission: Feedback driven optimizations have long proven to be powerful instruments for achieving better hardware utilization, but the on-going multi-core and many-core revolution opens up a whole new realm of possible applications and variations of feedback-directed compiler optimization. The increasing hardware diversity of execution platforms and the likewise increasing hardware heterogeneity of individual execution platforms make compile time resource planning less and less feasible. Dynamic compilation techniques are required, instead, that adapt application programs to the actual hardware they are running on to make best use of it. Furthermore, the abundance of compute cores allows us to run feedback-directed compiler optimizations in parallel with an application itself and, thus, to adapt a running application to the hardware it is running on or to the data it is processing, to name just a few opportunities. This workshop aims at bringing people together that share an interest in the novel opportunities for feedback directed optimisations in the context of the emerging heterogeneous architectures. === Main topics: + Feedback directed compiler optimization for multi-core architectures + Data representation for runtime feedback information + Performance modelling for feedback, including statistical and constraint-based techniques + Performance measurement techniques suitable for dynamic feedback + Exploiting feedback for improved scheduling and improved mapping + Adaptive, feedback-controlled runtime systems for multi-core architectures + Exploiting feedback information for energy savings === FD-COMA welcomes submission of papers describing: + Experimental work + Industrial experience + Theoretical work + Software and hardware platforms + Work in progress all with respect to the above workshop topics === Paper submission: Submitted papers must not have been published or simultaneously submitted elsewhere. The full manuscript should be at most 8 pages in ACM SIGPLAN double column format. Submit a PDF copy of your manuscript via EasyChair: https://www.easychair.org/conferences/?conf=fdcoma2013 . Each paper will receive a minimum of two reviews. Papers will be selected based on their originality, relevance, technical clarity and presentation. Authors of accepted papers must guarantee that their papers will be registered and presented at the workshop. Accepted papers will be made available in printed form during the shop as well as in electronic form on the workshop homepage and as part of the HiPEAC conference materials. === Important dates: Submission deadline: 12/10/2012 Notification of acceptance: 12/11/2012 Final version due: 8/12/2012 === Workshop organizers: Clemens Grelck, University of Amsterdam, Netherlands Kevin Hammond, University of St Andrews, United Kingdom Sven-Bodo Scholz, Heriot-Watt University, United Kingdom === -- -- Dr Clemens Grelck Science Park 904 University Lecturer 1098XH Amsterdam Netherlands University of Amsterdam Institute for InformaticsT +31 (0) 20 525 8683 Computer Systems Architecture Group F +31 (0) 20 525 7490 Office C3.105 www.science.uva.nl/~grelck --
[Haskell] ANNOUNCE: GHC version 7.6.1
= The (Interactive) Glasgow Haskell Compiler -- version 7.6.1 = The GHC Team is pleased to announce a new major release of GHC, 7.6.1. Here are some of the highlights of the 7.6 branch since 7.4: * Polymorphic kinds and data promotion are now fully implemented and supported features. * Windows 64bit is now a supported platform. * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. * The RTS now supports changing the number of capabilities at runtime with Control.Concurrent.setNumCapabilities. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
Woho! I love new GHC releases. On Thu, Sep 6, 2012 at 9:05 AM, Ian Lynagh i...@well-typed.com wrote: Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html 1. There are a bunch of TODOs in the release notes. :) 2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? -- Johan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On 7 September 2012 02:05, Ian Lynagh i...@well-typed.com wrote: = The (Interactive) Glasgow Haskell Compiler -- version 7.6.1 = The GHC Team is pleased to announce a new major release of GHC, 7.6.1. Here are some of the highlights of the 7.6 branch since 7.4: * Polymorphic kinds and data promotion are now fully implemented and supported features. * Windows 64bit is now a supported platform. * It is now possible to defer type errors until runtime using the -fdefer-type-errors flag. Is this flag reversible in ghci, so I can :set it to check what's going wrong with some code and then :unset it again? * The RTS now supports changing the number of capabilities at runtime with Control.Concurrent.setNumCapabilities. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] From monads to monoids in a small category
Moreover, `m a` is 'a' plus some terminal element , for example
Nothing, [], Left _ etc, So a morphism (a - m a) contains all the
morphisms of (m a - m a).
2012/9/5 Alberto G. Corona agocor...@gmail.com:
Alexander,
In my post (excuses for my dyslexia) I try to demonstrate that the
codomain (m a), from the point of view of C. Theory, can be seen as
'a' plus, optionally, some additional element, so a monadic morphism
(a - m a) is part of a endofunctor in (m a - m a)
When considering the concept of arrow from category theory, (not the
concept of function), a point in the domain can send more than one
arrow to the codomain, while a function do not. I think that this is
the most interesting part of the interpretation, if I´m right.
About this, I found this article revealing:
http://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/
Therefore, codomains of (a - m a) which are containers with multiple
a elements can be considered as multi-arrow morphisms from 'a' to 'a'
with the optional addition of some special elements that denote
special conditions.
For example
(a - [a])
May be considered as the general signature of the morphisms from the
set 'a' to the set ('a' + [])
So a monadic transformation (a - [a]) can be considered as a point
transformation of a endofunctor within the set (a + []).
Alberto
2012/9/5 Alexander Solla alex.so...@gmail.com:
On Tue, Sep 4, 2012 at 4:21 PM, Alexander Solla alex.so...@gmail.com
wrote:
On Tue, Sep 4, 2012 at 3:39 AM, Alberto G. Corona agocor...@gmail.com
wrote:
Monads are monoids in the category of endofunctors
This Monoid instance for the endofunctors of the set of all elements
of (m a) typematch in Haskell with FlexibleInstances:
instance Monad m = Monoid (a - m a) where
mappend = (=) -- kleisly operator
mempty = return
The objects of a Kliesli category for a monad m aren't endofunctors. You
want something like:
instance Monad m = Monoid (m a - m (m a)) where ...
/These/ are endofunctors, in virtue of join transforming an m (m a) into
an (m a).
Actually, even these aren't endofunctors, for a similar reason that : you
really want something like
instance Monad m = Monoid (m a - m a) where
mempty = id
mappend = undefined -- exercise left to the reader
(i.e., you want to do plumbing through the Eilenberg-Moore category for a
monad, instead of the Kliesli category for a monad -- my last message
exposes the kind of plumping you want, but not the right types.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: grid-1.1
I'm happy to announce a new package called grid: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, and hexagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
It seems cool, looking forward to play with it! On 6 September 2012 09:42, Amy de Buitléir a...@nualeargais.ie wrote: I'm happy to announce a new package called grid: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, and hexagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome. ___ 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] ANNOUNCE: grid-1.1
Looks nice. Does it scale well to millions of elements, and can it handle 3D? On Thu, Sep 6, 2012 at 12:37 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: It seems cool, looking forward to play with it! On 6 September 2012 09:42, Amy de Buitléir a...@nualeargais.ie wrote: I'm happy to announce a new package called grid: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, and hexagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
Paul Visschers mail at paulvisschers.net writes: Looks nice. Does it scale well to millions of elements, and can it handle 3D? The current implementation wouldn't scale well to millions of elements, but it shouldn't take much tweaking to support that. Currently, when a grid is constructed, the list of all possible indices is constructed as well, so that calls to the indices function are fast. To support large numbers of tiles, I would instead generate all possible indices only when the indices function is called. Then the indices function would be too slow to be usable for more than, say, 50,000 tiles. But perhaps you don't need that function. At present, the only 3D support I have is for square tiles on the surface of the torus. I could add more tile shapes on the surface of the torus or other 3D shapes. I could also add support for 3D tiles (e.g., cubes, pyramids) in a 3D volume, if that's what you need. Let me know what your needs are and I'll try to incorporate it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
On Thu, Sep 06, 2012 at 09:42:19AM +, Amy de Buitléir wrote: I'm happy to announce a new package called grid: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) Looks neat! By the way, the URLs within the Haddock documentation are formatted improperly (because Haddock interprets the forward slashes as italic markers). You should place the URLs within angle brackets like http://github.com/foo/bar and Haddock will turn them into real clickable links. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
On Thu, Sep 6, 2012 at 8:04 AM, Amy de Buitléir a...@nualeargais.ie wrote: Paul Visschers mail at paulvisschers.net writes: Looks nice. Does it scale well to millions of elements, and can it handle 3D? The current implementation wouldn't scale well to millions of elements, but it shouldn't take much tweaking to support that. Currently, when a grid is constructed, the list of all possible indices is constructed as well, so that calls to the indices function are fast. To support large numbers of tiles, I would instead generate all possible indices only when the indices function is called. Then the indices function would be too slow to be usable for more than, say, 50,000 tiles. But perhaps you don't need that function. It seems like you should be able to stick this behind some abstraction so that you can support multiple implementations for grids (i.e., currently storing indices as you mention, but could support other implementations with different trade offs ...)? kris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
It seems like you should be able to stick this behind some abstraction so that you can support multiple implementations for grids (i.e., currently storing indices as you mention, but could support other implementations with different trade offs ...)? kris Yes, there's a Grid typeclass which anyone can extend. The minimal complete definition is: indices, distance, and size. There are default implementations of the other functions, but you can also develop your own. So as you suggest, it would be easy for me to add other grid implementations that would live side-by-side with the current implementations, but would have different trade-offs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: grid-1.1
Brent Yorgey byorgey at seas.upenn.edu writes: Looks neat! By the way, the URLs within the Haddock documentation are formatted improperly... Cheers! I'll fix that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] performance issues with popCount
Dear Haskell Cafe,
I am struggling with the performance of the popCount function from
Data.Bits.
To be more precise: I downloaded the Haskell Platform 2012.2.0.0 from
http://hackage.haskell.org/platform/ (64 bit, Mac OS X). In this version
I found the popCount function to be broken. If I look in the online
documentation at
http://hackage.haskell.org/packages/archive/base/4.5.1.0/doc/html/src/Data-Bits.html#popCount
it is already fixed, but included with my Haskell Platform was the
broken version.
Anyway, I tried this version
popCount :: Integer - Int
popCount = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
and profiling showed that my program spent 80 % of its time counting bits.
So I thought I'm clever and implement a table-based version like this:
popCount' :: Integer - Int
popCount' = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
popCountN = 10
popCountMask :: Integer
popCountMask = shift 1 popCountN - 1
popCountTable :: Array Integer Int
popCountTable = listArray (0, popCountMask) $ map popCount' [0 ..
popCountMask]
popCount :: Integer - Int
popCount 0 = 0
popCount x = popCountTable ! (x .. popCountMask) + popCount (x `shiftR`
popCountN)
turns out this is even slower ... now my program spends 90 % of its time
counting bits :-(.
Any hints?
Thanks
--
Harald Bögeholzb...@ct.de (PGP key available from servers)
Redaktion c't Tel.: +49 511 5352-300 Fax: +49 511 5352-417
http://www.ct.de/
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
(Arndt/Haenel)
Affe Apfel Vergaser
/* Heise Zeitschriften Verlag GmbH Co. KG * Karl-Wiechert-Allee 10 *
30625 Hannover * Registergericht: Amtsgericht Hannover HRA 26709 *
Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag *
Geschäftsführung GmbH * Registergericht: Amtsgericht Hannover, HRB
60405 * Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder */
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] performance issues with popCount
What _should_ be happening is we should be calling GMP's popcount
function when using integer-gmp.
As for your code I worry about it:
* being too lazy, so add some bang patterns or seq
* using boxed arrays, so use unboxed
* indexing arrays by Integer comparison even when those are small
integers - just index by Int.
* will never terminate with negative values. Sure it's a solution but
calling 'error' is more appropriate.
But really I hope you spend the time fixing base, not making a one-off
solution that will still be slow.
Cheers,
Thomas
On Thu, Sep 6, 2012 at 9:46 AM, Harald Bögeholz b...@ct.de wrote:
Dear Haskell Cafe,
I am struggling with the performance of the popCount function from
Data.Bits.
To be more precise: I downloaded the Haskell Platform 2012.2.0.0 from
http://hackage.haskell.org/platform/ (64 bit, Mac OS X). In this version
I found the popCount function to be broken. If I look in the online
documentation at
http://hackage.haskell.org/packages/archive/base/4.5.1.0/doc/html/src/Data-Bits.html#popCount
it is already fixed, but included with my Haskell Platform was the
broken version.
Anyway, I tried this version
popCount :: Integer - Int
popCount = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
and profiling showed that my program spent 80 % of its time counting bits.
So I thought I'm clever and implement a table-based version like this:
popCount' :: Integer - Int
popCount' = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
popCountN = 10
popCountMask :: Integer
popCountMask = shift 1 popCountN - 1
popCountTable :: Array Integer Int
popCountTable = listArray (0, popCountMask) $ map popCount' [0 ..
popCountMask]
popCount :: Integer - Int
popCount 0 = 0
popCount x = popCountTable ! (x .. popCountMask) + popCount (x `shiftR`
popCountN)
turns out this is even slower ... now my program spends 90 % of its time
counting bits :-(.
Any hints?
Thanks
--
Harald Bögeholzb...@ct.de (PGP key available from servers)
Redaktion c't Tel.: +49 511 5352-300 Fax: +49 511 5352-417
http://www.ct.de/
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
(Arndt/Haenel)
Affe Apfel Vergaser
/* Heise Zeitschriften Verlag GmbH Co. KG * Karl-Wiechert-Allee 10 *
30625 Hannover * Registergericht: Amtsgericht Hannover HRA 26709 *
Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag *
Geschäftsführung GmbH * Registergericht: Amtsgericht Hannover, HRB
60405 * Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder */
___
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] performance issues with popCount
Hi Harald,
On Thu, Sep 6, 2012 at 9:46 AM, Harald Bögeholz b...@ct.de wrote:
Anyway, I tried this version
popCount :: Integer - Int
popCount = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
and profiling showed that my program spent 80 % of its time counting bits.
This is very much a placeholder version. I didn't spend any time
optimizing the Integer implementation (the implementations for fixed
sized type are quite optimal however).
So I thought I'm clever and implement a table-based version like this:
popCount' :: Integer - Int
popCount' = go 0
where
go c 0 = c
go c w = go (c+1) (w .. (w - 1))
popCountN = 10
popCountMask :: Integer
popCountMask = shift 1 popCountN - 1
popCountTable :: Array Integer Int
popCountTable = listArray (0, popCountMask) $ map popCount' [0 ..
popCountMask]
popCount :: Integer - Int
popCount 0 = 0
popCount x = popCountTable ! (x .. popCountMask) + popCount (x `shiftR`
popCountN)
Have a look at the popCount implementation for e.g. Int, which are
written in C and called through the FFI:
https://github.com/ghc/packages-ghc-prim/blob/master/cbits/popcnt.c
Perhaps you could create a binding to the GMP mpz_popcount function,
as Integer is implemented using GMP already? It would make a nice
patch to the Data.Bits module. Note that you'd still need a fallback
for those that use integer-simple instead of integer-gmp.
If you don't want to do that you can take this function:
uint8 popcnt8(uint8 x)
{
return popcount_tab[(unsigned char)x];
}
and call it repeatedly (via the FFI) for each byte in your Integer.
(Use the popcount_tab I linked to above.)
-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell with all the safeties off
I have no plans to do such a thing anytime soon, but is there a way to tell GHC to allow nasal demons to fly if the program forces bottom? This mode of operation would seem to be a useful optimization when compiling a program produced by Coq or similar, enabling various transformations that can turn bottom into non-bottom, eliminating runtime checks in incomplete patterns, etc. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
