Clarification of HsBang and isBanged

[Johan Tibell]

Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into
account either. Should it?

    reifyStrict :: DataCon.HsSrcBang -> TH.Strict
    reifyStrict HsNoBang                     = TH.NotStrict
    reifyStrict (HsSrcBang _ False)          = TH.NotStrict
    reifyStrict (HsSrcBang (Just True) True) = TH.Unpacked
    reifyStrict (HsSrcBang _     True)       = TH.IsStrict
    reifyStrict HsStrict                     = TH.IsStrict
    reifyStrict (HsUnpack {})                = TH.Unpacked

Should

    reifyStrict (HsSrcBang _     True)       = TH.IsStrict

be TH.Unpacked if we have -funbox-strict-fields?

On Sun, Jan 11, 2015 at 6:28 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Those comments and the renaming really help. Here are a couple of more
> questions I got after exploring some more:
>
> DsMeta.repBangTy look wrong to me:
>
>     repBangTy :: LBangType Name -> DsM (Core (TH.StrictTypeQ))
>     repBangTy ty= do
>       MkC s <- rep2 str []
>       MkC t <- repLTy ty'
>       rep2 strictTypeName [s, t]
>       where
>         (str, ty') = case ty of
>                        L _ (HsBangTy (HsSrcBang (Just True) True) ty) ->
> (unpackedName,  ty)
>                        L _ (HsBangTy (HsSrcBang _     True) ty)       ->
> (isStrictName,  ty)
>                        _                                              ->
> (notStrictName, ty)
>
> Shouldn't the second case look at whether -funbox-strict-fields or
> -funbox-small-strict-fields is set and use unpackedName instead of
> isStrictName if so? What is repBangTy for?
>
> A related question, in MkId.dataConArgRep we have:
>
>     dataConArgRep _ _ arg_ty HsStrict
>       = strict_but_not_unpacked arg_ty
>
> Here we're not looking at -funbox-strict-fields
> and -funbox-small-strict-fields. Is it the case that we only need to look
> at these flags in the case of HsSrcBang, because HsStrict can only be
> generated by us (and we presumably looked at the flags when we converted a
> HsSrcBang to a HsStrict)?
>
> On Thu, Jan 8, 2015 at 4:09 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>>  I’m glad you are getting back to strictness.
>>
>>
>>
>> Good questions.
>>
>>
>>
>> I’ve pushed (or will as soon as I have validated) a patch that adds type
>> synonyms, updates comments (some of which were indeed misleading), and
>> changes a few names for clarity and consistency.  I hope that answers all
>> your questions.
>>
>>
>>
>> Except these:
>>
>>
>>
>> ·         Why is there a coercion in `HsUnpack` but not in `HsUserBang
>> (Just True) True`?  Because the former is implementation generated but the
>> latter is source code specified.
>>
>> ·         Why isn't this information split over two data types.  Because
>> there’s a bit of overlap. See comments with HsSrcBang
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Johan Tibell [mailto:johan.tibell at gmail.com]
>> *Sent:* 08 January 2015 07:36
>> *To:* ghc-devs at haskell.org
>> *Cc:* Simon Peyton Jones
>> *Subject:* Clarification of HsBang and isBanged
>>
>>
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150111/08661ccc/attachment-0001.html>