Re: LAST CALL to comment on the Applicative/Monad Proposal

On 2019-03-31 at 18:02:13 +0200, Bardur Arantsson wrote: >> In all fairness, Herbert did state [1] he intends to write up the >> combination of AMP, MFP, and MNRP the way he likes it. > > Did anything come of this? Actually yes! I started prototyping how the library-report modules could like like

Re: LAST CALL to comment on the Applicative/Monad Proposal

Hello Mario et al., On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote: > While you're reviewing AMP, please take a bit of time to also comment on > the related new MonadPlus excise proposal at > https://github.com/haskell/rfcs/pull/23 > > The proposal is very short so it should be an easy

Re: [Haskell] [ANNOUNCE] GHC 8.6.1 released

Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later; please upgrade to

Re: [ANNOUNCE] GHC 8.6.1 released

Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later; please upgrade to

Re: PSA for Cabal 2.2 new-* users regarding .ghc.environment files

On Sat, May 12, 2018 at 10:41 PM, Gershom B wrote: > In particular, there is not good information provided by ghc about > when these files are picked up and used. Fwiw, there's already an overdue patch up for that at https://phabricator.haskell.org/D4689 If there's enough

Shall the Haskell Report remain in LaTeX?

Hello *, On 2017-09-08 at 00:46:52 +0200, Mario Blazevic wrote: [...] >> If the report was written in reStructuredText we could simply use >> something like the readthedocs.org service. But since it's LaTeX, we >> have to do a little bit more work to publishes ("deploys" in newspeak) >> .pdf

Re: Remove eq and show from num class

On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote: [...] > If this is to the committee, shouldn't it be on the committee list? > (I mean ghc-steering-committee.) > Or is there some other committee? I thought the Haskell-prime forum > and process was dead/replaced by the github proposals

Re: Remove eq and show from num class

Hello! On 2017-09-07 at 18:16:39 +0200, Mario Blazevic wrote: >> Btw, here's an old commit which updates the class diagram to this >> effect for the report: >> >> https://github.com/hvr/haskell-report/commit/ >> 339ea257ee8b0451fbba388480566efac6ecbbd3 >> > Ha, I wasn't aware of that repository.

Re: GitHub proposal repo permissions

On 2016-10-12 at 19:09:47 +0200, Iavor Diatchki wrote: > I was just trying to update the `Haskel 2020` project as it is not in sync > with the actual pull-requests, bit I can't see a way to do it. Am I > missing something, or do I simply not have the required permissions? > > If this is indeed a

Re: [Haskell-community] Standard package file format

On 2016-09-17 at 06:47:52 +0200, Bardur Arantsson wrote: [...] > I was actually curious about this, and it's interesting to note that > even JSON which was supposed to have *ONE STANDARD* now apparently has > two, an ECMA one and and IETF RFC (seems to be more recent). Btw, that's partly

Re: [Haskell-community] Standard package file format

On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote: [...] > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The >

Re: Limber separators

On 2016-05-31 at 15:42:14 +0200, Antonio Nikishaev wrote: [...] > Personally I don't need this extension per se since I don't care about one > excess diff line. > What I do care about however, is the horrendous style people invented to > avoid “the diff problem”. > As an example > > something

Re: Infrastructure status?

Hello! On 2016-05-31 at 19:50:54 +0200, Iavor Diatchki wrote: > what is the status of the discussion about how we should collaborate? > I am not picky and would be happy to use whatever tools others prefer. > If it was left to me, I'd use: 1) a git repo on github, which contains > the current

Re: Are there GHC extensions we'd like to incorporate wholesale?

On 2016-05-04 at 06:48:38 +0200, wren romano wrote: [...] > Speaking of which, are things like the AMP and FTP under our purview > or are they under the CLC? I tried to clarify in the call-for-nomination and the formation announcement that the library part of the Haskell Report shall be

Re: Are there GHC extensions we'd like to incorporate wholesale?

On 2016-05-03 at 00:57:38 +0200, John Wiegley wrote: > I wonder if there are GHC extensions we'd like to promote as features > in the next report, as a starting point for discussing new additions. > > There are a few GHC features that have become part of the regular > Haskell landscape, such that

Re: Chairship / responsibility

