Re: Use of forall as a sigil

I think the confusion for me is that I've trained myself to think of `forall` as explicitly introducing an implicit argument, and `->` as introducing an explicit argument. So the syntax `forall a ->` looks to me like a contradiction. On Thu, Dec 3, 2020, at 10:56, Richard Eisenberg wrote: > > >

Re: How should we treat changes to the GHC API?

a small group of stakeholders that get tagged on MRs to the public API, or a mailing list where you solicit feedback. Sent from my iPhone > On Jul 27, 2020, at 15:57, Richard Eisenberg wrote: > >  > >> On Jul 27, 2020, at 2:07 PM, Eric Seidel wrote: >> >> a s

Re: How should we treat changes to the GHC API?

As another former user of the GHC API, I'd say my two biggest complaints were the relative instability of the API and the lack of documentation. I haven't used the API in at least three years though, so it's possible much has changed since my experience. I remember often having to do

Re: Linear Types: ready for review

Hi Wolfgang, Just FYI, the GHC Steering Committee is currently reviewing a few more design decisions for the Linear Types proposal, one of which is the name of the unrestricted multiplicity. The current recommendation is to use Many rather than Omega

Re: The GHC Proposals Process

I've thought about this a little. The only advantage I can think of is that moving to GitLab would make it easier to cross-reference other GHC issues. For example, in the record-set-field proposal[1] people have referenced a few different Trac tickets. Sometimes the reference includes a link

Re: slow execution of built executables on a Mac

rts_dist_HC is where it builds the various versions of the RTS, right? I noticed a similar slowness building the RTS at ICFP on my MacBook Pro (macOS 10.12). I don't think my battery lasted long enough to get to stage 2. I'm afraid I don't have any clue why it's gotten so slow, but you're not

Re: Treatment of unknown pragmas

