Re: On the record pattern synonyms patch

[Matthew Pickering]

Hi Edward,

I don't understand what should and shouldn't be in interface files. I
tried to make the least changes to get everything still to work. The
change was because of the corresponding change to the datatype.

https://github.com/ghc/ghc/commit/2a74a64e8329ab9e0c74bec47198cb492d25affb#diff-b59958324bac281f11d55f4263de7b0fL111

If you have a concrete suggestion about how this should be changed
then please say and I will do it.

With regards to the comments, it seems like the only relevant one for
the long run is to do with mixing pattern synonym and record field
selectors. This is also included in the source. Maybe it would be good
to put the one about duplicate record fields somewhere as well, do you
have a suggestion as to where might be appropriate?

Matt

On Fri, Nov 13, 2015 at 12:51 AM, Edward Z. Yang  wrote:
> Hello Matthew,
>
> I have a question about the record pattern synonyms patch
> which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb).
>
> In IfaceSyn, you made the following change:
>
>  data IfaceIdDetails
>= IfVanillaId
> -  | IfRecSelId IfaceTyCon Bool
> +  | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool
>| IfDFunId
>
> I don't understand why IfRecSelIds can now store IfaceDecls.  Why aren't
> these declarations stored at the *top level* list of declarations in an
> interface file?  If they are, you shouldn't be storing the entire
> IfaceDecl structure when serializing to disk.  If they are not, I
> am afraid I don't understand this code.
>
> I also noticed that the commit message is quite long, and many of the
> comments I see are not replicated anywhere in the source.  Is there any
> reason why they should not be written down as proper notes, with
> cross-references from the appropriate code?
>
> Thanks,
> Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

[Richard Eisenberg]

Could you add your comment to the ticket I've created? 
https://ghc.haskell.org/trac/ghc/ticket/11082

As for case conventions: The parts of GHC I play in have a fairly reliable 
convention: underscores for local things (both local variables and non-exported 
helper functions) and camel case for exported things. It's a nice convention 
that I've used elsewhere. This is not rigorously applied, but it's pretty good.

Richard

On Nov 13, 2015, at 10:01 AM, Jan Stolarek  wrote:

> My view on this is:
> 
> Firstly, I hate explaining myself to Arcanist. When prompted to explain the 
> reason for too long 
> lines I typically enter "wontfix" without thinking too much.
> 
> Secondly, I really don't like how warnings clutter code reviews.
> 
> I have my Emacs highlight text beyond 80th column with a really ugly colour, 
> so I strive real hard 
> to maintain 80-column limit whenever possible. But sometimes fitting in that 
> limit is nearly 
> impossible: imagine being in a let nested in a do-notation nested in a guard 
> nested in a where 
> clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I 
> would support 
> introducing a hard limit on having no more than 80 columns. 
> 
> Janek
> 
> PS. It makes me really sad that we don't have any coding convention for GHC: 
> we mix camelCase with 
> underscore_case, indentation is inconsistent (good thing we at least got rid 
> of tabs!), 
> whitespace usage is inconsistent, etc. I could make this list very long.
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bÄ
> dź otrzymaliście jÄ
> przez pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> 
> This email contains information intended solely for the use of the individual 
> to whom it is addressed.
> If you are not the intended recipient or if you have received this message in 
> error,
> please notify the sender and delete it from your system.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Can't build current HEAD

[Jan Stolarek]

I am unable to build current HEAD. I'm getting a build error in Outputable 
module:

compiler/utils/Outputable.hs:1046:28:
Not in scope: type constructor or class ‘CallStack’

compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’

The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which 
added this:

#if __GLASGOW_HASKELL__ >= 710
pprSTrace :: (?location :: CallStack) => SDoc -> a -> a 
 
pprSTrace = pprTrace (showCallStack ?location)
#else
pprSTrace :: SDoc -> a -> a
pprSTrace = pprTrace "no callstack info"
#endif

The most interesting thing is that if I change the definition of pprSTrace in 
the first branch of 
#if to be identical to the definition in the second branch, then I get warnings 
that GHC.Stack 
and GHC.Exception imports are redundant. Any ideas what might be going on here? 
I'm compiling 
using GHC 7.10.1. This happens in a clean build tree.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build current HEAD

[Jan Stolarek]

I just verified this does not happen when building with GHC 7.8.4, so if our 
build machines 
(harbormaster, travis) are building using 7.8.4 this might not show up in the 
logs.

Janek

