-devs@haskell.org
Subject: Re: Clarification of HsBang and isBanged
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))
repBangT
:12
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Clarification of HsBang and isBanged
Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into
account either. Should it?
reifyStrict :: DataCon.HsSrcBang -> TH.Strict
reifyStrict
ed 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.tib...@gmail.com<mailto:johan.tib...@gmail.com>]
Sent: 08 January 2015 07:36
To:
s it might be
[HsUnpack, HsUnpack, HsNoBang]
From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 11 January 2015 17:28
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Clarification of HsBang and isBanged
Those comments and the renaming really help. Here are a couple of more
q
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.
>>>
>>>
>>>
>&
>
>> · 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. Becau
>
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 08 January 2015 07:36
> *To:* ghc-devs@haskell.org
> *Cc:* Simon Peyton Jones
> *Subject:* Clarification of HsBang and isBanged
>
>
>
> HsBang is defined as:
>
> --
erlap. See comments with HsSrcBang
Simon
From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 08 January 2015 07:36
To: ghc-devs@haskell.org
Cc: Simon Peyton Jones
Subject: Clarification of HsBang and isBanged
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
--
>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
ove
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
wrote:
> I also note that the definition of isBanged is confusing:
>
> isBanged :: H
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
a
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 #-}
12 matches
Mail list logo
