From conal at conal.net  Fri May  2 17:31:26 2014
From: conal at conal.net (Conal Elliott)
Date: Fri, 2 May 2014 10:31:26 -0700
Subject: "haskeline dylib failure on MacOS in GHC HEAD"
Message-ID: <CAD6SzRLTFrwgERe2o6nyHAYD-vXLUQNdsAM478rt36uOkwcGEg@mail.gmail.com>

I built GHC HEAD on MacOS 10.9.2 from GitHub yesterday and am getting an
error when trying to use a problem (HERMIT) that uses haskeline:

    Loading package haskeline-0.7.1.2 ... <command line>: can't load
.so/.DLL for:
/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib
(dlopen(/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib,
9): Symbol not found:
_terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziBase_termText1_closure
      Referenced from:
/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib
      Expected in:
/Users/conal/install/quickest/lib/ghc-7.9.20140430/bin/../terminfo-0.4.0.0/libHSterminfo-0.4.0.0-ghc7.9.20140430.dylib
     in
/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib)
    bash-3.2$ ls -l
/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib
    -rwxr-xr-x+ 1 conal  staff  2337596 May  2 10:22
/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib

Any ideas?

-- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140502/d28dcf48/attachment.html>

From ashley at semantic.org  Sat May  3 23:58:02 2014
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat, 03 May 2014 16:58:02 -0700
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
Message-ID: <5365828A.7050103@semantic.org>

So I want to install GHC + cabal on a new system, building cabal 
packages with profiling and documentation. Here's what I have to do:

1. Download, unpack and install GHC.

2. Download and unpack cabal-install, and run bootstrap.sh. As part of 
the bootstrap, it will download and build a bunch of packages.

3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they were 
built without profiling or documentation.

4. Call "cabal update" to get a default .cabal/config file.

5. Edit .cabal/config to switch on library-profiling, 
executable-profiling, and documentation.

6. Build my stuff.

This would be much simplified if binary versions of cabal-install were 
available. (It would be even simpler if they were just included in the 
GHC builds -- I could eliminate 2 & 3.)

-- Ashley Yakeley

From carter.schonwald at gmail.com  Sun May  4 00:00:25 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 3 May 2014 20:00:25 -0400
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <5365828A.7050103@semantic.org>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <5365828A.7050103@semantic.org>
Message-ID: <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>

I think there's now hosted official cabal install binaries online.  I'm Afk
but they should be a short google away. Should be linked more prominently
though

On Saturday, May 3, 2014, Ashley Yakeley <ashley at semantic.org> wrote:

> So I want to install GHC + cabal on a new system, building cabal packages
> with profiling and documentation. Here's what I have to do:
>
> 1. Download, unpack and install GHC.
>
> 2. Download and unpack cabal-install, and run bootstrap.sh. As part of the
> bootstrap, it will download and build a bunch of packages.
>
> 3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they were
> built without profiling or documentation.
>
> 4. Call "cabal update" to get a default .cabal/config file.
>
> 5. Edit .cabal/config to switch on library-profiling,
> executable-profiling, and documentation.
>
> 6. Build my stuff.
>
> This would be much simplified if binary versions of cabal-install were
> available. (It would be even simpler if they were just included in the GHC
> builds -- I could eliminate 2 & 3.)
>
> -- Ashley Yakeley
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140503/1a1c8fef/attachment.html>

From ashley at semantic.org  Sun May  4 00:06:04 2014
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat, 03 May 2014 17:06:04 -0700
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>	<5365828A.7050103@semantic.org>
 <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
Message-ID: <5365846C.5030705@semantic.org>

I couldn't find them, and they're not listed at 
<http://www.haskell.org/cabal/download.html> (except OS X), or at 
<http://www.haskell.org/haskellwiki/Cabal-Install>, or at 
<http://hackage.haskell.org/package/cabal-install>.

-- Ashley

On 2014-05-03 17:00, Carter Schonwald wrote:
> I think there's now hosted official cabal install binaries online. 
>  I'm Afk but they should be a short google away. Should be linked more 
> prominently though
>
> On Saturday, May 3, 2014, Ashley Yakeley <ashley at semantic.org 
> <mailto:ashley at semantic.org>> wrote:
>
>     So I want to install GHC + cabal on a new system, building cabal
>     packages with profiling and documentation. Here's what I have to do:
>
>     1. Download, unpack and install GHC.
>
>     2. Download and unpack cabal-install, and run bootstrap.sh. As
>     part of the bootstrap, it will download and build a bunch of packages.
>
>     3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they
>     were built without profiling or documentation.
>
>     4. Call "cabal update" to get a default .cabal/config file.
>
>     5. Edit .cabal/config to switch on library-profiling,
>     executable-profiling, and documentation.
>
>     6. Build my stuff.
>
>     This would be much simplified if binary versions of cabal-install
>     were available. (It would be even simpler if they were just
>     included in the GHC builds -- I could eliminate 2 & 3.)
>
>     -- Ashley Yakeley
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.org
>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


From johan.tibell at gmail.com  Sun May  4 00:24:35 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 4 May 2014 02:24:35 +0200
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <5365846C.5030705@semantic.org>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <5365828A.7050103@semantic.org>
 <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
 <5365846C.5030705@semantic.org>
Message-ID: <CAK-tuPY9x6fRGhWFR82DfyWDA_aT5b83Vp=1WMufqFBrTyQedg@mail.gmail.com>

I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm waiting
for someone to send me a Windows one.


On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley <ashley at semantic.org> wrote:

> I couldn't find them, and they're not listed at <
> http://www.haskell.org/cabal/download.html> (except OS X), or at <
> http://www.haskell.org/haskellwiki/Cabal-Install>, or at <
> http://hackage.haskell.org/package/cabal-install>.
>
> -- Ashley
>
>
> On 2014-05-03 17:00, Carter Schonwald wrote:
>
>> I think there's now hosted official cabal install binaries online.  I'm
>> Afk but they should be a short google away. Should be linked more
>> prominently though
>>
>> On Saturday, May 3, 2014, Ashley Yakeley <ashley at semantic.org <mailto:
>> ashley at semantic.org>> wrote:
>>
>>     So I want to install GHC + cabal on a new system, building cabal
>>     packages with profiling and documentation. Here's what I have to do:
>>
>>     1. Download, unpack and install GHC.
>>
>>     2. Download and unpack cabal-install, and run bootstrap.sh. As
>>     part of the bootstrap, it will download and build a bunch of packages.
>>
>>     3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they
>>     were built without profiling or documentation.
>>
>>     4. Call "cabal update" to get a default .cabal/config file.
>>
>>     5. Edit .cabal/config to switch on library-profiling,
>>     executable-profiling, and documentation.
>>
>>     6. Build my stuff.
>>
>>     This would be much simplified if binary versions of cabal-install
>>     were available. (It would be even simpler if they were just
>>     included in the GHC builds -- I could eliminate 2 & 3.)
>>
>>     -- Ashley Yakeley
>>     _______________________________________________
>>     Glasgow-haskell-users mailing list
>>     Glasgow-haskell-users at haskell.org
>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140504/b3f04121/attachment.html>

From metaniklas at gmail.com  Sun May  4 09:13:03 2014
From: metaniklas at gmail.com (Niklas Larsson)
Date: Sun, 4 May 2014 11:13:03 +0200
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAK-tuPY9x6fRGhWFR82DfyWDA_aT5b83Vp=1WMufqFBrTyQedg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <5365828A.7050103@semantic.org>
 <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
 <5365846C.5030705@semantic.org>
 <CAK-tuPY9x6fRGhWFR82DfyWDA_aT5b83Vp=1WMufqFBrTyQedg@mail.gmail.com>
Message-ID: <CACG=oWEQH4L2=SME8Kysyu24X8-jXOqQP2+Btd0pmDq1C8bP6A@mail.gmail.com>

Hi!

I put a Windows build here:
https://www.dropbox.com/s/at7wc1dh0lfr7lc/cabal.exe.zip

Niklas
2014-05-04 2:24 GMT+02:00 Johan Tibell <johan.tibell at gmail.com>:

> I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm
> waiting for someone to send me a Windows one.
>
>
> On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley <ashley at semantic.org>wrote:
>
>> I couldn't find them, and they're not listed at <
>> http://www.haskell.org/cabal/download.html> (except OS X), or at <
>> http://www.haskell.org/haskellwiki/Cabal-Install>, or at <
>> http://hackage.haskell.org/package/cabal-install>.
>>
>> -- Ashley
>>
>>
>> On 2014-05-03 17:00, Carter Schonwald wrote:
>>
>>> I think there's now hosted official cabal install binaries online.  I'm
>>> Afk but they should be a short google away. Should be linked more
>>> prominently though
>>>
>>> On Saturday, May 3, 2014, Ashley Yakeley <ashley at semantic.org <mailto:
>>> ashley at semantic.org>> wrote:
>>>
>>>     So I want to install GHC + cabal on a new system, building cabal
>>>     packages with profiling and documentation. Here's what I have to do:
>>>
>>>     1. Download, unpack and install GHC.
>>>
>>>     2. Download and unpack cabal-install, and run bootstrap.sh. As
>>>     part of the bootstrap, it will download and build a bunch of
>>> packages.
>>>
>>>     3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they
>>>     were built without profiling or documentation.
>>>
>>>     4. Call "cabal update" to get a default .cabal/config file.
>>>
>>>     5. Edit .cabal/config to switch on library-profiling,
>>>     executable-profiling, and documentation.
>>>
>>>     6. Build my stuff.
>>>
>>>     This would be much simplified if binary versions of cabal-install
>>>     were available. (It would be even simpler if they were just
>>>     included in the GHC builds -- I could eliminate 2 & 3.)
>>>
>>>     -- Ashley Yakeley
>>>     _______________________________________________
>>>     Glasgow-haskell-users mailing list
>>>     Glasgow-haskell-users at haskell.org
>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140504/c8a1d352/attachment-0001.html>

From johan.tibell at gmail.com  Sun May  4 09:34:50 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 4 May 2014 11:34:50 +0200
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CACG=oWEQH4L2=SME8Kysyu24X8-jXOqQP2+Btd0pmDq1C8bP6A@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <5365828A.7050103@semantic.org>
 <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
 <5365846C.5030705@semantic.org>
 <CAK-tuPY9x6fRGhWFR82DfyWDA_aT5b83Vp=1WMufqFBrTyQedg@mail.gmail.com>
 <CACG=oWEQH4L2=SME8Kysyu24X8-jXOqQP2+Btd0pmDq1C8bP6A@mail.gmail.com>
Message-ID: <CAK-tuPZwveJJLCxx0EavNpekTCKh0Ch4KZfUnUA5iD5hrVuCdA@mail.gmail.com>

Thanks. Between you and Mikhail we got the Windows side covered. :)


On Sun, May 4, 2014 at 11:13 AM, Niklas Larsson <metaniklas at gmail.com>wrote:

> Hi!
>
> I put a Windows build here:
> https://www.dropbox.com/s/at7wc1dh0lfr7lc/cabal.exe.zip
>
> Niklas
> 2014-05-04 2:24 GMT+02:00 Johan Tibell <johan.tibell at gmail.com>:
>
> I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm
>> waiting for someone to send me a Windows one.
>>
>>
>> On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley <ashley at semantic.org>wrote:
>>
>>> I couldn't find them, and they're not listed at <
>>> http://www.haskell.org/cabal/download.html> (except OS X), or at <
>>> http://www.haskell.org/haskellwiki/Cabal-Install>, or at <
>>> http://hackage.haskell.org/package/cabal-install>.
>>>
>>> -- Ashley
>>>
>>>
>>> On 2014-05-03 17:00, Carter Schonwald wrote:
>>>
>>>> I think there's now hosted official cabal install binaries online.  I'm
>>>> Afk but they should be a short google away. Should be linked more
>>>> prominently though
>>>>
>>>> On Saturday, May 3, 2014, Ashley Yakeley <ashley at semantic.org <mailto:
>>>> ashley at semantic.org>> wrote:
>>>>
>>>>     So I want to install GHC + cabal on a new system, building cabal
>>>>     packages with profiling and documentation. Here's what I have to do:
>>>>
>>>>     1. Download, unpack and install GHC.
>>>>
>>>>     2. Download and unpack cabal-install, and run bootstrap.sh. As
>>>>     part of the bootstrap, it will download and build a bunch of
>>>> packages.
>>>>
>>>>     3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they
>>>>     were built without profiling or documentation.
>>>>
>>>>     4. Call "cabal update" to get a default .cabal/config file.
>>>>
>>>>     5. Edit .cabal/config to switch on library-profiling,
>>>>     executable-profiling, and documentation.
>>>>
>>>>     6. Build my stuff.
>>>>
>>>>     This would be much simplified if binary versions of cabal-install
>>>>     were available. (It would be even simpler if they were just
>>>>     included in the GHC builds -- I could eliminate 2 & 3.)
>>>>
>>>>     -- Ashley Yakeley
>>>>     _______________________________________________
>>>>     Glasgow-haskell-users mailing list
>>>>     Glasgow-haskell-users at haskell.org
>>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140504/30a0ab16/attachment.html>

From voldermort at hotmail.com  Sun May  4 14:15:07 2014
From: voldermort at hotmail.com (harry)
Date: Sun, 4 May 2014 07:15:07 -0700 (PDT)
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAK-tuPZwveJJLCxx0EavNpekTCKh0Ch4KZfUnUA5iD5hrVuCdA@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <5365828A.7050103@semantic.org>
 <CAHYVw0y9Ef_Zcut5XJrsYS=P=Q16O9_ZVyXgKFLTdQWBfWG8yQ@mail.gmail.com>
 <5365846C.5030705@semantic.org>
 <CAK-tuPY9x6fRGhWFR82DfyWDA_aT5b83Vp=1WMufqFBrTyQedg@mail.gmail.com>
 <CACG=oWEQH4L2=SME8Kysyu24X8-jXOqQP2+Btd0pmDq1C8bP6A@mail.gmail.com>
 <CAK-tuPZwveJJLCxx0EavNpekTCKh0Ch4KZfUnUA5iD5hrVuCdA@mail.gmail.com>
Message-ID: <1399212907333-5749048.post@n5.nabble.com>

Linux?



--
View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5749048.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From simonpj at microsoft.com  Tue May  6 12:06:54 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 6 May 2014 12:06:54 +0000
Subject: GHC rewrite rules and constructor wrappers?
In-Reply-To: <CAD6SzRLH7MJeo88CidK7NPXzrOHkSrz0r34a4V8dRW=MvoccmQ@mail.gmail.com>
References: <CAD6SzRLH7MJeo88CidK7NPXzrOHkSrz0r34a4V8dRW=MvoccmQ@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF0C0C8788@DB3PRD3001MB020.064d.mgd.msft.net>

Can you give an example?

Generally the wrapper does stuff like evaluating arguments for a strict constructor, and unboxing UNPACKed fields.  So if you have
            data T = MkT ! {-# UNPACK #-} Int

the wrapper looks something like this

            $WMkT x = case x of I# y -> MkT y

That is, it evaluates and unboxes the argument.   The source-language reference to MkT gets replaced with a call to the wrapper.

In a RULE suppose you write
            f (MkT x) = ?blah?
and have a call
            ?f (MkT e)?.

After replacing MkT by its wrapper call we?d have
            RULE  f ($WMkT x) = ...blah...
and      ....f ($WMkT e)....

Now if the wrapper for MkT is inlined, we?ll see (f (case e of ?)) which won?t match well!

At the moment, the very first run of the simplifier has almost all inlinings switched off, so the rule will indeed have a chance to fire.  But (a) I want to change the early simplifier run to do more inlining, and (b) in any case it all fails if you had, say
            ...f (h x)....
where
            h x = $WMkT e
Here you want h to inline, exposing the opportunity for the rule to fire.  I don?t know if this is the source of your problem, but it might be.

The usual solution to the interaction between RULES and inlining is to delay inlining until the rule has had a chance to fire. But in this case the inlining isn?t under your control: it?s the wrapper for MkT.

Something very similar happens for the wrappers after strictness analysis; if an (automatically generated, INLINE) wrapper is inlined too early, a rule might not fire.  The crude but effective solution for strictness wappers is to give them an INLINE[0] pragma; ie don?t inline till phase 0.  Maybe we should do the same for constructor wrappers.


That was probably more than you wanted to know.  Do send a concrete example.  Thanks


Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 29 April 2014 23:03
To: glasgow-haskell-users at haskell.org<mailto:glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: GHC rewrite rules and constructor wrappers?

I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like

> "reify/(:<)" reifyEP (:<) = kPrim VecSP

This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire.

Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC.
-- Conal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140506/cde29124/attachment.html>

From brandon.m.simmons at gmail.com  Thu May  8 23:18:48 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Thu, 8 May 2014 19:18:48 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
Message-ID: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>

I have an unusual application with some unusual performance problems
and I'm trying to understand how I might use unsafeFreezeArray to help
me, as well as understand in detail what's going on with boxed mutable
arrays and GC. I'm using the interface from 'primitive' below.

First some basic questions, then a bit more background

1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
>> return a` and then use `a`? What problems could that cause?

2) And what if a do a `cloneMutableArray` on `a` and likewise use the
resulting array?

Background: I've been looking into an issue [1] in a library in which
as more mutable arrays are allocated, GC dominates (I think I verified
this?) and all code gets slower in proportion to the number of mutable
arrays that are hanging around.

I've been trying to understand how this is working internally. I don't
quite understand how the "remembered set" works with respect to
MutableArray. As best I understand: the remembered set in generation G
points to certain objects in older generations, which objects hold
references to objects in G. Then for MutableArrays specifically,
card-marking is used to mark regions of the array with garbage in some
way.

So my hypothesis is the slowdown is associated with the size of the
remembered set, and whatever the GC has to do on it. And in my tests,
freezing the array seems to make that overhead (at least the overhead
proportional to number of arrays) disappear.

Now I'm really lost in the woods though. My hope is that I might be
able to safely use unsafeFreezeArray to help me here [3]. Here are the
particulars of how I use MutableArray in my algorithm, which are
somewhat unusual:
  - keep around a small template `MutableArray Nothing`
  - use cloneMutableArray for fast allocation of new arrays
  - for each array only a *single* write (CAS actually) happens at each position

In fact as far as I can reason, there ought to be no garbage to
collect at all until the entire array becomes garbage (the initial
value is surely shared, especially since I'm keeping this template
array around to clone from, right?). In fact I was even playing with
the idea of rolling a new CAS that skips the card-marking stuff.

Any guidance is appreciated.

Thanks,
Brandon


[1]: http://stackoverflow.com/questions/23462004/code-becomes-slower-as-more-boxed-arrays-are-allocated
[2]: http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022142.html
[3]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/EagerPromotion

From brandon.m.simmons at gmail.com  Fri May  9 18:21:22 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Fri, 9 May 2014 14:21:22 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
Message-ID: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>

A couple of updates: Edward Yang responded here, confirming the sort
of track I was thinking on:

  http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/

And I can report that:
  1) cloning a frozen array doesn't provide the benefits of creating a
new array and freezing
  2) and anyway, I'm seeing some segfaults when cloning, freezing,
reading then writing in my library

I'd love to learn if there are any other approaches I might take, e.g.
maybe with my own CMM primop variants?

Thanks,
Brandon

From ezyang at mit.edu  Fri May  9 06:06:45 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 08 May 2014 23:06:45 -0700
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
Message-ID: <1399613912-sup-4255@sabre>

Hello Brandon,

Excerpts from Brandon Simmons's message of 2014-05-08 16:18:48 -0700:
> I have an unusual application with some unusual performance problems
> and I'm trying to understand how I might use unsafeFreezeArray to help
> me, as well as understand in detail what's going on with boxed mutable
> arrays and GC. I'm using the interface from 'primitive' below.
> 
> First some basic questions, then a bit more background
> 
> 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
> >> return a` and then use `a`? What problems could that cause?

Your code as written wouldn't compile, but assuming you're talking about
the primops newArray# and unsafeFreezeArray#, what this operation does
is allocate a new array of pointers (initially recorded as mutable), and
then freezes it in-place (by changing the info-table associated with
it), but while maintaining a pointer to the original mutable array.  Nothing bad
will happen immediately, but if you use this mutable reference to mutate
the pointer array, you can cause a crash (in particular, if the array
makes it to the old generation, it will not be on the mutable list and
so if you mutate it, you may be missing roots.)

> 2) And what if a do a `cloneMutableArray` on `a` and likewise use the
> resulting array?

