Re: D2038: [WIP] TysPrim: Generalize kind of (->)

> On Jan 31, 2017, at 5:41 PM, Simon Peyton Jones wrote: > > But that can only happen if `(->)` has suitable roles. > What if it doesn’t? The “correct” roles for (->) of the kind you gave is `nominal nominal nominal nominal representational representational`. That is, the dependent arguments

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

accomplish that goal quite nicely.) What do we think? It's not ideal, but I think it's the best of suboptimal alternatives. And it's no worse than 8.0 w.r.t. Constraint v Type. Richard > On Jan 31, 2017, at 5:56 PM, Richard Eisenberg wrote: > >> >&

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

> On Feb 1, 2017, at 3:34 AM, Simon Peyton Jones wrote: > > Who is acting there. Just Ben? Or are there bits Richard needs to help > with? Ben has done the real heavy lifting, with me opining on this bit or that. From what Ben says, it's very close. There is a small bit of new work to be

Re: Trac

As another data point, I am *not* seeing this change in behavior. My "Modify Ticket" tab is closed by default. Richard > On Feb 13, 2017, at 11:25 AM, George Colpitts > wrote: > > I'm seeing the same thing as Simon, when I open a ticket, e.g. > https://ghc.haskell.org/trac/ghc/ticket/4012 >

Re: Trac

> On Feb 13, 2017, at 1:06 PM, Ben Gamari wrote: > > What browsers are you all using? Firefox, in agreement with your experience. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: XTypeApplication and @spaces

> On Feb 21, 2017, at 12:45 PM, Gracjan Polak wrote: > > Hi all, > > I was thinking about implementing @Type syntax > > highlight for haskell-mode

Re: Travis again over time

> On Mar 4, 2017, at 12:56 PM, Joachim Breitner > wrote: > > I wonder if we should configure travis to send build error > messags to, for example, ghc-commits? +1 to public shaming. Where we understand that there is no shame is making mistakes. Richard ___

can't validate on Linux

Hi devs, When I try validating my patch, validation fails with > ... > Registering library for ghc-prim-0.5.0.0.. > ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error: > ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindi

Re: can't validate on Linux

ote: > > Richard Eisenberg writes: > >> Hi devs, >> >> When I try validating my patch, validation fails with >> >>> ... >>> Registering library for ghc-prim-0.5.0.0.. >>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install >

Re: can't validate on Linux

