RE: Haskell Error Messages

Is there currently any planned work around making the haskell error messages able to support something like the ones in IDRIS, as shown in David Christianson's talk "A Pretty printer that says what it means" at HIW? Not that I know of, but it would be a Good Thing. Simon From: ghc-devs

Re: Haskell Error Messages

That is indeed the ticket capturing the issue. Does anyone have plans to work on it? Alan On Wed, Sep 9, 2015 at 3:37 AM, Richard Eisenberg wrote: > Ticket #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809) seems the > best spot to look for this. > > Richard > > On Sep

Re: Cannot have GHC in ARMv6 architecture

On 09/ 9/15 01:22 PM, jmcf...@openmailbox.org wrote: So, when doing that, configure works (the logs were for the previous attempts). But why is that when I try to make, with a working configure, and a real sysroot, that I get the following error? $ make -j5 (...) "inplace/bin/mkdirhier"

Re: Cannot have GHC in ARMv6 architecture

Hi, sorry for not sending a CC to the mailing list, works differently from others I've used > > $ ls -R /home/jmcf125/ghc-raspberry-pi/sysroot/* > >/home/jmcf125/ghc-raspberry-pi/sysroot/lib: > >libcursesw.so libncurses.so libncurses++.so libncurses.so.5@ > >libncurses.so.5.9*

RE: Unlifted data types

| (denotationally, at least) is the outer-most level. That's why I liked | the original proposal (which probably disappeared too fast for most | people to read it), which was more like being able to talk about `!a` | as a thing in itself. It's the only semantic gap in being able to That's

Re: Unlifted data types

On Sep 9, 2015, at 8:28 AM, Simon Peyton Jones wrote: > I think it'd be better to have > > TYPE :: TypeShape -> * > > data TypeShape = Unboxed | Boxed Levity > data Levity = Lifted | Unlifted > Yes, of course. > So we really would get very little levity polymorphism

RE: Unlifted data types