If you do the clone before freezing, that's fine for all use-cases;
if you do the clone after, you will end up with the same result as (1).

> Background: I've been looking into an issue [1] in a library in which
> as more mutable arrays are allocated, GC dominates (I think I verified
> this?) and all code gets slower in proportion to the number of mutable
> arrays that are hanging around.
> 
> I've been trying to understand how this is working internally. I don't
> quite understand how the "remembered set" works with respect to
> MutableArray. As best I understand: the remembered set in generation G
> points to certain objects in older generations, which objects hold
> references to objects in G. Then for MutableArrays specifically,
> card-marking is used to mark regions of the array with garbage in some
> way.
> 
> So my hypothesis is the slowdown is associated with the size of the
> remembered set, and whatever the GC has to do on it. And in my tests,
> freezing the array seems to make that overhead (at least the overhead
> proportional to number of arrays) disappear.

You're basically correct.  In the current GC design, mutable arrays of
pointers are always placed on the mutable list.  The mutable list of
generations which are not being collected are always traversed; thus,
the number of pointer arrays corresponds to a linear overhead for minor GCs.

Here is a feature request tracking many of the infelicities that our
current GC design has:  https://ghc.haskell.org/trac/ghc/ticket/7662
The upshot is that the Haskell GC is very nicely tuned for mostly
immutable workloads, but there are some bad asymptotics when your
heap has lots of mutable objects.  This is generally a hard problem:
tuned GC implementations for mutable languages are a lot of work!
(Just ask the JVM implementors.)

> Now I'm really lost in the woods though. My hope is that I might be
> able to safely use unsafeFreezeArray to help me here [3]. Here are the
> particulars of how I use MutableArray in my algorithm, which are
> somewhat unusual:
>   - keep around a small template `MutableArray Nothing`
>   - use cloneMutableArray for fast allocation of new arrays
>   - for each array only a *single* write (CAS actually) happens at each position
> 
> In fact as far as I can reason, there ought to be no garbage to
> collect at all until the entire array becomes garbage (the initial
> value is surely shared, especially since I'm keeping this template
> array around to clone from, right?). In fact I was even playing with
> the idea of rolling a new CAS that skips the card-marking stuff.

I don't understand your full workload, but if you have a workload that
involves creating an array, mutating it over a short period of time,
and then never mutating it afterwards, you should simply freeze it after
you are done writing it.  Once frozen, the array will no longer be kept
on the mutable list and you won't pay for it when doing GC.  However,
the fact that you are doing a CAS makes it seem to me that your workflow
may be more complicated than that...

Cheers,
Edward

From brandon.m.simmons at gmail.com  Fri May  9 23:25:52 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Fri, 9 May 2014 19:25:52 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <1399613912-sup-4255@sabre>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
Message-ID: <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>

On May 9, 2014 5:13 PM, "Edward Z. Yang" <ezyang at mit.edu> wrote:
>
> Hello Brandon,
>
> Excerpts from Brandon Simmons's message of 2014-05-08 16:18:48 -0700:
> > I have an unusual application with some unusual performance problems
> > and I'm trying to understand how I might use unsafeFreezeArray to help
> > me, as well as understand in detail what's going on with boxed mutable
> > arrays and GC. I'm using the interface from 'primitive' below.
> >
> > First some basic questions, then a bit more background
> >
> > 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
> > >> return a` and then use `a`? What problems could that cause?
>
> Your code as written wouldn't compile, but assuming you're talking about
> the primops newArray# and unsafeFreezeArray#, what this operation does
> is allocate a new array of pointers (initially recorded as mutable), and
> then freezes it in-place (by changing the info-table associated with
> it), but while maintaining a pointer to the original mutable array.
 Nothing bad
> will happen immediately, but if you use this mutable reference to mutate
> the pointer array, you can cause a crash (in particular, if the array
> makes it to the old generation, it will not be on the mutable list and
> so if you mutate it, you may be missing roots.)
>
> > 2) And what if a do a `cloneMutableArray` on `a` and likewise use the
> > resulting array?
>
> If you do the clone before freezing, that's fine for all use-cases;
> if you do the clone after, you will end up with the same result as (1).
>
> > Background: I've been looking into an issue [1] in a library in which
> > as more mutable arrays are allocated, GC dominates (I think I verified
> > this?) and all code gets slower in proportion to the number of mutable
> > arrays that are hanging around.
> >
> > I've been trying to understand how this is working internally. I don't
> > quite understand how the "remembered set" works with respect to
> > MutableArray. As best I understand: the remembered set in generation G
> > points to certain objects in older generations, which objects hold
> > references to objects in G. Then for MutableArrays specifically,
> > card-marking is used to mark regions of the array with garbage in some
> > way.
> >
> > So my hypothesis is the slowdown is associated with the size of the
> > remembered set, and whatever the GC has to do on it. And in my tests,
> > freezing the array seems to make that overhead (at least the overhead
> > proportional to number of arrays) disappear.
>
> You're basically correct.  In the current GC design, mutable arrays of
> pointers are always placed on the mutable list.  The mutable list of
> generations which are not being collected are always traversed; thus,
> the number of pointer arrays corresponds to a linear overhead for minor
GCs.
>
> Here is a feature request tracking many of the infelicities that our
> current GC design has:  https://ghc.haskell.org/trac/ghc/ticket/7662
> The upshot is that the Haskell GC is very nicely tuned for mostly
> immutable workloads, but there are some bad asymptotics when your
> heap has lots of mutable objects.  This is generally a hard problem:
> tuned GC implementations for mutable languages are a lot of work!
> (Just ask the JVM implementors.)
>

Very helpful, thanks! And take some internet points.

> > Now I'm really lost in the woods though. My hope is that I might be
> > able to safely use unsafeFreezeArray to help me here [3]. Here are the
> > particulars of how I use MutableArray in my algorithm, which are
> > somewhat unusual:
> >   - keep around a small template `MutableArray Nothing`
> >   - use cloneMutableArray for fast allocation of new arrays
> >   - for each array only a *single* write (CAS actually) happens at each
position
> >
> > In fact as far as I can reason, there ought to be no garbage to
> > collect at all until the entire array becomes garbage (the initial
> > value is surely shared, especially since I'm keeping this template
> > array around to clone from, right?). In fact I was even playing with
> > the idea of rolling a new CAS that skips the card-marking stuff.
>
> I don't understand your full workload, but if you have a workload that
> involves creating an array, mutating it over a short period of time,
> and then never mutating it afterwards, you should simply freeze it after
> you are done writing it.  Once frozen, the array will no longer be kept
> on the mutable list and you won't pay for it when doing GC.  However,
> the fact that you are doing a CAS makes it seem to me that your workflow
> may be more complicated than that...

Yes I think for my use case the overhead required to determine when the
array can be frozen would not be worth it. I think I have some other knobs
I can twist here.

I'll keep an eye on that ticket and maybe chime in if I have any ideas.

Thanks,
Brandon

>
> Cheers,
> Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140509/7c6a7ea7/attachment.html>

From carter.schonwald at gmail.com  Fri May  9 23:49:07 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 9 May 2014 19:49:07 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
Message-ID: <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>

Any chance you could try to use storable or unboxed vectors?

On Friday, May 9, 2014, Brandon Simmons <brandon.m.simmons at gmail.com> wrote:

>
> On May 9, 2014 5:13 PM, "Edward Z. Yang" <ezyang at mit.edu<javascript:_e(%7B%7D,'cvml','ezyang at mit.edu');>>
> wrote:
> >
> > Hello Brandon,
> >
> > Excerpts from Brandon Simmons's message of 2014-05-08 16:18:48 -0700:
> > > I have an unusual application with some unusual performance problems
> > > and I'm trying to understand how I might use unsafeFreezeArray to help
> > > me, as well as understand in detail what's going on with boxed mutable
> > > arrays and GC. I'm using the interface from 'primitive' below.
> > >
> > > First some basic questions, then a bit more background
> > >
> > > 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
> > > >> return a` and then use `a`? What problems could that cause?
> >
> > Your code as written wouldn't compile, but assuming you're talking about
> > the primops newArray# and unsafeFreezeArray#, what this operation does
> > is allocate a new array of pointers (initially recorded as mutable), and
> > then freezes it in-place (by changing the info-table associated with
> > it), but while maintaining a pointer to the original mutable array.
>  Nothing bad
> > will happen immediately, but if you use this mutable reference to mutate
> > the pointer array, you can cause a crash (in particular, if the array
> > makes it to the old generation, it will not be on the mutable list and
> > so if you mutate it, you may be missing roots.)
> >
> > > 2) And what if a do a `cloneMutableArray` on `a` and likewise use the
> > > resulting array?
> >
> > If you do the clone before freezing, that's fine for all use-cases;
> > if you do the clone after, you will end up with the same result as (1).
> >
> > > Background: I've been looking into an issue [1] in a library in which
> > > as more mutable arrays are allocated, GC dominates (I think I verified
> > > this?) and all code gets slower in proportion to the number of mutable
> > > arrays that are hanging around.
> > >
> > > I've been trying to understand how this is working internally. I don't
> > > quite understand how the "remembered set" works with respect to
> > > MutableArray. As best I understand: the remembered set in generation G
> > > points to certain objects in older generations, which objects hold
> > > references to objects in G. Then for MutableArrays specifically,
> > > card-marking is used to mark regions of the array with garbage in some
> > > way.
> > >
> > > So my hypothesis is the slowdown is associated with the size of the
> > > remembered set, and whatever the GC has to do on it. And in my tests,
> > > freezing the array seems to make that overhead (at least the overhead
> > > proportional to number of arrays) disappear.
> >
> > You're basically correct.  In the current GC design, mutable arrays of
> > pointers are always placed on the mutable list.  The mutable list of
> > generations which are not being collected are always traversed; thus,
> > the number of pointer arrays corresponds to a linear overhead for minor
> GCs.
> >
> > Here is a feature request tracking many of the infelicities that our
> > current GC design has:  https://ghc.haskell.org/trac/ghc/ticket/7662
> > The upshot is that the Haskell GC is very nicely tuned for mostly
> > immutable workloads, but there are some bad asymptotics when your
> > heap has lots of mutable objects.  This is generally a hard problem:
> > tuned GC implementations for mutable languages are a lot of work!
> > (Just ask the JVM implementors.)
> >
>
> Very helpful, thanks! And take some internet points.
>
> > > Now I'm really lost in the woods though. My hope is that I might be
> > > able to safely use unsafeFreezeArray to help me here [3]. Here are the
> > > particulars of how I use MutableArray in my algorithm, which are
> > > somewhat unusual:
> > >   - keep around a small template `MutableArray Nothing`
> > >   - use cloneMutableArray for fast allocation of new arrays
> > >   - for each array only a *single* write (CAS actually) happens at
> each position
> > >
> > > In fact as far as I can reason, there ought to be no garbage to
> > > collect at all until the entire array becomes garbage (the initial
> > > value is surely shared, especially since I'm keeping this template
> > > array around to clone from, right?). In fact I was even playing with
> > > the idea of rolling a new CAS that skips the card-marking stuff.
> >
> > I don't understand your full workload, but if you have a workload that
> > involves creating an array, mutating it over a short period of time,
> > and then never mutating it afterwards, you should simply freeze it after
> > you are done writing it.  Once frozen, the array will no longer be kept
> > on the mutable list and you won't pay for it when doing GC.  However,
> > the fact that you are doing a CAS makes it seem to me that your workflow
> > may be more complicated than that...
>
> Yes I think for my use case the overhead required to determine when the
> array can be frozen would not be worth it. I think I have some other knobs
> I can twist here.
>
> I'll keep an eye on that ticket and maybe chime in if I have any ideas.
>
> Thanks,
> Brandon
>
> >
> > Cheers,
> > Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140509/32360768/attachment-0001.html>

From ezyang at mit.edu  Fri May  9 23:55:24 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 09 May 2014 16:55:24 -0700
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
 <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
Message-ID: <1399679707-sup-2949@sabre>

Excerpts from Carter Schonwald's message of 2014-05-09 16:49:07 -0700:
> Any chance you could try to use storable or unboxed vectors?

Neither of those will work if, at the end of the day, you need to
store pointers to heap objects

Edward

From carter.schonwald at gmail.com  Sat May 10 01:34:20 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 9 May 2014 21:34:20 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <1399679707-sup-2949@sabre>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
 <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
 <1399679707-sup-2949@sabre>
Message-ID: <CAHYVw0weqg9zZADvS2zbkBQLrXjWiE_G2n5123=tj958rxdE3A@mail.gmail.com>

true enough


On Fri, May 9, 2014 at 7:55 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Excerpts from Carter Schonwald's message of 2014-05-09 16:49:07 -0700:
> > Any chance you could try to use storable or unboxed vectors?
>
> Neither of those will work if, at the end of the day, you need to
> store pointers to heap objects
>
> Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140509/254d6b36/attachment.html>

From brandon.m.simmons at gmail.com  Sat May 10 18:47:51 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Sat, 10 May 2014 14:47:51 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
 <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
Message-ID: <CAAyGGy=AJKTCpnHeUkCRB1E6F8gRYiHt5_+Wn6Fy8nPT8zUc-w@mail.gmail.com>

On Fri, May 9, 2014 at 7:49 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Any chance you could try to use storable or unboxed vectors?
>

Yeah, I'd thought about a variant for Storables, but it didn't seem
like it would be a win on paper (probably requiring a CAS on one
unboxed array, a loadLoadBarrier, and a second write to a different
unboxed array), but it would probably be worth playing with in light
of this issue. Thanks for the suggestion!

Brandon

From brandon.m.simmons at gmail.com  Sat May 10 18:52:47 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Sat, 10 May 2014 14:52:47 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGy=AJKTCpnHeUkCRB1E6F8gRYiHt5_+Wn6Fy8nPT8zUc-w@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGy=Jn4bPjDi0nqZE0-ZCCwADLK+j7V=t+4xjTisTcgDZ+A@mail.gmail.com>
 <CAHYVw0y4eVku80Zr3O=tfdro3BH-fm1qpMScTxzBZUdqnLojsw@mail.gmail.com>
 <CAAyGGy=AJKTCpnHeUkCRB1E6F8gRYiHt5_+Wn6Fy8nPT8zUc-w@mail.gmail.com>
Message-ID: <CAAyGGymO3zgeWBqUWB-h6rzSOzfP+suu7ER3WSwhyAiALLu4LA@mail.gmail.com>

On Sat, May 10, 2014 at 2:47 PM, Brandon Simmons
<brandon.m.simmons at gmail.com> wrote:
> On Fri, May 9, 2014 at 7:49 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>> Any chance you could try to use storable or unboxed vectors?
>>
>
> Yeah, I'd thought about a variant for Storables, but it didn't seem
> like it would be a win on paper (probably requiring a CAS on one
> unboxed array, a loadLoadBarrier, and a second write to a different

Sorry s/loadLoadBarrier/writeBarrier/  i.e. write_barrier() from SMP.h

By the way, I'm playing with concurrent FIFO queue designs, I realized
I haven't mentioned!

> unboxed array), but it would probably be worth playing with in light
> of this issue. Thanks for the suggestion!
>
> Brandon

From brandon.m.simmons at gmail.com  Sat May 10 20:57:40 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Sat, 10 May 2014 16:57:40 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <1399613912-sup-4255@sabre>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
Message-ID: <CAAyGGyk2p2Ujyuvf32fCfGs_GRXW_mPPr_8VduHQPdXoziFqxA@mail.gmail.com>

