Clarification of HsBang and isBanged

[Johan Tibell]

>From looking at the code a bit more I'm pretty sure that only HsUserBang
corresponds to what the user wrote and the remaining constructors are used
to note the actual decision we made (e.g. are we going to unpack). Is that
correct Simon PJ? If that is the case, why isn't this information split
over two data types (which would make functions over HsBang simpler)?

On Thu, Jan 8, 2015 at 9:22 AM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> I know there was a bug in the parser related to setting the HsBang value,
> it could be that this whole area has just not received solid scrutiny
> before now.
>
> Alan
>
> On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> I also note that the definition of isBanged is confusing:
>>
>>     isBanged :: HsBang -> Bool
>>     isBanged HsNoBang                  = False
>>     isBanged (HsUserBang Nothing bang) = bang
>>     isBanged _                         = True
>>
>> Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
>> annotations with a missing "!", considered "banged"?
>>
>> On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>
>>> HsBang is defined as:
>>>
>>>     -- HsBang describes what the *programmer* wrote
>>>     -- This info is retained in the DataCon.dcStrictMarks field
>>>     data HsBang
>>>       = HsUserBang   -- The user's source-code request
>>>            (Maybe Bool)       -- Just True    {-# UNPACK #-}
>>>                               -- Just False   {-# NOUNPACK #-}
>>>                               -- Nothing      no pragma
>>>            Bool               -- True <=> '!' specified
>>>
>>>       | HsNoBang              -- Lazy field
>>>                               -- HsUserBang Nothing False means the same
>>> as HsNoBang
>>>
>>>       | HsUnpack              -- Definite commitment: this field is
>>> strict and unboxed
>>>            (Maybe Coercion)   --    co :: arg-ty ~ product-ty
>>>
>>>       | HsStrict              -- Definite commitment: this field is
>>> strict but not unboxed
>>>
>>> This data type is a bit unclear to me:
>>>
>>>  * What are the reasons for the following constructor overlaps?
>>>    * `HsNoBang` and `HsUserBang Nothing False`
>>>    * `HsStrict` and `HsUserBang Nothing True`
>>>    * `HsUnpack mb_co` and `HsUserBang (Just True) True`
>>>
>>> * Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
>>> True) True`?
>>>
>>> * Is there a difference in what the user wrote in the case of HsUserBang
>>> and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
>>> compiler as opposed to being written by the user (the function
>>> documentation notwithstanding)?
>>>
>>> A very related function is isBanged:
>>>
>>>     isBanged :: HsBang -> Bool
>>>     isBanged HsNoBang                  = False
>>>     isBanged (HsUserBang Nothing bang) = bang
>>>     isBanged _                         = True
>>>
>>> What's the meaning of this function? Is it intended to communicate what
>>> the user wrote or whether result of what the user wrote results in a strict
>>> function?
>>>
>>> Context: I'm adding a new StrictData language pragma [1] that makes
>>> fields strict by default and a '~' annotation of fields to reverse the
>>> default behavior. My intention is to change HsBang like so:
>>>
>>>     -       Bool               -- True <=> '!' specified
>>>     +       (Maybe Bool)       -- True <=> '!' specified, False <=> '~'
>>>     +                          -- specified, Nothing <=> unspecified
>>>
>>> 1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>>>
>>> -- Johan
>>>
>>
>>
>> _______________________________________________
>> 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/ghc-devs/attachments/20150108/12c5e421/attachment-0001.html>