> On Mar 13, 2017, at 5:57 PM, Ben Gamari wrote: > > Richard, this is on Linux, yes? Yes, it is. But I have now noticed other aspects of some very strange behavior regarding the filesystem on my Linux server, so the problem may be unrelated to GHC. (Example of other problem: running the tests

Re: Removing core-spec.pdf from repository?

Certainly no complaints from me. I knew I was doing a Bad Thing when I committed that file, but couldn't think of a good alternative, given the rarity of finding an ott installation. Thanks, Ben. Richard > On Mar 13, 2017, at 6:57 PM, Ben Gamari wrote: > > Hello everyone, > > Currently there

Re: Why are there no Show instances for internal types

My take is that we don't have these because they would slow down compilation times and add bloat. But enough people have asked for them (and, I can think of a few times when I would use them myself) that I think they should be added. It is conceivable that we could make the instances only when D

Re: Polymorphism over unboxed tuples

This was a design choice in implementing, and one that is open for revision (but not for 8.2). The key property is this: (*) Two types with different representations must have different kinds. Note that (*) does not stipulate what happens with two types with the same representation, such as (#

Re: Polymorphism over unboxed tuples

gt; > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 23 March 2017 16:19 > | To: Ryan Scott > | Cc: GHC developers > | Subject: Re: Polymorphism over unboxed tuples > | > | This wa

Re: D3316 status

> On Mar 29, 2017, at 2:31 PM, Ben Gamari wrote: > > Hi Richard, > > It took me a bit longer than expected to get back to D3316 but I think I > am now done. It wasn't quite as trivial as I thought it might be, so I > thought I would summarize what was needed, > > 1. tcSplitTyConApp_maybe and t

Re: GHC Core simplifier question: turn off all passes?

I second Rahul in that -ddump-ds is what you want. But the desugarer actually does a quick "simple-optimization" pass before -ddump-ds. If you really want the raw desugarer output, you'll need -ddump-ds *and* a DEBUG build of GHC. See the code in Desugar here: https://github.com/ghc/ghc/blob/ma

Re: GHC Core simplifier question: turn off all passes?

> On Apr 7, 2017, at 9:24 AM, Christopher Done wrote: > > all the > simplifier rules deleted or something? I'm not sure what you mean here by "simplifier rules deleted". The "simple-optimization" pass doesn't consult any user-specified RULES or anything -- it just does a few substitutions, e

testsuite failures on Mac

Hi devs, On today's HEAD, I built from a cleaned tree and then ran the testsuite. I got gobs of errors. Here's one: --- ./T2713.run/T2713.stderr.normalised 2017-04-07 15:13:22.0 -0400 +++ ./T2713.run/T2713.comp.stderr.normalised2017-04-07 15:13:22.0 -0400 @@ -1,8 +1,4 @@ - -

Re: testsuite failures on Mac

> On Apr 7, 2017, at 3:27 PM, Ben Gamari wrote: > > How clean is clean? distclean? maintainer-clean. I never settle for anything less. :) Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Harbormaster out to sea?

I've posted a few diffs today, but Harbormaster seems stalled in checking them: - https://phabricator.haskell.org/D3424 - https://phabricator.haskell.org/D3487 - https://phabricator.haskell.org/D3490 Do you have any insight into this? Thanks! Richard _

Re: debug output

Could the problem be that ghc doesn’t support a -ddebug-output flag? It has -dno-debug-output, but I don’t know of a way to reverse that decision. > On Apr 24, 2017, at 9:13 AM, Ben Gamari wrote: > > Simon Peyton Jones via ghc-devs writes: > >> mk/flavours/validate.mk has >> >> GhcStage2HcOp

validation failure on Mac

Hi devs, Trying to validate with tonight's HEAD (+ my local changes) on a Mac yields libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:7: error: error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 [-Werror,-Wundef] | 22 | #elif HAVE_CLOCK_GETTIME | ^ #elif HAVE

Re: Getting valid substitutions to work for subsumption

Hi Matthías, This is going to be challenging to fix, I'm afraid. When GHC sees a definition with a polymorphic type signature, it *skolemizes* the signature before ever looking at the definition. In this context, skolemizing means that GHC will fix the type variable a (in your trace, it become

Re: Getting valid substitutions to work for subsumption

> On May 18, 2017, at 5:27 PM, Simon Peyton Jones wrote: > > I don't agree. If you call (tcSubsumes hole_ty ty) with closed types > hole_ty, ty, it should return True if I agree here. But it looks like Matthías's function gets the expected type as pushed down by bidirectional typechecking.

Haskell Implementors' Workshop Call for Talks

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconf

Re: Hunting down a compilation performance regression involving type families

> On May 31, 2017, at 5:21 PM, Ryan Scott wrote: > Does you know what might be going on here? I think so, but I don't know how to fix it. The commit you found (thank you!) makes simple_opt_expr (the "simple optimizer", run directly after desugaring, even with -O0) a little more selective in w

Re: Interested to help with error messages

> On Jun 3, 2017, at 11:50 AM, Ben Gamari wrote: > > In particular, Richard Eisenberg > advocated that error message documents look like, > >-- A dynamically typed value embedded in an error message >data ErrItem = forall a. (Outputable a, Typeable a). ErrItem

external interpreter failing on Mac

Hi devs, It seems every test run through the external interpreter is failing for me on a Mac: => TH_mkName(ext-interp) 1 of 1 [0, 0, 0] cd "./TH_mkName.run" && "/Users/rae/ghc/ghc/inplace/test spaces/ghc-stage2" -c TH_mkName.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-wa

Re: external interpreter failing on Mac

ure. Something specific to the version of GMP, or some other external > tool/library? > > On 14 June 2017 at 14:55, Richard Eisenberg <mailto:r...@cs.brynmawr.edu>> wrote: > Hi devs, > > It seems every test run through the external interpreter is failing for me on >

Deadline in 2 days: Haskell Implementors' Workshop Call for Talks

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference

GHCi tests hanging on Mac

Hi devs, Some GHCi tests (but far from all!) hang on my Mac. I can't reproduce this behavior outside the testsuite driver, so I think it's the Python code, not the Haskell. Failing tests: ghci/prog017/prog017 ghci/scripts/T6018ghcifail ghci/scripts/T6018ghcirnfail And that's it! My Pytho

Proposed: Language.Haskell.TH.Internal

Hi devs, This is a brief proposal for an internal, non-user-facing restructuring of the implementation of Template Haskell. It's here (instead of at ghc-proposals) because it's not user-facing. When a user writes a TH quote [| foo bar baz |], GHC must desugar that into some Core code that buil

Re: D3754: Refactor uo_thing

Hi Simon, I suppose this is possible, but it would change lots of error messages. (Currently, the uo_thing -- when reported -- is included inline with other parts of the message.) In my opinion, if we're going to reformat error messages, we could do better than this, anyway. I'm thinking of som

Re: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d)

