Re: How lose can we be with strictness

Correct me if I'm wrong here, but it's preserving the effect of (==) forcing its arguments. This makes the optimization less surprising, in my opinion. Is there a benefit to not doing this? On Sat, May 20, 2017 at 11:56 AM, Joachim Breitner wrote: > Hi, > > I just

8.2 and earlier build times

I did a build time test with hackage.haskell.org/package/bloodhound today. I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part because it has very few but very large modules which is sort of a pathological case for GHC right now. I first built the deps and library with each

Improving GHC GC for latency-sensitive networked services

It'd be unfortunate if more companies trying out Haskell came to the same result: https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/#comment-2866985345 (They gave up and rewrote the service in Golang) Most of the state of the art I'm aware of (such as from Azul Systems) is from when I

Re: Allow top-level shadowing for imported names?

I agree with Tom on this. This isn't a good way to spend the cleverness budget. On Wed, Oct 5, 2016 at 11:34 AM, wrote: > I'm weakly against this proposal. I may compile with -Wall, but I read code > by many people who don't. When I'm browsing a file and see e.g. > > import

Re: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail

It's a bit tricky, you have to follow these steps: Click the commit link in the email: https://phabricator.haskell.org/rGHC3f27237b0e6d Click the build link on the commit page: B11120: rGHC3f27237b0e6d: Make tcrun042 fail ! Click another build link on

Re: How, precisely, can we improve?

ge issue, scanning the history for > files could potentially provide a list of “old” items, and > eventually one could just delete them from master (automatically?) > > >> On Sep 29, 2016, at 12:37 PM, Christopher Allen <c...@bitemyapp.com> wrote: >> >> Ma

Re: How, precisely, can we improve?

specific use case, as many of the results are often full of > interesting yet stale information. > > Anyhow, I don’t want to obligate anyone to do anything, and if this > was perceived that way, I’m truly sorry. > > Cheers, > Moritz > >> On Sep 29, 2016, at 12:24 PM

Re: How, precisely, can we improve?

I tend to agree, particularly as it would permit automated processing and conversion of the documentation much more readily than a website really ever has. I don't think I've ever used a public wiki that enforced broken link checking, whereas that's a sundry CI check for static markdown

Re: Notes from Ben's "contribute to ghc" discussion

I'd be willing to help with work required to open up GHC development more along multiple lines including: Bots/automation for Github Talking to Rust devs about what works, what doesn't Talking to GHC devs about what works, what doesn't, comparing/contrasting with other processes such as Rust's

Re: Notes from Ben's "contribute to ghc" discussion

ey need it. After a few patches, it gets much easier. > > If this comment makes no sense to you, then it would be even more > beneficial if you could explain to me how other people perceive the > process. > > Matt > > On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen &l

Re: Notes from Ben's "contribute to ghc" discussion

Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen: >> Seems reasonable, but much of the consternation over GHC dev process >> has been about the relative illegibility of it, even for working >> programmers who've hacked on compilers before. It's concerning to see >&

Re: Notes from Ben's "contribute to ghc" discussion

es nothing that addresses this. Can you point me to any discussions among GHC devs on this since the last time it was raised? On Sat, Sep 24, 2016 at 6:41 PM, Joachim Breitner <m...@joachim-breitner.de> wrote: > Hi, > > Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen: &

Re: Notes from Ben's "contribute to ghc" discussion

>I think the we'd want to restrict this to Diffs submitted by contributors who >already possess commit bits and specifically include a "no-review" tag in the >summary. Is this intended to address the issues new contributors have in contributing to GHC? This looks more insider stuff that misses

Noticing how the Rust team is improving compiler errors

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html I'd particularly note that their compiler errors were dramatically better to begin with, now they're doing this. Thought the list would be interested in this. --- Chris ___ ghc-devs

Re-exporting traverse_ from Data.Traversable

Any reason not to do it? I realize it needs Foldable, but even knowing that I still forget it's in Data.Foldable. Seems like a free UX win to me. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bikeshedding request for GHCi's :type

I agree with Iavor that :type should report the real type. I see this only stymieing and frustrating efforts to teach the language. I do like the :inst idea. > On Apr 27, 2016, at 12:22 PM, Iavor Diatchki wrote: > > Hello Richard, > > I think that `:type` should

Re: Specialized type hints

> particular reproducible test case, the error message you get, and the error > message you’d like to get. > > > Thanks > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > *Christopher > Allen > *Sent:*

Specialized type hints

I'd like to see how warm people would be to catching GHC's type error quality up a bit. I did a write-up on a confusion a reader of our book had: https://gist.github.com/bitemyapp/c27c721b92dab0248433 This is not new. A lot of people complain about this particular type error in particular when

Re: Patches/proposals waiting for review

I would very much like to see this get in as well. -- Chris > On Mar 1, 2016, at 9:54 AM, Eric Seidel wrote: > > Are we planning to release 8.0 before the ICFP deadline? I'm also swamped > between it and impending finals, but I want to make sure I get >

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

I agree 100% with Manuel here. My N is smaller (100s rather than thousands) but this is what I've seen working with self-learners, programmers and non-programmers alike. I don't have anything further to add because I couldn't find a point in his listing that didn't match my experience. > Sorry

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

I don't think it's a good idea to create a dumbed down Prelude and existing resources not covering what programmers need to know in order to actually use Haskell as everyone else uses it is much of the reason I had to write a book to begin with. This type isn't just noise for beginners, it's noise

New type of expressions containing (error ...) includes noisy implicit parameter

Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