On Fri, May 9, 2014 at 2:06 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hello Brandon,
>
> Excerpts from Brandon Simmons's message of 2014-05-08 16:18:48 -0700:
>> I have an unusual application with some unusual performance problems
>> and I'm trying to understand how I might use unsafeFreezeArray to help
>> me, as well as understand in detail what's going on with boxed mutable
>> arrays and GC. I'm using the interface from 'primitive' below.
>>
>> First some basic questions, then a bit more background
>>
>> 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
>> >> return a` and then use `a`? What problems could that cause?
>
> Your code as written wouldn't compile, but assuming you're talking about
> the primops newArray# and unsafeFreezeArray#, what this operation does
> is allocate a new array of pointers (initially recorded as mutable), and
> then freezes it in-place (by changing the info-table associated with
> it), but while maintaining a pointer to the original mutable array.  Nothing bad
> will happen immediately, but if you use this mutable reference to mutate
> the pointer array, you can cause a crash (in particular, if the array
> makes it to the old generation, it will not be on the mutable list and
> so if you mutate it, you may be missing roots.)
>
>> 2) And what if a do a `cloneMutableArray` on `a` and likewise use the
>> resulting array?
>
> If you do the clone before freezing, that's fine for all use-cases;
> if you do the clone after, you will end up with the same result as (1).
>
>> Background: I've been looking into an issue [1] in a library in which
>> as more mutable arrays are allocated, GC dominates (I think I verified
>> this?) and all code gets slower in proportion to the number of mutable
>> arrays that are hanging around.
>>
>> I've been trying to understand how this is working internally. I don't
>> quite understand how the "remembered set" works with respect to
>> MutableArray. As best I understand: the remembered set in generation G
>> points to certain objects in older generations, which objects hold
>> references to objects in G. Then for MutableArrays specifically,
>> card-marking is used to mark regions of the array with garbage in some
>> way.
>>
>> So my hypothesis is the slowdown is associated with the size of the
>> remembered set, and whatever the GC has to do on it. And in my tests,
>> freezing the array seems to make that overhead (at least the overhead
>> proportional to number of arrays) disappear.
>
> You're basically correct.  In the current GC design, mutable arrays of
> pointers are always placed on the mutable list.  The mutable list of
> generations which are not being collected are always traversed; thus,
> the number of pointer arrays corresponds to a linear overhead for minor GCs.
>
> Here is a feature request tracking many of the infelicities that our
> current GC design has:  https://ghc.haskell.org/trac/ghc/ticket/7662
> The upshot is that the Haskell GC is very nicely tuned for mostly
> immutable workloads, but there are some bad asymptotics when your
> heap has lots of mutable objects.  This is generally a hard problem:
> tuned GC implementations for mutable languages are a lot of work!
> (Just ask the JVM implementors.)
>
>> Now I'm really lost in the woods though. My hope is that I might be
>> able to safely use unsafeFreezeArray to help me here [3]. Here are the
>> particulars of how I use MutableArray in my algorithm, which are
>> somewhat unusual:
>>   - keep around a small template `MutableArray Nothing`
>>   - use cloneMutableArray for fast allocation of new arrays
>>   - for each array only a *single* write (CAS actually) happens at each position
>>
>> In fact as far as I can reason, there ought to be no garbage to
>> collect at all until the entire array becomes garbage (the initial
>> value is surely shared, especially since I'm keeping this template
>> array around to clone from, right?). In fact I was even playing with
>> the idea of rolling a new CAS that skips the card-marking stuff.
>
> I don't understand your full workload, but if you have a workload that
> involves creating an array, mutating it over a short period of time,
> and then never mutating it afterwards, you should simply freeze it after
> you are done writing it.  Once frozen, the array will no longer be kept
> on the mutable list and you won't pay for it when doing GC.  However,
> the fact that you are doing a CAS makes it seem to me that your workflow
> may be more complicated than that...
>
> Cheers,
> Edward

Another silly question: when card-marking happens after a write or
CAS, does that indicate "this segment maybe contains old-to-new
generation references, so be sure to preserve (scavenge?) them from
collection "? In my initial question I was thinking of the cards as
indicating "here be garbage" (e.g. a previous overwritten array
value), but I think I had the wrong idea about how copying GC works
generally (shouldn't it really be called Non-Garbage Preservation?).

Thanks again,
Brandon

From strake888 at gmail.com  Sun May 11 02:17:17 2014
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 10 May 2014 21:17:17 -0500
Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
In-Reply-To: <CAL3m8eANonQkaCSrBNf1ZFrxi7-hyF-DYNzdpr=4G=o1tysGWA@mail.gmail.com>
References: <CAL3m8eANonQkaCSrBNf1ZFrxi7-hyF-DYNzdpr=4G=o1tysGWA@mail.gmail.com>
Message-ID: <CAL3m8eDU=Emjh6JAWGZc+ntuXeEe3JixYih=Bys30CVKwxXPww@mail.gmail.com>

I rebuilt ghc with clang and gcc; same problem.

It works if I add memcpy et al. to libraries/ghc-prim/cbits, but that
seems a bad method, as they're available in libc.

It seems that I must somehow tell GHC to pull in libc whenever it
links against ghc-prim, or to include all needed code from libc in
HSghc-prim-0.3.1.0.o. How can I do so? I tried "extra-libraries: c" in
ghc-prim.cabal, which fails perplexively, with addDLL: unknown error,
tho I disabled building dynamic libraries.

From marlowsd at gmail.com  Mon May 12 08:29:17 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 12 May 2014 09:29:17 +0100
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGyk2p2Ujyuvf32fCfGs_GRXW_mPPr_8VduHQPdXoziFqxA@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGyk2p2Ujyuvf32fCfGs_GRXW_mPPr_8VduHQPdXoziFqxA@mail.gmail.com>
Message-ID: <5370865D.6010406@gmail.com>

On 10/05/2014 21:57, Brandon Simmons wrote:
> Another silly question: when card-marking happens after a write or
> CAS, does that indicate "this segment maybe contains old-to-new
> generation references, so be sure to preserve (scavenge?) them from
> collection "?

Yes, that's exactly right.

Cheers,
Simon

From marlowsd at gmail.com  Mon May 12 08:32:30 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 12 May 2014 09:32:30 +0100
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
Message-ID: <5370871E.8020900@gmail.com>

On 09/05/2014 19:21, Brandon Simmons wrote:
> A couple of updates: Edward Yang responded here, confirming the sort
> of track I was thinking on:
>
>    http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/
>
> And I can report that:
>    1) cloning a frozen array doesn't provide the benefits of creating a
> new array and freezing
>    2) and anyway, I'm seeing some segfaults when cloning, freezing,
> reading then writing in my library
>
> I'd love to learn if there are any other approaches I might take, e.g.
> maybe with my own CMM primop variants?

I'm not sure exactly what your workload looks like, but if you have 
arrays that tend to be unmodified for long periods of time it's 
sometimes useful to keep them frozen but thaw before mutating.

How large are your arrays? Perhaps the new small array type (in HEAD but 
not 7.8) would help?

Cheers,
Simon

From brandon.m.simmons at gmail.com  Mon May 12 20:28:31 2014
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Mon, 12 May 2014 16:28:31 -0400
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <5370871E.8020900@gmail.com>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
Message-ID: <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>

On Mon, May 12, 2014 at 4:32 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 09/05/2014 19:21, Brandon Simmons wrote:
>>
>> A couple of updates: Edward Yang responded here, confirming the sort
>> of track I was thinking on:
>>
>>
>> http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/
>>
>> And I can report that:
>>    1) cloning a frozen array doesn't provide the benefits of creating a
>> new array and freezing
>>    2) and anyway, I'm seeing some segfaults when cloning, freezing,
>> reading then writing in my library
>>
>> I'd love to learn if there are any other approaches I might take, e.g.
>> maybe with my own CMM primop variants?
>
>
> I'm not sure exactly what your workload looks like, but if you have arrays
> that tend to be unmodified for long periods of time it's sometimes useful to
> keep them frozen but thaw before mutating.

The idea is I'm using two atomic counters to coordinate concurrent
readers and writers along an "infinite array" (a linked list of array
segments that get allocated as needed and garbage collected as we go).
So currently each cell in each array is written to only once, with a
CAS.

>
> How large are your arrays? Perhaps the new small array type (in HEAD but not
> 7.8) would help?

Thanks, maybe so! The arrays can be any size, but probably not smaller
than length 64 (this will be static, at compile-time).

I read through https://ghc.haskell.org/trac/ghc/ticket/5925, and it
seems like the idea is to improve array creation. I'm pretty happy
with the speed of cloning an array (but maybe cloneSmallArray will be
even faster still).

It also looks like stg_casSmallArrayzh (in PrimOps.cmm) omits the card
marking (maybe the idea is if the array is already at ~128 elements or
less, then the card-marking is all just overhead?).

Brandon

>
> Cheers,
> Simon

From ezyang at mit.edu  Sun May 11 00:28:19 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 10 May 2014 17:28:19 -0700
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGyk2p2Ujyuvf32fCfGs_GRXW_mPPr_8VduHQPdXoziFqxA@mail.gmail.com>
References: <CAAyGGykKSThzEdpemdMMXLWn9kEj827FmyqbaAsZRcXucBxkMw@mail.gmail.com>
 <1399613912-sup-4255@sabre>
 <CAAyGGyk2p2Ujyuvf32fCfGs_GRXW_mPPr_8VduHQPdXoziFqxA@mail.gmail.com>
Message-ID: <1399768045-sup-813@sabre>

Excerpts from Brandon Simmons's message of 2014-05-10 13:57:40 -0700:
> Another silly question: when card-marking happens after a write or
> CAS, does that indicate "this segment maybe contains old-to-new
> generation references, so be sure to preserve (scavenge?) them from
> collection "? In my initial question I was thinking of the cards as
> indicating "here be garbage" (e.g. a previous overwritten array
> value), but I think I had the wrong idea about how copying GC works
> generally (shouldn't it really be called Non-Garbage Preservation?).

That's correct.

Cheers,
Edward

From marlowsd at gmail.com  Tue May 13 11:01:28 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 13 May 2014 12:01:28 +0100
Subject: Using mutable array after an unsafeFreezeArray, and GC details
In-Reply-To: <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
 <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
Message-ID: <5371FB88.9070805@gmail.com>

On 12/05/2014 21:28, Brandon Simmons wrote:
> The idea is I'm using two atomic counters to coordinate concurrent
> readers and writers along an "infinite array" (a linked list of array
> segments that get allocated as needed and garbage collected as we go).
> So currently each cell in each array is written to only once, with a
> CAS.

Certainly you should freeze arrays when you're done writing to them, 
this will help the GC a lot.

>> How large are your arrays? Perhaps the new small array type (in HEAD but not
>> 7.8) would help?
>
> Thanks, maybe so! The arrays can be any size, but probably not smaller
> than length 64 (this will be static, at compile-time).
>
> I read through https://ghc.haskell.org/trac/ghc/ticket/5925, and it
> seems like the idea is to improve array creation. I'm pretty happy
> with the speed of cloning an array (but maybe cloneSmallArray will be
> even faster still).
>
> It also looks like stg_casSmallArrayzh (in PrimOps.cmm) omits the card
> marking (maybe the idea is if the array is already at ~128 elements or
> less, then the card-marking is all just overhead?).

That right, the cards currently cover 128 elements, and there's also a 
per-array dirty bit, so the card table in an array smaller than 128 elts 
is just overhead.

Cheers,
Simon

From john at repetae.net  Tue May 13 14:04:36 2014
From: john at repetae.net (John Meacham)
Date: Tue, 13 May 2014 07:04:36 -0700
Subject: AlternateLayoutRule
Message-ID: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>

Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
having trouble finding information about it. Is it based on my
proposal and sample implementation?
http://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html

https://ghc.haskell.org/trac/haskell-prime/wiki/AlternativeLayoutRule
implies it has been in use since 6.13. If that is the case, I assume
it has been found stable?

I ask because I was going to rewrite the jhc lexer and would like to
use the new mechanism in a way that is compatible with ghc. If it is
already using my code, so much the better.

    John

-- 
John Meacham - http://notanumber.net/

From doaitse at swierstra.net  Tue May 13 18:20:01 2014
From: doaitse at swierstra.net (S. Doaitse Swierstra)
Date: Tue, 13 May 2014 15:20:01 -0300
Subject: question about GADT's and error messages
In-Reply-To: <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
 <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
Message-ID: <74A2AA2D-CA40-491B-9855-E73A2BB413EB@swierstra.net>

Given the following code:

{-# LANGUAGE GADTs #-}
data Any a where
AInt :: Int -> Any Int

-- demo 1 does not compile
{-
demo1 a = do case a of
            (AInt i) -> print i

 Couldn't match expected type ?t? with actual type ?IO ()?
   ?t? is untouchable
     inside the constraints (t1 ~ Int)
     bound by a pattern with constructor
                AInt :: Int -> Any Int,
              in a case alternative
     at /Users/doaitse/TryHaskell/TestGADT.hs:6:17-22
   ?t? is a rigid type variable bound by
       the inferred type of demo1 :: Any t1 -> t
       at /Users/doaitse/TryHaskell/TestGADT.hs:5:1
 Relevant bindings include
   demo1 :: Any t1 -> t
     (bound at /Users/doaitse/TryHaskell/TestGADT.hs:5:1)
 In the expression: print i
 In a case alternative: (AInt i) -> print i
Failed, modules loaded: none.
-}


-- all the following go through without complaints:

a = AInt 3
demo2 = do case a of
            (AInt i) -> print i

demo3 :: IO ()
demo3 = do case a of
            (AInt i) -> print i


demo4 = do case AInt 3 of
            (AInt i) -> print i

demo5 :: Any Int -> IO ()
demo5 a = do case a of
            (AInt i) -> print i

I do not see why the error message in demo1 arises. It claims it can't match some t with the type IO (), but when I tell that the result is IO () it can?
I think at least the error message is confusing, and not very helpful. I would have in no way been able to get the clue that add a type signature as in the case of demo5 would solve the problem.

What am I overlooking?

Doaitse



From marlowsd at gmail.com  Tue May 13 20:32:31 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 13 May 2014 21:32:31 +0100
Subject: AlternateLayoutRule
In-Reply-To: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
Message-ID: <5372815F.40807@gmail.com>

On 13/05/14 15:04, John Meacham wrote:
> Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
> having trouble finding information about it. Is it based on my
> proposal and sample implementation?
> http://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html

Yes it is, but I think we had to flesh it out with a few more cases. 
Ian will know more, he implemented it in GHC.

It has never been the default implementation, because it wasn't possible 
to cover 100% of the strange ways that code in the wild currently relies 
on the parse-error behaviour in the layout rule.  You can get it with 
-XAlternateLayoutRule though.

I'm not sure what we should do about it.  I think Ian's motivation was 
to experiment with a view to proposing it as a replacement for the 
layout rule in Haskell', but (and this is my opinion) I think it ends up 
not being as clean as we might have hoped, and the cases where it 
doesn't work in the same way as the old rule aren't easily explainable 
to people.

On the other hand, we did find a nice use for it in GHC: the multiline 
parser in GHCi can tell whether you've finished typing a complete 
expression using the alternate layout rule.

Cheers,
Simon

> https://ghc.haskell.org/trac/haskell-prime/wiki/AlternativeLayoutRule
> implies it has been in use since 6.13. If that is the case, I assume
> it has been found stable?
>
> I ask because I was going to rewrite the jhc lexer and would like to
> use the new mechanism in a way that is compatible with ghc. If it is
> already using my code, so much the better.

From igloo at earth.li  Tue May 13 21:22:23 2014
From: igloo at earth.li (Ian Lynagh)
Date: Tue, 13 May 2014 22:22:23 +0100
Subject: AlternateLayoutRule
In-Reply-To: <5372815F.40807@gmail.com>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com>
Message-ID: <20140513212223.GA4774@matrix.chaos.earth.li>

On Tue, May 13, 2014 at 09:32:31PM +0100, Simon Marlow wrote:
> On 13/05/14 15:04, John Meacham wrote:
> >Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
> >having trouble finding information about it. Is it based on my
> >proposal and sample implementation?
> >http://www.mail-archive.com/haskell-prime at haskell.org/msg01938.html
> 
> Yes it is, but I think we had to flesh it out with a few more cases.
> Ian will know more, he implemented it in GHC.
> 
> I'm not sure what we should do about it.  I think Ian's motivation
> was to experiment with a view to proposing it as a replacement for
> the layout rule in Haskell', but (and this is my opinion) I think it
> ends up not being as clean as we might have hoped, and the cases
> where it doesn't work in the same way as the old rule aren't easily
> explainable to people.
> >
> >I ask because I was going to rewrite the jhc lexer and would like to
> >use the new mechanism in a way that is compatible with ghc. If it is
> >already using my code, so much the better.

It's based on your code, but I had to essentially completely re-write it
to work with the way that GHC's parser works; I don't think sharing the
code will be feasible.

I also fixed some bugs (e.g. I think that with your code,
    foo = let { x = x }
          in x
turns into something like
    foo = let { x = x }
          } in x
) and made some tweaks after trying it on GHC+bootlibs, but I don't have
details to hand.

However, the consensus was that the new rule has too many cases, due to
trying to match the old rule as closely as possible, and despite that it
doesn't have the advantage that it is a drop-in replacement. ISTR Cabal
in particular needed several changes to compile with it
(0aba7b9f2e5d8acea156d575184a4a63af0a1ed3). Most of them were code of
the form
    case e of
    p -> e'
    where bs
needing the 'where' clause to be less indented.

The plan, yet to be implemented, was to remove some of the cases of the
new rule, making it easier to understand, specify and implement, at the
expense of breaking more code when the switch is flipped.

Ideally, there would be a period during which compilers would check
during compilation whether the new rule would give a different token
sequence to the old rule, and warn if so.


Thanks
Ian


From wagnerdm at seas.upenn.edu  Tue May 13 21:28:39 2014
From: wagnerdm at seas.upenn.edu (Daniel Wagner)
Date: Tue, 13 May 2014 17:28:39 -0400
Subject: question about GADT's and error messages
In-Reply-To: <74A2AA2D-CA40-491B-9855-E73A2BB413EB@swierstra.net>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
 <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
 <74A2AA2D-CA40-491B-9855-E73A2BB413EB@swierstra.net>
Message-ID: <25b72ac14d786f0e9432661b3f2fe771@seas.upenn.edu>

I just hit a similar error the other day. I think the gist of it is that 
there are two perfectly good types, and neither is more general than the 
other. A slightly different example shows why more clearly:

foo (AInt i) = (3 :: Int)

Now, what type should this have?

foo :: Any a -> a
foo :: Any a -> Int

both seem pretty good, and neither is clearly better. It's not *as* 
obvious what the two candidates might be for your example, but maybe you 
could imagine something like these two types:

demo1 :: AInt a -> IO ()
type family Foo a
type instance Foo Int = IO ()
demo1 :: AInt a -> Foo a

Again, not too clear that one is better, I think.
~d

On 2014-05-13 14:20, S. Doaitse Swierstra wrote:
> Given the following code:
> 
> {-# LANGUAGE GADTs #-}
> data Any a where
> AInt :: Int -> Any Int
> 
> -- demo 1 does not compile
> {-
> demo1 a = do case a of
>             (AInt i) -> print i
> 
>  Couldn't match expected type ?t? with actual type ?IO ()?
>    ?t? is untouchable
>      inside the constraints (t1 ~ Int)
>      bound by a pattern with constructor
>                 AInt :: Int -> Any Int,
>               in a case alternative
>      at /Users/doaitse/TryHaskell/TestGADT.hs:6:17-22
>    ?t? is a rigid type variable bound by
>        the inferred type of demo1 :: Any t1 -> t
>        at /Users/doaitse/TryHaskell/TestGADT.hs:5:1
>  Relevant bindings include
>    demo1 :: Any t1 -> t
>      (bound at /Users/doaitse/TryHaskell/TestGADT.hs:5:1)
>  In the expression: print i
>  In a case alternative: (AInt i) -> print i
> Failed, modules loaded: none.
> -}
> 
> 
> -- all the following go through without complaints:
> 
> a = AInt 3
> demo2 = do case a of
>             (AInt i) -> print i
> 
> demo3 :: IO ()
> demo3 = do case a of
>             (AInt i) -> print i
> 
> 
> demo4 = do case AInt 3 of
>             (AInt i) -> print i
> 
> demo5 :: Any Int -> IO ()
> demo5 a = do case a of
>             (AInt i) -> print i
> 
> I do not see why the error message in demo1 arises. It claims it can't
> match some t with the type IO (), but when I tell that the result is
> IO () it can?
> I think at least the error message is confusing, and not very helpful.
> I would have in no way been able to get the clue that add a type
> signature as in the case of demo5 would solve the problem.
> 
> What am I overlooking?
> 
> Doaitse
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From andres at well-typed.com  Tue May 13 21:51:39 2014
From: andres at well-typed.com (=?UTF-8?Q?Andres_L=C3=B6h?=)
Date: Tue, 13 May 2014 23:51:39 +0200
Subject: question about GADT's and error messages
In-Reply-To: <25b72ac14d786f0e9432661b3f2fe771@seas.upenn.edu>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
 <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
 <74A2AA2D-CA40-491B-9855-E73A2BB413EB@swierstra.net>
 <25b72ac14d786f0e9432661b3f2fe771@seas.upenn.edu>
Message-ID: <CALjd_v6eDa9aJLVM0xFvRfw+SUjOC9P=6w+biq+EVZSMhtunXA@mail.gmail.com>

Hi.

Daniel is certainly right to point out general problems with GADT
pattern matching and principal types. Nevertheless, the changing
behaviour of GHC over time is currently a bit confusing to me.

In GHC-6.12.3, Doaitse's program fails with three errors (demo1,
demo2, demo4, all the GADT pattern matches without type signature),
and the error messages are:

/home/andres/trans/GT.hs:7:15:
    GADT pattern match in non-rigid context for `AInt'
      Probable solution: add a type signature for the scrutinee of the