It might be nice if GHC were to actually parse the extensible tool pragmas and insert them into the AST! Aesthetically, I prefer the {-# X_HLINT ... #-} syntax over the {-# TOOL HLINT ... #-} syntax, but I don't feel strongly about it. On Wed, Oct 24, 2018, at 13:38, Ben Gamari wrote: > Neil

Re: Treatment of unknown pragmas

Another option could be to introduce a lighter ANN that doesn’t actually embed anything into the module, instead just making the annotations available to plugins and API users during compilation of that particular module. It could also be restricted to string annotations to avoid invoking the

Re: Treatment of unknown pragmas

> > This sounds exactly like the existing ANN pragma, which is what I've wanted > > LiquidHaskell to move towards for a long time. What is wrong with using the > > ANN pragma? > > Significant compilation performance penalty and extra recompilation. > ANN pragmas is what HLint currently uses.

Re: Treatment of unknown pragmas

On Tue, Oct 16, 2018, at 15:14, Ben Gamari wrote: > For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}` LiquidHaskell does not use `{-@ LIQUID ... @-}`, we just write the annotation inside `{-@ ... @-}` :) > I think it makes a lot of sense to have a standard way for

Re: Travis again over time

On Sat, Mar 18, 2017, at 05:36, Alan & Kim Zimmerman wrote: > FYI, liquidhaskell switched from travis to circleci.com because of > timeout > problems. > > It seems the time available is larger there. IIRC CircleCI doesn't have an overall build timeout at all, just (configurable) per-command

Re: ANN: `dump-core` a prettier GHC core viewer

Hi Iavor, This sounds like a great idea, but it's not clear from the package description *how* the output is improved over -ddump-simpl. An example of the html output would be a great addition! Thanks! Eric On Thu, Jan 12, 2017, at 10:36, Iavor Diatchki wrote: > Hello, > > Over the holidays I

Re: Default options for -threaded

> Do you know if this is by design or a bug? > > On Sat, Oct 8, 2016 at 6:13 PM, Eric Seidel <e...@seidel.io> wrote: > > > I would prefer keeping -N1 as a default, especially now that the number > > of capabilities can be set at runtime. Programs can then use the more > > comm

Re: Default options for -threaded

I would prefer keeping -N1 as a default, especially now that the number of capabilities can be set at runtime. Programs can then use the more common -j flag to enable parallelism. Regarding -qa, I was experimenting with it over the summer and found its behavior a bit surprising. It did prevent

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote: > Moritz Angermann writes: > > > All that arc essentially does is, compute the diff from an offset > > (e.g. master) to the current HEAD and upload that to a new or existing > > (--update) differential. It also adds some

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

On Fri, Sep 23, 2016, at 23:46, Joachim Breitner wrote: > Any reason not to use http://stackoverflow.com/? That would certainly be the easiest solution. The questions that occur to me are: 1. Do GHC-dev questions fit within the purview of StackOverflow? I think so, there are plenty of

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

I found a list of StackOverflow clones. (I don't know how difficult it is to get an official StackExchange site, or if we would even want that) http://meta.stackexchange.com/questions/2267/stack-exchange-clones On Fri, Sep 23, 2016, at 18:44, Simon Peyton Jones via ghc-devs wrote: > Friends > >

Re: arc stopped working

Have you tried `git submodule update --init`? I believe the arc linter is a submodule. On Fri, May 13, 2016, at 07:38, Peter Trommler wrote: > Hi *, > > I am getting the following error message from arc: > > peter@montebre:/local/home/peter/ghc> arc diff > Usage Exception: Failed to load phutil

Re: Bikeshedding request for GHCi's :type

I think design A (deeply instantiate + generalize) produces the most sensible types. I don't know what the curly braces mean (perhaps that we can't use type application anymore since the order changed?) but I don't think they'd show up at all without -fprint-explicit-foralls, right? If so, I'm not

Re: GHC 8 and Template Haskell

I think a general "no TH changes after the first RC" seems reasonable as part of the broader feature freeze. But this case seems decidedly more of a bug fix than a feature addition, since TH *should* have feature parity with Haskell syntax. So I'd favor merging Iavor's patch. I also like

Re: Initial compile time benchmarks

Very cool! It would be nice to add build flags to the table (or at least optimization levels) as these probably differ across packages, and will certainly impact the numbers. I'd also be really interested to see a comparison of the timing data for -O0 and -O. I think the biggest impact for

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

ll blown IDE to support the staged languages and > >> (2) AFIK any Racket program in a simpler language is still a valid Racket > >> program in a more advanced language. (The latter wouldn’t be the case with, > >> e.g., a Prelude omitting type classes as you need to introd

Re: instantiating visible parameters in when deriving instances

I'm inclined to go with option 3 as `Functor (Proxy *)` is the only instance that would typecheck. Perhaps with a warning to let the user know the instance is less general than they might expect? I think this is the most user-friendly route: the user can suppress the warning if they don't care,

Re: Specialized type hints

On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote: > 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 Wow, this is a pretty

Re: Patches/proposals waiting for review

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 https://phabricator.haskell.org/D1912 merged in time. Eric Sent from my iPhone > On Mar 1, 2016, at 03:33, Simon Peyton Jones

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

On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: > I have tried a beginner's Prelude with people. I don't have a lot of data > because it was clearly a failure early on so I bailed them out into the > usual thing. It's just not worth it and it deprives them of the > preparedness to go

Re: Is anything being done to remedy the soul crushing compile times of GHC?

On Tue, Feb 16, 2016, at 05:49, Simon Peyton Jones wrote: > * We discussed it in our weekly GHC Skype chat yesterday. One thing that > would really help is to make it laughably easy to track >- Micro: whether my commit made anything significantly worse > (compile time/allocs, run

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

On Sat, Feb 13, 2016, at 01:25, Ben Gamari wrote: > Christopher Allen writes: > > > Prelude> let myList = [1, 2, 3 :: Integer] > > Prelude> let myList' = myList ++ undefined > > Prelude> :t myList > > myList :: [Integer] > > Prelude> :t myList' > > myList' ::

Re: CallStack naming

Thanks for the reminder! I've added a section [1] on setCallStack with my explanation from above. [1]: https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#GeneralizingtosetCallStack On Tue, Feb 2, 2016, at 10:50, Ben Gamari wrote: > Simon Peyton Jones

Re: CallStack naming

On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote: > | It’d probably need a built-in function > | > | setCallStack :: CallStack -> (AppendsCallStack => a) -> a > > Correct. This is easy to write in Core but not in Haskell. Ugh, I just realized that we can't write setCallStack (with

Re: CallStack naming

On Wed, Jan 20, 2016, at 02:25, Simon Peyton Jones wrote: > | > undefined :: AppendsCallStack => a > | > | Seems simpler. Is it problems with a nullary class? > > Hmm. Actually I think that's quite a good idea. I agree, this is much nicer than enabling ImplicitParams and having to remember

Re: kind of type equalities (was: equality relations: user-facing pretty-printing question)

On Mon, Jan 18, 2016, at 10:26, Richard Eisenberg wrote: > And lifted ones can exist at runtime, via deferred type errors. With > deferred type errors, a lifted equality might be a thunk that evaluates > to a type error. Ah, fair point. > I also think that "because Core needs it" is a

Re: FW: Shaking up GHC

I'm pretty sure you can only post to the list with the address you used to subscribe. According to https://mail.haskell.org/cgi-bin/mailman/roster/ghc-devs it looks like Andrey is subscribed with andrey.mokhov at ncl.ac.uk but the email you forwarded is from andrey.mokhov at

Re: A comment on Introspective-Haskell

On Fri, Dec 11, 2015, at 14:54, Levent Erkok wrote: > Spot on.. I really want "Template Core," independent of TH. > > To be honest, "GHC Plugins" already provides "Template Core" in this > sense; > but would be nicer if one can get his hands on the Core in the regular > Haskell context, not just

Re: A comment on Introspective-Haskell

On Fri, Dec 11, 2015, at 15:28, Levent Erkok wrote: > My "hidden agenda" is to liberate the SBV library to work on Haskell > programs directly. (http://hackage.haskell.org/package/sbv) > So the idea is to translate a Haskell expression to an SBV symbolic expression, which you can then ship off

Re: Plugins: Accessing unexported bindings

ent: 07 December 2015 13:11 > To: Simon Peyton Jones <simo...@microsoft.com> > Cc: Eric Seidel <e...@seidel.io>; omeraga...@gmail.com; ezy...@mit.edu; > ghc-devs@haskell.org > Subject: Re: Plugins: Accessing unexported bindings > > That's a good point; keepi

Re: How do I use CallStack?

that reworks the CallStack solver due to a similar bug with let binders. I suspect it will fix this bug too, I'll check it out in my branch. > > Many thanks, > Richard > > On Dec 7, 2015, at 1:39 AM, Eric Seidel <e...@seidel.io> wrote: > > > Hi Richard, &g

Re: A GHC Library

I think a lot of conferences allow authors to host pre-prints elsewhere, like arXiv. We could ask the authors of the relevant papers to make the submission and then update the links on the Reading List. (Perhaps arXiv even has some sort of collection feature?) But you're right that we probably

Re: How do I use CallStack?

> > As quite a separate point from above, I may have found a bug: I put a > > (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then > > put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained > > about a redundant constraint on rewriteEqEvidence, and indeed its

Re: How do I use CallStack?

> On Dec 7, 2015, at 11:25, Richard Eisenberg <e...@cis.upenn.edu> wrote: > > >> On Dec 7, 2015, at 2:23 PM, Eric Seidel <e...@seidel.io> wrote: >> >> After staring at your bug confusedly for a few minutes, wondering why I >> couldn't simplify it, I r

Re: Plugins: Accessing unexported bindings

GHC should only drop un-exported bindings from the ModGuts if they're also unused, ie *dead code*. The only way I know to get around this is to use the bindings somewhere, or just export them. On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote: > Hello, > > The mg_binds field of the ModGuts seem

Re: How do I use CallStack?

Hi Richard, Sorry for all of the confusion, it seems the docs do indeed need some love! On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote: > That looks like exactly what I want. Thanks. > > There remain two mysteries: > - I thought that CallStacks were a new feature that would come with

Re: Pre-Proposal: Introspective Template Haskell

I think backwards-compatibility is still a potential issue, not because the pattern/type synonym layer seems implausible, but because I suspect people will begin to sidestep the compatibility layer and just use the GHC API (I certainly would). GHC is not shy about breaking backwards-compatibility

Re: Pre-Proposal: Introspective Template Haskell

On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > On Nov 11, 2015, at 12:46 PM, Eric Seidel <e...@seidel.io> wrote: > > > I think backwards-compatibility is still a potential issue, not because > > the pattern/type synonym layer seems implausible, but b

Re: MIN_VERSION macros

I've been meaning to ask about this as well. It also forces tools like ghc-mod and hdevtools to be cabal-aware, which is an unnecessary source of complexity IMO. GHC certainly has enough information to generate these macros, as it knows which packages (and versions) it's compiling against. I

Re: Unlifted data types

Another good example would be foo :: ![Int] -> ![Int] Does this force just the first constructor or the whole spine? My guess would be the latter. On Fri, Sep 4, 2015, at 08:43, Edward Z. Yang wrote: > Excerpts from Eric Seidel's message of 2015-09-04 08:29:59 -0700: > > You mention NFData in

Re: Revert revert revert

You could use `git cherry-pick` (http://git-scm.com/docs/git-cherry-pick) to re-apply each commit individually. I think it would just be a simple $ git cherry-pick commit for each commit in the reverted list. cherry-pick accepts multiple commits per invocation, but I'm not sure if it will

Re: Backporting srcLoc to the GHC 7.10 branch

IIRC the patch doesn't directly depend on -fwarn-redundant-constraints, but I think I ran into some merge conflicts that had to be resolved. I agree with Austin that backporting it should be doable, and would be happy to help if there's interest. Also, I still mean to submit a follow-on patch

Re: Phabricator question

You'll want to run $ arc diff --update D652 base where base is the ref you want to diff against (presumably master). Specifying the base is important, as arc will *replace* the current diff with the new one, so you want to make sure the base is consistent across updates. Eric On Wed, Feb

How to get notifications when a build fails?

Hi devs, Is there any way to make Phab email you when a revision you've submitted fails to build? I looked through the settings but couldn't find anything that seems to fit the bill. Thanks! Eric ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Typechecker plugins and 7.10

I agree, marking type-checker plugins as experimental and subject to change makes perfect sense given how little experience we have writing them at the moment. Eric Richard Eisenberg e...@cis.upenn.edu writes: As I'm referenced here, I'll speak up: yes, I think we should advertise that the

Re: Typechecker plugins: request for review and another workflow question

this in On Sun, Nov 16, 2014 at 1:33 PM, Eric Seidel e...@seidel.io wrote: Hi Adam, I've made a few changes based on your branch. Specifically I've removed the call to runTcPlugins inside solveFlats, and have replaced it with a specific runTcPluginsGiven that runs in a loop inside

Re: Typechecker plugins: request for review and another workflow question

Gundry wrote: Thanks Eric! On 16/11/14 19:33, Eric Seidel wrote: I've made a few changes based on your branch. Specifically I've removed the call to runTcPlugins inside solveFlats, and have replaced it with a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven much like

Re: Typechecker plugins: request for review and another workflow question

Hi Adam, I've made a few changes based on your branch. Specifically I've removed the call to runTcPlugins inside solveFlats, and have replaced it with a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven much like your runTcPluginsFinal runs inside solveFlatsWanted. I think

Re: Typechecker plugins: request for review and another workflow question

On Nov 14, 2014, at 09:14, Adam Gundry a...@well-typed.com wrote: Thanks, Simon! I've been convinced that TcS is more than we need, and I think the right thing to do is to (optionally) invoke the plugin after the constraints have been unflattened anyway. I've just pushed a commit to

Re: Typechecker plugins: request for review and another workflow question

to GHC). -Iavor On Fri, Nov 14, 2014 at 10:09 AM, Eric Seidel e...@seidel.io wrote: On Nov 14, 2014, at 09:14, Adam Gundry a...@well-typed.com wrote: Thanks, Simon! I've been convinced that TcS is more than we need, and I think the right thing to do

Re: Typechecker plugins: request for review and another workflow question

On Nov 10, 2014, at 09:46, Adam Gundry a...@well-typed.com wrote: On 10/11/14 15:58, Austin Seipp wrote: - 2) I am kind of not a fan of having separate 'plugins for core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and -fplugin. Ideally I would think all plugins could be

Re: Typechecker plugins: request for review and another workflow question

On Nov 10, 2014, at 07:58, Austin Seipp aus...@well-typed.com wrote: Hi Iavor; I took a very, very cursory glance. Naturally I am not a typechecker guru, but I did look over the mechanical changes/extensions to thread things around. Two things popped out to me: - 1) Ugh, a new

Re: Making GHCi awesomer?

On Oct 20, 2014, at 09:14, Ben Gamari bgamari.f...@gmail.com wrote: Simon Peyton Jones simo...@microsoft.com writes: Christopher You are doing very cool things. Thank you. What I’m puzzled about is this: the GHC API *is* a programmatic interface to GHC. Why not just use it? One

Re: Making GHCi awesomer?

, 2014 at 12:32 PM, Eric Seidel e...@seidel.io wrote: How feasible would it be to add this feature to GHC? At a first glance it seems like it would help substantially Only until you need to hand off data between them, sadly. -- brandon s allbery kf8nh sine

RE: A couple of GHC-API questions

On July 24, 2014 at 23:49:10, Simon Peyton Jones (simo...@microsoft.com) wrote: | I think part of the confusion is coming from the fact that we don’t | process each module individually, resolve all of the types, and | serialize them to disk somewhere. Rather, when we check a module, we |

RE: A couple of GHC-API questions

Sorry for the double email Simon, I hadn’t signed up for ghc-devs so my response was rejected.. --- Thanks for getting back to me so quickly!  On July 24, 2014 at 0:33:44, Simon Peyton Jones (simo...@microsoft.com) wrote:  Eric    I'd like to help but I don't understand the question. What do

RE: A couple of GHC-API questions

I think I see where the confusion is now. In your example, hscTcRnLookupRdrName should work perfectly. I’m thinking of a different scenario, where we are trying to use the specification of a function that has been imported from another module. Suppose we have module List where data List = Nil