I like your suggestion! I think it'd be better to have TYPE :: TypeShape -> * data TypeShape = Unboxed | Boxed Levity data Levity = Lifted | Unlifted Now the awkward "unboxed/lifted" combination doesn't arise. Now, 'error' is "TypeShape-polymorphic": error :: forall (ts :: TypeShape) (a ::

Re: Proposal: Automatic derivation of Lift

I proposed automated derivation of Lift earlier (this year even?), but it got shot down as "needless and trivial to do using TH", so if people are now in favour consider me a very strong +1. This would make it significantly easier to implement an efficient version of

Re: Proposal: accept pull requests on GitHub

> > (I'm tempted naively to ask: is there an automated way to go from a GitHub > > PR to a Phab ticket? Then we could convert the former (if someone wants to > > submit that way) into the latter.) Or: is there a way contributors can create a Phab differential off a GitHub branch? This

Re: Cannot have GHC in ARMv6 architecture

So ghc-stage1 is working. Good! Now just to find why your base is broken, please rebuild ghc completely and this time does not use any -j 5 option. It'll use just one core, but will stop on the first error. Let's see how far you get. Karel On 09/ 9/15 02:59 PM, jmcf...@openmailbox.org

Re: Unlifted data types

On Sep 9, 2015, at 8:40 AM, Simon Peyton Jones wrote: > Can you be more specific? What does "gloss over" mean? I mean that, for example, `length` will work over both strict lists and lazy lists. It will infer the strictness of its argument through ordinary type

RE: Unlifted data types

| That's right. The levity polymorphism is, essentially, only to have a | nice type inference story. Once the code gets passed to the back end, | the polymorphism would have to be removed. My idea was to use it to | allow users to gloss (somewhat) over the ! vs. no-! distinction by | having

Re: Cannot have GHC in ARMv6 architecture

> How exactly ghc-stage1 behaves? What does ghc-stage1 --info tells you? $ ../inplace/bin/ghc-stage1 --make HelloWorld.lhs HelloWorld.lhs:1:1: Could not find module ‘Prelude’ There are files missing in the ‘base-4.8.1.0’ package, try running 'ghc-pkg check'. Use -v to see a list

RE: Unlifted data types

| I mean that, for example, `length` will work over both strict lists | and lazy lists. It will infer the strictness of its argument through | ordinary type inference. So users have to be aware of strictness, but | they will be able to use the same functions in both cases. I didn't understand

Re: Unlifted data types

On Sep 9, 2015, at 8:57 AM, Simon Peyton Jones wrote: > | I mean that, for example, `length` will work over both strict lists > | and lazy lists. It will infer the strictness of its argument through > | ordinary type inference. So users have to be aware of strictness,

Re: Proposal: accept pull requests on GitHub

As a junior ghc contributor, I have to comment that git push -u my-fork my-branch and arc diff are about of the same “cognitive load”. Yes, one must have arc on the machine, but if the right version could live as a submodule in GHC tree: even better. And a bit tangental comment: I can

Re: Cannot have GHC in ARMv6 architecture

> So ghc-stage1 is working. Good! Now just to find why your base is broken, > please rebuild ghc completely and this time does not use any -j 5 option. > It'll use just one core, but will stop on the first error. Let's see how far > you get. Ah. Alright, it took a while longer. $ ./configure

Re: Cannot have GHC in ARMv6 architecture

On 09/ 9/15 04:21 PM, jmcf...@openmailbox.org wrote: So ghc-stage1 is working. Good! Now just to find why your base is broken, please rebuild ghc completely and this time does not use any -j 5 option. It'll use just one core, but will stop on the first error. Let's see how far you get. Ah.

Re: Cannot have GHC in ARMv6 architecture

On Wed, Sep 9, 2015 at 11:46 AM, Karel Gardas wrote: > On 09/ 9/15 04:21 PM, jmcf...@openmailbox.org wrote: > >> So ghc-stage1 is working. Good! Now just to find why your base is broken, >>> please rebuild ghc completely and this time does not use any -j 5 option. >>>

Re: Cannot have GHC in ARMv6 architecture

On 09/ 9/15 05:59 PM, Reid Barton wrote: This is not weird at all! GHC does not provide ARM NCG and so it is using LLVM if you compile ARM registerised build. But "./configure [...] --enable-unregisterised" should mean using the C backend, not LLVM, right? So this still looks strange.

Re: Cannot have GHC in ARMv6 architecture

Okay, I tried with LLVM registerised, I've read about it and the idea sounds nice. > What is in your build.mk? Maybe you are using one of the build flavors that > sets -fllvm explicitly? Ah, so that was it. I followed Karel's blog, seems back then the BuildFlavour = quick-cross option he used

Converting unboxed sum types in StgCmm

Hi! The original idea for implementing the backend part of the unboxed sums proposal was to convert from the core representation to the actual data representation (i.e. a tag followed by some pointer and non-pointer fields) in the unarise stg-to-stg

Re: Converting unboxed sum types in StgCmm

I wonder if rewriting any aliased pointer field as Any in Stg and any non-pointer field as Word# would work. I suspect that not all non-pointer fields (e.g. Double# on 32-bit) can be represented as Word#. On Wed, Sep 9, 2015 at 3:22 PM, Johan Tibell wrote: > Hi! > > The

Re: Converting unboxed sum types in StgCmm

Some of the SSE types are too big for that even on 64 bit, I think. Like DoubleX8#. On Thu, Sep 10, 2015 at 1:16 AM, Johan Tibell wrote: > I wonder if rewriting any aliased pointer field as Any in Stg and any > non-pointer field as Word# would work. I suspect that not all

Shared data type for extension flags

I don't think it makes very much sense to reuse bin-package-db; at least, not without renaming it at the very least (who'd expect a list of language extension flags to live in a binary package database?) We could name it something like 'ghc-types'? Edward Excerpts from Simon Peyton Jones's

Re: Unlifted data types

On Wed, Sep 9, 2015 at 9:03 AM, Richard Eisenberg wrote: > No functions (excepting `error` and friends) are truly levity polymorphic. I was talking with Ed Kmett about this yesterday, and he pointed out that this isn't true. There are a significant array of levity polymorphic

Re: Unlifted data types

I think ultimately the two views of levity that we've been talking diverge along the same lines as the pi vs forall discussion from your Levity polymorphism talk. I've been focused entirely on situations where forall suffices, and no distinction is needed in how you compile for both levities.