case expression
    In the pattern: AInt i
    In a case alternative: (AInt i) -> print i
    In the expression: case a of { (AInt i) -> print i }

/home/andres/trans/GT.hs:33:18:
    GADT pattern match with non-rigid result type `t'
      Solution: add a type signature for the entire case expression
    In a case alternative: (AInt i) -> print i
    In the expression: case a of { (AInt i) -> print i }
    In the expression: do { case a of { (AInt i) -> print i } }

/home/andres/trans/GT.hs:41:18:
    GADT pattern match with non-rigid result type `t'
      Solution: add a type signature for the entire case expression
    In a case alternative: (AInt i) -> print i
    In the expression: case AInt 3 of { (AInt i) -> print i }
    In the expression: do { case AInt 3 of { (AInt i) -> print i } }

These error messages are conservative, but clear. They ask the user to
add a type signature.

With GHC-7.0.4, GHC-7.2.1, GHC-7.4.2, and GHC-7.6.3, the program
compiles without error, including demo1.

With GHC-7.8.2, the compiler reports the error Doaitse mentioned:

/home/andres/trans/GT.hs:7:27:
    Couldn't match expected type ?t? with actual type ?IO ()?
      ?t? is untouchable
        inside the constraints (t1 ~ Int)

I think the error message would be more helpful if it would mention
adding a type signature as a possible fix again.

But, assuming for the time being that GHC is "correct" to reject this
program and that GHC-7 was "wrong" up until now, then I'd like to know
what the new rule for GADT pattern matching is. Obviously, it's more
relaxed than it used to be (because demo2 and demo4 are still
accepted). Also, am I correct that the OutsideIn JFP paper is still
the correct description of what's going on in the type checker? If so,
is GHC-7.6 or GHC-7.8 closer to implementing what the OutsideIn paper
describes? Is the change in behaviour documented somewhere?

Thanks.

Cheers,
  Andres

-- 
Andres L?h, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England & Wales, OC335890
250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England

From john at repetae.net  Tue May 13 22:11:16 2014
From: john at repetae.net (John Meacham)
Date: Tue, 13 May 2014 15:11:16 -0700
Subject: AlternateLayoutRule
In-Reply-To: <20140513212223.GA4774@matrix.chaos.earth.li>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com> <20140513212223.GA4774@matrix.chaos.earth.li>
Message-ID: <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>

On Tue, May 13, 2014 at 2:22 PM, Ian Lynagh <igloo at earth.li> wrote:
> It's based on your code, but I had to essentially completely re-write it
> to work with the way that GHC's parser works; I don't think sharing the
> code will be feasible.

Ah, yeah, I didn't think the code would translate directly, but I'd want the
logic to match of course.

But on that subject of sharing code, I just relicensed jhc under a
permissive license like ghc with the last release so code can move both
ways. I mainly think it will be useful in the libraryies and support
routines rather than compiler core stuff. though, I may nab the c--
parser/emitter. I already use it as an intermediate language but with no
external representation.

My lexer/parser is based on a branch of the thih
source which also eventually begat haskell-src but it is fairly hairy.
Written before monad syntax so has hand written CPS everywhere. I am hoping
that if the new layout rule works I can move to a packrat or hybrid
recursive descent parser, letting LALR handle the gross structure but use
hand written recursive descent with excellent error messages for
expressions. The only reason I have stuck it out with the happy one for so
long is it has the magic lexer/layout interaction baked in.

> I also fixed some bugs (e.g. I think that with your code,
> ?  ?  foo = let { x = x }
> ?  ?  ?  ?  ?  in x
> turns into something like
> ?  ?  foo = let { x = x }
> ?  ?  ?  ?  ?  } in x
> ) and made some tweaks after trying it on GHC+bootlibs, but I don't have
> details to hand.

ah cool, can you point me to which file it is implemented in in the source
so I can copy your new rules?

> However, the consensus was that the new rule has too many cases, due to
> trying to match the old rule as closely as possible, and despite that it
> doesn't have the advantage that it is a drop-in replacement. ISTR Cabal
> in particular needed several changes to compile with it
> (0aba7b9f2e5d8acea156d575184a4a63af0a1ed3). Most of them were code of
> the form
> ?  ?  case e of
> ?  ?  p -> e'
> ?  ?  where bs
> needing the 'where' clause to be less indented.

Hmm.. interesting. I only tested against the whole nofib suite originally. I
need to expand that.

> The plan, yet to be implemented, was to remove some of the cases of the
> new rule, making it easier to understand, specify and implement, at the
> expense of breaking more code when the switch is flipped.

I don't mind that if it makes sense. Would only work if ghc did it though as
no one is going to relayout their code for jhc (unless they are one of the
ones using it to compile to ARM boards with 32k of RAM :) ).

Maybe I can twiddle the algorithm in ghc itself for a bit first to take
advantage of the bigger accessible codebase to test on.

> Ideally, there would be a period during which compilers would check
> during compilation whether the new rule would give a different token
> sequence to the old rule, and warn if so.

Yeah, it would be tricky in jhc to support both front ends, though... maybe
I can revert my current lexer parser back to simpler haskell 98 syntax and
require anything that uses extensions to use the new layout rule.

Thanks,
        John

--
John Meacham - http://notanumber.net/

From igloo at earth.li  Tue May 13 22:32:55 2014
From: igloo at earth.li (Ian Lynagh)
Date: Tue, 13 May 2014 23:32:55 +0100
Subject: AlternateLayoutRule
In-Reply-To: <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com>
 <20140513212223.GA4774@matrix.chaos.earth.li>
 <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
Message-ID: <20140513223255.GA6385@matrix.chaos.earth.li>

On Tue, May 13, 2014 at 03:11:16PM -0700, John Meacham wrote:
> 
> ah cool, can you point me to which file it is implemented in in the source
> so I can copy your new rules?

It's lexTokenAlr and friends in compiler/parser/Lexer.x

It's a while since I looked at it, but IIRC it's not as clean to read as
your specification code was, as GHC needs a function that it can call
that will just give it the next token. That means that we need to keep
some state for what we've recently seen, and if we want to return
multiple tokens then we can only return the first one, and need to store
the rest to be returned by subsequent calls


Thanks
Ian


From jwlato at gmail.com  Wed May 14 01:39:57 2014
From: jwlato at gmail.com (John Lato)
Date: Tue, 13 May 2014 18:39:57 -0700
Subject: vector and GeneralizedNewtypeDeriving
Message-ID: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>

Hello,

Prior to ghc-7.8, it was possible to do this:

> module M where
>
> import qualified Data.Vector.Generic.Base as G
> import qualified Data.Vector.Generic.Mutable as M
> import Data.Vector.Unboxed.Base -- provides MVector and Vector
>
> newtype Foo = Foo Int deriving (Eq, Show, Num,
>     M.MVector MVector, G.Vector Vector, Unbox)

M.MVector is defined as

> class MVector v a where
>     basicLength :: v s a -> Int
etc.

With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector
s Foo and MVector s Int have different types.  The error suggests trying
-XStandaloneDeriving to manually specify the context, however I don't see
any way that will help in this case.

For that matter, I don't see any way to fix this in the vector package
either.  We might think to define

> type role M.MVector nominal representational