> On Jul 27, 2017, at 8:01 AM, Simon Peyton Jones via ghc-devs > wrote: > > I think Richard just forgot to update the commit message. Indeed. Bah. I don't suppose there's a way of fixing that now. Sorry! Richard ___ ghc-devs mailing list ghc-devs@ha

Re: Debugging inside the typechecker knot

My secret is that I've been annoyed by this problem, too! Perhaps a better answer is that you probably don't need the information you don't have. All the type-checking decisions are around the kinds of the types floating through the system, so look there. You might want to know what type that k

Re: Debugging inside the typechecker knot

> On Aug 4, 2017, at 12:43 PM, Ryan Scott wrote: > > Maybe I could start by trying to produce HsType in that particular spot in > the code (or does this need to be done all at once?). I don't know. I haven't looked into this at all, really. Any light you can shed will be helpful._

Phab: conditional approval

Hi devs, When reviewing a diff on Phab, I can "accept" or "request changes". Sometimes, though, I want to do both: I suggest very minor (e.g., typo) changes, but then when these changes are made, I accept. I'm leery of making the suggestions and saying "accept", because then someone working qui

Re: Disabling Travis?

Indeed I wrote and then deleted an email to you asking to update the Travis script to work again. I deleted it because I realized that fixing this myself was easy. So, at least one person cares about Travis. :) Why do I care? Because I find it easier to validate with Travis than with Phab, for

Re: Disabling Travis?

lures, even in DEBUG mode. Richard > On Aug 21, 2017, at 3:54 AM, Joachim Breitner > wrote: > > Hi, > > Am Sonntag, den 20.08.2017, 23:55 -0400 schrieb Richard Eisenberg: >> The big minus to Travis, as I see it, are that only committers can >> use it. (A forked re

Re: Disabling Travis?

its again. Did you have more > luck? > > Greetings, > Joachim > > Am Montag, den 21.08.2017, 23:17 -0400 schrieb Richard Eisenberg: >> I have not been getting emails from Travis, despite using it for >> other projects (and thus being registered). So perhaps something is

Re: GHC staus

Might implication constraints make it in time for 8.4? And I believe two of Stephanie's students (with some guidance from yours truly) are working on visible kind application and visible type patterns, respectively. But I have no idea about the timeline. I'm not personally planning anything new

Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)

Hi Jared, I have nothing in particular to offer in the way of feedback, other than that this sounds great. Thanks for doing this, and good luck finishing up the work! Richard > On Sep 1, 2017, at 5:00 AM, Jared Weakly wrote: > > Hey y'all, > > A quick ToC before I dive right in: > > * What

Re: Phab: conditional approval

;> On 19 August 2017 at 03:56, Richard Eisenberg wrote: >> >>> Hi devs, >>> >>> When reviewing a diff on Phab, I can "accept" or "request changes". >>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo) >

Re: A type checker plugin for row types

Here are my stabs at answers to two of your questions. > • When/where exactly do Derived constraints arise? I'm not recognizing them > in the OutsideIn paper. I agree with others' comments on this point, but perhaps I can expand. A Derived constraint is essentially a Wanted constraint, but one

Re: Invariants about UnivCo?

> On Sep 19, 2017, at 9:50 AM, Nicolas Frisby wrote: > > Questions: > > 1) Is there a robust way to ensure that covar's uniques are always printed? > (Is the pprIface reuse with a free cobox part of the issue here?) Try rebasing. I ran into a similar issue not long ago and revised the code

