Re: [GHC] #7395: DefaultSignatures conflict with default implementations
#7395: DefaultSignatures conflict with default implementations --+- Reporter: cgaebel| Owner: Type: bug| Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: DefaultSignatures | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by basvandijk): * cc: v.dijk.bas@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7395#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] #7339: GHC fails to build from source on Alpha
#7339: GHC fails to build from source on Alpha -+-- Reporter: creemj| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Linux Architecture: alpha | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by slyfox): * cc: slyfox@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7339#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7339: GHC fails to build from source on Alpha
#7339: GHC fails to build from source on Alpha -+-- Reporter: creemj| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Linux Architecture: alpha | Failure: Building GHC failed Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by slyfox): I have the same fault on stage2 build (ghc-7.4.2 + alex-3.0.2) Looks like alex-2.3.5 fails to pass tests when built against ghc-7.4.1. so I guess miscompiled alex (or misgenerated lexer) is the real bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7339#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ 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 ___ 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: Unexpected ambiguity in a seemingly valid Haskell 2010 program
Right. What I meant is that with -XMonomorphismRestriction, it compiles with with both -XMonoLocalBinds and -XNoMonoLocalBinds. That means that MonoLocalBinds can not be solely responsible for this behaviour. Anyway, I just noticed that a very similar example (using Read) is described in the Haskell report's section on the monomorphism restriction. Roman * Erik Hesselink hessel...@gmail.com [2012-11-11 16:43:20+0100] That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ 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 ___ 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: Unexpected ambiguity in a seemingly valid Haskell 2010 program
That makes sense: MonomorphismRestriction makes bindings without parameters monomorphic, and MonoLocalBinds makes local bindings monomorphic. So either one will make this binding monomorphic. Only when both are off does it become polymorphic and does the error occur. Erik On Sun, Nov 11, 2012 at 5:37 PM, Roman Cheplyaka r...@ro-che.info wrote: Right. What I meant is that with -XMonomorphismRestriction, it compiles with with both -XMonoLocalBinds and -XNoMonoLocalBinds. That means that MonoLocalBinds can not be solely responsible for this behaviour. Anyway, I just noticed that a very similar example (using Read) is described in the Haskell report's section on the monomorphism restriction. Roman * Erik Hesselink hessel...@gmail.com [2012-11-11 16:43:20+0100] That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ 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 ___ 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
How to use `trace` while debuging GHC
Hello, While working on GHC sometimes I find it useful to dump the values of intermediate expressions, perhaps in the middle of pure code, using a combination of `trace` and `ppr`. The issue is that `ppr` returns an `SDoc`, and to turn an `SDoc` into a `String`, I need some `DynFlags`. There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use `trace` while debuging GHC
On Sun, Nov 11, 2012 at 05:24:06PM -0800, Iavor Diatchki wrote: There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? There is now StaticFlags.unsafeGlobalDynFlags. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use `trace` while debuging GHC
I've recently used the conveniently-typed (pprTrace :: String - SDoc - a - a) for this purpose. You have to compile with -DDEBUG, but it works great. Richard On Nov 11, 2012, at 8:36 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Nov 11, 2012 at 05:24:06PM -0800, Iavor Diatchki wrote: There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? There is now StaticFlags.unsafeGlobalDynFlags. Thanks Ian ___ 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] HaXml
On 9 Nov 2012, at 23:04, Michael Mossey wrote: Couldn't match expected type Text.XML.HaXml.Types.QName with actual type String. Poking around, I found this webpage describing an issue with a change to HaXml that happened after version 1.20.2: http://stackoverflow.com/questions/7501037/how-to-make-haxml-and-drift-work-with-ghc-7-0-3 This web page suggests that I need to install HaXml-1.20.2 to use it with the current version of the DtdToHaskell utility. For the record (and future web searches), this issue with HaXml (DtdToHaskell generating non-compilable code) was fixed in version 1.23 onwards, from around April 2012. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Taking over ghc-core
Great! On 10 November 2012 16:17, Shachaf Ben-Kiki shac...@gmail.com wrote: With Don Stewart's blessing (https://twitter.com/donsbot/status/267060717843279872), I'll be taking over maintainership of ghc-core, which hasn't been updated since 2010. I'll release a version with support for GHC 7.6 later today. Shachaf ___ 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] Not exporting a class
Hi, dear package authors. If you define a useful class, please think twice before you do not export the methods, otherwise something like this will happen: Am Samstag, den 10.11.2012, 21:39 -0800 schrieb David Fox: It looks like there is an export copy of the whole prettyprint system in template-haskell. I could switch over to that. Oh, and another one in uulib. And also in ansi-wl-pprint. I think I will switch to this last one. On Sat, Nov 10, 2012 at 6:17 PM, David Fox d...@seereason.com wrote: It may belong in Text.PrettyPrint. On Sat, Nov 10, 2012 at 6:16 PM, David Fox d...@seereason.com wrote: About as small as a package can get! Yeah, the Pretty class is in haskell-src, but they don't export the pretty method. I will drop them a line, but I sort of assumed they had a reason for doing it that way On Thu, Nov 8, 2012 at 2:02 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi David, your pretty-class package is pretty small. In the interest of preventing package proliferation: Have you talked to the maintainers of pretty or haskell-src-exts whether they’d include the class in their code? Thanks, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata 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] Not exporting a class
Hi Joachim, On Sun, Nov 11, 2012 at 02:10:34PM +0100, Joachim Breitner wrote: dear package authors. If you define a useful class, please think twice before you do not export the methods, otherwise something like this will happen: I like the way 'Common Lisp' deals with this issue. Exported symbols can be accessed by 'package:symbol' and non exported symbols can be accessed by 'package::symbol'. By using '::' you could still get something done but know, that you did something improper and should consult the appropriate maintainer. You almost have the best of both worlds, because I think that it's a good thing to export as few symbols as possible. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] size of Haskell Platform
This note is an offshoot of curl package broken in Windows, where this item appeared: Did you know that Strawberry Perl includes a cygwin gcc? ... Maybe Haskell Platform could do the same. The suggestion brought to mind a true-life parable: the pump station at Tok. (Tok is the third corner--after Anchorage and Fairbanks--of Alaska's triangular core of long-distance highways.) When I visited Tok long ago, it was a village of several hundred souls, almost all of whom were employed by one government agency or another, principal among which were the highway department, the Alaska Communication Service and the pump station, which kept fuel flowing to Eielson Air Force Base. The mission of the station was to keep one pump running 24 hours a day. Most of the time, of course, the pump hummed along by itself. To assure that, there had to be a standby machine, an operator to watch over both, and a mechanic who could fix them if need be. For such a lonely job it was deemed well to have two operators. And there had to be two operators for each of several shifts. A little redundancy on the mechanical side seemed wise, too. The crew and their families, say nothing of the pumps themselves, needed to be housed, and the installation needed to be supplied with the necessities of life. (The nearest supermarket was in Fairbanks, 300 miles away.) These needs demanded a motor pool and property maintenance cadre, whose very presence reinforced the need. Thus the support team to keep one pump going ballooned to about 100 people--a chain reaction that barely avoided criticality. So it seems to be with Haskell Platform, which aims to include all you need to get up and running--an extensive set of standard libraries and utilities with full documentation. I get the impression that the Platform is bedeviled by the same prospect of almost unfettered growth. [One ominous sign: the description of the Haskell Platform at lambda.haskell.org/platform/doc/current/start.html suggests that one must join some mysterious Cabal, whose nature is hidden by a link to nowhere, simply to get started.] What principles guide the selection of components for all you need to get up and running? Doug McIlroy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] size of Haskell Platform
Hey Doug, The process for adding new packages is specified here: http://trac.haskell.org/haskell-platform/wiki/AddingPackages The HP aims for comprehensive, general functionality. Things like databases, graphics libraries and web servers are well in scope for inclusion. It should grow. Cheers, Don On Nov 11, 2012 12:00 PM, Doug McIlroy d...@cs.dartmouth.edu wrote: This note is an offshoot of curl package broken in Windows, where this item appeared: Did you know that Strawberry Perl includes a cygwin gcc? ... Maybe Haskell Platform could do the same. The suggestion brought to mind a true-life parable: the pump station at Tok. (Tok is the third corner--after Anchorage and Fairbanks--of Alaska's triangular core of long-distance highways.) When I visited Tok long ago, it was a village of several hundred souls, almost all of whom were employed by one government agency or another, principal among which were the highway department, the Alaska Communication Service and the pump station, which kept fuel flowing to Eielson Air Force Base. The mission of the station was to keep one pump running 24 hours a day. Most of the time, of course, the pump hummed along by itself. To assure that, there had to be a standby machine, an operator to watch over both, and a mechanic who could fix them if need be. For such a lonely job it was deemed well to have two operators. And there had to be two operators for each of several shifts. A little redundancy on the mechanical side seemed wise, too. The crew and their families, say nothing of the pumps themselves, needed to be housed, and the installation needed to be supplied with the necessities of life. (The nearest supermarket was in Fairbanks, 300 miles away.) These needs demanded a motor pool and property maintenance cadre, whose very presence reinforced the need. Thus the support team to keep one pump going ballooned to about 100 people--a chain reaction that barely avoided criticality. So it seems to be with Haskell Platform, which aims to include all you need to get up and running--an extensive set of standard libraries and utilities with full documentation. I get the impression that the Platform is bedeviled by the same prospect of almost unfettered growth. [One ominous sign: the description of the Haskell Platform at lambda.haskell.org/platform/doc/current/start.html suggests that one must join some mysterious Cabal, whose nature is hidden by a link to nowhere, simply to get started.] What principles guide the selection of components for all you need to get up and running? Doug McIlroy ___ 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] size of Haskell Platform
On Sun, Nov 11, 2012 at 11:59 AM, Doug McIlroy d...@cs.dartmouth.edu wrote: So it seems to be with Haskell Platform, which aims to include all you need to get up and running--an extensive set of standard libraries and utilities with full documentation. I get the impression that the Platform is bedeviled by the same prospect of almost unfettered growth. That's an interesting story, but I think the analogy is fundamentally broken. So the pump needed someone to watch it, needed spares, needed multiple people for multiple shifts, then they needed mechanics and motor pools and all their families came along etc until finally it was a little town? Well, OK. But there's no such effect in software libraries - if I add in a bytestring library to the HP, I don't wind up needing a MS Excel shim library to service it! When I added in some popular core library like bytestring, there's no expansionary loop - I don't find myself needing to add in a dozen libraries just to make bytestring run better. Bytestring already runs fine. Its dependencies are all already in the HP; the additional complexity for adding Bytestring is just... Bytestring. The arrow of dependency points the other way than in your story - if I need a MS Excel shim library, maybe I'll need the bytestring library. It's a pyramid, not a repeatedly cycling positive feedback loop. (Incidentally, Geoffrey West's city research suggests that cities benefit from sublinear scaling of most infrastructure; so barely missing criticality is not at all surprising.) -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] size of Haskell Platform
I love it when people explain things or make a point using a relevant story (or parable) :) It reminds me of when Michael Abrash would start his articles with the same. Ah, the memories... Cheers Doug. On 11 Nov 2012 17:00, Doug McIlroy d...@cs.dartmouth.edu wrote: This note is an offshoot of curl package broken in Windows, where this item appeared: Did you know that Strawberry Perl includes a cygwin gcc? ... Maybe Haskell Platform could do the same. The suggestion brought to mind a true-life parable: the pump station at Tok. (Tok is the third corner--after Anchorage and Fairbanks--of Alaska's triangular core of long-distance highways.) When I visited Tok long ago, it was a village of several hundred souls, almost all of whom were employed by one government agency or another, principal among which were the highway department, the Alaska Communication Service and the pump station, which kept fuel flowing to Eielson Air Force Base. The mission of the station was to keep one pump running 24 hours a day. Most of the time, of course, the pump hummed along by itself. To assure that, there had to be a standby machine, an operator to watch over both, and a mechanic who could fix them if need be. For such a lonely job it was deemed well to have two operators. And there had to be two operators for each of several shifts. A little redundancy on the mechanical side seemed wise, too. The crew and their families, say nothing of the pumps themselves, needed to be housed, and the installation needed to be supplied with the necessities of life. (The nearest supermarket was in Fairbanks, 300 miles away.) These needs demanded a motor pool and property maintenance cadre, whose very presence reinforced the need. Thus the support team to keep one pump going ballooned to about 100 people--a chain reaction that barely avoided criticality. So it seems to be with Haskell Platform, which aims to include all you need to get up and running--an extensive set of standard libraries and utilities with full documentation. I get the impression that the Platform is bedeviled by the same prospect of almost unfettered growth. [One ominous sign: the description of the Haskell Platform at lambda.haskell.org/platform/doc/current/start.html suggests that one must join some mysterious Cabal, whose nature is hidden by a link to nowhere, simply to get started.] What principles guide the selection of components for all you need to get up and running? Doug McIlroy ___ 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] curl package broken in Windows
Heh, I was trying to build this yesterday and it was making by eyes bleed. With the curl package on Hackage, I merely need an SSL enabled version of libcurl, and every Linux distro I've tried this on has several variations of such a package. (You have a choice of OpenSSL or GNUTLS, for example.) Apparently neither OpenSSL nor cURL wants to provide such a Windows binary package, though, so I attempted to build a version of libcurl with SSL support... Sigbjorn's instructions are definitely out of date. (I couldn't use his ZIP package, either.) Using MSYS, though, I was able to compile a version of libcurl with winssl, but then every variation of cabal install command wasn't cooperating. What should I be using instead of the following, neither of which seems to tell cabal where to find libcurl? ``` $ CPPFLAGS=-Ic:/code/curl_install/include cabal install curl --ld-options=-Lc:/code/curl_install/lib $ cabal install curl --extra-lib-dirs=c:/code/curl_install/lib --extra-include-dirs=c:/code/curl_install/include ``` Detail, showing some verbose error messages: https://gist.github.com/4056331 Kevin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Hi Clark. I think we just use dependencies [to specify] different things. If dependency version constraints are specified as a white-list -- i.e. we include only those few versions that have been actually verified and exclude everything else --, then we take the risk of excluding *too much*. There will be versions of the dependencies that would work just fine with our package, but the Cabal file prevents them from being used in the build. The opposite approach is to specify constraints as a black-list. This means that we don't constrain our build inputs at all, unless we know for a fact that some specific versions cannot be used to build our package. In that case, we'll exclude exactly those versions, but nothing else. In this approach, we risk excluding *too little*. There will probably be versions of our dependencies that cannot be used to build our package, but the Cabal file doesn't exclude them from being used. Now, the black-list approach has a significant advantage. In current versions of cabal-install, it is possible for users to extend an incomplete black-list by adding appropriate --constraint flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way. In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file. For this reason, dependency constraints in Cabal should rather be underspecified than overspecified. Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC for mobile devices?
Yes, and the Android NDK allows you to write arbitrary C code, it's just a slightly less than pleasant interface with the SDK :-(. Perhaps it's easier to do this in iOS as it's all objective C rather than a vm with a runtime system. Also not sure what the status of porting the runtime system to ios would be. kris On Sat, Nov 10, 2012 at 9:03 PM, Andrew Pennebaker andrew.penneba...@gmail.com wrote: ASM for iOS is possible, so GHC mobile should be possible. www.shervinemami.info/armAssembly.html#howto On Nov 10, 2012 5:59 PM, Andrew Pennebaker andrew.penneba...@gmail.com wrote: I've tried porting GHC to Haiku OS, a Unix-like desktop OS, but the state of the GHC build system is fairly confusing. The build scripts contain a Perl script with a bad shebang, and you can't build GHC without already having a working older version. If someone can point me to the most recent GHC code that doesn't need itself to compile, I can work on a Haiku version as practice. I really want GHC for every possible system. On Nov 10, 2012 5:49 PM, Kristopher Micinski krismicin...@gmail.com wrote: On Sat, Nov 10, 2012 at 3:50 PM, Casey Basichis caseybasic...@gmail.com wrote: Hi Kris, No offense taken, it was an argument that works to shut down constructive discussion of how to get Haskell running on mobile, a task which has perplexed me for several long days. I agree most apps are pretty terrible, at least on iOS though, despite the percentages being wildly off there are still a few hundred apps that are very well done and thoughtful, none of them using Haskell I'm sure. Yup! Most of the time apps are merely translated versions of rails frontends. (For better or for worse, I assume that if we were to port haskell to work with Android really it would be mostly to appease my purity.) I'm looking to pass Haskell lists of musical data and return processed musical ideas from it (not audio, not realtime). I was also planning on handling a database within Haskell as the information contained would be used by the music processing and from what I have read Haskell interfaces to SQL far more readily than with a C++ orm type solution. I was planning on working with Haskells Euterpea as base to build my ideas off of, my I might end up rolling my own similar library as my aims are a bit different than theirs. I'm not sure I understand completely, but I agree this isn't a bad idea. Everything else would be C++, including the interface, audio and dsp processing etc. I already have the C++ stuff running on my phone. I have read about the difficulty of getting Haskell working in real world scenarios, but as far as I understand my plans for it are fairly well suited to it. I don't disagree! Since much of the documentation online about Haskell seems to be out of date, its tough to get a general feel for whats working. I see people mention that cross-compilation was finished a while back which should allow for targeting arm but nothing concrete and the website gives conflicting info. I've also considered using GHC to generate C to paste into the project but it seems there have been and may be more integrated ways to get it running. I am venturing into my embarrassing lack of knowledge about GHC internals here, but how easily would the run time system work on Android..? I had assumed a large part of the effort into getting OCaml to work on iPhone went into the runtime system, no? If you're (Andrew or anyone) still interested in pursuing this I would be interested in helping out, I have some Android internals knowledge and would be glad to lend a hand. One major thing that seems to be necessary is congealing all the (mis/outdated)information into the wiki article on haskell.org. kris ___ 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] curl package broken in Windows
Kevin Cantu wrote: With the curl package on Hackage, I merely need an SSL enabled version of libcurl, and every Linux distro I've tried this on has several variations of such a package. (You have a choice of OpenSSL or GNUTLS, for example.) I tried the CURL bindings on Linux some time ago and I personally found the thing pretty much un-usable. The API was incomplete, inconsistent and way too close to the C API. However, I have had much better luck with Michael Snoyman's http-conduit package, which being pure Haskell (ie no C) should be much easier to install on windows. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Peter Simons sim...@cryp.to writes: [...] Now, the black-list approach has a significant advantage. In current versions of cabal-install, it is possible for users to extend an incomplete black-list by adding appropriate --constraint flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way. In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file. ...but on the down side w.r.t. to white-listing: doesn't the black-list approach allow for a clean-environment 'cabal install package-with-many-transitive-deps' to suddenly break because a new major version of a dependee package was uploaded to Hackage which causes disturbances in the equilibrium due to API incompatibilities (even though the PVP was followed)? On the other hand, the white-list approach ensures reproducible builds (again, assuming the PVP is followed) in the sense that if there was a valid install-plan yesterday with a given GHC version, cabal-install will be able to find one today as well with the same GHC even though Hackage may have received new major versions. In other words, the white-list approach strives to conserve the invariant of sound package version interdependency constraints. That invariant is usually not the weakest possible one, but it converges against the ideal invariant. Whereas the black-list approach doesn't provide any such invariant, it's always lagging behind, trying to catch up with the ideal invariant as well, but from the other direction. So IMHO, from a formal standpoint, the white-list approach seems more correct, as it doesn't ever lead to an incompatible set of packages being compiled/linked against each other. cheers, hvr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Motion to unify all the string data types
From: Francesco Mazzoli f...@mazzo.li At Sat, 10 Nov 2012 15:16:30 +0100, Alberto G. Corona wrote: There is a ListLike package, which does this nice abstraction. but I don't know if it is ready for and/or enough complete for serious usage. I?m thinking into using it for the same reasons. Anyone has some experiences to share about it? I've used it in the past and it's solid, it's been around for a while and the original author knows his Haskell. Things I don't like: * The classes are huge: http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:ListLike . I'd much rater prefer to have all those utilities functions outside the type class, for no particular reason other then the ugliness of the type class. Speaking as the ListLike maintainer, I'd like this too. But it's difficult to do so without sacrificing performance. In some cases, sacrificing *a lot* of performance. So they have to be class members. However, there's no reason ListLike has to remain a single monolithic class. I'd prefer an API that's split up into several classes, as was done in Edison. Then 'ListLike' itself would just be a type synonym, or possibly a small type class with the appropriate superclasses. However this seems like a lot of work for relatively little payoff, which makes it a low priority for me. * It defines its own wrappers for `ByteString': http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:CharString . The community's view on newtypes is funny. On the one hand, I see all the time the claim Just use a newtype wrapper to write instances for ... (e.g. the recent suggestion of 'instance Num a = Num (a,a)'. On the other, nobody actually seems to want to use these newtype wrappers. Maybe it clutters the code? I don't know. I couldn't think of a better way to implement this functionality, patches would be gratefully accepted. Anyway, you really shouldn't use these wrappers unless you're using a ByteString to represent ASCII text. Which you shouldn't be doing anyway. If you're using a ByteString to represent a sequence of bytes, you needn't ever encounter CharString. * It doesn't have instances for `Text', you have to resort to the `listlike-instances' package. Given that text and vector are both in the Haskell Platform, I wouldn't object to these instances being rolled into the main ListLike package. Any comments on this? John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strange behavior with listArray
I'm stymied trying to figure out why the program below blows up with loop when I use f 0 for building the array, but if I substitute g or h in place of f, they work fine. Is this a bug or am I overlooking something? I am using GHC 7.4.2. Thanks, Alex P.S. Forgive the seemingly pointless program; I distilled this test from a longer actual program that was exhibiting this behavior. import Data.Array((!),Array,elems,listArray) import Data.List(intercalate) solve = let a :: Array Int Int a = listArray (0, 3) (0 : f 0) f k = if k 0 then f (a!0) else 0 : f 1 g k = k : a!(k+1) : a!(k+1) : a!(k+2) : a!(k+3) : [] h k = a!k : h (k+1) in (intercalate . map show . elems) a main = putStrLn solve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: fixed-vector
On 11/10/2012 06:59 AM, Aleksey Khudyakov wrote: Hello cafe! I want to announce library for the small vectors of fixed length fixed-vector[1]. Fixed means that vector's length is determined by its type. Generic API can work with both ATD-based vector like complex or Vec written below and array-based ones. data Vec a = Vec a a a It's based on post by Roman Leschinsiy[2]. Library also provide array-based vectors with memory representation similar to onves from vector package. It's more compact though because there is no need to store lengh and and offset to first element. [1] http://hackage.haskell.org/package/fixed-vector [2] http://unlines.wordpress.com/2010/11/15/generics-for-small-fixed-size-vectors/ I have a lot of one-off code where I've defined these myself. Is it possible to e.g. define vectors in R^2 and R^3, and write the p-norm functions only once? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: fixed-vector
Michael, I think that calls for a type-class! (though I imagine theres a slicker way of writing it) On Sun, Nov 11, 2012 at 11:18 PM, Michael Orlitzky mich...@orlitzky.comwrote: On 11/10/2012 06:59 AM, Aleksey Khudyakov wrote: Hello cafe! I want to announce library for the small vectors of fixed length fixed-vector[1]. Fixed means that vector's length is determined by its type. Generic API can work with both ATD-based vector like complex or Vec written below and array-based ones. data Vec a = Vec a a a It's based on post by Roman Leschinsiy[2]. Library also provide array-based vectors with memory representation similar to onves from vector package. It's more compact though because there is no need to store lengh and and offset to first element. [1] http://hackage.haskell.org/package/fixed-vector [2] http://unlines.wordpress.com/2010/11/15/generics-for-small-fixed-size-vectors/ I have a lot of one-off code where I've defined these myself. Is it possible to e.g. define vectors in R^2 and R^3, and write the p-norm functions only once? ___ 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] Strange behavior with listArray
On 12 November 2012 04:50, Alex Stangl a...@stangl.us wrote: I'm stymied trying to figure out why the program below blows up with loop when I use f 0 If you replace the a!0 in f by its value 0, f is equivalent to: f k = if k 0 then f 0 else 0 : f 1 Do you see the loop now? Maybe you meant f to be: f k = if k 0 then f (a!k) else 0 : f 1 Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Motion to unify all the string data types
On 10 November 2012 17:57, Johan Tibell johan.tib...@gmail.com wrote: It better communicates intent. A e.g. lazy byte string can be used for two separate things: * to model a stream of bytes, or * to avoid costs due to concatenating strings. By using a strict byte string you make it clear that you're not trying to do the former (at some potential cost due to the latter). When you want to do the former it should be clear to the consumer that he/she better consume the string in an incremental manner as to preserve laziness and avoid space leaks (by forcing the whole string). Good advice. And when you want to do the latter you should use a Builder[1] (or [2] if you're working with text). Bas [1] http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/Data-ByteString-Builder.html [2] http://hackage.haskell.org/packages/archive/text/0.11.2.3/doc/html/Data-Text-Lazy-Builder.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