Hello *, On 2016-04-29 at 15:17:43 +0200, Richard Eisenberg wrote: > Is there a chair of this committee? Herbert has been acting as such > (thank you!) but doesn't list himself as the chair in the initial > announcement. > > I am **in no way** trying to change any status quo and > am **not**

Re: Haskell Prime 2020 committee

Hello, On 2016-04-28 at 23:28:11 +0200, wren romano wrote: > On Thu, Apr 28, 2016 at 5:19 PM, José Manuel Calderón Trilla > wrote: >> There seems to be a minimum of 5 characters for a username, which was >> giving me the “Username doesn't match local naming policy.” error. >> >> I

Infrastructure & Communication

Hello Fellow Committee Members! Following up on the official announcement, here's a few basic things we should get agreement over before proceeding. First off, I'm hoping we can manage to avoid confusing email-threading in the interest of finding information easier lateron in the email

Re: Reconsidering -Wall and -Wcompat

On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote: [...] > * include -Wcompat and -Wall, but make it "magic" so that -Wcompat > never causes a build to fail even when users set -Wall -Werror. Tbh, I don't like the "magic" part at all. In fact, I currently rely on `-Wcompat -Werror`

Re: Reconsidering -Wall and -Wcompat

On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote: [...] > As stated on the Wiki, stuff in -Wcompat will often be non-actionable, > so the only option I see if -Wcompat is included in -Wall will be > -Wno-compat for all my projects. This depends on what we mean by "actionable". I'm not sure I'd

Re: Reconsidering -Wall and -Wcompat

On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote: > On Feb 14, 2016, at 1:51 PM, Sven Panne wrote: >> >> IMHO, the distinction between "during development" and "outside of it" is >> purely hypothetical. > > I find this comment quite interesting, as I see quite a

Re: Breaking Changes and Long Term Support Haskell

On 2015-10-22 at 08:04:10 +0200, Taru Karttunen wrote: [...] > B) There is an automated tool that can be used to fix most code > to compile with new versions of GHC without warnings or CPP. Fyi, Alan is currently working on levaraging HaRe[1] in https://github.com/alanz/Hs2010To201x (the

Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Hello, On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: [...] > In effect, only those who actively follow the libraries list have had a > voice in these decisions. Maybe that is what the community wants. I hope > not. How then can people like me (and Henrik and Graham) have a say >

[Haskell] Final Call for Haskell Prime language committee Nominations!

at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https

Re: MRP, 3-year-support-window, and the non-requirement of CPP

I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in y

Re: MRP, 3-year-support-window, and the non-requirement of CPP

Hi, On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote: > On 6 October 2015 at 19:03, Herbert Valerio Riedel <h...@gnu.org> wrote: >>> In the specific case of MRP, I can offer you a Wall-perfect transition >>> scheme by either using `ghc-options: -fno-mrp-warni

MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins [...] >> Strongly -1 from me also. My experience over the last couple of years is >> that every GHC release breaks my libraries in annoying ways that require >> CPP to

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote: > I was always under the impression that +1/-1 was just a quick > indicator of opinion, not a vote, and that it was the core libraries > committee that would make the final call if enough consensus was > reached to enact the change. I'd like

Re: MRP, 3-year-support-window, and the non-requirement of CPP

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my

Re: MRP, 3-year-support-window, and the non-requirement of CPP

I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in y

Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote: > 2015-10-05 11:59 GMT+02:00 Simon Thompson : > >> [...] It’s really interesting to have this discussion, which pulls in all >> sorts of well-made points about orthogonality, teaching, the evolution of >> the language and

[Haskell] ANN: CfN for new Haskell Prime language committee

Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html for more details. Cheers, hvr -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C

Call for Nominations: Haskell Prime language committee

` list[5] indicating your desire to self-nominate and any relevant experience. Decisions on these nominations will then be made by discussion among the current members of the committee. Nominations close in 3 weeks time. Regards, Herbert Valerio Riedel [1]: https://ghc.haskell.org/tra

ANN: CfN for new Haskell Prime language committee

Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html for more details. Cheers, hvr -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C

Re: simultaneous ghc versions

On 2015-07-31 at 20:32:43 +0200, Evan Laforge wrote: On Fri, Jul 31, 2015 at 11:26 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Btw, I simply prepend to the $PATH env variable, or pass the appropriate executable name to `cabal`'s -w --with-compiler=PATHgive the path