Re: Invariants about UnivCo?

chard > > I'm optimistic that fixing this up will help. Does it sound promising/ring > any bells for you? > > Thanks. -Nick > > On Wed, Sep 20, 2017 at 7:47 PM Richard Eisenberg <mailto:r...@cs.brynmawr.edu>> wrote: > > > On Sep 19, 2017, at

Re: Why isn't this Typeable?

The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be

Re: Why isn't this Typeable?

thing we can fingerprint. Is there any difficulty fingerprinting types > like Foo 'Just and > Bar @'Just @Int? Fingerprints are useful for lots of applications where > decomposition isn't > necessary. > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard E

Re: Why isn't this Typeable?

eck first how much that matters. > > > David Feuer > Well-Typed, LLP > > ---- Original message > From: Richard Eisenberg > Date: 9/25/17 2:42 PM (GMT-05:00) > To: David Feuer > Cc: Ben Gamari , ghc-devs@haskell.org > Subject: Re: Why isn't this Type

Re: CircleCI (Was: Disable Travis?)

I just tried to get on board this new train. But I can't seem to figure out how to "follow" ghc. I signed up through my GitHub account, but CircleCI doesn't seem to want me to follow an open-source project with which I have no formal association in GitHub. Joachim, it seemed you unlocked this ca

Re: CircleCI (Was: Disable Travis?)

> On Oct 2, 2017, at 1:15 PM, Joachim Breitner wrote: > > Well, eventually we will have Jenkins and All Is Well™. But in the meantime, I can push to my branch and then manually check CircleCI a little while later and get meaningful results, which is much better than we've had in some time. Em

Re: Massive detabbing of the source

I don't know whether the files have been "stable" or not, but I'm working on some pretty massive changes to a handful of files in order to support promotion of GADTs, among other fun things. So, if I may ask, please stay away from detabbing the following: TypeRep Type Coercion OptCoercion Unify

Re: Massive detabbing of the source

I like Alexander's idea, but there's a subtle problem with it: Any sizeable change to one file requires (at least) small changes in several other files. Say X.hs has tabs. If I make a one-line change to X.hs, and you're in the middle of massive changes to X.hs, and I detab X.hs in the course of

Re: RFC: Singleton equality witnesses

2 ~ Integer@, > and also @Demote 3 ~ Integer@, but @Demote "Hello" ~ String@. -} > ---------- > > Regarding Richard's decidable equality suggestion, I think this would > be the next step. IIRC, empty case expressions ha

Re: RFC: Singleton equality witnesses

On Feb 6, 2013, at 1:03 PM, Gabor Greif wrote: > On 2/5/13, Richard Eisenberg wrote: > >> >> My argument would be not to return >> Maybe (SameSing kparam a b) >> but to return >> Either (SameSing kparam a b) (SameSing kparam a b -> Void) >> or so

Re: GHC 7.8 release?

Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland wrote: > In practice the versions of GHC that are widely used are those that are > included in the platform. Maybe we should coordinate with their next > release? They are targeting a May

Re: RFC: Singleton equality witnesses

the reason to have it in > > base. > > Is it tied to TypeLits? > > > > > > Cheers, > > Pedro > > > > On Thu, Feb 7, 2013 at 2:21 PM, Gabor Greif wrote: > > > >> Oi José, > >> > >> this is a library-only i

Re: [commit: ghc] master: Fix Trac #7681. (7b098b6)

; Simon > > | -Original Message- > | From: ghc-commits-boun...@haskell.org [mailto:ghc-commits- > | boun...@haskell.org] On Behalf Of Richard Eisenberg > | Sent: 12 February 2013 04:10 > | To: ghc-comm...@haskell.org > | Subject: [commit: ghc] master: Fix Trac #7681. (7b

Re: Setting up a sandboxed installation of GHC HEAD

I'm not sure if it completely solves your problem, but have you looked into stow (http://www.gnu.org/software/stow/)? Using stow, you install an application into a directory under ~/local/stow (using, say, ./configure --prefix=…) and then the stow executable places symlinks to all of that appli

Re: building on Mac