ician.net> wrote: > On 02/05/2016 08:05 PM, Christopher Allen wrote: > > Changing the name doesn't fix the issue. The issue is the noise and the > > referent, not the referrer. There's a habit of over-focusing on names in > > programming communities. I think it'd be a m

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

Changing the name doesn't fix the issue. The issue is the noise and the referent, not the referrer. There's a habit of over-focusing on names in programming communities. I think it'd be a mistake to do that here and risk missing the point. You can make all of the keywords in the Java example

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

, the impredicativity hack is a completely different > >> thing. So while you won't be able to define your own ($) and be able > >> to (runST $ do ...), you can at least define your own ($) and have it > >> work with unlifted return types. :) &g

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

t; > >> :k Int# -> Int# > > > >> > > > >> is okay. Now, if you want an explanation as to WHY that's the case, > I > > > >> don't think I could give one, as I simply got this information from > > > >> [1] (see the fourth bullet point

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

s encapsulate the implicit impredicativity of ($) for > making runST $ work? I don't presently see how it would. > > > > You're right, the impredicativity hack is a completely different > > thing. So while you won't be able to define your own ($) and be able > > to

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

$ ghci :lGHCi, version 8.0.0.20160122: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/callen/.ghci Prelude> :t ($) ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b As someone that's working on a book for beginners/intermediates and

Re: Guarantees for ST and IO shared in common?

operations must be done first. > Simple! > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > *Christopher > Allen > *Sent:* 03 February 2016 23:30 > *To:* ghc-devs@haskell.org > *Subject:* Guarantees for

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

My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? Prelude> :info (->) data (->) a b -- Defined in ‘GHC.Prim’ Prelude> :k (->) (->) :: * -> * -> * Basically I'm asking why ($) changed and (->) did not when (->) had similar properties

Guarantees for ST and IO shared in common?

Underlying ST is: GHC.Prim.State# s -> (# GHC.Prim.State# s, a #) Underlying IO is: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #) Based on the (very helpful!) conversation I had on the #ghc IRC channel, it seems to me that the mechanism for preventing

Re: Nailing down what we expect IO to do and not do - and why

s*, then my working hypothesis is that all that stuff should be > irrelevant, and indeed confusing. State# etc is just an implementation > technique. Just use the semantics in “Tackling the awkward squad”. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-boun..

Nailing down what we expect IO to do and not do - and why

I'm writing a book, I'd like to get this nailed down and to get it right. If anyone on here that's familiar with the various ways in which IO/State#/realWorld# work in GHC and you have time to reply, anything at all would be welcome. Any pointers, links, references, details, anecdotes, or faint

Re: Birthday greetings

Happy Birthday! Haskell is all the better for your work and direction and we've all benefited thereby. Your work has made computing more enjoyable for many :) On Mon, Jan 18, 2016 at 6:22 PM, Simon Peyton Jones wrote: > Dear GHC devs (all 600+ of you), > > It’s my

Re: Context for typed holes

It's not just you. That's why I didn't mention holes in the book as people suggested. It's not just confusing for new people - it drives me nuts every time I use a hole in non-trivial code at work. On Thu, Oct 8, 2015 at 6:25 PM, David Feuer wrote: > Unless something has

Re: Taking a step back

Thank you for your contributions to the Haskell community. Your work has done a lot, especially for working Haskell programmers like myself and my coworkers. I'm also grateful that you're willing to continue moving the ball forward with unordered-containers and ekg. You didn't mention it

Re: Kind equalities update

My opinion may not count for a lot from a compiler engineering perspective, but I can say with a fair bit of confidence that violating the "capitalized -> concrete constructor, lowercase -> variable" convention for types would be _very_ surprising to learners and users. I don't think it's a petty

Re: [RFC] Moving user's guide to ReStructuredText

The GHC docs in general could use some love. The navigation isn't that nice. On Wed, Sep 23, 2015 at 9:32 AM, wrote: > You might consider the Racket documentation ecosystem: > > http://pkg-build.racket-lang.org/doc/scribble/index.html > > or > >

Re: download all of Hackage?

It's a little out of date, but I've been using that repo I made to do surveys of Haskell code and figure out how frequently things are used. I could really do with a Haskell-source-code-aware grep though. Being able to specify type, data, etc. would be really nice! On Mon, Sep 14, 2015 at 10:19

Re: expanding type synonyms in error messages

Just to add my own +1, having this when working with streaming libraries (I've needed it less with lens, oddly) would be a tremendous help for people learning them I think. I think I've run into the same thing as Kostiantyn in the past. On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan

Re: the platform has outgrown Travis-CI

Christopher and Mark, Great to meet you. Could you let me know what the name of the project on GitHub and the owner's account name is? I'll have a look if I can adjust the timeout upwards for this project. Cheers, Mathias On Tue, Jun 9, 2015 at 3:50 PM, Christopher Allen c...@bitemyapp.com wrote

Re: the platform has outgrown Travis-CI

I rang the gong of the TravisCI people about this. I'll let y'all know if they come back with an answer, but the GH issue timeouts were being discussed in didn't look promising. They were suggesting to the reporter that they break the build up into smaller components. Old ticket though – something

Re: GHC Trac

Yes, has been for a good chunk of the day for myself and others. On Fri, Mar 20, 2015 at 6:20 PM, Simon Peyton Jones simo...@microsoft.com wrote: Is it just me, or is GHC’s Trac super-slow (again)? Actually it’s not just slow but offline from where I am. Simon

Re: Making GHCi awesomer?

Sorry to bother everybody, but where is this documented? What happens if incompatible versions pass data between each other? On Mon, Oct 20, 2014 at 1:22 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Eric Seidel's message of 2014-10-20 09:32:41 -0700: I read recently that Rust has