Dnia piątek, 13 listopada 2015, Jan Stolarek napisał:
> I am unable to build current HEAD. I'm getting a build error in Outputable
> module:
>
> compiler/utils/Outputable.hs:1046:28:
> Not in scope: type constructor or class ‘CallStack’
>
> compiler/utils/Outputable.hs:1047:23: Not in scope: ‘showCallStack’
>
> The most likely culprit is 80d7ce8038a100f6797a89755c893c6f67f18a30, which
> added this:
>
> #if __GLASGOW_HASKELL__ >= 710
> pprSTrace :: (?location :: CallStack) => SDoc -> a -> a
> pprSTrace = pprTrace (showCallStack ?location)
> #else
> pprSTrace :: SDoc -> a -> a
> pprSTrace = pprTrace "no callstack info"
> #endif
>
> The most interesting thing is that if I change the definition of pprSTrace
> in the first branch of #if to be identical to the definition in the second
> branch, then I get warnings that GHC.Stack and GHC.Exception imports are
> redundant. Any ideas what might be going on here? I'm compiling using GHC
> 7.10.1. This happens in a clean build tree.
>
> Janek
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed. If you are not the intended recipient
> or if you have received this message in error, please notify the sender and
> delete it from your system.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pre-Proposal: Introspective Template Haskell

[Geoffrey Mainland]

Sounds like a good pan to me. Note that we would still need a small
GHC-version-specific shim, somewhere, to define the Q monad, which does
occasionally change. We could push it into the GHC API.

Having three Haskell ASTs has always been a pain---it would be nice to
finally fix this situation.

Using your proposal, we could implement a fully compatible
template-haskell library on top of the GHC AST and the "internal" Q
monad. We could also implement an analogous package that was based on
haskell-src-exts instead; in fact, it would be nice if the latter became
the "standard" Template Haskell implementation, as it would also help us
avoid hacks like haskell-src-meta.

Geoff