Querying the git commit id of GHC snapshots (was: ANNOUNCE: GHC 7.10.2 Release Candidate 1)

On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote: Is the 7.10.2 hvr ppa using this RC? ...it's easy to check, as since 7.10 we embed the Git commit id into the source-tarball as well as into the generated ghc binary: $ /opt/ghc/7.10.2/bin/ghc --info | grep Git ,(Project Git commit

Native -XCPP Conclusion (was: RFC: Native -XCPP Proposal)

plan 4[1]? [1]: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp [2]: http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869 Thanks, HVR On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote: Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: At the risk of antagonizing some (most? all?) of you, how about... -XCPP stands for the native CPP -XGNUCPP stands for GNU's GCC CPP -XClangCPP stands for Clang's CPP -XCPPHS stands for CPPHS Assuming this was a serious suggestion,

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project

RFC: Native -XCPP Proposal

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a traditional mode c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed

Re: RFC: Native -XCPP Proposal

On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote: As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a traditional mode c-preprocessor. Yes. This is one of my favourite things in GHC-land --

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

Hi Mark, On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote: I've just built a bindist under 10.10, but just normal not expressly llvm. I'll test this in a bit then post it -- but might be sometime tomorrow before it is up. How's progress on this btw? Are you also working on a GHC 7.8.4

Re: How to remove a cabal package from the local system?

On 2015-01-22 at 09:04:30 +0100, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? Not sure if this is what you want, but the `cab` tool has an `uninstall` sub-command to unregister and remove installed packages.

Re: How to remove a cabal package from the local system?

On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? Not sure if this is what you want, but the `cab` tool has an `uninstall` sub-command to unregister and remove installed packages.

Re: GHC 7.10 regression when using foldr

Hello Bryan, On 2015-01-20 at 23:17:01 +0100, Bryan O'Sullivan wrote: [...] For the record, it took me almost an hour to update attoparsec to fix all the various regressions, or to put it more charitably changes, introduced in GHC 7.10. I have twenty-something other packages to go through. I

Re: GHC 7.10 regression when using foldr

On 2015-01-21 at 00:27:39 +0100, Edward Z. Yang wrote: Hello Edward, Shouldn't we publicize this trick? Perhaps in the changelog? Fwiw, I've added that workaround/recipe to https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant feel free to improve the

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote: 2014-11-25 20:46 GMT+01:00 Austin Seipp aus...@well-typed.com: We are pleased to announce the first release candidate for GHC 7.8.4: https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...] Would it be possible to get the RC on

Re: Hiding module *exports*

On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote: [...] I propose that instead, we're able to simply say what we mean: module Foo hiding (Lockbox(MkLockbox), internalFunction) where I think its semantics are immediately clear to the reader. There's a little bit of bikeshedding that

Re: Hiding module *exports*

On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote: [...] module Foo hiding (Lockbox(MkLockbox), internalFunction) where I think its semantics are immediately clear to the reader. There's a little bit of bikeshedding that needs to happen (e.g. is hiding (Foo(..)) sufficient to hide the

Re: Hiding import behaviour

On 2014-10-19 at 00:39:42 +0200, Joachim Breitner wrote: I guess my central point is I don't see how anyone can benefit from the current behaviour. For instance, a simple real world example: import Prelude import Data.Text.Lazy.IO (putStrLn) I find this quite convincing. If I bother to

Aliasing current module qualifier

Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null

Re: Overlapping and incoherent instances