I, too, had this problem, saying /usr/bin/gcc could not execute on a Mac. gcc was indeed there and could run just fine. Even more oddly, when I tried `make` again, compilation would get past the point it was stuck only to fall over again several files later. I probably could have gotten everythi

Re: Overlapping families (specificity/degrees of freedom)

Hi Gabor, I can't comment specifically on your code, because I'm afraid I don't understand it all. But, I think I can answer your question: GHC will select a type instance branch to use in a given type family application if and only if the following 2 conditions hold: 1. There is a substituti

Re: building on Mac

I have Mountain Lion (10.8.2, to be exact) with XCode 4.6 installed, and I can build GHC. I don't use XCode when building, but I believe the command-line dev tools (like gcc) are shipped with XCode, so that might be something to look at. Sorry I don't have any more suggestions! Richard On Mar 1

Re: constraint deduction bug?

It certainly looks trivial to me. Richard On Mar 21, 2013, at 7:59 PM, Gabor Greif wrote: > In context of a bigger source file I got this error from GHC (HEAD) > >Could not deduce (Intersect >[KeySegment] (BuriedUnder sub k ('Empty > [KeySegment])) inv >

Could not find 'Prelude'

On HEAD, commit b9d53..., a freshly built ghc-stage2 can't find its Prelude: > rae:22:06:54 ~/temp> ~/Documents/ghc-baseline/inplace/bin/ghc-stage2 > Scratch.hs > > Scratch.hs:1:1: > Could not find module ‛Prelude’ > There are files missing in the ‛base’ package, > try running 'ghc-p

Re: Could not find 'Prelude'

Yep. That change did it. My Makefile-fu isn't quite strong enough to feel comfortable changing the build process, but perhaps someone should take a look at this, because I doubt I'm the only one who would have the problem. Thanks, Edward! Richard On Mar 26, 2013, at 10:48 PM, "Edward Z. Yang"

Re: What promotes to (* :: BOX) ?

For more immediate satisfaction (i.e., before we get around to updating GHC in the manner suggested on the wiki page), you have to use a parameterized type and then specialize it to *: > data Prom2 a = Typic a Now, we have (Prom2 * :: BOX) with (Typic Int :: Prom2 *). Unfortunately, we have no

Proxy, new Typeable, and type-level equality

Hi all, Combining ideas from a number of people/threads ("Proxy and new-typeable" [on libraries] and "RFC: Singleton equality witnesses" [on ghc-devs]), I propose this: > module GHC.TypeReasoning where > > data a :~: b where > Refl :: a :~: a > > -- with credit to Conal Elliott for 'ty' and

Restrictions on polytypes with type families

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this

Re: Overlapping families (specificity/degrees of freedom)

On Apr 3, 2013, at 3:01 PM, Gabor Greif wrote: > > What I want is a function that can e.g. create the minimal union of > two Symbol singletons, possibly by consulting decidable (in)equality: > > {{{ (sketch) > type family MinUnion (a :: Symbol) (b :: Symbol) :: [Symbol] > type instance where >

Re: HEAD build fails on OS X

I'm able to build, but not install, on a freshly-cloned HEAD, commit b84da617, from Simon PJ. Here's the end of my output: Installing library in /Users/rae/local/stow/ghc-head/lib/ghc-7.7.20130403/haskell2010-1.1.1.0 "/Users/rae/local/stow/ghc-head/lib/ghc-7.7.20130403/bin/ghc-pkg" --force --gl

Re: Restrictions on polytypes with type families

I'm not sure the use case being discussed here is really what I'm after. This use case has a type family application appearing within a forall > Maybe (forall a. F [a]) ... This actually seems to work OK when I test it, though I haven't looked closely at the internal machinery. I'm more concer

package installation woes with Template Haskell / dynamic libraries

Hi all, --- tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's? --- I've built and insta

Re: wiki page explaining the git branches

+1 to this idea. It could also identify branches which are no longer active and perhaps can be deleted. On Apr 11, 2013, at 3:11 PM, Nicolas Frisby wrote: > I'd like a wiki page that briefly explains the git branches. > > 1) Does it exist? My search for it failed. > > 2) Should it exist?

Re: Proxy, new Typeable, and type-level equality

ctionality that is classically not derivable for Leibnizian > equality. > > Sent from my iPhone > > On Apr 4, 2013, at 3:01 AM, Erik Hesselink wrote: > >> On Wed, Apr 3, 2013 at 6:08 PM, Richard Eisenberg wrote: >>> Comments? Thoughts? >> >> Edward

Re: HP 2013.2 and GHC 7.6.2

On Apr 16, 2013, at 3:43 AM, Christian Maeder wrote: > > What is the exact command to get the relevant ghc sources. > First, make sure that your installed GHC is *not* a snapshot distribution, but one of the main releases (such as 7.6.1 or 7.6.2). You may also want to check out http://hackag

Re: Proxy, new Typeable, and type-level equality

wikipage to a > base library > branch: https://github.com/ghc/packages-base/tree/data-proxy > > Some code (and lots of documentation) is still missing; feel free to help! > > > Cheers, > Pedro > > On Fri, Apr 12, 2013 at 2:01 PM, Richard Eisenberg wrote: > I have u

browsing on github

Hi fellow devs, Do any of you use github for browsing the GHC code? I find it useful sometimes, especially when I'm collaborating with someone remotely and wish to send a link to some code, or when I don't have a particular branch to hand. As of October, github now renders all .lhs files as Mar

Re: GHC internals

http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ > give syntax, static semantics, and operational semantics of Core. > > Moreover, Richard Eisenberg has developed a specification of the Real Core in > GHC, kept in the source tree in docs/core-spec > > I enclos

Re: GHC internals

. Richard On Apr 29, 2013, at 12:00 PM, Simon Peyton-Jones wrote: > That's not really true though. The compiler implements beta-reduction; and > inlining; and directly implements the "Push" rules in exprIsConApp_maybe. > > S > > | -Original Me

development snapshot

Hello all, I recently posted a bug report about cabal that's exposed by its interaction with GHC HEAD, and one of the cabal devs reasonably asked about a snapshot of HEAD somewhere. The link from http://www.haskell.org/ghc/download leads to an empty directory. Is there another place I can offer

haddock test suite

Hi all, I've implemented the proposal at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity, which involved a few changes to HsDecl datatypes (FamilyDecl, TyFamInstDecl, etc.), thus requiring a change to Haddock. I tried to be as minimal as I could there, but prudence tells me I sh

RE: haddock test suite

> -Original Message- > From: ghc-devs-boun...@haskell.org [mailto:ghc-devs- > boun...@haskell.org] On Behalf Of Mateusz Kowalczyk > > This means your GHC is too old. Compile from git and try again. I don't think that's it -- I merged with HEAD this morning. > > Out of interest, can you p

Re: Exposing newtype coercions to Haskell

Hi Joachim, A few responses to your plan: - I think you *do* want HsExprs not CoreExprs. Though I haven't worked much in TcDeriv myself, I imagine everything uses HsExprs so that they can be type-checked. This allows nice error messages to be reported at the site of a user's "deriving instanc

Re: Exposing newtype coercions to Haskell

n't have a clear enough opinion to express on that front. Richard On 2013-07-23 08:21, Joachim Breitner wrote: Hi Richard and Simon, thanks for your detailed notes. Am Montag, den 22.07.2013, 17:01 +0100 schrieb Richard Eisenberg: - I think you *do* want HsExprs not CoreExprs. Though I ha

Re: Exposing newtype coercions to Haskell

You're right, of course. I'm now thinking we really do need ~R# to make this work. That's annoying, but not technically difficult. I'll continue to think about this. Richard On 2013-07-23 10:00, Joachim Breitner wrote: Hi, Am Dienstag, den 23.07.2013, 09:51 +0100 schri

Re: Exposing newtype coercions to Haskell

hole point of this exercise > is not to write that -- and the type might not be an instance of Functor. > > I'm thinking we need (~R#) as a type constructor. > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On

Re: haddock: internal error: synifyKind

My fault -- sorry. Forgot to push the change to haddock when I pushed base. Update your haddock, and you should be OK. Richard On 2013-07-24 13:10, Simon Marlow wrote: A validate today on x86_64/Linux is failing with haddock: internal error: synifyKind While haddocking the base package.

RE: new-typeable, new cast?

ock.Convert line 356 Simon | -Original Message----- | From: Richard Eisenberg [mailto:e...@cis.upenn.edu] | Sent: 23 July 2013 15:12 | To: Edward Kmett | Cc: José Pedro Magalhães; Dimitrios Vytiniotis; Simon Peyton-Jones; Stephanie | Weirich; josepedromagalh...@gmail.com; librar..

Re: [commit: base] master: Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning (365b9d8)

t the Typeable instance for Proxy > go in Data.Typeable.Internals? (And perhaps similarly for other instances.) > > Simon > > | -Original Message- > | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of > | Richard Eisenberg > |

RE: [commit: base] master: Implement "TypeLevelReasoning" proposal at wiki:TypeLevelReasoning (365b9d8)

types declared as instances of Typeable at the place that Typeable class is defined; no harm in one more. So I'd really prefer the re-jig if that's ok Simon | -Original Message- | From: Richard Eisenberg [mailto:e...@cis.upenn.edu] | Sent: 24 July 2013 22:37 | To: Simon Pe

Re: Mentoring for implementing #8004

I haven't played much with instances, but it looks to me like tcInstDecls1, in typecheck/TcInstDecls.lhs, is a good place. Toward the end of the body of that function is a bunch of checks in the style that you will need to write (such as for bogus Typeable instances). I hope this helps! Richar

Re: Exposing newtype coercions to Haskell

Hi Joachim, As discussed previously, I do think we need a way to store representational coercions. In my roles branch (which is getting close to pushing, I believe), I have created eqReprPrimTyCon, which is like eqPrimTyCon, but it is the type of coercions witnessing representational equality.

Re: Need to pull Cabal revs from upstream repos over to GHC ones?

Thanks for the heads up. I did indeed not push libraries/Cabal, because I thought it would go along with pushing ghc. (I find git submodules to be rather confusing.) I've now pushed, but to darcs.haskell.org/srv/darcs/libraries/Cabal, which I believe is the same place. Please try again and let

Re: Ian leaving and the glorious future

I think a hacking session is a great idea, either over IRC or at ICFP. I'm also thinking about how to foster involvement from newcomers on a more continual basis. Every several months, someone posts saying, essentially "I'd like a project. Give me one." The answers seem to be, "Find an interes

libffi-tarballs

After the libffi-tarballs submodule was added, I did a ./sync-all pull, a ./sync-all get, and a git submodule update. Everything builds just fine, but I get this answer from git status: # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # #

Re: Ian leaving and the glorious future

OK -- the page is up at http://ghc.haskell.org/trac/ghc/wiki/Newcomers Please improve it as you see fit! Richard On 2013-08-06 07:04, Vincent Hanquez wrote: On 08/05/2013 10:51 AM, Richard Eisenberg wrote: I think a hacking session is a great idea, either over IRC or at ICFP. I'm

Re: Ian leaving and the glorious future

d submit a patch. And as an aside question, when would one need to compile state 1 vs stage 2 (aside from the first compilation)? On Fri, Aug 9, 2013 at 6:56 AM, Richard Eisenberg wrote: OK -- the page is up at http://ghc.haskell.org/trac/ghc/wiki/Newcomers [1]   Please improve it as you see fit

Re: Successful build of GHC HEAD on OS X 10.9 Mavericks

I'm not aware of any outstanding bugs in the role checker that would cause a core lint failure (or any other problems), so if you're seeing one, that sounds like new news. How did you run into this? Thanks, Richard On Aug 9, 2013, at 3:33 AM, Dr. ERDI Gergo wrote: > On Fri, 9 Aug 2013, Luke Ia

Re: request for reviews for my first patch -- ticket 7401

Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to make sure that we're conforming to the Haskell standard. But, if the user has specified EmptyDataDecls, then we're not bound to that requirement anymore

Re: Cannot compile phase 2 after recent Roles patch

It looks to me that the problem is caused by an outdated libraries/base repo. Have you run ./sync-all pull? In particular, your libraries/base repo needs to be at ab9e8e3… or later. Let me know if this was indeed the problem! Thanks, Richard On Aug 11, 2013, at 2:21 AM, Dr. ERDI Gergo wrote:

<    1   2   3   4   5   6   7   8   9   10   >