but that doesn't work as both parameters to M.MVector require a nominal
role (and it's probably not what we really want anyway).  Furthermore
Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
a data family, so we're stuck at that point also.

So given this situation, is there any way to automatically derive Vector
instances from newtypes?

tl;dr: I would really like to be able to do:

> coerce (someVector :: Vector Foo) :: Vector Int

am I correct that the current machinery isn't up to handling this?

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140513/6c0d0a42/attachment.html>

From carter.schonwald at gmail.com  Wed May 14 05:40:53 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 14 May 2014 01:40:53 -0400
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
Message-ID: <CAHYVw0ynwBweFKNNXF0DrPYBFMkeieeKxx+rFTCfsJDCd=z-Lg@mail.gmail.com>

can you get the deriving to work on
a newtype instance MVector s Foo = ....
?


On Tue, May 13, 2014 at 9:39 PM, John Lato <jwlato at gmail.com> wrote:

> Hello,
>
> Prior to ghc-7.8, it was possible to do this:
>
> > module M where
> >
> > import qualified Data.Vector.Generic.Base as G
> > import qualified Data.Vector.Generic.Mutable as M
> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
> >
> > newtype Foo = Foo Int deriving (Eq, Show, Num,
> >     M.MVector MVector, G.Vector Vector, Unbox)
>
> M.MVector is defined as
>
> > class MVector v a where
> >     basicLength :: v s a -> Int
> etc.
>
> With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector
> s Foo and MVector s Int have different types.  The error suggests trying
> -XStandaloneDeriving to manually specify the context, however I don't see
> any way that will help in this case.
>
> For that matter, I don't see any way to fix this in the vector package
> either.  We might think to define
>
> > type role M.MVector nominal representational
>
> but that doesn't work as both parameters to M.MVector require a nominal
> role (and it's probably not what we really want anyway).  Furthermore
> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
> a data family, so we're stuck at that point also.
>
> So given this situation, is there any way to automatically derive Vector
> instances from newtypes?
>
> tl;dr: I would really like to be able to do:
>
> > coerce (someVector :: Vector Foo) :: Vector Int
>
> am I correct that the current machinery isn't up to handling this?
>
> Thanks,
> John
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/7ed41efa/attachment.html>

From jwlato at gmail.com  Wed May 14 05:54:20 2014
From: jwlato at gmail.com (John Lato)
Date: Tue, 13 May 2014 22:54:20 -0700
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAHYVw0ynwBweFKNNXF0DrPYBFMkeieeKxx+rFTCfsJDCd=z-Lg@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <CAHYVw0ynwBweFKNNXF0DrPYBFMkeieeKxx+rFTCfsJDCd=z-Lg@mail.gmail.com>
Message-ID: <CAJ727GjA=TZtj6=Os9_Ve-SJ6YFizRXvnJqu7WDiU5qumfn=sg@mail.gmail.com>

Not by anything I've tried yet, no.


On Tue, May 13, 2014 at 10:40 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> can you get the deriving to work on
> a newtype instance MVector s Foo = ....
> ?
>
>
> On Tue, May 13, 2014 at 9:39 PM, John Lato <jwlato at gmail.com> wrote:
>
>> Hello,
>>
>> Prior to ghc-7.8, it was possible to do this:
>>
>> > module M where
>> >
>> > import qualified Data.Vector.Generic.Base as G
>> > import qualified Data.Vector.Generic.Mutable as M
>> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
>> >
>> > newtype Foo = Foo Int deriving (Eq, Show, Num,
>> >     M.MVector MVector, G.Vector Vector, Unbox)
>>
>> M.MVector is defined as
>>
>> > class MVector v a where
>> >     basicLength :: v s a -> Int
>> etc.
>>
>> With ghc-7.8 this no longer compiles due to an unsafe coercion, as
>> MVector s Foo and MVector s Int have different types.  The error suggests
>> trying -XStandaloneDeriving to manually specify the context, however I
>> don't see any way that will help in this case.
>>
>> For that matter, I don't see any way to fix this in the vector package
>> either.  We might think to define
>>
>> > type role M.MVector nominal representational
>>
>> but that doesn't work as both parameters to M.MVector require a nominal
>> role (and it's probably not what we really want anyway).  Furthermore
>> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
>> a data family, so we're stuck at that point also.
>>
>> So given this situation, is there any way to automatically derive Vector
>> instances from newtypes?
>>
>> tl;dr: I would really like to be able to do:
>>
>> > coerce (someVector :: Vector Foo) :: Vector Int
>>
>> am I correct that the current machinery isn't up to handling this?
>>
>> Thanks,
>> John
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140513/1a685da4/attachment.html>

From john at repetae.net  Wed May 14 06:20:25 2014
From: john at repetae.net (John Meacham)
Date: Tue, 13 May 2014 23:20:25 -0700
Subject: AlternateLayoutRule
In-Reply-To: <20140513223255.GA6385@matrix.chaos.earth.li>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com> <20140513212223.GA4774@matrix.chaos.earth.li>
 <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
 <20140513223255.GA6385@matrix.chaos.earth.li>
Message-ID: <CAM0WKeVTdNc=EnH-77daVP8NNGKWsUkx+RYTfaK8=Nzc+G-nHA@mail.gmail.com>

Okay, I believe I have come up with a modified version that accepts many more
programs and doesn't require complicated comma handling, you can make all
decisions based on the top of the context stack. It also allows many useful
layouts that were illegal under the old system.

The main change was to store the expected closing token in addition to the
opening one on the context stack, then look up the appropriate token in a
table based on the immediately enclosing context. Unlike the old version
that recursed up the stack, this only needs to look at the top.

The rules are (where _ means true everywhere)

always enabled:
        (case,of)
        (if,then)
        (then,else)
        ('(',')')
        ('[',']')
        ('{','}')
conditional:
        of => ('|','->')
        let => ('|','=')
        '[' => ('|',']')

then we follow the same rules as before, except we check the token against
the stored ending token at the top of the stack and 'let' is only terminated
by ',' if '|' is at the top of the context stack.

In addition I added a list of 'layout insensitive' symbols, that will never
poke the layout rule, they are ["|","->","=",";",","]. lines starting with
these will not continue or close layout contexts.

So, there are still a couple obscure cases this won't lay out properly, but
it does allow some handy things that were not allowed before.

it boils down to the fact that layout is turned off inside any enclosing
brackets and effects do not propagate outside of them. So nothing done
between [ .. ] can affect anything outside of them.

some handy things this allows

-- a 'cond' construct that lines up nicely.
foo = case () of ()
      | cond1 -> exp1
      | cond2 -> exp2
      | cond3 -> exp3

line up your tuple defs

(alpha
,beta
,gamma) = foo

no need to double indent conditionals in do let

let f x y z
    | x == z = y
    | x == y = z
    | y == z = x


The simple rule is, inside enclosing brackets, layout is turned off and
doesn't propagate. I am testing the rules with ghc and they are promising so
far. pattern bindings

    John

From eir at cis.upenn.edu  Wed May 14 13:02:58 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 14 May 2014 09:02:58 -0400
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
Message-ID: <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>

Is this an instance of https://ghc.haskell.org/trac/ghc/ticket/8177 ? I think so.

The problem boils down to the fact that Vector and MVector are data families and are thus (currently) exempted from the roles mechanism. (Or, more properly, may *only* have nominal roles.) There is no technical reason for this restriction. It's just that the feature would take a few solid days of work to implement and I wasn't aware of a concrete use case.

Here is such a use case.

If you agree that you've hit #8177, please post to that bug report and raise the priority to High -- being able to coerce Vectors seems very reasonable indeed, and we should support it. I doubt the feature will land in 7.8.3 (depending on the timeline for that release), but I'll get to it eventually. (Or, if you feel this is more critical in the larger picture, shout more loudly on the ticket and perhaps I can squeeze it in before 7.8.3.)

Thanks,
Richard

On May 13, 2014, at 9:39 PM, John Lato <jwlato at gmail.com> wrote:

> Hello,
> 
> Prior to ghc-7.8, it was possible to do this:
> 
> > module M where
> >
> > import qualified Data.Vector.Generic.Base as G
> > import qualified Data.Vector.Generic.Mutable as M
> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
> >
> > newtype Foo = Foo Int deriving (Eq, Show, Num,
> >     M.MVector MVector, G.Vector Vector, Unbox)
> 
> M.MVector is defined as
> 
> > class MVector v a where
> >     basicLength :: v s a -> Int
> etc.
> 
> With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector s Foo and MVector s Int have different types.  The error suggests trying -XStandaloneDeriving to manually specify the context, however I don't see any way that will help in this case.
> 
> For that matter, I don't see any way to fix this in the vector package either.  We might think to define
> 
> > type role M.MVector nominal representational
> 
> but that doesn't work as both parameters to M.MVector require a nominal role (and it's probably not what we really want anyway).  Furthermore Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is a data family, so we're stuck at that point also.
> 
> So given this situation, is there any way to automatically derive Vector instances from newtypes?
> 
> tl;dr: I would really like to be able to do:
> 
> > coerce (someVector :: Vector Foo) :: Vector Int
> 
> am I correct that the current machinery isn't up to handling this?
> 
> Thanks,
> John
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/8680be88/attachment.html>

From igloo at earth.li  Wed May 14 14:29:51 2014
From: igloo at earth.li (Ian Lynagh)
Date: Wed, 14 May 2014 15:29:51 +0100
Subject: AlternateLayoutRule
In-Reply-To: <CAM0WKeVTdNc=EnH-77daVP8NNGKWsUkx+RYTfaK8=Nzc+G-nHA@mail.gmail.com>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com>
 <20140513212223.GA4774@matrix.chaos.earth.li>
 <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
 <20140513223255.GA6385@matrix.chaos.earth.li>
 <CAM0WKeVTdNc=EnH-77daVP8NNGKWsUkx+RYTfaK8=Nzc+G-nHA@mail.gmail.com>
Message-ID: <20140514142951.GA16968@matrix.chaos.earth.li>

On Tue, May 13, 2014 at 11:20:25PM -0700, John Meacham wrote:
> Okay, I believe I have come up with a modified version that accepts many more
> programs and doesn't require complicated comma handling, you can make all
> decisions based on the top of the context stack. It also allows many useful
> layouts that were illegal under the old system.

From your description, the rule still sounds quite complex. It depends
whether the objective is a rule that is close enough to the current rule
that we can switch with very little code breaking, or a rule that is
simple to explain to newcomers to the language (but which will require
much more code tweaking when updating packages to compile with the new
standard).


Thanks
Ian


From eir at cis.upenn.edu  Wed May 14 18:32:28 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 14 May 2014 14:32:28 -0400
Subject: question about GADT's and error messages
In-Reply-To: <CALjd_v6eDa9aJLVM0xFvRfw+SUjOC9P=6w+biq+EVZSMhtunXA@mail.gmail.com>
References: <CAAyGGymtk7kHo8007Bx+owf=EOg5J5owh7QO1m_D_mrKpg-mBA@mail.gmail.com>
 <5370871E.8020900@gmail.com>
 <CAAyGGy=eqfXU8YsgjPcdFZx87K=CxBZaxZeKNqG=-2H5Bk87_A@mail.gmail.com>
 <74A2AA2D-CA40-491B-9855-E73A2BB413EB@swierstra.net>
 <25b72ac14d786f0e9432661b3f2fe771@seas.upenn.edu>
 <CALjd_v6eDa9aJLVM0xFvRfw+SUjOC9P=6w+biq+EVZSMhtunXA@mail.gmail.com>
Message-ID: <F13C37B1-3B6F-49F6-BC5C-29C5C30B4F07@cis.upenn.edu>

My understanding of OutsideIn leads me to believe that GHC 7.8 has the behavior closer to that spec. See Section 5.2 of that paper (http://research.microsoft.com/en-us/um/people/simonpj/Papers/constraints/jfp-outsidein.pdf), which is a relatively accessible explanation of this phenomenon. Daniel's explanation is essentially a condensed version of that section.

I'm not surprised that the behavior changed between GHC 6.x and 7.x, as I believe 7.x is what brought in OutsideIn. I don't know much about the change between 7.6 and 7.8, though. And, I agree that the "untouchable" error messages are generally inscrutable. When I see that message in my own code, my takeaway is generally "I have a mistake somewhere near that line", nothing more specific or useful. I've accordingly posted a bug report #9109 (https://ghc.haskell.org/trac/ghc/ticket/9109). Please comment there if you have either useful examples or other contributions to the fix -- it may be hard to get this one right.

Richard

On May 13, 2014, at 5:51 PM, Andres L?h <andres at well-typed.com> wrote:

> Hi.
> 
> Daniel is certainly right to point out general problems with GADT
> pattern matching and principal types. Nevertheless, the changing
> behaviour of GHC over time is currently a bit confusing to me.
> 
> In GHC-6.12.3, Doaitse's program fails with three errors (demo1,
> demo2, demo4, all the GADT pattern matches without type signature),
> and the error messages are:
> 
> /home/andres/trans/GT.hs:7:15:
>    GADT pattern match in non-rigid context for `AInt'
>      Probable solution: add a type signature for the scrutinee of the
> case expression
>    In the pattern: AInt i
>    In a case alternative: (AInt i) -> print i
>    In the expression: case a of { (AInt i) -> print i }
> 
> /home/andres/trans/GT.hs:33:18:
>    GADT pattern match with non-rigid result type `t'
>      Solution: add a type signature for the entire case expression
>    In a case alternative: (AInt i) -> print i
>    In the expression: case a of { (AInt i) -> print i }
>    In the expression: do { case a of { (AInt i) -> print i } }
> 
> /home/andres/trans/GT.hs:41:18:
>    GADT pattern match with non-rigid result type `t'
>      Solution: add a type signature for the entire case expression
>    In a case alternative: (AInt i) -> print i
>    In the expression: case AInt 3 of { (AInt i) -> print i }
>    In the expression: do { case AInt 3 of { (AInt i) -> print i } }
> 
> These error messages are conservative, but clear. They ask the user to
> add a type signature.
> 
> With GHC-7.0.4, GHC-7.2.1, GHC-7.4.2, and GHC-7.6.3, the program
> compiles without error, including demo1.
> 
> With GHC-7.8.2, the compiler reports the error Doaitse mentioned:
> 
> /home/andres/trans/GT.hs:7:27:
>    Couldn't match expected type ?t? with actual type ?IO ()?
>      ?t? is untouchable
>        inside the constraints (t1 ~ Int)
> 
> I think the error message would be more helpful if it would mention
> adding a type signature as a possible fix again.
> 
> But, assuming for the time being that GHC is "correct" to reject this
> program and that GHC-7 was "wrong" up until now, then I'd like to know
> what the new rule for GADT pattern matching is. Obviously, it's more
> relaxed than it used to be (because demo2 and demo4 are still
> accepted). Also, am I correct that the OutsideIn JFP paper is still
> the correct description of what's going on in the type checker? If so,
> is GHC-7.6 or GHC-7.8 closer to implementing what the OutsideIn paper
> describes? Is the change in behaviour documented somewhere?
> 
> Thanks.
> 
> Cheers,
>  Andres
> 
> -- 
> Andres L?h, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com
> 
> Registered in England & Wales, OC335890
> 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


From john at repetae.net  Wed May 14 20:16:11 2014
From: john at repetae.net (John Meacham)
Date: Wed, 14 May 2014 13:16:11 -0700
Subject: AlternateLayoutRule
In-Reply-To: <20140514142951.GA16968@matrix.chaos.earth.li>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com> <20140513212223.GA4774@matrix.chaos.earth.li>
 <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
 <20140513223255.GA6385@matrix.chaos.earth.li>
 <CAM0WKeVTdNc=EnH-77daVP8NNGKWsUkx+RYTfaK8=Nzc+G-nHA@mail.gmail.com>
 <20140514142951.GA16968@matrix.chaos.earth.li>
Message-ID: <CAM0WKeUA=hkjXX-rMuOUKROoGbiq4ARrOk1Q9K6KFneNTFVMMw@mail.gmail.com>

Actually, it has less cases than my previous version, I think I just
wasn't presenting it well. My goal is to make something that will
accept current programs out there _and_ be much simpler than the
current rule. The parse exception brings a huge amount of complexity
into the old rule. LALR parsers are notoriously tricky for even
experienced programmers.

So, compared to the H98 rule the major simplification is:

Rather than extend layout until the language parser encounters an
error, I proactively disable layout when inserting a semi or brace
would guarentee a parse error under a simple parsing algorithm that
only keeps track of 'nesting level' and nothing else.

So, we basically just keep track of when inserting a semi or close
brace would cause an error of the form '(' with no matching ')' found
and don't do it then.

which state your automata goes to next depends on simple pattern
matching on current symbol and current top of stack and can be listed
as a set of tuples.

in other words, a textbook deterministic push down automaton.

    John



On Wed, May 14, 2014 at 7:29 AM, Ian Lynagh <igloo at earth.li> wrote:
> On Tue, May 13, 2014 at 11:20:25PM -0700, John Meacham wrote:
>> Okay, I believe I have come up with a modified version that accepts many more
>> programs and doesn't require complicated comma handling, you can make all
>> decisions based on the top of the context stack. It also allows many useful
>> layouts that were illegal under the old system.
>
> From your description, the rule still sounds quite complex. It depends
> whether the objective is a rule that is close enough to the current rule
> that we can switch with very little code breaking, or a rule that is
> simple to explain to newcomers to the language (but which will require
> much more code tweaking when updating packages to compile with the new
> standard).
>
>
> Thanks
> Ian
>



-- 
John Meacham - http://notanumber.net/

From jwlato at gmail.com  Thu May 15 02:02:05 2014
From: jwlato at gmail.com (John Lato)
Date: Wed, 14 May 2014 19:02:05 -0700
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
Message-ID: <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>

Hi Richard,

Thanks for pointing me to the ticket; I agree that's the issue (although
I'm glad to have you and Simon confirm it).  I've summarized the issue and
raised the priority, and Simon linked to this thread.

I would have expected this would have affected a lot users, but as I
haven't heard many complaints (and nobody else said anything here!) maybe
the impact is smaller than I thought.

Thanks,
John


On Wed, May 14, 2014 at 6:02 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> Is this an instance of https://ghc.haskell.org/trac/ghc/ticket/8177 ? I
> think so.
>
> The problem boils down to the fact that Vector and MVector are data
> families and are thus (currently) exempted from the roles mechanism. (Or,
> more properly, may *only* have nominal roles.) There is no technical reason
> for this restriction. It's just that the feature would take a few solid
> days of work to implement and I wasn't aware of a concrete use case.
>
> Here is such a use case.
>
> If you agree that you've hit #8177, please post to that bug report and
> raise the priority to High -- being able to coerce Vectors seems very
> reasonable indeed, and we should support it. I doubt the feature will land
> in 7.8.3 (depending on the timeline for that release), but I'll get to it
> eventually. (Or, if you feel this is more critical in the larger picture,
> shout more loudly on the ticket and perhaps I can squeeze it in before
> 7.8.3.)
>
> Thanks,
> Richard
>
> On May 13, 2014, at 9:39 PM, John Lato <jwlato at gmail.com> wrote:
>
> Hello,
>
> Prior to ghc-7.8, it was possible to do this:
>
> > module M where
> >
> > import qualified Data.Vector.Generic.Base as G
> > import qualified Data.Vector.Generic.Mutable as M
> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
> >
> > newtype Foo = Foo Int deriving (Eq, Show, Num,
> >     M.MVector MVector, G.Vector Vector, Unbox)
>
> M.MVector is defined as
>
> > class MVector v a where
> >     basicLength :: v s a -> Int
> etc.
>
> With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector
> s Foo and MVector s Int have different types.  The error suggests trying
> -XStandaloneDeriving to manually specify the context, however I don't see
> any way that will help in this case.
>
> For that matter, I don't see any way to fix this in the vector package
> either.  We might think to define
>
> > type role M.MVector nominal representational
>
> but that doesn't work as both parameters to M.MVector require a nominal
> role (and it's probably not what we really want anyway).  Furthermore
> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
> a data family, so we're stuck at that point also.
>
> So given this situation, is there any way to automatically derive Vector
> instances from newtypes?
>
> tl;dr: I would really like to be able to do:
>
> > coerce (someVector :: Vector Foo) :: Vector Int
>
> am I correct that the current machinery isn't up to handling this?
>
> Thanks,
> John
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/45e52191/attachment-0001.html>

From carter.schonwald at gmail.com  Thu May 15 02:14:59 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 14 May 2014 22:14:59 -0400
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
 <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
Message-ID: <CAHYVw0z2FKJ6Tz_7iFTDQVGM5+ciejh8-X58y1hjf1VquQaE_w@mail.gmail.com>

this is an issue i'll be running into shortly, otoh I don't think many
folks are writing new unboxed vector instances and related engineering :)


On Wed, May 14, 2014 at 10:02 PM, John Lato <jwlato at gmail.com> wrote:

> Hi Richard,
>
> Thanks for pointing me to the ticket; I agree that's the issue (although
> I'm glad to have you and Simon confirm it).  I've summarized the issue and
> raised the priority, and Simon linked to this thread.
>
> I would have expected this would have affected a lot users, but as I
> haven't heard many complaints (and nobody else said anything here!) maybe
> the impact is smaller than I thought.
>
> Thanks,
> John
>
>
> On Wed, May 14, 2014 at 6:02 AM, Richard Eisenberg <eir at cis.upenn.edu>wrote:
>
>> Is this an instance of https://ghc.haskell.org/trac/ghc/ticket/8177 ? I
>> think so.
>>
>> The problem boils down to the fact that Vector and MVector are data
>> families and are thus (currently) exempted from the roles mechanism. (Or,
>> more properly, may *only* have nominal roles.) There is no technical reason
>> for this restriction. It's just that the feature would take a few solid
>> days of work to implement and I wasn't aware of a concrete use case.
>>
>> Here is such a use case.
>>
>> If you agree that you've hit #8177, please post to that bug report and
>> raise the priority to High -- being able to coerce Vectors seems very
>> reasonable indeed, and we should support it. I doubt the feature will land
>> in 7.8.3 (depending on the timeline for that release), but I'll get to it
>> eventually. (Or, if you feel this is more critical in the larger picture,
>> shout more loudly on the ticket and perhaps I can squeeze it in before
>> 7.8.3.)
>>
>> Thanks,
>> Richard
>>
>> On May 13, 2014, at 9:39 PM, John Lato <jwlato at gmail.com> wrote:
>>
>> Hello,
>>
>> Prior to ghc-7.8, it was possible to do this:
>>
>> > module M where
>> >
>> > import qualified Data.Vector.Generic.Base as G
>> > import qualified Data.Vector.Generic.Mutable as M
>> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
>> >
>> > newtype Foo = Foo Int deriving (Eq, Show, Num,
>> >     M.MVector MVector, G.Vector Vector, Unbox)
>>
>> M.MVector is defined as
>>
>> > class MVector v a where
>> >     basicLength :: v s a -> Int
>> etc.
>>
>> With ghc-7.8 this no longer compiles due to an unsafe coercion, as
>> MVector s Foo and MVector s Int have different types.  The error suggests
>> trying -XStandaloneDeriving to manually specify the context, however I
>> don't see any way that will help in this case.
>>
>> For that matter, I don't see any way to fix this in the vector package
>> either.  We might think to define
>>
>> > type role M.MVector nominal representational
>>
>> but that doesn't work as both parameters to M.MVector require a nominal
>> role (and it's probably not what we really want anyway).  Furthermore
>> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
>> a data family, so we're stuck at that point also.
>>
>> So given this situation, is there any way to automatically derive Vector
>> instances from newtypes?
>>
>> tl;dr: I would really like to be able to do:
>>
>> > coerce (someVector :: Vector Foo) :: Vector Int
>>
>> am I correct that the current machinery isn't up to handling this?
>>
>> Thanks,
>> John
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/6b9ba947/attachment.html>

From bos at serpentine.com  Thu May 15 04:10:07 2014
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Wed, 14 May 2014 21:10:07 -0700
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
 <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
Message-ID: <CACw0ni+X+zdfGrLZQkSUry9x0usjZr3q50QJ-GD2HHtw7UxrTA@mail.gmail.com>

On Wed, May 14, 2014 at 7:02 PM, John Lato <jwlato at gmail.com> wrote:

> I would have expected this would have affected a lot users, but as I
> haven't heard many complaints (and nobody else said anything here!) maybe
> the impact is smaller than I thought.
>

I think people just haven't migrated much to 7.8 yet. This is definitely a
substantial problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/670461d4/attachment.html>

From jwlato at gmail.com  Thu May 15 04:17:59 2014
From: jwlato at gmail.com (John Lato)
Date: Wed, 14 May 2014 21:17:59 -0700
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CACw0ni+X+zdfGrLZQkSUry9x0usjZr3q50QJ-GD2HHtw7UxrTA@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
 <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
 <CACw0ni+X+zdfGrLZQkSUry9x0usjZr3q50QJ-GD2HHtw7UxrTA@mail.gmail.com>
Message-ID: <CAJ727GgN8inn9Wd8wAyJU9kHE1+UEqrs191EL+Y+u9XsUuFTew@mail.gmail.com>

Hi Richard,

Following your comment, I created a new ticket,
https://ghc.haskell.org/trac/ghc/ticket/9112, for this issue.

I'm not entirely sure I follow all the subtleties of your analysis, but I
think it's correct.


On Wed, May 14, 2014 at 9:10 PM, Bryan O'Sullivan <bos at serpentine.com>wrote:

>
> On Wed, May 14, 2014 at 7:02 PM, John Lato <jwlato at gmail.com> wrote:
>
>> I would have expected this would have affected a lot users, but as I
>> haven't heard many complaints (and nobody else said anything here!) maybe
>> the impact is smaller than I thought.
>>
>
> I think people just haven't migrated much to 7.8 yet. This is definitely a
> substantial problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140514/d529ae6e/attachment.html>

From choener at tbi.univie.ac.at  Thu May 15 11:06:23 2014
From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen)
Date: Thu, 15 May 2014 13:06:23 +0200
Subject: vector and GeneralizedNewtypeDeriving
In-Reply-To: <CAHYVw0z2FKJ6Tz_7iFTDQVGM5+ciejh8-X58y1hjf1VquQaE_w@mail.gmail.com>
References: <CAJ727GjrCvuJ1Hw8C60Dh6XcBdXS5gFed2nBwrh2cVYO+peG7Q@mail.gmail.com>
 <FECA2CFC-A758-499B-86B6-B03D13690183@cis.upenn.edu>
 <CAJ727Gh06rVHFs_Ub27UHFbQER=rKPmc=3S=fUa_5cazj99rbw@mail.gmail.com>
 <CAHYVw0z2FKJ6Tz_7iFTDQVGM5+ciejh8-X58y1hjf1VquQaE_w@mail.gmail.com>
Message-ID: <20140515110623.GA29120@lambda>

Greetings,

As an avid user of unboxed vectors (with a dozen libraries using them
with many newtypes), I've basically been using vector-th-unbox, which is
fine for parameter-free newtypes.

Viele Gruesse,
Christian

* Carter Schonwald <carter.schonwald at gmail.com> [15.05.2014 04:15]:
>    this is an issue i'll be running into shortly, otoh I don't think many
>    folks are writing new unboxed vector instances and related engineering
>    :)A 
> 
>    On Wed, May 14, 2014 at 10:02 PM, John Lato <jwlato at gmail.com> wrote:
> 
>      Hi Richard,
>      Thanks for pointing me to the ticket; I agree that's the issue (although
>      I'm glad to have you and Simon confirm it). A I've summarized the issue
>      and raised the priority, and Simon linked to this thread.
>      I would have expected this would have affected a lot users, but as I
>      haven't heard many complaints (and nobody else said anything here!)
>      maybe the impact is smaller than I thought.
>      Thanks,
>      John
> 
>      On Wed, May 14, 2014 at 6:02 AM, Richard Eisenberg <eir at cis.upenn.edu>
>      wrote:
> 
>        Is this an instance ofA https://ghc.haskell.org/trac/ghc/ticket/8177 ?
>        I think so.
>        The problem boils down to the fact that Vector and MVector are data
>        families and are thus (currently) exempted from the roles mechanism.
>        (Or, more properly, may *only* have nominal roles.) There is no
>        technical reason for this restriction. It's just that the feature
>        would take a few solid days of work to implement and I wasn't aware of
>        a concrete use case.
>        Here is such a use case.
>        If you agree that you've hit #8177, please post to that bug report and
>        raise the priority to High -- being able to coerce Vectors seems very
>        reasonable indeed, and we should support it. I doubt the feature will
>        land in 7.8.3 (depending on the timeline for that release), but I'll
>        get to it eventually. (Or, if you feel this is more critical in the
>        larger picture, shout more loudly on the ticket and perhaps I can
>        squeeze it in before 7.8.3.)
>        Thanks,
>        Richard
>        On May 13, 2014, at 9:39 PM, John Lato <jwlato at gmail.com> wrote:
> 
>          Hello,
>          Prior to ghc-7.8, it was possible to do this:
>          > module M where
>          >
>          > import qualifiedA Data.Vector.Generic.Base as G
>          > import qualified Data.Vector.Generic.Mutable as M
>          > import Data.Vector.Unboxed.Base -- provides MVector and Vector
>          >
>          > newtype Foo = Foo Int deriving (Eq, Show, Num,
>          > A  A A M.MVector MVector, G.Vector Vector, Unbox)
>          M.MVector is defined as
>          > class MVector v a where
>          > A  A  basicLength :: v s a -> Int
>          etc.
>          With ghc-7.8 this no longer compiles due to an unsafe coercion, as
>          MVector s Foo and MVector s Int have different types. A The error
>          suggests trying -XStandaloneDeriving to manually specify the
>          context, however I don't see any way that will help in this case.
>          For that matter, I don't see any way to fix this in the vector
>          package either. A We might think to define
>          > type role M.MVector nominal representational
>          but that doesn't work as both parameters to M.MVector require a
>          nominal role (and it's probably not what we really want anyway).
>          A Furthermore Data.Vector.Unboxed.Base.MVector (which fills in at
>          `v` in the instance) is a data family, so we're stuck at that point
>          also.
>          So given this situation, is there any way to automatically derive
>          Vector instances from newtypes?
>          tl;dr: I would really like to be able to do:
>          > coerce (someVector :: Vector Foo) :: Vector Int
>          am I correct that the current machinery isn't up to handling this?
>          Thanks,
>          John
>          _______________________________________________
>          Glasgow-haskell-users mailing list
>          Glasgow-haskell-users at haskell.org
>          http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
>      _______________________________________________
>      Glasgow-haskell-users mailing list
>      Glasgow-haskell-users at haskell.org
>      http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140515/ec6c9650/attachment.sig>

From v.dijk.bas at gmail.com  Fri May 16 15:11:02 2014
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Fri, 16 May 2014 17:11:02 +0200
Subject: Caching intermediate powers in GHC.Float
Message-ID: <CADLz5wXwMYB+jj3ATrzkhRDxGnBhJcR9C8dSomk-tXFacrGqdw@mail.gmail.com>

Does the following make sense:

https://ghc.haskell.org/trac/ghc/ticket/9120

Bas

From voldermort at hotmail.com  Mon May 19 12:50:18 2014
From: voldermort at hotmail.com (harry)
Date: Mon, 19 May 2014 05:50:18 -0700 (PDT)
Subject: Future of DYNAMIC_GHC_PROGRAMS?
Message-ID: <1400503818726-5749793.post@n5.nabble.com>

I need to build GHC 7.8 so that Template Haskell will work without shared
libraries (due to a shortage of space).

I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and
associated build options. Is this possibility going to be kept going
forward, or will it be deprecated once dynamic GHC is fully supported on all
platforms?



--
View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp5749793.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From voldermort at hotmail.com  Mon May 19 12:51:07 2014
From: voldermort at hotmail.com (harry)
Date: Mon, 19 May 2014 05:51:07 -0700 (PDT)
Subject: Future of DYNAMIC_GHC_PROGRAMS?
In-Reply-To: <1400503818726-5749793.post@n5.nabble.com>
References: <1400503818726-5749793.post@n5.nabble.com>
Message-ID: <1400503867017-5749794.post@n5.nabble.com>

harry wrote
> I need to build GHC 7.8 so that Template Haskell will work without shared
> libraries (due to a shortage of space).
> 
> I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and
> associated build options. Is this possibility going to be kept going
> forward, or will it be deprecated once dynamic GHC is fully supported on
> all platforms?

PS This is for Linux x64.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp5749793p5749794.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From marlowsd at gmail.com  Sat May 24 18:48:20 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 24 May 2014 19:48:20 +0100
Subject: Future of DYNAMIC_GHC_PROGRAMS?
In-Reply-To: <1400503867017-5749794.post@n5.nabble.com>
References: <1400503818726-5749793.post@n5.nabble.com>
 <1400503867017-5749794.post@n5.nabble.com>
Message-ID: <5380E974.5060004@gmail.com>

On 19/05/2014 13:51, harry wrote:
> harry wrote
>> I need to build GHC 7.8 so that Template Haskell will work without shared
>> libraries (due to a shortage of space).
>>
>> I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and
>> associated build options. Is this possibility going to be kept going
>> forward, or will it be deprecated once dynamic GHC is fully supported on
>> all platforms?
>
> PS This is for Linux x64.

We may yet go back and turn DYNAMIC_GHC_PROGRAMS off by default, it has 
yet to be decided.  The worst situation would be to have to support 
both, so I imagine once we've decided one way or the other we'll 
deprecated the other method.

Is it just shortage of space, or is there anything else that pushes you 
towards DYNAMIC_GHC_PROGRAMS=NO?  Isn't disk space cheap?

Cheers,
Simon

From jwlato at gmail.com  Sat May 24 19:59:15 2014
From: jwlato at gmail.com (John Lato)
Date: Sat, 24 May 2014 12:59:15 -0700
Subject: Future of DYNAMIC_GHC_PROGRAMS?
In-Reply-To: <5380E974.5060004@gmail.com>
References: <1400503818726-5749793.post@n5.nabble.com>
 <1400503867017-5749794.post@n5.nabble.com>
 <5380E974.5060004@gmail.com>
Message-ID: <CAJ727GjZTOdg+311LpcD-O+h=SUZLw5T4nCr6smT8mEkkJvAQA@mail.gmail.com>

On May 24, 2014 11:48 AM, "Simon Marlow" <marlowsd at gmail.com> wrote:
>
> On 19/05/2014 13:51, harry wrote:
>>
>> harry wrote
>>>
>>> I need to build GHC 7.8 so that Template Haskell will work without
shared
>>> libraries (due to a shortage of space).
>>>
>>> I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS
and
>>> associated build options. Is this possibility going to be kept going
>>> forward, or will it be deprecated once dynamic GHC is fully supported on
>>> all platforms?
>>
>>
>> PS This is for Linux x64.
>
>
> We may yet go back and turn DYNAMIC_GHC_PROGRAMS off by default, it has
yet to be decided.  The worst situation would be to have to support both,
so I imagine once we've decided one way or the other we'll deprecated the
other method.
>
> Is it just shortage of space, or is there anything else that pushes you
towards DYNAMIC_GHC_PROGRAMS=NO?  Isn't disk space cheap?
>
> Cheers,
> Simon

Speaking for myself, but I've noticed compilation times can be much shorter
with DYNAMIC_GHC_PROGRAMS=NO.  On one project using dynamic ghc added about
18 minutes to the build time (45 minutes vs 27). That's significant enough
that we're leaning towards static ghc for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140524/83c6607e/attachment.html>

From voldermort at hotmail.com  Sun May 25 06:36:49 2014
From: voldermort at hotmail.com (harry)
Date: Sat, 24 May 2014 23:36:49 -0700 (PDT)
Subject: Future of DYNAMIC_GHC_PROGRAMS?
In-Reply-To: <5380E974.5060004@gmail.com>
References: <1400503818726-5749793.post@n5.nabble.com>
 <1400503867017-5749794.post@n5.nabble.com> <5380E974.5060004@gmail.com>
Message-ID: <1400999809243-5750165.post@n5.nabble.com>

Simon Marlow-7 wrote
> Is it just shortage of space, or is there anything else that pushes you 
> towards DYNAMIC_GHC_PROGRAMS=NO?  Isn't disk space cheap?

Disc space is prohibitively expensive for zero-budget open source projects
deployed to the free tier of cloud computing providers.

We typically get 1Gb for everything, including GHC, third-party libraries,
our own code, and data. A full install of GHC is nearly 1Gb by itself.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp5749793p5750165.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From amindfv at gmail.com  Sun May 25 14:51:54 2014
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 25 May 2014 10:51:54 -0400
Subject: Future of DYNAMIC_GHC_PROGRAMS?
In-Reply-To: <1400999809243-5750165.post@n5.nabble.com>
References: <1400503818726-5749793.post@n5.nabble.com>
 <1400503867017-5749794.post@n5.nabble.com> <5380E974.5060004@gmail.com>
 <1400999809243-5750165.post@n5.nabble.com>
Message-ID: <0ED2ED10-5C4A-4F86-8F16-15A66E398F45@gmail.com>

You probably want to compile locally, e.g. with Vagrant, and then send the binary "into the cloud"

Tom


El May 25, 2014, a las 2:36, harry <voldermort at hotmail.com> escribi?:

> Simon Marlow-7 wrote
>> Is it just shortage of space, or is there anything else that pushes you 
>> towards DYNAMIC_GHC_PROGRAMS=NO?  Isn't disk space cheap?
> 
> Disc space is prohibitively expensive for zero-budget open source projects
> deployed to the free tier of cloud computing providers.
> 
> We typically get 1Gb for everything, including GHC, third-party libraries,
> our own code, and data. A full install of GHC is nearly 1Gb by itself.
> 
> 
> 
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp5749793p5750165.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From mail at joachim-breitner.de  Mon May 26 15:54:31 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 26 May 2014 17:54:31 +0200
Subject: Asserting that list fusing kicked in
Message-ID: <1401119671.6617.4.camel@kirk>

Hi,

for those of you who don?t follow Planet Haskell and haven?t seen my
blog post? on it:

I have created a (very) small library list-fusion-probe with an identity
function

        fuseThis :: [a] -> [a]
        
that will complain loudly (at run-time, for the time being) if the
argument is not fused away. Using it might give you more confidence in
that your code really fuses as well as you think it does.

Greetings from TFP (where the invited talk by Geoffrey Mainland inspired
me to write that),
Joachim

? http://www.joachim-breitner.de/blog/archives/649-Does-list-fusion-work.html

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140526/86fa77f5/attachment.sig>

From felipe.lessa at gmail.com  Mon May 26 16:04:33 2014
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Mon, 26 May 2014 13:04:33 -0300
Subject: Asserting that list fusing kicked in
In-Reply-To: <1401119671.6617.4.camel@kirk>
References: <1401119671.6617.4.camel@kirk>
Message-ID: <53836611.9080504@gmail.com>

Interesting hack.  I couldn't figure out how you did it, and just in a
lunch-break, until I took a look at the code :).

Cheers!

-- 
Felipe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140526/7fc172d6/attachment.sig>

From austin at well-typed.com  Tue May 27 08:06:39 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 27 May 2014 03:06:39 -0500
Subject: GHC 7.8.3 release
Message-ID: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>

Hello all,

After a long week, I've finally gotten a little time to reply to
emails, and I mainly have one question I'd like to ask.

First, please direct your attention to this:

https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority

This is the 7.8.3 milestone, but it only considers things that are:

 - 1) Fixed
 - 2) Going to be merged
 - 3) Are a patch to be still merged.

That is, it is a solid representation of the difference between 7.8.2
and the 7.8 branch tip.

The question is: when should we do the release? There are several bugs
there that seem quite problematic for users - #9045, #7097, #9001,
#8768 and #9078 in particular.

If these bugs are really problematic (and I sort of feel they are)
then the release can happen soon. I can do it within a week from now,
and we could punt more to a 7.8.4 release.

I ask this because my time to dedicate to GHC is a bit thin right now,
so you must help me decide what's important! So please let me know -
just a general vote in favor of doing it within some X timeframe (even
'real soon' or 'a week would be great') would be nice.

PS: I apologize for the lack of status updates and brief email - my
time for GHC has been in very short order the past two weeks in
particular, and I've finally just returned to a computer (not mine)
for right now to ask this.

PPS: This might also impact the 7.10 schedule, but last Simon and I
talked, we thought perhaps shooting for ICFP this time (and actually
hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
happen a few months from now, after summer.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From kazu at iij.ad.jp  Tue May 27 08:39:34 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 27 May 2014 17:39:34 +0900 (JST)
Subject: GHC 7.8.3 release
In-Reply-To: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
Message-ID: <20140527.173934.244924476991584853.kazu@iij.ad.jp>

Hi Austin,

> I ask this because my time to dedicate to GHC is a bit thin right now,
> so you must help me decide what's important! So please let me know -
> just a general vote in favor of doing it within some X timeframe (even
> 'real soon' or 'a week would be great') would be nice.

Would you give a look at: 
	http://www.haskell.org/pipermail/ghc-devs/2014-May/004990.html
	http://www.haskell.org/pipermail/ghc-devs/2014-May/004993.html

yesod-bin cannot be compiled with the coming GHC 7.8.3 yet. I believe
regression was introduced.

--Kazu

From michael at snoyman.com  Tue May 27 08:47:10 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 27 May 2014 11:47:10 +0300
Subject: GHC 7.8.3 release
In-Reply-To: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
Message-ID: <CAKA2JgLG_A9ynrfw_RHA-nHig-Xp=5zLXzrF50O+W-yCxWWoqA@mail.gmail.com>

I'm building the GHC-7.8 branch now, and will then kick off a Stackage
build. That should give a good indication if there are regressions.


On Tue, May 27, 2014 at 11:06 AM, Austin Seipp <austin at well-typed.com>wrote:

> Hello all,
>
> After a long week, I've finally gotten a little time to reply to
> emails, and I mainly have one question I'd like to ask.
>
> First, please direct your attention to this:
>
>
> https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
>
> This is the 7.8.3 milestone, but it only considers things that are:
>
>  - 1) Fixed
>  - 2) Going to be merged
>  - 3) Are a patch to be still merged.
>
> That is, it is a solid representation of the difference between 7.8.2
> and the 7.8 branch tip.
>
> The question is: when should we do the release? There are several bugs
> there that seem quite problematic for users - #9045, #7097, #9001,
> #8768 and #9078 in particular.
>
> If these bugs are really problematic (and I sort of feel they are)
> then the release can happen soon. I can do it within a week from now,
> and we could punt more to a 7.8.4 release.
>
> I ask this because my time to dedicate to GHC is a bit thin right now,
> so you must help me decide what's important! So please let me know -
> just a general vote in favor of doing it within some X timeframe (even
> 'real soon' or 'a week would be great') would be nice.
>
> PS: I apologize for the lack of status updates and brief email - my
> time for GHC has been in very short order the past two weeks in
> particular, and I've finally just returned to a computer (not mine)
> for right now to ask this.
>
> PPS: This might also impact the 7.10 schedule, but last Simon and I
> talked, we thought perhaps shooting for ICFP this time (and actually
> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
> happen a few months from now, after summer.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140527/ab4f2b4f/attachment.html>

From johan.tibell at gmail.com  Tue May 27 09:01:22 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 27 May 2014 11:01:22 +0200
Subject: GHC 7.8.3 release
In-Reply-To: <CAKA2JgLG_A9ynrfw_RHA-nHig-Xp=5zLXzrF50O+W-yCxWWoqA@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
 <CAKA2JgLG_A9ynrfw_RHA-nHig-Xp=5zLXzrF50O+W-yCxWWoqA@mail.gmail.com>
Message-ID: <CAK-tuPajQ6DExSkCy=cZsPj53p1K_6x5YuL0xoST0e_u11wj3Q@mail.gmail.com>

I would say "sooner". Here are still unmerged things that I think we could
merge before (i.e. easy to merge):

https://ghc.haskell.org/trac/ghc/ticket/9001
https://ghc.haskell.org/trac/ghc/ticket/9078
https://ghc.haskell.org/trac/ghc/ticket/8475
https://ghc.haskell.org/trac/ghc/ticket/8783
https://ghc.haskell.org/trac/ghc/ticket/9068
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140527/a99a1600/attachment.html>

From chak at cse.unsw.edu.au  Tue May 27 09:11:09 2014
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Tue, 27 May 2014 19:11:09 +1000
Subject: GHC 7.8.3 release
In-Reply-To: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
Message-ID: <037FC672-9933-40C1-85EB-5A8AC356A2A4@cse.unsw.edu.au>

I believe #9078 affects all EDSLs that use Andy Gill?s stable name method to implement observable sharing. It certainly crashes Accelerate.

I would very much appreciate if 7.8.3 would be released in time to make it into the upcoming Haskell Platform. (If the platform would ship with 7.8.2., that would be a quite bad for all affected EDSL libraries.)

Do we know the projected release date for the platform?

Manuel

PS: For Accelerate, the situation is actually rather awkward right now. Due to the changes re ambiguous signatures in GHC 7.8, Accelerate needs to introduce a breaking API change to compile with 7.8. However, we can?t really fully transition to 7.8 until #9078 is fixed.

Austin Seipp <austin at well-typed.com>:
> Hello all,
> 
> After a long week, I've finally gotten a little time to reply to
> emails, and I mainly have one question I'd like to ask.
> 
> First, please direct your attention to this:
> 
> https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> 
> This is the 7.8.3 milestone, but it only considers things that are:
> 
> - 1) Fixed
> - 2) Going to be merged
> - 3) Are a patch to be still merged.
> 
> That is, it is a solid representation of the difference between 7.8.2
> and the 7.8 branch tip.
> 
> The question is: when should we do the release? There are several bugs
> there that seem quite problematic for users - #9045, #7097, #9001,
> #8768 and #9078 in particular.
> 
> If these bugs are really problematic (and I sort of feel they are)
> then the release can happen soon. I can do it within a week from now,
> and we could punt more to a 7.8.4 release.
> 
> I ask this because my time to dedicate to GHC is a bit thin right now,
> so you must help me decide what's important! So please let me know -
> just a general vote in favor of doing it within some X timeframe (even
> 'real soon' or 'a week would be great') would be nice.
> 
> PS: I apologize for the lack of status updates and brief email - my
> time for GHC has been in very short order the past two weeks in
> particular, and I've finally just returned to a computer (not mine)
> for right now to ask this.
> 
> PPS: This might also impact the 7.10 schedule, but last Simon and I
> talked, we thought perhaps shooting for ICFP this time (and actually
> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
> happen a few months from now, after summer.
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From metaniklas at gmail.com  Tue May 27 16:15:19 2014
From: metaniklas at gmail.com (Niklas Larsson)
Date: Tue, 27 May 2014 18:15:19 +0200
Subject: GHC 7.8.3 release
In-Reply-To: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
Message-ID: <CACG=oWHLZGGJRA9kRx--rC_Jxev8Dti5AbqzvSWnkF+xtzoKag@mail.gmail.com>

Hi!

It would be great if the patch I added on #9080 was put into 7.8.3 (well, I
guess someone has to commit it to master first).

Niklas


2014-05-27 10:06 GMT+02:00 Austin Seipp <austin at well-typed.com>:

> Hello all,
>
> After a long week, I've finally gotten a little time to reply to
> emails, and I mainly have one question I'd like to ask.
>
> First, please direct your attention to this:
>
>
> https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
>
> This is the 7.8.3 milestone, but it only considers things that are:
>
>  - 1) Fixed
>  - 2) Going to be merged
>  - 3) Are a patch to be still merged.
>
> That is, it is a solid representation of the difference between 7.8.2
> and the 7.8 branch tip.
>
> The question is: when should we do the release? There are several bugs
> there that seem quite problematic for users - #9045, #7097, #9001,
> #8768 and #9078 in particular.
>
> If these bugs are really problematic (and I sort of feel they are)
> then the release can happen soon. I can do it within a week from now,
> and we could punt more to a 7.8.4 release.
>
> I ask this because my time to dedicate to GHC is a bit thin right now,
> so you must help me decide what's important! So please let me know -
> just a general vote in favor of doing it within some X timeframe (even
> 'real soon' or 'a week would be great') would be nice.
>
> PS: I apologize for the lack of status updates and brief email - my
> time for GHC has been in very short order the past two weeks in
> particular, and I've finally just returned to a computer (not mine)
> for right now to ask this.
>
> PPS: This might also impact the 7.10 schedule, but last Simon and I
> talked, we thought perhaps shooting for ICFP this time (and actually
> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
> happen a few months from now, after summer.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140527/afd9d574/attachment.html>

From austin at well-typed.com  Tue May 27 16:27:57 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 27 May 2014 11:27:57 -0500
Subject: GHC 7.8.3 release
In-Reply-To: <CACG=oWHLZGGJRA9kRx--rC_Jxev8Dti5AbqzvSWnkF+xtzoKag@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
 <CACG=oWHLZGGJRA9kRx--rC_Jxev8Dti5AbqzvSWnkF+xtzoKag@mail.gmail.com>
Message-ID: <CAEs96n3Sf2c4G8iwns6sYQ9CMvO-k=rjbqPtHKOkRrXuWqQQhg@mail.gmail.com>

Hi Niklas,

Yes, that patch looks great, thank you. The only reason it wasn't
included in the list earlier was that the status was set to 'new', not
to 'patch!' I'm afraid this is perhaps the most critical aspect
necessary for me to recognize such tickets. I have marked it as patch,
and it can go into 7.8.3, yes.

(Let it be known that, essentially, as time moves forward, the
probability of Austin forgetting a patch that is NOT marked
appropriately on trac rapidly, rapidly approaches one - if you have a
patch, please double-check that super-important 'status' field
please!)

On Tue, May 27, 2014 at 11:15 AM, Niklas Larsson <metaniklas at gmail.com> wrote:
> Hi!
>
> It would be great if the patch I added on #9080 was put into 7.8.3 (well, I
> guess someone has to commit it to master first).
>
> Niklas
>
>
> 2014-05-27 10:06 GMT+02:00 Austin Seipp <austin at well-typed.com>:
>>
>> Hello all,
>>
>> After a long week, I've finally gotten a little time to reply to
>> emails, and I mainly have one question I'd like to ask.
>>
>> First, please direct your attention to this:
>>
>>
>> https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=patch&milestone=7.8.3&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
>>
>> This is the 7.8.3 milestone, but it only considers things that are:
>>
>>  - 1) Fixed
>>  - 2) Going to be merged
>>  - 3) Are a patch to be still merged.
>>
>> That is, it is a solid representation of the difference between 7.8.2
>> and the 7.8 branch tip.
>>
>> The question is: when should we do the release? There are several bugs
>> there that seem quite problematic for users - #9045, #7097, #9001,
>> #8768 and #9078 in particular.
>>
>> If these bugs are really problematic (and I sort of feel they are)
>> then the release can happen soon. I can do it within a week from now,
>> and we could punt more to a 7.8.4 release.
>>
>> I ask this because my time to dedicate to GHC is a bit thin right now,
>> so you must help me decide what's important! So please let me know -
>> just a general vote in favor of doing it within some X timeframe (even
>> 'real soon' or 'a week would be great') would be nice.
>>
>> PS: I apologize for the lack of status updates and brief email - my
>> time for GHC has been in very short order the past two weeks in
>> particular, and I've finally just returned to a computer (not mine)
>> for right now to ask this.
>>
>> PPS: This might also impact the 7.10 schedule, but last Simon and I
>> talked, we thought perhaps shooting for ICFP this time (and actually
>> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
>> happen a few months from now, after summer.
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From sol at typeful.net  Fri May 30 02:27:30 2014
From: sol at typeful.net (Simon Hengel)
Date: Fri, 30 May 2014 10:27:30 +0800
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <535E12BF.2040008@gmail.com>
References: <535A6065.1000606@gmail.com>
 <535E12BF.2040008@gmail.com>
Message-ID: <20140530022730.GA2991@x200>

> Thanks for all the feedback.  Clearly opinion is divided on this one,
> so I'll sit on it and think it through some more.

My assumption was that with what Felipe Lessa suggested, this proposal
is pretty much obsolete.  As I understand it, it provides the same
benefits, the major difference being that you create a symlink instead
of specifying a command line flag.

It has been pointed out that symlinks work just fine with git.

I can see two advantages of this approach over the original proposal:

 - Cabal and other tools will continue to work without any modification

 - Somebody working with your code who is not aware of the "shortcut",
   will still find the source files where he expects them

Are there any disadvantages?

Cheers.

From john at repetae.net  Fri May 30 09:00:38 2014
From: john at repetae.net (John Meacham)
Date: Fri, 30 May 2014 02:00:38 -0700
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <535A6065.1000606@gmail.com>
References: <535A6065.1000606@gmail.com>
Message-ID: <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>

JHC has the feature that

Graphics.UI.GTK.Button can live in any of:

Graphics/UI/GTK/Button.hs
Graphics/UI/GTK.Button.hs
Graphics/UI.GTK.Button.hs
Graphics.UI.GTK.Button.hs

It lets you have deep module hiarchies without deep directory
hierarchies and is not terribly surprising as behaviors go.

     John

On Fri, Apr 25, 2014 at 6:17 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> I want to propose a simple change to the -i flag for finding source files.
> The problem we often have is that when you're writing code for a library
> that lives deep in the module hierarchy, you end up needing a deep directory
> structure, e.g.
>
>  src/
>    Graphics/
>      UI/
>       Gtk/
>         Button.hs
>         Label.hs
>         ...
>
> where the top few layers are all empty.  There have been proposals of
> elaborate solutions for this in the past (module grafting etc.), but I want
> to propose something really simple that would avoid this problem with
> minimal additional complexity:
>
>   ghc -iGraphics.UI.Gtk=src
>
> the meaning of this flag is that when searching for modules, ghc will look
> for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than
> src/Graphics/UI/Gtk/Button.hs.  The source file itself is unchanged: it
> still begins with "module Graphics.UI.Gtk.Button ...".
>
> The implementation is only a few lines in the Finder (and probably rather
> more in the manual and testsuite), but I wanted to get a sense of whether
> people thought this would be a good idea, or if there's a better alternative
> before I push it.
>
> Pros:
>
>   - simple implementation (but Cabal needs mods, see below)
>   - solves the deep directory problem
>
> Cons:
>
>   - It makes the rules about finding files a bit more complicated.
>     People need to find source files too, not just compilers.
>   - packages that want to be compatible with older compilers can't
>     use it yet.
>   - you can't use '=' in a source directory name (but we could pick
>     a different syntax if necessary)
>   - It won't work for Cabal packages until Cabal is modified to
>     support it (PreProcess and SrcDist and perhaps Haddock are the only
>     places affected, I think)
>   - Hackage will need to reject packages that use this feature without
>     also specifying ghc >= 7.10 and some cabal-version too.
>   - Are there other tools/libraries that will need changes? Leksah?
>
> Cheers,
> Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
John Meacham - http://notanumber.net/

From gtener at gmail.com  Fri May 30 09:05:29 2014
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Fri, 30 May 2014 11:05:29 +0200
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
Message-ID: <CAM7aEVGbzHGQwnqmPYy8VD5TirC7JKYteUyqQRNjuQ+zu8jNHw@mail.gmail.com>

I would personally love to see this feature ported to GHC.

Best regards,
Krzysztof

On Fri, May 30, 2014 at 11:00 AM, John Meacham <john at repetae.net> wrote:

> JHC has the feature that
>
> Graphics.UI.GTK.Button can live in any of:
>
> Graphics/UI/GTK/Button.hs
> Graphics/UI/GTK.Button.hs
> Graphics/UI.GTK.Button.hs
> Graphics.UI.GTK.Button.hs
>
> It lets you have deep module hiarchies without deep directory
> hierarchies and is not terribly surprising as behaviors go.
>
>      John
>
> On Fri, Apr 25, 2014 at 6:17 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> > I want to propose a simple change to the -i flag for finding source
> files.
> > The problem we often have is that when you're writing code for a library
> > that lives deep in the module hierarchy, you end up needing a deep
> directory
> > structure, e.g.
> >
> >  src/
> >    Graphics/
> >      UI/
> >       Gtk/
> >         Button.hs
> >         Label.hs
> >         ...
> >
> > where the top few layers are all empty.  There have been proposals of
> > elaborate solutions for this in the past (module grafting etc.), but I
> want
> > to propose something really simple that would avoid this problem with
> > minimal additional complexity:
> >
> >   ghc -iGraphics.UI.Gtk=src
> >
> > the meaning of this flag is that when searching for modules, ghc will
> look
> > for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than
> > src/Graphics/UI/Gtk/Button.hs.  The source file itself is unchanged: it
> > still begins with "module Graphics.UI.Gtk.Button ...".
> >
> > The implementation is only a few lines in the Finder (and probably rather
> > more in the manual and testsuite), but I wanted to get a sense of whether
> > people thought this would be a good idea, or if there's a better
> alternative
> > before I push it.
> >
> > Pros:
> >
> >   - simple implementation (but Cabal needs mods, see below)
> >   - solves the deep directory problem
> >
> > Cons:
> >
> >   - It makes the rules about finding files a bit more complicated.
> >     People need to find source files too, not just compilers.
> >   - packages that want to be compatible with older compilers can't
> >     use it yet.
> >   - you can't use '=' in a source directory name (but we could pick
> >     a different syntax if necessary)
> >   - It won't work for Cabal packages until Cabal is modified to
> >     support it (PreProcess and SrcDist and perhaps Haddock are the only
> >     places affected, I think)
> >   - Hackage will need to reject packages that use this feature without
> >     also specifying ghc >= 7.10 and some cabal-version too.
> >   - Are there other tools/libraries that will need changes? Leksah?
> >
> > Cheers,
> > Simon
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
> --
> John Meacham - http://notanumber.net/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140530/50e39cc9/attachment.html>

From daniel.trstenjak at gmail.com  Fri May 30 09:45:52 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Fri, 30 May 2014 11:45:52 +0200
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
Message-ID: <20140530094552.GA8175@machine>

On Fri, May 30, 2014 at 02:00:38AM -0700, John Meacham wrote:
> JHC has the feature that
> 
> Graphics.UI.GTK.Button can live in any of:
> 
> Graphics/UI/GTK/Button.hs
> Graphics/UI/GTK.Button.hs
> Graphics/UI.GTK.Button.hs
> Graphics.UI.GTK.Button.hs
> 
> It lets you have deep module hiarchies without deep directory
> hierarchies and is not terribly surprising as behaviors go.

Well, it might not be terribly surprising in itself, but we
just have quite complex systems and the not terribly surprising
things just accumulate and then it might get surprising somewhere.

I really prefer simplicity and explicitly.

If a central tool like GHC adds this behaviour, then all other
tools are forced to follow.


Greetings,
Daniel

From hvr at gnu.org  Fri May 30 10:10:08 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 30 May 2014 12:10:08 +0200
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
 (John Meacham's message of "Fri, 30 May 2014 02:00:38 -0700")
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
Message-ID: <87oayf1ssf.fsf@gnu.org>

On 2014-05-30 at 11:00:38 +0200, John Meacham wrote:
> JHC has the feature that
>
> Graphics.UI.GTK.Button can live in any of:
>
> Graphics/UI/GTK/Button.hs
> Graphics/UI/GTK.Button.hs
> Graphics/UI.GTK.Button.hs
> Graphics.UI.GTK.Button.hs

Just wondering: Does JHC warn if, for instance,
`Graphics/UI/GTK/Button.hs` as well as `Graphics.UI.GTK.Button.hs` exists?

From john at repetae.net  Fri May 30 10:10:47 2014
From: john at repetae.net (John Meacham)
Date: Fri, 30 May 2014 03:10:47 -0700
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <20140530094552.GA8175@machine>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
 <20140530094552.GA8175@machine>
Message-ID: <CAM0WKeVxWg=L2wwixDDEaTEGTPHtdrPc8uA8Vj2qEYgRGck1uA@mail.gmail.com>

On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak
<daniel.trstenjak at gmail.com> wrote:
> Well, it might not be terribly surprising in itself, but we
> just have quite complex systems and the not terribly surprising
> things just accumulate and then it might get surprising somewhere.
>
> I really prefer simplicity and explicitly.
>
> If a central tool like GHC adds this behaviour, then all other
> tools are forced to follow.


Well, I just proposed it as an alternative to some of the other ideas
floated here. A command line flag like -i would definitely be ghc
specific and inherently non-portable.

    John

-- 
John Meacham - http://notanumber.net/

From john at repetae.net  Fri May 30 10:13:45 2014
From: john at repetae.net (John Meacham)
Date: Fri, 30 May 2014 03:13:45 -0700
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <87oayf1ssf.fsf@gnu.org>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
 <87oayf1ssf.fsf@gnu.org>
Message-ID: <CAM0WKeW0FyXrYjhWVkapqKZ9v=y-06fCuppNMdfvsXoOE+xoMQ@mail.gmail.com>

No, it would be trivial to make it do so, but it would be ususual and
contrary to how ghc does things.

For instance, ghc doesnt warn if both Foo.lhs and Foo.hs exist or
src/Foo.hs and bar/Foo.hs when both -isrc and -ibar are specified on
the command line.

   John

On Fri, May 30, 2014 at 3:10 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> On 2014-05-30 at 11:00:38 +0200, John Meacham wrote:
>> JHC has the feature that
>>
>> Graphics.UI.GTK.Button can live in any of:
>>
>> Graphics/UI/GTK/Button.hs
>> Graphics/UI/GTK.Button.hs
>> Graphics/UI.GTK.Button.hs
>> Graphics.UI.GTK.Button.hs
>
> Just wondering: Does JHC warn if, for instance,
> `Graphics/UI/GTK/Button.hs` as well as `Graphics.UI.GTK.Button.hs` exists?



-- 
John Meacham - http://notanumber.net/

From christiaan.baaij at gmail.com  Fri May 30 13:29:41 2014
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Fri, 30 May 2014 15:29:41 +0200
Subject: GHC 7.8.2 bindist for OS X with Xcode 4
Message-ID: <DD01445C-F020-44E9-B14B-B60AEDE7572F@gmail.com>

The Xcode 5 version of GHC 7.8.2, at http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64, does not work on my machine where I only have Xcode 4 installed.
Under the assumption that there are other people out there who also do not (want to) upgrade to Xcode 5, and don't like building GHC from source either, I've created bindists for GHC 7.8.2 that work with Xcode 4:

https://www.dropbox.com/s/v6ax3itgjo0imy9/ghc-7.8.2-x86_64-apple-darwin.tar.bz2
https://www.dropbox.com/s/d5xpkoiia2tg0e4/ghc-7.8.2-x86_64-apple-darwin.tar.xz

Is there a process through which I could perhaps get them added to: http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64 ?
I see that there are multiple releases for other platforms as well.

-- Christiaan

From spam at scientician.net  Fri May 30 14:46:19 2014
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 30 May 2014 16:46:19 +0200
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
Message-ID: <lma5jr$qbv$1@ger.gmane.org>

On 2014-05-30 11:00, John Meacham wrote:
> JHC has the feature that
> 
> Graphics.UI.GTK.Button can live in any of:
> 
> Graphics/UI/GTK/Button.hs
> Graphics/UI/GTK.Button.hs
> Graphics/UI.GTK.Button.hs
> Graphics.UI.GTK.Button.hs
> 
> It lets you have deep module hiarchies without deep directory
> hierarchies and is not terribly surprising as behaviors go.
> 

This sounds much more appealing idea in that all the necessary
information is still in the file system and not tangled up in the build
specification (compiler flags).

Regards,


From marlowsd at gmail.com  Fri May 30 19:59:24 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 30 May 2014 20:59:24 +0100
Subject: RFC: changes to -i flag for finding source files
In-Reply-To: <CAM0WKeVxWg=L2wwixDDEaTEGTPHtdrPc8uA8Vj2qEYgRGck1uA@mail.gmail.com>
References: <535A6065.1000606@gmail.com>
 <CAM0WKeVZYD6UO9zq6m02=ugsQhPtgJNUaEH51GZhPGCN-r=P6Q@mail.gmail.com>
 <20140530094552.GA8175@machine>
 <CAM0WKeVxWg=L2wwixDDEaTEGTPHtdrPc8uA8Vj2qEYgRGck1uA@mail.gmail.com>
Message-ID: <5388E31C.5070800@gmail.com>

On 30/05/14 11:10, John Meacham wrote:
> On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak
> <daniel.trstenjak at gmail.com> wrote:
>> Well, it might not be terribly surprising in itself, but we
>> just have quite complex systems and the not terribly surprising
>> things just accumulate and then it might get surprising somewhere.
>>
>> I really prefer simplicity and explicitly.
>>
>> If a central tool like GHC adds this behaviour, then all other
>> tools are forced to follow.
>
>
> Well, I just proposed it as an alternative to some of the other ideas
> floated here. A command line flag like -i would definitely be ghc
> specific and inherently non-portable.

Just to clarify this point, what I proposed was not intended to be 
compiler-specific, because it would be a change to the hs-source-dirs 
field of a .cabal file, and implemented in whatever way each compiler 
wants to do it.  In the case of GHC the hs-source-dirs are just wrapped 
in -i flags.

Still, I'm not planning to push the change into GHC because (a) changes 
are needed in Cabal and a few other places, (b) opinion was divided, and 
(c) it's not a big enough win.

JHC's semantics would also need changes in Cabal, incidentally, for the 
same reason: supporting 'sdist' (and possibly other reasons that I've 
forgotten).

Cheers,
Simon



From marlowsd at gmail.com  Fri May 30 21:46:27 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 30 May 2014 22:46:27 +0100
Subject: GHC 7.8.3 release
In-Reply-To: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
Message-ID: <5388FC33.3040004@gmail.com>

On 27/05/14 09:06, Austin Seipp wrote:
> PPS: This might also impact the 7.10 schedule, but last Simon and I
> talked, we thought perhaps shooting for ICFP this time (and actually
> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
> happen a few months from now, after summer.

FWIW, I think doing 7.10 in October is way too soon.  Major releases 
create a large distributed effort for package maintainers and users, and 
there are other knock-on effects, so we shouldn't do them too often.  A 
lot of our users want stability, while many of them also want progress, 
and 12 months between major releases is the compromise we settled on.

The last major release slipped for various reasons, but I don't believe 
that means we should try to get back on track by having a short time 
between 7.8 and 7.10.  7.8 will be out of maintenance when it has only 
just made it into a platform release.

Anyway, that's my opinion.  Of course if everyone says they don't mind a 
7.10 in October then I withdraw my objection :-)

(as a data point, upgrading to 7.8 at work cost me three weeks, but 
we're probably a special case)

Cheers,
Simon


From vogt.adam at gmail.com  Sat May 31 05:12:50 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Sat, 31 May 2014 01:12:50 -0400
Subject: Data.Type.Equality.== works better when used at kind * -> * -> Bool
Message-ID: <CAHfjoWkXAmzk62JcNqK_xU_244T4nCA2HwbAwcrr-D6iO2JNWw@mail.gmail.com>

Hello List,

Given the following definitions:

> class HEq (x :: k) (y :: k) (b :: Bool) | x y -> b

> instance ((Proxy x == Proxy y) ~ b) => HEq x y b -- (A)

> instance ((x == y) ~ b) => HEq x y b -- (B)

The instance (A) lets HList compile, which can be reproduced with:

 darcs get http://code.haskell.org/~aavogt/HList/
 cd HList
 cabal install -fnew_type_eq

When I select instance (B) instead by uncommenting the alternative
instance in Data/HList/FakePrelude.hs, one of the more informative
type errors suggests that the == type family is getting stuck:

Data/HList/Variant.hs:202:29: Warning:
    Could not deduce (HasField'
                        (l Data.Type.Equality.== l) l (Tagged l (Maybe
e) : v) (Maybe e))
      arising from a use of ?mkVariant?
    from the context (ConvHList p,
                      SameLength' v v,
                      HMapCxt HMaybeF p v,
                      le ~ Tagged l (Maybe e))

Does this suggest that type (==) should work with all kinds, as it would with:

> type a == b = Proxy a `EqStar` Proxy b

https://github.com/ghc/packages-base/blob/master/Data/Type/Equality.hs
mentions "A poly-kinded instance is /not/ provided, as a recursive
definition for algebraic kinds is generally more useful.", but are
there instances of (==) that behave differently from the poly-kinded
version?

Regards,
Adam

From bioprogrammer at gmail.com  Sat May 31 06:42:57 2014
From: bioprogrammer at gmail.com (Caitlin)
Date: Fri, 30 May 2014 23:42:57 -0700
Subject: Haskell Platform Update?
Message-ID: <CABDKo+xBfeYxMsLv=ESDUY7E1NYBvvsWR9acd49_P-TPqcE2BQ@mail.gmail.com>

Hi all.

I was just wondering if an updated release for the Haskell Platform was
planned in the neat future? The current schedule lists November of last
year as being the time for release candidates..

Thanks,

~Caitlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140530/f4428910/attachment.html>

From daniel.is.fischer at googlemail.com  Sat May 31 08:28:15 2014
From: daniel.is.fischer at googlemail.com (Daniel Fischer)
Date: Sat, 31 May 2014 10:28:15 +0200
Subject: Haskell Platform Update?
In-Reply-To: <CABDKo+xBfeYxMsLv=ESDUY7E1NYBvvsWR9acd49_P-TPqcE2BQ@mail.gmail.com>
References: <CABDKo+xBfeYxMsLv=ESDUY7E1NYBvvsWR9acd49_P-TPqcE2BQ@mail.gmail.com>
Message-ID: <2475124.NrUBLXSTay@linux-hpeb.site>

On Friday 30 May 2014, 23:42:57, Caitlin wrote:
> Hi all.
> 
> I was just wondering if an updated release for the Haskell Platform was
> planned in the neat future? The current schedule lists November of last
> year as being the time for release candidates..
> 
> Thanks,
> 
> ~Caitlin

Yes, the preparations are in progress. I can't tell if it's going to be 
released really soon (next week) or within the next month, or whether 
something again throws a spanner into the works and it takes longer.

The delay is in no small part due to the release of GHC 7.8 having been 
delayed for a nontrivial amount of time.

From george.colpitts at gmail.com  Sat May 31 12:28:19 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 31 May 2014 09:28:19 -0300
Subject: GHC 7.8.3 release
In-Reply-To: <5388FC33.3040004@gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
 <5388FC33.3040004@gmail.com>
Message-ID: <CAB-d4A58hvj+SaEnQRW6xB39-1f9N5aXac+A595V3a7TAS4FQw@mail.gmail.com>

+1

Stability is very important.

Also, do we have an ETA for when we will have an improved infrastructure
for automated builds and the associated tests. I think this would help a
lot with stability and  shorten the time to the next release.


On Fri, May 30, 2014 at 6:46 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 27/05/14 09:06, Austin Seipp wrote:
>
>> PPS: This might also impact the 7.10 schedule, but last Simon and I
>> talked, we thought perhaps shooting for ICFP this time (and actually
>> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
>> happen a few months from now, after summer.
>>
>
> FWIW, I think doing 7.10 in October is way too soon.  Major releases
> create a large distributed effort for package maintainers and users, and
> there are other knock-on effects, so we shouldn't do them too often.  A lot
> of our users want stability, while many of them also want progress, and 12
> months between major releases is the compromise we settled on.
>
> The last major release slipped for various reasons, but I don't believe
> that means we should try to get back on track by having a short time
> between 7.8 and 7.10.  7.8 will be out of maintenance when it has only just
> made it into a platform release.
>
> Anyway, that's my opinion.  Of course if everyone says they don't mind a
> 7.10 in October then I withdraw my objection :-)
>
> (as a data point, upgrading to 7.8 at work cost me three weeks, but we're
> probably a special case)
>
> Cheers,
> Simon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140531/d5d649cf/attachment.html>

From greg at gregweber.info  Sat May 31 20:13:15 2014
From: greg at gregweber.info (Greg Weber)
Date: Sat, 31 May 2014 13:13:15 -0700
Subject: GHC 7.8.3 release
In-Reply-To: <5388FC33.3040004@gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
 <5388FC33.3040004@gmail.com>
Message-ID: <CAKRanNCp1rc_HLziVCsxisiRBOLpM+1MaqzB67PgTcNCfqjzEw@mail.gmail.com>

For me upgrading to 7.8 was very easy. The release slippage actually helped
out with that. 7.8 had already been specified well enough and already had
some active users for a long time. This made for a long window for package
maintainers to update their packages to have 7.8 compatibility. Perhaps
October is a good timeline to try to cut an initial alpha release that
specifies the interface for package authors to compile against, but the
actual release can wait until later.


On Fri, May 30, 2014 at 2:46 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 27/05/14 09:06, Austin Seipp wrote:
>
>> PPS: This might also impact the 7.10 schedule, but last Simon and I
>> talked, we thought perhaps shooting for ICFP this time (and actually
>> hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
>> happen a few months from now, after summer.
>>
>
> FWIW, I think doing 7.10 in October is way too soon.  Major releases
> create a large distributed effort for package maintainers and users, and
> there are other knock-on effects, so we shouldn't do them too often.  A lot
> of our users want stability, while many of them also want progress, and 12
> months between major releases is the compromise we settled on.
>
> The last major release slipped for various reasons, but I don't believe
> that means we should try to get back on track by having a short time
> between 7.8 and 7.10.  7.8 will be out of maintenance when it has only just
> made it into a platform release.
>
> Anyway, that's my opinion.  Of course if everyone says they don't mind a
> 7.10 in October then I withdraw my objection :-)
>
> (as a data point, upgrading to 7.8 at work cost me three weeks, but we're
> probably a special case)
>
> Cheers,
> Simon
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140531/8e22df8d/attachment.html>

From alain.odea at gmail.com  Sat May 31 20:54:26 2014
From: alain.odea at gmail.com (Alain O'Dea)
Date: Sat, 31 May 2014 20:54:26 +0000
Subject: GHC 7.8.3 release
In-Reply-To: <CAB-d4A58hvj+SaEnQRW6xB39-1f9N5aXac+A595V3a7TAS4FQw@mail.gmail.com>
References: <CAEs96n3qyYjF9vVpScVhrGmEUX+ofrjiD-vQCLSpa=9CPYHuPw@mail.gmail.com>
 <5388FC33.3040004@gmail.com>
 <CAB-d4A58hvj+SaEnQRW6xB39-1f9N5aXac+A595V3a7TAS4FQw@mail.gmail.com>
Message-ID: <538A4182.9030702@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/31/2014 12:28 PM, George Colpitts wrote:
> +1
> 
> Stability is very important.
> 
> Also, do we have an ETA for when we will have an improved
> infrastructure for automated builds and the associated tests. I
> think this would help a lot with stability and  shorten the time to
> the next release.
> 
> 
> On Fri, May 30, 2014 at 6:46 PM, Simon Marlow <marlowsd at gmail.com 
> <mailto:marlowsd at gmail.com>> wrote:
> 
> On 27/05/14 09:06, Austin Seipp wrote:
> 
> PPS: This might also impact the 7.10 schedule, but last Simon and
> I talked, we thought perhaps shooting for ICFP this time (and
> actually hitting it) was a good plan. So I'd estimate on that a
> 7.8.4 might happen a few months from now, after summer.
> 
> 
> FWIW, I think doing 7.10 in October is way too soon.  Major
> releases create a large distributed effort for package maintainers
> and users, and there are other knock-on effects, so we shouldn't do
> them too often.  A lot of our users want stability, while many of
> them also want progress, and 12 months between major releases is
> the compromise we settled on.
> 
> The last major release slipped for various reasons, but I don't 
> believe that means we should try to get back on track by having a 
> short time between 7.8 and 7.10.  7.8 will be out of maintenance 
> when it has only just made it into a platform release.
> 
> Anyway, that's my opinion.  Of course if everyone says they don't 
> mind a 7.10 in October then I withdraw my objection :-)
> 
> (as a data point, upgrading to 7.8 at work cost me three weeks,
> but we're probably a special case)
> 
> Cheers, Simon

Hi George:

There are continuous builds of GHC HEAD on several platforms and
architectures:
http://haskell.inf.elte.hu/builders/

There are still some bugs to work out there for sure (particularly
mine on SmartOS), but a lot of progress has been made.

The most critical gap is the lack of Windows and OS X builders since
they are Tier 1 platforms for GHC.

If you have Windows or OS X machines available please consider
offering a builder:
https://ghc.haskell.org/trac/ghc/wiki/Builder

Best,
Alain
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEbBAEBAgAGBQJTikGBAAoJEP0rIXJNjNSA/KsH+I7mug5uqHDr5YzZJSPl0awS
1PudhQqnBLf8Op/IQuPR7lYZEsXNTUb+VU1vV0vEo8+nRAaueVlhffsXYe7YRRHF
wQqA1WsmIfwwDsU2DkeVOhKMht9iB1eKC3vvsTEvZE8GJKvQZDTIeas5QtUki/i0
yuTPrRMZjf6IubsxeY90mlDCgpRMjRIWcRPm9fWj7c0wdzUNmMR0IPshMiXjZbbM
US9hkoyuXUyYZrtn19vbPGNTss3gZJEqengyDNDyVNrEd4QXC8Us/dqbnbjrKPI3
8D9BbVTOyELJ44mFXmlcXT8DSfIYCAv/sS81sXNm4lQX3jhTOyx2hNa3jvqIrQ==
=sZkd
-----END PGP SIGNATURE-----

From eir at cis.upenn.edu  Sat May 31 21:21:19 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 31 May 2014 17:21:19 -0400
Subject: Data.Type.Equality.== works better when used at kind * -> * ->
 Bool
In-Reply-To: <CAHfjoWkXAmzk62JcNqK_xU_244T4nCA2HwbAwcrr-D6iO2JNWw@mail.gmail.com>
References: <CAHfjoWkXAmzk62JcNqK_xU_244T4nCA2HwbAwcrr-D6iO2JNWw@mail.gmail.com>
Message-ID: <76FBB61E-C45E-4B85-A76B-606F962640F6@cis.upenn.edu>

On May 31, 2014, at 1:12 AM, adam vogt <vogt.adam at gmail.com> wrote:

> are
> there instances of (==) that behave differently from the poly-kinded
> version?

Yes.

To be concrete, here would be the polykinded instance:

> type family EqPoly (a :: k) (b :: k) where
>   EqPoly a a = True
>   EqPoly a b = False
> type instance (a :: k) == (b :: k) = EqPoly a b

Note that this overlaps with every other instance -- if this were defined, it would be the only instance for (==).

Now, consider
> data Nat = Zero | Succ Nat

Suppose I want
> foo :: (Succ n == Succ m) ~ True => ((n == m) :~: True)
> foo = Refl

This would not type-check with the poly-kinded instance. `Succ n == Succ m` quickly becomes `EqPoly (Succ n) (Succ m)` but then is stuck. We don't know enough about `n` and `m` to reduce further.

On the other hand, consider this:

> type family EqNat (a :: Nat) (b :: Nat) where
>   EqNat Zero     Zero     = True
>   EqNat (Succ n) (Succ m) = EqNat n m
>   EqNat n        m        = False
> type instance (a :: Nat) == (b :: Nat) = EqNat a b

With this instance, `foo` type-checks fine. `Succ n == Succ m` becomes `EqNat (Succ n) (Succ m)` which becomes `EqNat n m`. Thus, we can conclude `(n == m) ~ True` as desired.

So, the Nat-specific instance allows strictly more reductions, and is thus preferable to the poly-kinded instance. But, if we introduce the poly-kinded instance, we are barred from writing the Nat-specific instance, due to overlap.

Even better than the current instance for * would be one that does this sort of recursion for all datatypes, something like this:

> type family EqStar (a :: *) (b :: *) where
>   EqStar Bool Bool = True
>   EqStar (a,b) (c,d) = a == c && b == d
>   EqStar (Maybe a) (Maybe b) = a == b
>   ...
>   EqStar a b = False

The problem is the (...) is extensible -- we would want to add new cases for all datatypes in scope. This is not currently possible for closed type families. Perhaps it would be an improvement to write the cases for all types in scope in Data.Type.Equality -- that is, the types exported from `base`.

I hope this is helpful. In any case, I will put some of the text in this email into the comments in Data.Type.Equality for the next person who looks.

Richard