On 11/12/15 9:14 AM, Richard Eisenberg wrote:
> Yes, that's right. But with a compatibility shim, no longer tied into GHC, 
> that could provide stability and/or a simpler interface. This compatibility 
> shim would likely be called template-haskell. (I retract the idea of 
> deprecating the package. But we could democratize its maintenance rather 
> easily after this change.)
>
> Richard
>
> On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland  wrote:
>
>> Hi Richard,
>>
>> Please correct me if I misunderstand, but in summary, you propose to
>> change Template Haskell so that GHC's internal AST is produced directly,
>> instead of the current route where there is an intermediate TH AST?
>>
>> Geoff
>>
>> On 11/11/2015 11:26 AM, Richard Eisenberg wrote:
>>> Hi devs,
>>>
>>> There's a bunch of open tickets around Template Haskell. A great many of 
>>> them are attempts to make TH more like what's already in GHC. Of course, 
>>> when someone improves GHC, then TH also has to be updated. But this doesn't 
>>> always happen, leading to several of these tickets.
>>>
>>> I believe I have a solution to the problem: just eliminate Template Haskell 
>>> and provide direct access to GHC's internal structures. The idea (still 
>>> very sketchy; hence pre-proposal) is like this (numbered for easy 
>>> reference, but no order is implied):
>>>
>>> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that 
>>> produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). 
>>> (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.)
>>>
>>> 2. TH splices would remain, working much as they do now. The expression 
>>> inside, say, an expression splice would have type (Q exp) where we can 
>>> satisfy the constraint (SpliceExpr exp). There would be instances for 
>>> (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as 
>>> the non-located variants. Generalizing the type of expressions here allows 
>>> users not to worry about un-renaming when roundtripping between quotes and 
>>> splices.
>>>
>>> 3. Reification would remain, using an Info structure much like we have now. 
>>> Would we expose the real GHC TyCons as the result of reification? Or is it 
>>> better to give the users HsDecls? This would need to be fleshed out.
>>>
>>> 4. Lifting would remain, doing the obvious thing.
>>>
>>> 5. The template-haskell package could even remain, as a 
>>> backward-compatibility shim. It would declare gobs of pattern synonyms and 
>>> type synonyms to wrap the new underlying interface. This re-imagined 
>>> template-haskell package would not need to be a boot library, and could be 
>>> upgraded separately from GHC. We could even maintain multiple versions of 
>>> the library so that TH clients wouldn't have to change their code when GHC 
>>> upgrades. Perhaps someday we could think about deprecating, if that's the 
>>> way the wind blows.
>>>
>>> So, the end result is a completely re-engineered TH, but I believe we could 
>>> keep full backward compatibility. (I have not considered Typed TH in any 
>>> depth yet. But my hope is that it's not too different from the above.) And, 
>>> we're left with a significantly lower maintenance burden, especially if we 
>>> eliminate template-haskell someday.
>>>
>>> And, tantalizingly, the flexibility in splices might allow us to splice in 
>>> *Core* code someday. Perhaps we could also reify Core code. Then clients 
>>> could write their own custom, domain-aware optimizations. Like RULES on 
>>> steroids. But that's all for the next phase. (Giving due credit, this last 
>>> bit is inspired by work David Christiansen is doing in Idris.)
>>>
>>> What's wrong with this idea? I feel like *something* has to be more 
>>> complicated than I've made it seem!
>>>
>>> Richard

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pre-Proposal: Introspective Template Haskell

[Richard Eisenberg]

This proposal now has a home at wiki:TemplateHaskell/Introspective and #11081.

I think exploring how this might help haskell-src-exts would be very fruitful.

Richard

On Nov 13, 2015, at 4:18 PM, Geoffrey Mainland  wrote:

> Sounds like a good pan to me. Note that we would still need a small
> GHC-version-specific shim, somewhere, to define the Q monad, which does
> occasionally change. We could push it into the GHC API.
> 
> Having three Haskell ASTs has always been a pain---it would be nice to
> finally fix this situation.
> 
> Using your proposal, we could implement a fully compatible
> template-haskell library on top of the GHC AST and the "internal" Q
> monad. We could also implement an analogous package that was based on
> haskell-src-exts instead; in fact, it would be nice if the latter became
> the "standard" Template Haskell implementation, as it would also help us
> avoid hacks like haskell-src-meta.
> 
> Geoff
> 
> On 11/12/15 9:14 AM, Richard Eisenberg wrote:
>> Yes, that's right. But with a compatibility shim, no longer tied into GHC, 
>> that could provide stability and/or a simpler interface. This compatibility 
>> shim would likely be called template-haskell. (I retract the idea of 
>> deprecating the package. But we could democratize its maintenance rather 
>> easily after this change.)
>> 
>> Richard
>> 
>> On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland  wrote:
>> 
>>> Hi Richard,
>>> 
>>> Please correct me if I misunderstand, but in summary, you propose to
>>> change Template Haskell so that GHC's internal AST is produced directly,
>>> instead of the current route where there is an intermediate TH AST?
>>> 
>>> Geoff
>>> 
>>> On 11/11/2015 11:26 AM, Richard Eisenberg wrote:
 Hi devs,
 
 There's a bunch of open tickets around Template Haskell. A great many of 
 them are attempts to make TH more like what's already in GHC. Of course, 
 when someone improves GHC, then TH also has to be updated. But this 
 doesn't always happen, leading to several of these tickets.
 
 I believe I have a solution to the problem: just eliminate Template 
 Haskell and provide direct access to GHC's internal structures. The idea 
 (still very sketchy; hence pre-proposal) is like this (numbered for easy 
 reference, but no order is implied):
 
 1. TH quotes would remain. DsMeta would desugar quotes into Core code that 
 produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). 
 (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.)
 
 2. TH splices would remain, working much as they do now. The expression 
 inside, say, an expression splice would have type (Q exp) where we can 
 satisfy the constraint (SpliceExpr exp). There would be instances for 
 (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as 
 the non-located variants. Generalizing the type of expressions here allows 
 users not to worry about un-renaming when roundtripping between quotes and 
 splices.
 
 3. Reification would remain, using an Info structure much like we have 
 now. Would we expose the real GHC TyCons as the result of reification? Or 
 is it better to give the users HsDecls? This would need to be fleshed out.
 
 4. Lifting would remain, doing the obvious thing.
 
 5. The template-haskell package could even remain, as a 
 backward-compatibility shim. It would declare gobs of pattern synonyms and 
 type synonyms to wrap the new underlying interface. This re-imagined 
 template-haskell package would not need to be a boot library, and could be 
 upgraded separately from GHC. We could even maintain multiple versions of 
 the library so that TH clients wouldn't have to change their code when GHC 
 upgrades. Perhaps someday we could think about deprecating, if that's the 
 way the wind blows.
 
 So, the end result is a completely re-engineered TH, but I believe we 
 could keep full backward compatibility. (I have not considered Typed TH in 
 any depth yet. But my hope is that it's not too different from the above.) 
 And, we're left with a significantly lower maintenance burden, especially 
 if we eliminate template-haskell someday.
 
 And, tantalizingly, the flexibility in splices might allow us to splice in 
 *Core* code someday. Perhaps we could also reify Core code. Then clients 
 could write their own custom, domain-aware optimizations. Like RULES on 
 steroids. But that's all for the next phase. (Giving due credit, this last 
 bit is inspired by work David Christiansen is doing in Idris.)
 
 What's wrong with this idea? I feel like *something* has to be more 
 complicated than I've made it seem!
 
 Richard
> 

___
ghc-devs mailing list
ghc-devs@haskell.org