<p dir="ltr">Please take a took at that commit, UNPACK was also handled there, despite commit message do not explicitly state this.</p>
<div class="gmail_quote">On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How is parsing of the *NOUNPACK* pragma relevant here?<br>
<br>
On 23/01/15 10:45, Alexander V Vershilov wrote:<br>
> Hi.<br>
><br>
> As far as I understand  it was fixed as:<br>
><br>
> commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27<br>
> Author: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>><br>
> Date:   Mon Dec 1 17:07:48 2014 +0000<br>
><br>
>     Fix parser for UNPACK pragmas<br>
><br>
>        {-# NOUNPACK #-}<br>
>        {-# NOUNPACK #-} !<br>
>     were being parsed the same way.  The former was wrong.<br>
><br>
>     Thanks to Alan Zimmerman for pointing this out<br>
><br>
><br>
> So it will fix is in 7.10. And I can't reproduce this anymore on<br>
> ghc-HEAD.<br>
><br>
><br>
> On 20 January 2015 at 17:35, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
>> Interesting question. I managed to trace this to:<br>
>><br>
>> compiler/basicTypes/MkId.hs:699<br>
>><br>
>> isUnpackableType fam_envs ty<br>
>>   | Just (tc, _) <- splitTyConApp_maybe ty<br>
>>   , Just con <- tyConSingleAlgDataCon_maybe tc<br>
>>   , isVanillaDataCon con<br>
>>   = ok_con_args (unitNameSet (getName tc)) con<br>
>>   | otherwise<br>
>>   = False<br>
>><br>
>> where isVanillaDataCon is defined as:<br>
>><br>
>> dcVanilla :: Bool,<br>
>> -- True <=> This is a vanilla Haskell 98 data constructor<br>
>> --          Its type is of form<br>
>> --              forall a1..an . t1 -> ... tm -> T a1..an<br>
>> --          No existentials, no coercions, nothing.<br>
>><br>
>> There's no explanation why this limitation is introduced; it might be<br>
>> just a conservative one.<br>
>><br>
>> On 20/01/15 15:08, Nicholas Clarke wrote:<br>
>>> I'd like to be able to use the UNPACK pragma on an existentially<br>
>>> quantified datatype. So as in the below example:<br>
>>><br>
>>> {-# LANGUAGE ExistentialQuantification #-}<br>
>>><br>
>>> data Foo = forall a. Show a => Foo !a<br>
>>> instance Show Foo where<br>
>>>   show (Foo a) = "Foo! " ++ show a<br>
>>><br>
>>> data Bar =<br>
>>>     Bar {-# UNPACK #-} !Foo<br>
>>>   deriving (Show)<br>
>>><br>
>>> main :: IO ()<br>
>>> main = do<br>
>>>   let foo = Foo "Hello"<br>
>>>       bar = Bar foo<br>
>>>   print bar<br>
>>><br>
>>> I would expect the `Foo` constructor to be unpacked into Bar, as if I<br>
>>> had written:<br>
>>><br>
>>> data Bar = forall a. Show a => Bar !a<br>
>>><br>
>>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first<br>
>>> argument of ‘Bar’' warning. Is there a reason this shouldn't work, or a<br>
>>> workaround to get it to do so?<br>
>><br>
>> _______________________________________________<br>
>> Glasgow-haskell-users mailing list<br>
>> <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
><br>
><br>
><br>
<br>
</blockquote></div>