On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote: instance {-# OVERLAPPABLE #-} Show a = Show [a] where … Is the syntax somewhat flexible in where the pragma can be placed? For example, some might prefer {-# OVERLAPPING #-} instance Show [Char] where … This variant may also be

Re: RFC: Unicode primes and super/subscript characters in GHC

On 2014-06-16 at 02:26:49 +0200, Mateusz Kowalczyk wrote: [...] While personally I like the proposal (wanted prime and sub/sup scripts way too many times), I worry what this means for compatibility reasons: suddenly we'll have code that fails to build on 7.8 and before because someone using

Re: RFC: changes to -i flag for finding source files

On 2014-05-30 at 11:00:38 +0200, John Meacham wrote: JHC has the feature that Graphics.UI.GTK.Button can live in any of: Graphics/UI/GTK/Button.hs Graphics/UI/GTK.Button.hs Graphics/UI.GTK.Button.hs Graphics.UI.GTK.Button.hs Just wondering: Does JHC warn if, for instance,

Re: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check'

On 2014-04-09 at 19:53:47 +0200, Conal Elliott wrote: From a bit of experimentation, it appears that the problematic packages do indeed have Haddock failures. For instance, bash-3.2$ cd random-1.0.1.1/ bash-3.2$ cabal configure Resolving dependencies... Configuring

Re: 7.8.1 cabal install of vector package (dependent on primitive package) fails

On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote: Indeed. It was using the wrong cabal-install version. Even though I had installed the newest cabal-install I needed to restart the xterm I was working in. Lemme guess, you're using Bash, and you installed cabal-install into a new

Re: ghc-7.8.1 and stm

On 2014-02-18 at 23:22:13 +0100, Joachim Breitner wrote: Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox: It seems to me that the stm library that is supposed to be built into ghc-7.8.1 is missing. The deb provides and conflicts with libghc-stm-dev , but does not provide

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1

On 2014-02-03 at 23:35:14 +0100, Austin Seipp wrote: We are pleased to announce the first release candidate for GHC 7.8.1: [...] Please test as much as possible; bugs are much cheaper if we find them before the release! Please note that GHC 7.8.1RC1 is also available for Travis-CI as part of

Over/underflow semantics for 'Int' et al.

Hello *, I'd like to point your attention to https://ghc.haskell.org/trac/ghc/ticket/8695 which brings up the issue what the results operations such as * `div minBound (-1)` * `quot minBound (-1)` * `abs minBound` shall result in for the standard H2010 fixed-width signed types such as

Re: RFC: include a cabal-install executable in future GHC releases

On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: I feel this blurs the roles of GHC and the Platform. IMO, that's a weak argument, as the roles are already blurred: GHC

Re: RFC: include a cabal-install executable in future GHC releases

On 2014-01-20 at 01:02:27 +0100, Carter Schonwald wrote: I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in,

Re: Enabling TypeHoles by default

On 2014-01-15 at 03:24:29 +0100, Austin Seipp wrote: I'll submit a change to Cabal to remove its awareness of TypeHoles as an extension. ...actually, I forgot that 'TypeHoles' actually never made into Cabal when we added missing language-extensions tokens, as Duncan noticed in [1], that | We

Re: Enabling TypeHoles by default

Hi, On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote: On 14.01.2014 17:07, Austin Seipp wrote: We probably won't change the name right now however. It's already been put into Cabal (as a recognized extension,) so the name has propagated a slight bit. We can however give it a new

Re: Hiding top level declaration with tilde

On 2014-01-09 at 08:46:28 +0100, Ramin Honary wrote: [...] So as we all know, when there is no exports list in a module declaration, everything in the top level is exported by default. If you provide an exports list, everything is hidden except what you declare in the exports list. Btw,

Re: Trying to compile ghc HEAD on xubuntu 13.04-x64

On 2013-10-04 at 22:55:01 +0200, Nathan Hüsken wrote: [...] haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20131004 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough.

Re: [Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote: I spent some time looking into the touch points between ghc and cabal in the past, and the first oddity i saw was a direct dependency from ghc to the cabal sources. After taking a closer look it seems that ghc shares some common, low level

Why do remaining HECs busy-wait during unsafe-FFI calls?

Hello, Recently, I stumbled over E.Z.Yang's Safety first: FFI and threading[1] post and then while experimenting with unsafe-imported FFI functions I've noticed a somewhat surprising behaviour: Consider the following contrived program: --8---cut

Re: Why do remaining HECs busy-wait during unsafe-FFI calls?

Andreas Voellmy andreas.voel...@gmail.com writes: When an unsafe call is made, the OS thread currently running on the HEC makes the call without releasing the HEC. If the main thread was on the run queue of the HEC making the foreign unsafe call when the foreign call was made, then no other

Dangers of registerTimeout (was: Race-condition in alternative 'System.Timeout.timeout' implementation)

Herbert Valerio Riedel h...@gnu.org writes: [...] (bracket (E.registerTimeout em to (throwTo tid ex)) (E.unregisterTimeout em) (\_ - fmap Just f)) ...after some discussion on #ghc, I've realized, that 'registerTimeout

Re: base package -- goals

Ian Lynagh i...@well-typed.com writes: [...] If we did that then every package would depend on haskell2010, which is fine until haskell2013 comes along and they all need to be changed (or miss out on any improvements that were made). ...wouldn't there also be the danger of

Race-condition in alternative 'System.Timeout.timeout' implementation

Hello *, I've been experimenting with an alternative implementation of 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new thread for each invocation. Part of my motivation is to see if I can implement a faster version of threadWaitReadTimeout :: Int - Fd - IO Bool

Re: GHC 7.8 release?

wren ng thornton w...@freegeek.org writes: [...] But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? Some time last year, I tried to extract the module import inter-dependencies in the base package (with the help of GHC's

Re: Newtype wrappers

Simon Peyton-Jones simo...@microsoft.com writes: [...] x1 :: [Int] x2 :: Char - Int x3 :: T Int x4 :: S IO Int Can we convert these into the corresponding forms where the Int is replaced by Age? Alas, not easily, and certainly not without overhead Maybe a stupid question: Can

Re: [Haskell-cafe] Fighting research paper bit-rot

cheater cheater cheate...@gmail.com writes: after yet another episode of trying to figure out why library code doesn't make any sense when reading the related paper, I decided to start a small wiki just for the purpose of describing differences between what's in the paper and what's in the

Re: Tagging subjects of emails sent from the list

Johan Tibell johan.tib...@gmail.com writes: I'd prefer if they weren't tagged. My mail reader (GMail) can do the tagging for me and I'll end up with duplicated tags and the list of subjects get harder to scan. Same here; that's what RFC-2919[1] is for... [1]:

Re: [Haskell-cafe] ANNOUNCE: tie-knot library

Brandon Allbery allber...@gmail.com writes: Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP

Re: [Haskell-cafe] LGPL and Haskell

Alfredo Di Napoli alfredo.dinap...@gmail.com writes: Let me just chime in to give my 2 cents; I quote Micheal 100%; if we want to push Haskell out of the academic/open source world to the real world, well, GPL is not the way to go, due to its viral nature. just to throw in a different

Re: Does GHC still support x87 floating point math?

Ben Lippmeier b...@ouroborus.net writes: On 06/12/2012, at 12:12 , Johan Tibell wrote: I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? It's on by default unless

Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?

Iustin Pop ius...@google.com writes: [...] Let's say we have a simple JSON message: an array of 5 million numbers. I would like to parse this in constant space, such that if I only need the last element, overall memory usage is low (yes, unrealistic use, but please bear with me for a

Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?

Clark Gaebel cgae...@uwaterloo.ca writes: [...] I didn't even know people used JSON to store millions of integers. It sounds like fun. Actually, JSON is quite convenient if you need a standardized common interchange format between Python, Ruby, JS et al. based components as it directly maps

Re: lambda case

Jon Fairbairn jon.fairba...@cl.cam.ac.uk writes: [...] “\case” complicates lambda, using “of” simply breaks “case … of …” into two easily understood parts. Just some observation (I'm rather late to the lambda-case discussion, so this might have been already pointed out previously): if the

Re: [Haskell-cafe] lambda case

Jon Fairbairn jon.fairba...@cl.cam.ac.uk writes: [...] “\case” complicates lambda, using “of” simply breaks “case … of …” into two easily understood parts. Just some observation (I'm rather late to the lambda-case discussion, so this might have been already pointed out previously): if the

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. btw, how is it planned to have .so libraries interact with the soon-to-be-released cabal-install sandbox feature?

Re: Dynamic libraries by default and GHC 7.8

Ian Lynagh i...@well-typed.com writes: On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote: Ian Lynagh i...@well-typed.com writes: [...] There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default

Re: [Haskell-cafe] cabal configure cabal build cabal install

Brent Yorgey byor...@seas.upenn.edu writes: On Sun, Nov 25, 2012 at 06:09:26PM -0500, Albert Y. C. Lai wrote: If you begin with cabal configure, the correct idiom is: cabal configure [flags] cabal build [cabal haddock, if you want] cabal copy cabal register Even this does not do the

Re: [Haskell-cafe] Custom Enum instance with non-consecutive indices

Nicolas Trangez nico...@incubaid.com writes: On Sat, 2012-11-17 at 16:52 +0200, Roman Cheplyaka wrote: Hi Nicolas, The simplest approach would be to use the standard (derived) Enum instance that would be used for enumerations (like [Flag1..]), and have your own functions to convert to/from

Re: [Haskell-cafe] using createProcess and waitForProcess, but mpg123 plays for only 6 seconds

rnons remotenonse...@gmail.com writes: [...] mpgLoop = do let sh = mpg123 -R (Just hin, Just hout, _, hdl) - createProcess (shell sh){ std_in = CreatePipe, std_out=CreatePipe } --hPutStrLn hin SILENCE hPutStrLn hin LOAD /home/rnons/Music/test.mp3 hFlush hin

Undocumented(?) magic this package-id in PackageImports

Hello Simon, I just found out that in combination with the PackageImports extension there's a special module name this which according to [1] always refers to the current package. But I couldn't find this rather useful feature mentioned in the GHC 7.6.1 Manual PackageImports section[2]. Has this

Re: Undocumented(?) magic this package-id in PackageImports

Simon Marlow marlo...@gmail.com writes: Please submit a bug (ideally with a patch!). It should be documented. done - http://hackage.haskell.org/trac/ghc/ticket/7409 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org

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,

Re: [Haskell-cafe] [ANNOUNCE] hashable-generics

Clark Gaebel cgae...@uwaterloo.ca writes: How would the ghc-dependance affect hashable's inclusion in the haskell platform? Doesn't the haskell platform ship only a recent version of ghc (i.e. one with support for generics)? I was under the impression that the haskell platform, albeit

Re: [Haskell-cafe] [ANNOUNCE] hashable-generics

Clark Gaebel cgae...@uwaterloo.ca writes: For the merge into Hashable, the default instance is only included if we're on a compatible GHC. I originally tried to make the same argument for enhancing `deepseq`, but I was made aware this would lead to a conditional API, which is frowned upon, or

Re: [Haskell-cafe] [ANNOUNCE] hashable-generics

Clark Gaebel cgae...@uwaterloo.ca writes: [...] Oh yeah, and if anyone wants to help me figure out why it's 1.3x slower than my hand-rolled instances, that would be really helpful. [...] I've taken a look at the bench/Bench.hs benchmark[1]: The generated Core looks almost[2] the same as

Re: [Haskell-cafe] [ANNOUNCE] hashable-generics

Clark Gaebel cgae...@uwaterloo.ca writes: @dag: I would love for this to be merged into Data.Hashable, and I think it would make a lot of people's lives easier, and prevent them from writing bad hash functions accidentally. Jfyi, a discussion came up when I posted a proposal to add a

Re: Understanding the core2core simplifier - occurence-analysis interaction

Herbert Valerio Riedel h...@gnu.org writes: Hello GHC HQ, I've been trying to improve/fix a minor optimization sub-optimality w.r.t to the following code (code like that results from the generics-based NFData deriver[1]): [...] jfyi, this has been migrated to http://hackage.haskell.org/trac

Understanding the core2core simplifier - occurence-analysis interaction

Hello GHC HQ, I've been trying to improve/fix a minor optimization sub-optimality w.r.t to the following code (code like that results from the generics-based NFData deriver[1]): data Foo = Foo1 | Foo2 | Foo3 !Int rnf1 :: Foo - () rnf1 x = case x of Foo1 - ()

Re: copyArray# bug

Roman Leshchinskiy r...@cse.unsw.edu.au writes: [...] If I'm right then I would suggest not to use copyArray# and copyMutableArray# for GHC 7.8. I've grepped today's http://hackage.haskell.org/cgi-bin/hackage-scripts/archive.tar for occurences of those two primitives, and this resulted

Re: [Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)

Johan Tibell johan.tib...@gmail.com writes: I'll make a bugfix release for cabal-install and Cabal in a few days to include fixes to issues people found so far. If everyone who had some problem related to the latest release could please post it here so I can make sure that we include a fix

Re: ANNOUNCE: GHC version 7.6.1

Ian Lynagh i...@well-typed.com writes: 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. ...why has bytestring-0.10.0.0 been held back? (afaics,

Re: RFC: Adding support for an API-since-version-attribute to Haddock?

Evan Laforge qdun...@gmail.com writes: Would such an enhancement to Haddock be worthwhile or is it a bad idea? Has such a proposal come up in the past already? Are there alternative approaches to consider? It would be even cooler to automatically figure them out from the hackage history. I

  1   2   >