Re: GHC 7.8 release?

* Manuel M T Chakravarty c...@cse.unsw.edu.au [2013-02-10 21:17:07+1100] Re (2): we should encourage contributors to fork the GHC repos on GitHub and work in those. That makes it easy for everybody to build forks (which will be longer-lived under the above policy) and creating a fork doesn't

base package (was: GHC 7.8 release?)

* Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+] It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. It would be great to have a portable

Re: Advance notice that I'd like to make Cabal depend on parsec

* Heinrich Apfelmus apfel...@quantentunnel.de [2013-03-15 10:38:37+0100] Duncan Coutts wrote: Hi folks, I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package,

Re: Advance notice that I'd like to make Cabal depend on parsec

* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-03-15 22:12:47+1100] On 15 March 2013 22:05, Roman Cheplyaka r...@ro-che.info wrote: * Heinrich Apfelmus apfel...@quantentunnel.de [2013-03-15 10:38:37+0100] Duncan Coutts wrote: Hi folks, I want to give you advance notice that I

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

Hi Austin, I apologize for not having read the full email yet (I'm in a hurry right now), but... * Austin Seipp ase...@pobox.com [2013-06-09 00:23:22-0500] -- Let's just put base and testsuite inside the GHC repository directly. No submodules, no floating repos. Just put it directly inside

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

* Austin Seipp ase...@pobox.com [2013-06-09 11:15:37-0500] Hi Roman, On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka r...@ro-che.info wrote: I'm a strong -1 on this. As one example, we have forks of base and ghc-prim for Haskell suite: https://github.com/haskell-suite/base https

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

* John Lato jwl...@gmail.com [2013-06-10 07:59:55+0800] On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote: What I'm trying to say here is that there's hope for a portable base. Maybe not in the form of split base — I don't know. But it's the direction we should

Re: Ian leaving and the glorious future

There will also be a Haskell hackathon in Zurich at the end of the month. http://www.haskell.org/haskellwiki/ZuriHac2013 Roman * Erik de Castro Lopo mle...@mega-nerd.com [2013-08-05 18:15:40+1000] Vincent Hanquez wrote: As a suggestion to increase participation, OcamlLab recently hosted a

Re: Bit-rotting(?) HUGS-specific code in GHC boot libraries

Herbert, Yes, you are right. It was my experience when compiling base with haskell-names' hs-gen-iface that, unless __GLASGOW_HASKELL__ is defined, many functions (including H2010) would simply not be defined, and some code wouldn't even be well-formed Haskell. First I tried to fix that on the

Re: [PATCH 1/2] System.IO.Unsafe: fix doc typo: 'System.IO.IO' to 'System.IO'

This may be not a typo, but rather a reference to the IO type from the System.IO module. * sly...@gmail.com sly...@gmail.com [2013-09-18 16:07:03+0300] From: Sergei Trofimovich sly...@gentoo.org Signed-off-by: Sergei Trofimovich sly...@gentoo.org --- System/IO/Unsafe.hs | 2 +- 1 file

Build error: No (or multiple) ghc rts package is registered

Hi, I tried to build GHC HEAD today, but eventually got this error: ghc-cabal: No (or multiple) ghc rts package is registered!! make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 I did make clean before starting the build — is it not sufficient?

Re: Build error: No (or multiple) ghc rts package is registered

$ make -j2 which will 'really clean' everything. If it persists, file a bug please. On Sun, Oct 13, 2013 at 3:37 PM, Roman Cheplyaka r...@ro-che.info wrote: Hi, I tried again today[*] and it failed with the same error. Any suggestions? [*] I re-synced with: % ./sync-all get

Re: More GND + role inference woes

* Richard Eisenberg e...@cis.upenn.edu [2013-10-16 13:28:54-0400] Moreover, I think this solves the other failures in http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html. Here is one example, in that email. smallcheck has this: newtype Series m a = Series (ReaderT Depth

Re: Renaming Void#

Have you read the Note [Nullary unboxed tuple] in compiler/types/Type.lhs? I think it addresses this, although I'm not going to pretend I understand what's going on there. Roman * Krzysztof Gogolewski krz.gogolew...@gmail.com [2013-12-17 19:28:14+0100] Hello, Small bikeshedding: I propose to

Re: Enable TypeHoles by default?

* Simon Peyton Jones simo...@microsoft.com [2014-01-13 08:57:51+] This would be fine by me - it's a user-experience question. It would slightly threaten the notion that GHC is, by default, a Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects non-H2010 programs. But

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

* Ryan Newton rrnew...@gmail.com [2014-01-14 11:41:48-0500] Replacing containers seems like a real pain for end users Is it a real pain? Why? I just tried 'cabal install containers', and it went flawlessly. To make it clear, I'm not in any way opposed to containers upgrade, but that phrase

Re: [commit: packages/base] master: Implement foldl with foldr (b63face)

* Simon Marlow marlo...@gmail.com [2014-02-17 10:22:48+] This worries me a bit. If foldl isn't inlined, I get a less efficient version, so it has to be inlined everywhere. So -O0 code gets worse, and binary sizes for -O1+ get bigger - foldl, sum, and product are now INLINE. Correct me

Re: cpphs bug

that it was discussed. What was the conclusion? * Roman Cheplyaka r...@ro-che.info [2014-02-21 18:04:17+0200] Hi Malcolm, This appears to be a cpphs bug. For the following code #define x (1 == 1) #if x YES #else NO #endif cpphs 1.18.1 prints NO, while the expected output

Re: What does the DWARF information generated by your GHC branch look like?

Or he's not subscribed to this list and his messages do not come through * Austin Seipp aus...@well-typed.com [2014-02-28 09:53:31-0600] (Passive note - this conversation looks like Johan talking to himself, as I suspect Peter is not 'reply all'-ing to the developers list. So other people may

Re: Getting warnings when pushing to git.haskell.org

Try setting your locale to something like en_US.UTF-8: export LANG=en_US.UTF-8 unset LC_CTYPE * Johan Tibell johan.tib...@gmail.com [2014-03-11 22:15:16+0100] Hi, I get the following warning every time I push to git.haskell.org. Anyone have an idea what the correct fix is? $ git push

Re: Proposal - Foreign enum support

I am reluctant about adding a new syntactic feature for such a niche problem. Can't this be achieved with a quaiquoter? Roman signature.asc Description: Digital signature ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Status updates

Hi Austin, Could you consider #9012 for 7.8.3? * Austin Seipp aus...@well-typed.com [2014-05-05 11:54:20-0500] Hi all, - The HCAR entry was quickly completed last week thanks to everyone, much appreciated for the quick response! And it made me aware of some other new things in the

Re: Injective type families

* Kim-Ee Yeoh k...@atamo.com [2014-07-10 23:40:44+0700] On Thu, Jul 10, 2014 at 9:37 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: 1. Standard injective type family (all parameters uniquely determined by the RHS): injective type family F a b c | a b c snip 2. Type family

Re: Early draft spec of Strict language pragma

* Johan Tibell johan.tib...@gmail.com [2014-07-23 17:48:29+0200] Hi! I started a draft spec for the Strict language pragma we chatted about during our call a while ago. I made the big mistake of writing it much after the actual discussion, so I forgot most of the details.

Re: Preliminary proposal: Monoidal categories in base and proc notation support

On Mon, 2014-09-15 at 17:30 +1000, Sophie Taylor wrote: Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any

Re: Permitting trailing commas for record syntax ADT declarations

On 23/09/14 10:11, Alexander Berntsen wrote: On 22/09/14 21:07, Simon Peyton Jones wrote: have a language extension TrailingCommas (or something) to enable the extension For clarification: are you overruling the do we sneak it in HEAD or use pragma(s)-vote and telling me to do the latter?

Re: Permitting trailing commas for record syntax ADT declarations

pick up this new pragma and thus making it unnecessary eventually, but the standardization process is dead (and even when it was alive, it was lagging actual practice enough that it was largely ignored.) On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka r...@ro-che.info wrote: On 23/09/14

Re: Permitting trailing commas for record syntax ADT declarations

On 26/09/14 22:17, Richard Eisenberg wrote: A modest counter-proposal to this idea: What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing. Things can get somewhat ambiguous: module M (module A value B type C)

Re: are patterns synonyms definable in GHCI?

On 18/12/14 12:51, Dr. ERDI Gergo wrote: On Thu, 18 Dec 2014, Carter Schonwald wrote: Hey all,I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? I thought GHCi accepts things that would be

Re: GHC support for the new record package

How would that be different from the ORF? The library as it stands is worse than the ORF: translation into (essentially) tuples hurts error messages; no good story for sum types; no way to make fields strict/unpacked etc. Hopefully, if this is to become a ghc extension, these problems will be

Re: Build failure under Fedora 21

Do you know you can simply install the ghc binary distribution without having to compile anything? https://www.haskell.org/ghc/download_ghc_7_8_4 On 11/01/15 08:07, Dominick Samperi wrote: Hello, I'm trying to build ghc-7.8 branch under Fedora 21 and I get the failure diagnostics appended

Re: seq#: do we actually need it as a primitive?

I made an attempt at a better documentation for evaluate. See here: https://phabricator.haskell.org/D615 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Build failure under Fedora 21

On 12/01/15 04:00, Dominick Samperi wrote: Hi Roman. As I said in my comments I tried the binary distribution provided for CentOS65 Linux but ran into problems. I also tried the distribution provided for Debian Linux; this installed, but there were problems. Fedora is the most cutting

Re: Deprecating functions

On 09/01/15 12:02, Jan Stolarek wrote: We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically

Re: seq#: do we actually need it as a primitive?

On 08/01/15 10:00, Edward Z. Yang wrote: For posterity, the answer is no, and it is explained in this comment: https://ghc.haskell.org/trac/ghc/ticket/5129#comment:2 Thanks, this is helpful. So we have three potential implementations for evaluate: (1) \x - return $! x (2) \x - (return $! x) =

Re: seq#: do we actually need it as a primitive?

On 08/01/15 15:42, Roman Cheplyaka wrote: Also, where can I find the 'instance Monad IO' as understood by GHC? grep didn't find one. Found it; it's in libraries/base/GHC/Base.hs. There are two spaces after instance; that's why I didn't find it the first time. Roman

Re: seq#: do we actually need it as a primitive?

Of | Roman Cheplyaka | Sent: 08 January 2015 13:42 | To: Edward Z. Yang; David Feuer | Cc: ghc-devs | Subject: Re: seq#: do we actually need it as a primitive? | | On 08/01/15 10:00, Edward Z. Yang wrote: | For posterity, the answer is no, and it is explained in this | comment

Re: wither the Platform

I also thought about it recently. IIRC ghc can already deal with any number of stacked package dbs; we only need to expose this somehow through cabal. On 22/03/15 11:52, Herbert Valerio Riedel wrote: On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: [...] The Platform arose in an era

Re: Proposal: Turn on ScopedTypeVariables by default

On 24/02/15 14:46, Herbert Valerio Riedel wrote: On 2015-02-23 at 18:45:20 +0100, David Feuer wrote: I know this will be controversial, because it can break (weird) code and because it's not Haskell 2010, but hey, you can't make brain salad without breaking a few heads. Are you suggesting

Re: release timing

I'd love to see GHC 7.10.2 once this haddock issue is fixed: https://github.com/haskell/haddock/issues/385 On 05/05/15 13:08, Simon Peyton Jones wrote: This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off Good

Re: GADT confusion

On 18/05/15 10:57, Alan Kim Zimmerman wrote: Hi all I am working on D836 and have the following test case data MaybeDefault v where SetTo4 :: forall v a. (( Eq v, Show v ) = v - MaybeDefault v - a - MaybeDefault [a]) GHC 7.10.1 regards the return type of SetTo4 as

Re: MonadFail proposal (MFP): Moving fail out of Monad

On 10/06/15 14:22, Johan Tibell wrote: On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky dluposchain...@googlemail.com mailto:dluposchain...@googlemail.com wrote: I think there are two important consequences of MonadFail. First of all, we can all safely write failable

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

On 21/05/15 19:07, Herbert Valerio Riedel wrote: Don't you still have to support -pgmF? I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run... It's not just about legacy; -pgmF is used for all sorts of awesome

Re: INLINE pragmas

On 30/07/15 13:24, Joachim Breitner wrote: BTW, the docs say about NOINLINE “You shouldn't ever need to do this, unless you're very cautious about code size.” – should this also mention that NOINLINE are often necessary with RULES? unsafePerformIO is another popular and valid usecase for

Re: Further custom type error questions

Iavor, Ben, et al.: How about much simpler type family Head (a :: [k]) :: k where Head (x ': xs) = x Head '[] = Error "Empty list" Can this be expressed through Error-as-constraint? On 11/17/2015 02:09 AM, Iavor Diatchki wrote: > Hello, > > I imagine people wanting to do things as in the

Re: Applicative Comprehensions

I like this idea because having the pure function call at the beginning (rather than at the end, as with do-notation) is more consistent with the original <$>,<*>-notation. It only slightly bothers me that the bracket notation in this form has nothing to do with lists, so that may be a bit

Re: Unlifted data types

On 05/09/15 00:41, Roman Cheplyaka wrote: > On 05/09/15 00:23, Edward Z. Yang wrote: >> I would certainly agree that in terms of the data that is representable, >> there is not much difference; but there is a lot of difference for the >> client between Force and a str

Re: Unlifted data types

On 05/09/15 00:23, Edward Z. Yang wrote: > I would certainly agree that in terms of the data that is representable, > there is not much difference; but there is a lot of difference for the > client between Force and a strict field. If I write: > > let x = undefined > y = Strict x >

Re: Unlifted data types

On 11/09/15 06:22, Carter Schonwald wrote: > Would this allow having a strict monoid instance for maybe, given the > right hinting at the use site? That's a fantastic idea, especially if it could be generalized to Applicative functors, where the problem of "inner laziness" is pervasive. But

Re: Planning for the 7.12 release

On 28/08/15 20:33, Ben Gamari wrote: I half-jokingly suggested that 8.0 should only come with Phase 2 of Richard's Dependent Haskell work Ah, that would be perfect. signature.asc Description: OpenPGP digital signature ___ ghc-devs mailing list

Re: -XStrict: Why some binders are not made strict?

On 12/11/2015 02:21 PM, Johan Tibell wrote: > If we force strictness all the way down it's not really call-by-value > either, because the caller doesn't know what to evaluate (I think). Not sure what you mean here. > In addition, making pattern matching strict in this way makes it hard to > mix

Re: -XStrict: Why some binders are not made strict?

not well described. > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Roman > | Cheplyaka > | Sent: 11 December 2015 12:57 > | To: Johan Tibell <johan.tib...@gmail.com> > | Cc: ghc-devs@haskell.org > |

Re: User manual sub-sections

On 12/08/2015 05:41 PM, Ben Gamari wrote: > Simon Peyton Jones writes: > >> Ben, Austin, >> Could we see the sub-sub-sections of the user manual in the table of contents >> http://downloads.haskell.org/~ghc/master/users-guide/ >> The section titles are often very helpful.

Re: -XStrict: Why some binders are not made strict?

On 12/10/2015 04:34 PM, Johan Tibell wrote: > I'm snowed under but I promise I will try to reply soon! To think about > in the mean time: what do existing strict languages with pattern > matching do? Well, strict languages do not have lazy data to force to begin with, do they? Personally, I find

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

On 02/06/2016 02:09 AM, Richard Eisenberg wrote: > The old type of ($) was always a lie. -XMagicHash just changes the > parser, allowing the # suffix. It is only by convention that most (all?) > unlifted things end in #. The old type of ($) was perhaps a harmless > lie, but a lie nonetheless. > >

Re: New type of ($) operator in GHC 8.0 is problematic

On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > I'm not really sure how you would change the type of 'id' based on > a language pragma. > > How do people feel about a cosmetic fix, where we introduce a new > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity >

Re: Automatically deriving Generic for every algebraic data type

On 02/04/2016 02:19 PM, Wolfgang Jeltsch wrote: > Hi, > > if you do generic programming these days, you can use DeriveAnyClass to > write code like the following (where Serializable is a class with a > generic default implementation): > >> data Tree a = Leaf | Branch (Tree a) a (Tree a) >>