From jan.stolarek at p.lodz.pl  Tue Dec  1 12:21:15 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 1 Dec 2015 13:21:15 +0100
Subject: Wildcards in type functions vs. named wild cards
Message-ID: <201512011321.15662.jan.stolarek@p.lodz.pl>

Simon,

One of my students (Micha?, CCd) is hacking on #10982 and he noticed a rather unexpected 
behaviour. If I say:

{-# LANGUAGE TypeFamilies #-}

module T10982 where

type family F a where
    F _t = Int

Then everything is fine. But if I enable NamedWildCards extension then suddenly this code is 
rejected:

T10982.hs:7:7: error:
    Unexpected wild card: ?_t?
    In the declaration for type synonym ?F?

I am 99% sure this is a bug and the program should be accepted even with NamedWildCards. Am I 
correct? Does this interact in any way with your upcomming refactoring of wildcards?

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.

From simonpj at microsoft.com  Tue Dec  1 13:07:53 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Dec 2015 13:07:53 +0000
Subject: Wildcards in type functions vs. named wild cards
In-Reply-To: <201512011321.15662.jan.stolarek@p.lodz.pl>
References: <201512011321.15662.jan.stolarek@p.lodz.pl>
Message-ID: <788bdf199f444c12933961e26d801997@DB4PR30MB030.064d.mgd.msft.net>

Hmm.  I suppose that

  F _ = Int

should mean just the same as

  F a = Int

But what about 
 
  F _a = _a -> _a

Does that mean anything different from

  F a = a -> a

If F _a = .. is allowed at all, I guess it should mean just the same as an ordinary type variable.

Would you like to implement that, and document it?  (My wildcard refactoring patch is about to land.)

Simon

|  -----Original Message-----
|  From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl]
|  Sent: 01 December 2015 12:21
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org; Micha? So?nicki <180692 at edu.p.lodz.pl>
|  Subject: Wildcards in type functions vs. named wild cards
|  
|  Simon,
|  
|  One of my students (Micha?, CCd) is hacking on #10982 and he noticed a
|  rather unexpected behaviour. If I say:
|  
|  {-# LANGUAGE TypeFamilies #-}
|  
|  module T10982 where
|  
|  type family F a where
|      F _t = Int
|  
|  Then everything is fine. But if I enable NamedWildCards extension then
|  suddenly this code is
|  rejected:
|  
|  T10982.hs:7:7: error:
|      Unexpected wild card: ?_t?
|      In the declaration for type synonym ?F?
|  
|  I am 99% sure this is a bug and the program should be accepted even
|  with NamedWildCards. Am I correct? Does this interact in any way with
|  your upcomming refactoring of wildcards?
|  
|  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.

From jan.stolarek at p.lodz.pl  Tue Dec  1 13:21:04 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 1 Dec 2015 14:21:04 +0100
Subject: Wildcards in type functions vs. named wild cards
In-Reply-To: <788bdf199f444c12933961e26d801997@DB4PR30MB030.064d.mgd.msft.net>
References: <201512011321.15662.jan.stolarek@p.lodz.pl>
 <788bdf199f444c12933961e26d801997@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <201512011421.04314.jan.stolarek@p.lodz.pl>

> If F _a = .. is allowed at all, I guess it should mean just the same as an
> ordinary type variable.
Yes, exactly. I want type-level behaviour to mimic term level here.

> Would you like to implement that, and document it?
Micha? is working on that.

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.

From simonpj at microsoft.com  Tue Dec  1 13:34:54 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Dec 2015 13:34:54 +0000
Subject: Wildcard refactoring
Message-ID: <2b8ff720af6b47b8a62720776443d6e2@DB4PR30MB030.064d.mgd.msft.net>

OK, I think it?s time to commit my branch

            wip/spj-wildcard-refactor

Ben: could you commit it as a single large patch (ignore the branch history).  A commit message appears below.  There is a corresponding patch for haddock, with same branch name in the haddock repo.


Could you also open a ticket for the performance regression on perf/compiler/T3064?  I don?t want to forget it, but it?s past time to commit such a big, invasive patch.

There are two other tests failing for me, which appear to do with the version number for the containers sub-module.  I think I have failed to get the other submodules (other than haddock) right.  I was NOT intending to change them, so just use origin/master for them.


Everyone: take a look at the commit message below.  I?ve been working on this for far too long, in spare moments.  Richard, I?m sorry that it?ll be disruptive to your changes, but in a good way I hope.

Simon



This patch began as a modest refactoring of HsType and friends, to

clarify and tidy up exactly where quantification takes place in

types. Although initially driven by making the implementation of

wildcards more tidy (and fixing a number of bugs), I gradually got

drawn into a pretty big process, which I've been doing on and off for

quite a long time.



There is one compiler performance regression as a result of all

this, in perf/compiler/T3064.  I still need to look into that.



* The principal driving change is described in Note [HsType binders]

  in HsType.  Well worth reading!



* Those data type changes drive almost

  everything else.  In particular we now statically know where

       (a) implicit quantification only (LHsSigType),

           e.g. in instance declaratios and SPECIALISE signatures

       (b) implicit quantification and wildcards (LHsSigWcType)

           can appear, e.g. in function type signatures



* As part of this change, HsForAllTy is (a) simplified (no wildcards)

  and (b) split into HsForAllTy and HsQualTy.  The two contructors

  appear when and only when the correponding user-level construct

  appears.  Again see Note [HsType binders].



  HsExplicitFlag disappears altogether.



* Other simplifications

     - ExprWithTySig no longer needs an ExprWithTySigOut variant

     - TypeSig no longer needs a PostRn name [name] field

       for wildcards

     - PatSynSig records a LHsSigType rather than the decomposed pieces

     - The mysterious 'GenericSig' is now 'ClassOpSig'



* Renamed LHsTyVarBndrs to LHsQTyVars



* There are some uninteresting knock-on changes in Haddock,

  because of the HsSyn changes





I also did a bunch of loosely-related changes:



* We already had type synonyms CoercionN/CoercionR for nominal and

  representational coercions.  I've added similar treatment for

      TcCoercionN/TcCoercionR

      mkWpCastN/mkWpCastN

  All just type synonyms but jolly useful.



* I record-ised ForeignImport and ForeignExport



* I improved the (poor) fix to Trac #10896, by making

  TcTyClsDecls.checkValidTyCl recover from errors, but adding a

  harmless, abstract TyCon to the envt if so.



* I did some significant refactoring in RnEnv.lookupSubBndrOcc,

  for reasons that I have (embarrassingly) now totally forgotten.

  It had to do with something to do with import and export




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151201/bc1d5f09/attachment-0001.html>

From ben at well-typed.com  Tue Dec  1 16:45:22 2015
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 01 Dec 2015 17:45:22 +0100
Subject: Wildcard refactoring
In-Reply-To: <2b8ff720af6b47b8a62720776443d6e2@DB4PR30MB030.064d.mgd.msft.net>
References: <2b8ff720af6b47b8a62720776443d6e2@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87poyq5d99.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> OK, I think it?s time to commit my branch
>
>             wip/spj-wildcard-refactor
>
> Ben: could you commit it as a single large patch (ignore the branch
> history). A commit message appears below. There is a corresponding
> patch for haddock, with same branch name in the haddock repo.
>
Great. I'm doing a local validation and will push as soon as it is finished.

> Could you also open a ticket for the performance regression on
> perf/compiler/T3064?
>
Of course.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151201/05fc2a4a/attachment.sig>

From alan.zimm at gmail.com  Tue Dec  1 21:38:02 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Tue, 1 Dec 2015 23:38:02 +0200
Subject: linker error in haddock, D1558
Message-ID: <CANma=H_T8Y6KfPjRsHow03R88Vc24CP0Qn0GRJQmuX77W959wQ@mail.gmail.com>

Does anyone know why a build would be failing with

utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skOK_info':
(.text+0x75c8): undefined reference to `stg_ap_0_upd_info'
utils/haddock/dist/build/Haddock/GhcUtils.dyn_o: In function `skP5_info':
(.text+0x7728): undefined reference to `stg_ap_0_upd_info'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
utils/haddock/ghc.mk:21: recipe for target
'utils/haddock/dist/build/tmp/haddock' failed
make[1]: *** [utils/haddock/dist/build/tmp/haddock] Error 1

This is happening on
https://phabricator.haskell.org/harbormaster/build/8393/, a build of
https://phabricator.haskell.org/D1558

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151201/b01c2406/attachment.html>

From austin at well-typed.com  Wed Dec  2 00:17:23 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 1 Dec 2015 18:17:23 -0600
Subject: HEADS UP: Moving Phabricator to a new server soon
Message-ID: <CAEs96n2aQ380yytG7J9qyCQ_XS1U7vKmRD-C2fNctyjhngjZ-A@mail.gmail.com>

Hello all,

As I said about a week or two ago[1], I still have plans to move the
Phabricator server. I'd like to do this tonight.

I plan on starting this around 10pm CST or so. This is late at night
in the US and quite early in the EU, so I'm hoping to avoid causing
problems for anyone.

I'll follow up with more emails in response to this one later tonight,
as things move forward.

Thanks!

[1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010519.html

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From juhpetersen at gmail.com  Wed Dec  2 06:54:03 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Wed, 2 Dec 2015 15:54:03 +0900
Subject: [ANNOUNCE] 7.10.3 release candidate 3
In-Reply-To: <87si3o7t5n.fsf@smart-cactus.org>
References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org>
 <CAEDGBqJgvaq9Ty3wm-nJ7uUU0PUWjKtFUY-djFQMyT-32CmcsA@mail.gmail.com>
 <87si3o7t5n.fsf@smart-cactus.org>
Message-ID: <CAEDGBq+bfHAtpUDBfnVWw0QTD=S_rKC-DBwpxtnS9yoXOXju7Q@mail.gmail.com>

On 29 November 2015 at 23:54, Ben Gamari <ben at well-typed.com> wrote:
> On that note, 7.10.3 is coming. At the moment I am blocked on getting a
> Cabal release tagged but hopefully this will happen Real Soon Now(TM).

Cool - Cabal-1.22.5.0 went into Stackage Nightly yesterday. :-)

From simonpj at microsoft.com  Wed Dec  2 16:50:34 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Dec 2015 16:50:34 +0000
Subject: FW: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only
 (isIrrefutablePat)
In-Reply-To: <20151202160510.57676.37892@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-mx2hkzzcnqsjjp2gksma@phabricator.haskell.org>
 <20151202160510.57676.37892@phabricator.haskell.org>
Message-ID: <bbabc89bb30044338a03b32366bc4e4c@DB4PR30MB030.064d.mgd.msft.net>

Haddock is a constant mystery.

I added five lines of comments to GHC's source code, and one of the Haddock performance tests fails (see below).  That's all the patch contains.

I am reluctant to fix it by deleting the comments!

Simon

-----Original Message-----
From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] 
Sent: 02 December 2015 16:05
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only (isIrrefutablePat)

Harbormaster failed to build B7060: rGHC52b02e66025f: Comments only (isIrrefutablePat)!

BRANCHES
  master

USERS
  simonpj (Author)
  GHC - HsSyn/Parser (Auditor)
  GHC - Renamer (Auditor)

COMMIT
  https://phabricator.haskell.org/rGHC52b02e66025f

EMAIL PREFERENCES
  https://phabricator.haskell.org/settings/panel/emailpreferences/

To: simonpj, GHC - HsSyn/Parser, GHC - Renamer

From ben at smart-cactus.org  Wed Dec  2 17:19:44 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 02 Dec 2015 18:19:44 +0100
Subject: FW: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only
 (isIrrefutablePat)
In-Reply-To: <bbabc89bb30044338a03b32366bc4e4c@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-mx2hkzzcnqsjjp2gksma@phabricator.haskell.org>
 <20151202160510.57676.37892@phabricator.haskell.org>
 <bbabc89bb30044338a03b32366bc4e4c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87r3j44vkf.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Haddock is a constant mystery.
>
> I added five lines of comments to GHC's source code, and one of the
> Haddock performance tests fails (see below). That's all the patch
> contains.
>
Don't worry, I think it's niteria's patch that is to blame here.
Diffusion is a convenient way to check the state of the tree [1].

Cheers,

- Ben

[1] https://phabricator.haskell.org/diffusion/GHC/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151202/624ca363/attachment.sig>

From ben at well-typed.com  Wed Dec  2 19:34:10 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 02 Dec 2015 20:34:10 +0100
Subject: The GHC 8.0 feature freeze is coming
Message-ID: <87lh9c4pcd.fsf@smart-cactus.org>

tl;dr: feature freeze is imminent; get any remaining patches in ASAP.


Hello all,

The GHC 8.0 release cycle is quickly approaching its conclusion. While
there are a few patches still outstanding (most notably the no-kinds
branch to which we owe the major version number bump), most everything
else has at this point been merged.

If you are still sitting on a patch then please post it for review as
soon as possible. We will enter a formal feature freeze within the next
week. If things go according to plan we will have be able to fork the
8.0 branch shortly thereafter and have a release candidate within two
weeks.

Thanks to everyone who has contributed to this release!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151202/f7a65fc8/attachment.sig>

From omeragacan at gmail.com  Thu Dec  3 00:07:39 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 2 Dec 2015 19:07:39 -0500
Subject: ok to do reformatting commits?
In-Reply-To: <CACbaDy5suqBvgLhTsDwR0nA8J4tHJAuxKmNUcq7jbGV449ujqg@mail.gmail.com>
References: <CACbaDy5suqBvgLhTsDwR0nA8J4tHJAuxKmNUcq7jbGV449ujqg@mail.gmail.com>
Message-ID: <CAMQQO3=5uiLG-Wg=maaN64_NZCaccVPQ+MJVCqycAYr=Xgs3Ug@mail.gmail.com>

2015-11-24 22:14 GMT-05:00 Evan Laforge <qdunkan at gmail.com>:
> When I was doing a recent patch, I was annoyed by lint errors about
>>80 lines when I was just conforming to the existing style.

I just wanted to mention that I've been using --nolint flag of arc diff lately
and it's really great. It doesn't clutter Phabricator diff page with hundreds
of "lint error" boxes, unlike plain `arc diff`.

From niteria at gmail.com  Thu Dec  3 11:49:02 2015
From: niteria at gmail.com (Bartosz Nitka)
Date: Thu, 3 Dec 2015 11:49:02 +0000
Subject: FW: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only
 (isIrrefutablePat)
In-Reply-To: <87r3j44vkf.fsf@smart-cactus.org>
References: <diffusion-audit-PHID-CMIT-mx2hkzzcnqsjjp2gksma@phabricator.haskell.org>
 <20151202160510.57676.37892@phabricator.haskell.org>
 <bbabc89bb30044338a03b32366bc4e4c@DB4PR30MB030.064d.mgd.msft.net>
 <87r3j44vkf.fsf@smart-cactus.org>
Message-ID: <CAOSxnRiDPn0UAdkfKAHz--o3oxG4fCeWghP61FFipUNnuaSy+A@mail.gmail.com>

I've gathered some numbers (most recent commits last):

290def72f54db7969258b4541aaefc87b54ce448  44354749424  Implement warnings
for Semigroups as parent of Monoid
afb721390cd506f09ce9f04aa3fb19324c2ae5a0  44354739384  MkId: Typos in
comments
14d0f7f1221db758cd06a69f53803d9d0150164a  44354739384  Build system: Add
stage specific SRC_HC_(WARNING_)OPTS
6dce643d1981f1ecba2b38f5932720385999244b  44354736328  Fix grammar and typo
in TcTyDecls
36c1247846bbbc1af939c098660ce27ddaa36a0d  44354706024  Remove duplicated
line
44c3e3768e28199468d2ffff0b25db055d22c310  44354770368  Fix warning about
unused pattern variable
b432e2f39c095d8acbb0cfcc63bd08436c7a3e49  44354770368  Make the determinism
tests more robust
1e041b7382b6aa329e4ad9625439f811e0f27232  44420002848  Refactor treatment
of wildcards
218fdf92370021b900af1e78323764cceb7ac609  44420193216  Make the order of
fixities in the iface file deterministic
741f837d652fd00671614d52a6cb16fbc3758480  44489177576  Implement more
deterministic operations and document them

I've collected them on my machine and they differ from what harbormaster
reports, the last commit measured by harbormaster is 44728541608.

The target value is 40624322224 +/-10% and my numbers suggest it's been
steadily climbing out of that range. I don't know what this test measures
exactly, does it depend on the number of haddock comments in GHC's source?

Cheers,
Bartosz

2015-12-02 17:19 GMT+00:00 Ben Gamari <ben at smart-cactus.org>:

> Simon Peyton Jones <simonpj at microsoft.com> writes:
>
> > Haddock is a constant mystery.
> >
> > I added five lines of comments to GHC's source code, and one of the
> > Haddock performance tests fails (see below). That's all the patch
> > contains.
> >
> Don't worry, I think it's niteria's patch that is to blame here.
> Diffusion is a convenient way to check the state of the tree [1].
>
> Cheers,
>
> - Ben
>
> [1] https://phabricator.haskell.org/diffusion/GHC/
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/298c2f10/attachment.html>

From ben at smart-cactus.org  Thu Dec  3 12:16:51 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 03 Dec 2015 13:16:51 +0100
Subject: Warning suppression pragmas
In-Reply-To: <CAEvjXHSLBCtwx8UHe9vO62MYotU01Exm7bZNNh-VgrqBKytmpw@mail.gmail.com>
References: <CAEvjXHSLBCtwx8UHe9vO62MYotU01Exm7bZNNh-VgrqBKytmpw@mail.gmail.com>
Message-ID: <87si3j3ex8.fsf@smart-cactus.org>

????? ?????????? <edzhavoronkov at gmail.com> writes:

> Hello devs!
>
> I am trying to implement some kind of local warnings suppresion and i need
> some help.
>
> I want to use a pragma to mark functions so compiler won't throw warnings
> from them. I defined my pragma in lexer, parser and added type signature in
> HsBinds.hs. And i am stuck. I don't know what to do. What should i consider
> doing further?
>
I think it would be helpful to focus on further elaborating the
specification before we move into the implementation. There are still a
number of open questions about the design that the wiki page doesn't yet
address.

For instance, you should explicitly specify,

 * What are the identifiers that appear after the `SUPPRESS` token?

 * What exactly does the pragma apply to? For instance, if I have a case
   like,

       hello :: Int -> Int
       {-# SUPPRESS some-warning #-}
       helloAgain :: Type -> AnotherType
       hello = (+1)
       helloAgain = error "42"

   or even just
       hello = (+1)
       {-# SUPPRESS another-warning #-}
       helloAgain = error "oops"

   What do you expect to happen? The behavior of the pragma in both of
   these cases should be unambiguously stated in the specification.

 * An concrete use-case motivating the change (preferably with examples
   showing how the proposed syntax would address the motivation)

I know this sounds repetitive, but the act of writing down a proposal 
will help you immensely when you do move on to implementing your ideas.

Thanks for your persistence.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/4c4877a0/attachment.sig>

From stegeman at gmail.com  Thu Dec  3 12:57:38 2015
From: stegeman at gmail.com (Luite Stegeman)
Date: Thu, 03 Dec 2015 12:57:38 +0000
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <87lh9c4pcd.fsf@smart-cactus.org>
References: <87lh9c4pcd.fsf@smart-cactus.org>
Message-ID: <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>

Is Simon's remote GHCi patch planned to go in before the fork? I'm still
working on upgrading GHCJS to work with the master branch, but I haven't
quite finished yet. This change would clearly require some restructuring of
GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
to test the changes. Also the recent removal of boot file merging
reintroduces a problem with that I'm not sure can be fixed without adding a
new hook.

What's the policy on adding hooks or GHC API tweaks after the freeze?

cheers,

Luite

On Wed, Dec 2, 2015 at 7:34 PM Ben Gamari <ben at well-typed.com> wrote:

> tl;dr: feature freeze is imminent; get any remaining patches in ASAP.
>
>
> Hello all,
>
> The GHC 8.0 release cycle is quickly approaching its conclusion. While
> there are a few patches still outstanding (most notably the no-kinds
> branch to which we owe the major version number bump), most everything
> else has at this point been merged.
>
> If you are still sitting on a patch then please post it for review as
> soon as possible. We will enter a formal feature freeze within the next
> week. If things go according to plan we will have be able to fork the
> 8.0 branch shortly thereafter and have a release candidate within two
> weeks.
>
> Thanks to everyone who has contributed to this release!
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/16f78de4/attachment.html>

From simonpj at microsoft.com  Thu Dec  3 13:03:51 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 3 Dec 2015 13:03:51 +0000
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <87vb8f3fed.fsf@smart-cactus.org>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <cd3b6a721b9149f4900d1191a9630432@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_6xG6-F7d4RqOPEWpRP3xZ9kq=+MT+u4DEEBt0f=5MTkw@mail.gmail.com>
 <878u5b4zh7.fsf@smart-cactus.org>
 <CAEwUq_6Q7LnBzp=BCYbdTiO-tNUAUwr4Vfip5JGaehW3AR=JCw@mail.gmail.com>
 <87vb8f3fed.fsf@smart-cactus.org>
Message-ID: <938f21cfb3ff4b5d968029695d45c658@DB4PR30MB030.064d.mgd.msft.net>

|  HEAD is sadly currently broken for unrelated reasons which I am
|  working on resolving at the moment.  I'll send a message to ghc-devs
|  when I've pushed my fix.

Does that mean I should not pull for now?  Which means I can't push either.

Simon


From ben at well-typed.com  Thu Dec  3 13:45:44 2015
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 03 Dec 2015 14:45:44 +0100
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <938f21cfb3ff4b5d968029695d45c658@DB4PR30MB030.064d.mgd.msft.net>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <cd3b6a721b9149f4900d1191a9630432@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_6xG6-F7d4RqOPEWpRP3xZ9kq=+MT+u4DEEBt0f=5MTkw@mail.gmail.com>
 <878u5b4zh7.fsf@smart-cactus.org>
 <CAEwUq_6Q7LnBzp=BCYbdTiO-tNUAUwr4Vfip5JGaehW3AR=JCw@mail.gmail.com>
 <87vb8f3fed.fsf@smart-cactus.org>
 <938f21cfb3ff4b5d968029695d45c658@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87k2ov3at3.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  HEAD is sadly currently broken for unrelated reasons which I am
> |  working on resolving at the moment.  I'll send a message to ghc-devs
> |  when I've pushed my fix.
>
> Does that mean I should not pull for now?  Which means I can't push either.
>
No, feel free to pull and push.

The problem is that Harbormaster builds are failing to validate due to
changes in haddock allocations leading to failures of testsuite stat
tests [1]. Sadly I'm unable to reproduce this locally but I just pushed
what I believe should be a fix.

Sadly now we need to work through the fall-out from George's patch.

Cheers,

- Ben

[1] https://phabricator.haskell.org/harbormaster/build/8442/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/d876565f/attachment.sig>

From ben at well-typed.com  Thu Dec  3 13:50:26 2015
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 03 Dec 2015 14:50:26 +0100
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
Message-ID: <87h9jz3al9.fsf@smart-cactus.org>

Luite Stegeman <stegeman at gmail.com> writes:

> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
> working on upgrading GHCJS to work with the master branch, but I haven't
> quite finished yet. This change would clearly require some restructuring of
> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
> to test the changes. Also the recent removal of boot file merging
> reintroduces a problem with that I'm not sure can be fixed without adding a
> new hook.
>
Simon, what do you think about this?

I'm a bit worried that this patch is quite late and breaks users like
Luite. Nevertheless, I am willing to hear arguments for merging.

> What's the policy on adding hooks or GHC API tweaks after the freeze?
>
We'll need to work that out when we get to that point. It largely
depends upon how confined and "safe" a change appears to be. That being
said, given how much other churn has happened for this release, I don't
think we want to be sloppy with merge discipline this time around.

Austin, what do you think?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/d8c7bbf4/attachment.sig>

From austin at well-typed.com  Thu Dec  3 14:31:37 2015
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 3 Dec 2015 08:31:37 -0600
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <87h9jz3al9.fsf@smart-cactus.org>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org>
Message-ID: <CAEs96n1Ck+xTZ33HfBt8gk5yfTLkKM_ZugaLqGUzWMDGVTjS-w@mail.gmail.com>

On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari <ben at well-typed.com> wrote:
> Luite Stegeman <stegeman at gmail.com> writes:
>
>> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
>> working on upgrading GHCJS to work with the master branch, but I haven't
>> quite finished yet. This change would clearly require some restructuring of
>> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
>> to test the changes. Also the recent removal of boot file merging
>> reintroduces a problem with that I'm not sure can be fixed without adding a
>> new hook.
>>
> Simon, what do you think about this?
>
> I'm a bit worried that this patch is quite late and breaks users like
> Luite. Nevertheless, I am willing to hear arguments for merging.

I think this is one we're best off leaving in HEAD. It's a very large
change, and I'm a bit scared of bringing it in right at the finish
line, so to speak. I think it might be best to just get it in sometime
after the branch IMO...

>> What's the policy on adding hooks or GHC API tweaks after the freeze?
>>
> We'll need to work that out when we get to that point. It largely
> depends upon how confined and "safe" a change appears to be. That being
> said, given how much other churn has happened for this release, I don't
> think we want to be sloppy with merge discipline this time around.
>
> Austin, what do you think?
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

Hrm. If possible I would like to avoid any breaking changes past the
first RC, which has normally been my policy... Generally it's just
easier for everyone this way and people typically don't like too many
mid-flight changes, once things are in RC-mode.

That said, if it's something game-breaking for, say, GHCJS, I'd be
open to it. But we should try to fix it ASAP, not in the middle of
February. So it would be best if we could find out what hooks or
tweaks we needed Very Soon.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From alan.zimm at gmail.com  Thu Dec  3 14:44:42 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 3 Dec 2015 16:44:42 +0200
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <CAEs96n1Ck+xTZ33HfBt8gk5yfTLkKM_ZugaLqGUzWMDGVTjS-w@mail.gmail.com>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org>
 <CAEs96n1Ck+xTZ33HfBt8gk5yfTLkKM_ZugaLqGUzWMDGVTjS-w@mail.gmail.com>
Message-ID: <CANma=H-iCv10nSadvK99K1iCYRvbA=JJDB8rUh+O1c1ATo1tXw@mail.gmail.com>

My 2c, I would love to see the remote GHCi patch land for 8.0.

It is a  big change though.

Alan

On Thu, Dec 3, 2015 at 4:31 PM, Austin Seipp <austin at well-typed.com> wrote:
> On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari <ben at well-typed.com> wrote:
>> Luite Stegeman <stegeman at gmail.com> writes:
>>
>>> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
>>> working on upgrading GHCJS to work with the master branch, but I haven't
>>> quite finished yet. This change would clearly require some restructuring of
>>> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
>>> to test the changes. Also the recent removal of boot file merging
>>> reintroduces a problem with that I'm not sure can be fixed without adding a
>>> new hook.
>>>
>> Simon, what do you think about this?
>>
>> I'm a bit worried that this patch is quite late and breaks users like
>> Luite. Nevertheless, I am willing to hear arguments for merging.
>
> I think this is one we're best off leaving in HEAD. It's a very large
> change, and I'm a bit scared of bringing it in right at the finish
> line, so to speak. I think it might be best to just get it in sometime
> after the branch IMO...
>
>>> What's the policy on adding hooks or GHC API tweaks after the freeze?
>>>
>> We'll need to work that out when we get to that point. It largely
>> depends upon how confined and "safe" a change appears to be. That being
>> said, given how much other churn has happened for this release, I don't
>> think we want to be sloppy with merge discipline this time around.
>>
>> Austin, what do you think?
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> Hrm. If possible I would like to avoid any breaking changes past the
> first RC, which has normally been my policy... Generally it's just
> easier for everyone this way and people typically don't like too many
> mid-flight changes, once things are in RC-mode.
>
> That said, if it's something game-breaking for, say, GHCJS, I'd be
> open to it. But we should try to fix it ASAP, not in the middle of
> February. So it would be best if we could find out what hooks or
> tweaks we needed Very Soon.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From marlowsd at gmail.com  Thu Dec  3 17:50:37 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Dec 2015 17:50:37 +0000
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <87h9jz3al9.fsf@smart-cactus.org>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org>
Message-ID: <566080ED.8010406@gmail.com>

On 03/12/2015 13:50, Ben Gamari wrote:
> Luite Stegeman <stegeman at gmail.com> writes:
>
>> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
>> working on upgrading GHCJS to work with the master branch, but I haven't
>> quite finished yet. This change would clearly require some restructuring of
>> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
>> to test the changes. Also the recent removal of boot file merging
>> reintroduces a problem with that I'm not sure can be fixed without adding a
>> new hook.
>>
> Simon, what do you think about this?
>
> I'm a bit worried that this patch is quite late and breaks users like
> Luite. Nevertheless, I am willing to hear arguments for merging.

It doesn't have to go in, but I think it would be nice.  I'd like to 
have it out for at least one major release in a disabled-by-default 
state so that we can experiment with it.  But as far as my particular 
goals for this feature are concerned, I'll backport the patch to 7.10 
and use it in our local GHC build at Facebook regardless.

Luite - the hooks you use are still intact, so I don't think you have to 
do any major restructuring in GHCJS until you're ready.  What I've 
implemented will almost certainly need work to be usable or shareable 
with GHCJS, and it's not clear to me exactly what the changes will look 
like, but for the time being I thought the changes should not impact 
GHCJS's implementation of TH & GHCi.  I could be wrong though, if so 
please let me know how it breaks you.

Cheers,
Simon

>> What's the policy on adding hooks or GHC API tweaks after the freeze?
>>
> We'll need to work that out when we get to that point. It largely
> depends upon how confined and "safe" a change appears to be. That being
> said, given how much other churn has happened for this release, I don't
> think we want to be sloppy with merge discipline this time around.
>
> Austin, what do you think?
>
> Cheers,
>
> - Ben
>

From marlowsd at gmail.com  Thu Dec  3 18:18:54 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 3 Dec 2015 18:18:54 +0000
Subject: Bad interface file
In-Reply-To: <da23796f0559438cbe820b3240885473@DB4PR30MB030.064d.mgd.msft.net>
References: <da23796f0559438cbe820b3240885473@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <5660878E.1070803@gmail.com>

On 27/11/2015 15:31, Simon Peyton Jones wrote:
> Can anyone confirm that Trac #11122 is fixed in HEAD?
>
> When I try to reproduce it, I tried this, *with a freshly-built HEAD*
>
> cabal install parsec
> --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2
>
> But that fails as below, with a bizarre ?bad interface file? error.
> Does anyone have a clue about what?s happening?  Does it work for you?

You probably have .hi files generated by a previous version of HEAD 
installed under your ~/.cabal/lib, and the current HEAD chokes on them. 
  Try rm -rf ~/.cabal/lib/*ghc-7.11*

Cheers
Simon


> Simon
>
> cabal install parsec
> --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2
>
> Resolving dependencies...
>
> Configuring mtl-2.2.1...
>
> Building mtl-2.2.1...
>
> Preprocessing library mtl-2.2.1...
>
> [ 1 of 22] Compiling Control.Monad.Writer.Class (
> Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o )
>
> [ 2 of 22] Compiling Control.Monad.State.Class (
> Control/Monad/State/Class.hs, dist/build/Control/Monad/State/Class.o )
>
> [ 3 of 22] Compiling Control.Monad.Reader.Class (
> Control/Monad/Reader/Class.hs, dist/build/Control/Monad/Reader/Class.o )
>
> [ 4 of 22] Compiling Control.Monad.RWS.Class (
> Control/Monad/RWS/Class.hs, dist/build/Control/Monad/RWS/Class.o )
>
> [ 5 of 22] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs,
> dist/build/Control/Monad/Identity.o )
>
> [ 6 of 22] Compiling Control.Monad.Error.Class (
> Control/Monad/Error/Class.hs, dist/build/Control/Monad/Error/Class.o )
>
> [ 7 of 22] Compiling Control.Monad.Cont.Class (
> Control/Monad/Cont/Class.hs, dist/build/Control/Monad/Cont/Class.o )
>
> [ 8 of 22] Compiling Control.Monad.Trans ( Control/Monad/Trans.hs,
> dist/build/Control/Monad/Trans.o )
>
> [ 9 of 22] Compiling Control.Monad.Error ( Control/Monad/Error.hs,
> dist/build/Control/Monad/Error.o )
>
> [10 of 22] Compiling Control.Monad.Except ( Control/Monad/Except.hs,
> dist/build/Control/Monad/Except.o )
>
> [11 of 22] Compiling Control.Monad.List ( Control/Monad/List.hs,
> dist/build/Control/Monad/List.o )
>
> [12 of 22] Compiling Control.Monad.RWS.Lazy ( Control/Monad/RWS/Lazy.hs,
> dist/build/Control/Monad/RWS/Lazy.o )
>
> [13 of 22] Compiling Control.Monad.RWS ( Control/Monad/RWS.hs,
> dist/build/Control/Monad/RWS.o )
>
> [14 of 22] Compiling Control.Monad.Reader ( Control/Monad/Reader.hs,
> dist/build/Control/Monad/Reader.o )
>
> [15 of 22] Compiling Control.Monad.RWS.Strict (
> Control/Monad/RWS/Strict.hs, dist/build/Control/Monad/RWS/Strict.o )
>
> [16 of 22] Compiling Control.Monad.State.Lazy (
> Control/Monad/State/Lazy.hs, dist/build/Control/Monad/State/Lazy.o )
>
> [17 of 22] Compiling Control.Monad.State ( Control/Monad/State.hs,
> dist/build/Control/Monad/State.o )
>
> [18 of 22] Compiling Control.Monad.State.Strict (
> Control/Monad/State/Strict.hs, dist/build/Control/Monad/State/Strict.o )
>
> [19 of 22] Compiling Control.Monad.Writer.Lazy (
> Control/Monad/Writer/Lazy.hs, dist/build/Control/Monad/Writer/Lazy.o )
>
> [20 of 22] Compiling Control.Monad.Writer ( Control/Monad/Writer.hs,
> dist/build/Control/Monad/Writer.o )
>
> [21 of 22] Compiling Control.Monad.Writer.Strict (
> Control/Monad/Writer/Strict.hs, dist/build/Control/Monad/Writer/Strict.o )
>
> [22 of 22] Compiling Control.Monad.Cont ( Control/Monad/Cont.hs,
> dist/build/Control/Monad/Cont.o )
>
> In-place registering mtl-2.2.1...
>
> Creating package registration file: /tmp/pkgConf-mtl-2.253500.1
>
> Installing library in
>
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp
>
> Registering mtl-2.2.1...
>
> Installed mtl-2.2.1
>
> Downloading text-1.2.1.3...
>
> Failed to install text-1.2.1.3
>
> cabal: Error: some packages failed to install:
>
> parsec-3.1.9 depends on text-1.2.1.3 which failed to install.
>
> text-1.2.1.3 failed while downloading the package. The exception was:
>
> <socket: 10>: hGetBufSome: resource vanished (Connection reset by peer)
>
> simonpj at cam-05-unx:~/5builds/HEAD-5$ cabal install parsec
> --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2
>
> Resolving dependencies...
>
> Downloading text-1.2.1.3...
>
> Configuring text-1.2.1.3...
>
> Building text-1.2.1.3...
>
> Preprocessing library text-1.2.1.3...
>
> [ 1 of 44] Compiling Data.Text.Internal.Read (
> Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o )
>
> [ 2 of 44] Compiling Data.Text.Internal.Encoding.Utf32 (
> Data/Text/Internal/Encoding/Utf32.hs,
> dist/build/Data/Text/Internal/Encoding/Utf32.o )
>
> [ 3 of 44] Compiling Data.Text.Internal.Builder.RealFloat.Functions (
> Data/Text/Internal/Builder/RealFloat/Functions.hs,
> dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o )
>
> [ 4 of 44] Compiling Data.Text.Internal.Builder.Int.Digits (
> Data/Text/Internal/Builder/Int/Digits.hs,
> dist/build/Data/Text/Internal/Builder/Int/Digits.o )
>
> [ 5 of 44] Compiling Data.Text.Encoding.Error (
> Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o )
>
> Data/Text/Encoding/Error.hs:3:14: warning:
>
>      ?Data.Text.Encoding.Error? is marked as Trustworthy but has been
> inferred as safe!
>
> [ 6 of 44] Compiling Data.Text.Internal.Unsafe.Shift (
> Data/Text/Internal/Unsafe/Shift.hs,
> dist/build/Data/Text/Internal/Unsafe/Shift.o )
>
> [ 7 of 44] Compiling Data.Text.Internal.Encoding.Utf16 (
> Data/Text/Internal/Encoding/Utf16.hs,
> dist/build/Data/Text/Internal/Encoding/Utf16.o )
>
> [ 8 of 44] Compiling Data.Text.Internal.Functions (
> Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o )
>
> [ 9 of 44] Compiling Data.Text.Internal.Unsafe (
> Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o )
>
> [10 of 44] Compiling Data.Text.Array  ( Data/Text/Array.hs,
> dist/build/Data/Text/Array.o )
>
> [11 of 44] Compiling Data.Text.Internal.Unsafe.Char (
> Data/Text/Internal/Unsafe/Char.hs,
> dist/build/Data/Text/Internal/Unsafe/Char.o )
>
> [12 of 44] Compiling Data.Text.Internal ( Data/Text/Internal.hs,
> dist/build/Data/Text/Internal.o )
>
> [13 of 44] Compiling Data.Text.Internal.Fusion.Size (
> Data/Text/Internal/Fusion/Size.hs,
> dist/build/Data/Text/Internal/Fusion/Size.o )
>
> [14 of 44] Compiling Data.Text.Internal.Fusion.Types (
> Data/Text/Internal/Fusion/Types.hs,
> dist/build/Data/Text/Internal/Fusion/Types.o )
>
> [15 of 44] Compiling Data.Text.Internal.Fusion.CaseMapping (
> Data/Text/Internal/Fusion/CaseMapping.hs,
> dist/build/Data/Text/Internal/Fusion/CaseMapping.o )
>
> [16 of 44] Compiling Data.Text.Internal.Fusion.Common (
> Data/Text/Internal/Fusion/Common.hs,
> dist/build/Data/Text/Internal/Fusion/Common.o )
>
> [17 of 44] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs,
> dist/build/Data/Text/Unsafe.o )
>
> [18 of 44] Compiling Data.Text.Internal.Private (
> Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o )
>
> [19 of 44] Compiling Data.Text.Internal.Fusion (
> Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o )
>
> [20 of 44] Compiling Data.Text.Show   ( Data/Text/Show.hs,
> dist/build/Data/Text/Show.o )
>
> Data/Text/Show.hs:57:11: warning:
>
>      Rule "TEXT literal UTF8" may never fire
>
>        because ?unpackCStringUtf8#? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for
> ?unpackCStringUtf8#?
>
> [21 of 44] Compiling Data.Text.Internal.Encoding.Fusion.Common (
> Data/Text/Internal/Encoding/Fusion/Common.hs,
> dist/build/Data/Text/Internal/Encoding/Fusion/Common.o )
>
> [22 of 44] Compiling Data.Text.Internal.Encoding.Utf8 (
> Data/Text/Internal/Encoding/Utf8.hs,
> dist/build/Data/Text/Internal/Encoding/Utf8.o )
>
> [23 of 44] Compiling Data.Text.Internal.Encoding.Fusion (
> Data/Text/Internal/Encoding/Fusion.hs,
> dist/build/Data/Text/Internal/Encoding/Fusion.o )
>
> [24 of 44] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs,
> dist/build/Data/Text/Encoding.o )
>
> [25 of 44] Compiling Data.Text.Internal.Lazy.Encoding.Fusion (
> Data/Text/Internal/Lazy/Encoding/Fusion.hs,
> dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o )
>
> [26 of 44] Compiling Data.Text.Internal.Search (
> Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o )
>
> [27 of 44] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs,
> dist/build/Data/Text/Foreign.o )
>
> [28 of 44] Compiling Data.Text        ( Data/Text.hs,
> dist/build/Data/Text.o )
>
> Data/Text.hs:558:1: warning:
>
>      Rule "TEXT compareN/length -> compareLength" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:563:1: warning:
>
>      Rule "TEXT ==N/length -> compareLength/==EQ" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:568:1: warning:
>
>      Rule "TEXT /=N/length -> compareLength//=EQ" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:573:1: warning:
>
>      Rule "TEXT <N/length -> compareLength/==LT" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:578:1: warning:
>
>      Rule "TEXT <=N/length -> compareLength//=GT" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:583:1: warning:
>
>      Rule "TEXT >N/length -> compareLength/==GT" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> Data/Text.hs:588:1: warning:
>
>      Rule "TEXT >=N/length -> compareLength//=LT" may never fire
>
>        because ?length? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?length?
>
> [29 of 44] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs,
> dist/build/Data/Text/Internal/IO.o )
>
> [30 of 44] Compiling Data.Text.IO     ( Data/Text/IO.hs,
> dist/build/Data/Text/IO.o )
>
> [31 of 44] Compiling Data.Text.Internal.Lazy (
> Data/Text/Internal/Lazy.hs, dist/build/Data/Text/Internal/Lazy.o )
>
> [32 of 44] Compiling Data.Text.Internal.Lazy.Fusion (
> Data/Text/Internal/Lazy/Fusion.hs,
> dist/build/Data/Text/Internal/Lazy/Fusion.o )
>
> [33 of 44] Compiling Data.Text.Internal.Lazy.Search (
> Data/Text/Internal/Lazy/Search.hs,
> dist/build/Data/Text/Internal/Lazy/Search.o )
>
> [34 of 44] Compiling Data.Text.Lazy.Internal (
> Data/Text/Lazy/Internal.hs, dist/build/Data/Text/Lazy/Internal.o )
>
> [35 of 44] Compiling Data.Text.Lazy.Encoding (
> Data/Text/Lazy/Encoding.hs, dist/build/Data/Text/Lazy/Encoding.o )
>
> [36 of 44] Compiling Data.Text.Lazy   ( Data/Text/Lazy.hs,
> dist/build/Data/Text/Lazy.o )
>
> Data/Text/Lazy.hs:403:11: warning:
>
>      Rule "TEXT literal UTF8" may never fire
>
>        because ?unpackCStringUtf8#? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for
> ?unpackCStringUtf8#?
>
> [37 of 44] Compiling Data.Text.Internal.Builder (
> Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o )
>
> Data/Text/Internal/Builder.hs:311:1: warning:
>
>      Rule "flush/flush" may never fire
>
>        because ?flush? might inline first
>
>      Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ?flush?
>
> [38 of 44] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs,
> dist/build/Data/Text/Lazy/Builder.o )
>
> [39 of 44] Compiling Data.Text.Internal.Builder.Functions (
> Data/Text/Internal/Builder/Functions.hs,
> dist/build/Data/Text/Internal/Builder/Functions.o )
>
> [40 of 44] Compiling Data.Text.Lazy.Builder.Int (
> Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o )
>
> [41 of 44] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs,
> dist/build/Data/Text/Lazy/IO.o )
>
> [42 of 44] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs,
> dist/build/Data/Text/Lazy/Read.o )
>
> Data/Text/Lazy/Read.hs:3:14: warning:
>
>      ?Data.Text.Lazy.Read? is marked as Trustworthy but has been
> inferred as safe!
>
> [43 of 44] Compiling Data.Text.Lazy.Builder.RealFloat (
> Data/Text/Lazy/Builder/RealFloat.hs,
> dist/build/Data/Text/Lazy/Builder/RealFloat.o )
>
> [44 of 44] Compiling Data.Text.Read   ( Data/Text/Read.hs,
> dist/build/Data/Text/Read.o )
>
> In-place registering text-1.2.1.3...
>
> Creating package registration file: /tmp/pkgConf-text-1.2.118076.3
>
> Installing library in
>
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly
>
> Registering text-1.2.1.3...
>
> Installed text-1.2.1.3
>
> Configuring parsec-3.1.9...
>
> Building parsec-3.1.9...
>
> Preprocessing library parsec-3.1.9...
>
> [ 1 of 25] Compiling Text.Parsec.Pos  ( Text/Parsec/Pos.hs,
> dist/build/Text/Parsec/Pos.o )
>
> [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs,
> dist/build/Text/Parsec/Error.o )
>
> [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error (
> Text/ParserCombinators/Parsec/Error.hs,
> dist/build/Text/ParserCombinators/Parsec/Error.o )
>
> [ 4 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs,
> dist/build/Text/Parsec/Prim.o )
>
> Text/Parsec/Prim.hs:75:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text.hi
>
>          Something is amiss; requested module
> text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text
> differs from name found in the interface file
> text_5Rq52TgwV3S3ky6aLF96ly:Data.Text
>
> Text/Parsec/Prim.hs:76:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/text_5Rq52TgwV3S3ky6aLF96ly/Data/Text/Lazy.hi
>
>          Something is amiss; requested module
> text-1.2.1.3 at text-1.2.1.3-97fb94aeb32201606fe5187cbce5d852:Data.Text.Lazy differs
> from name found in the interface file
> text_5Rq52TgwV3S3ky6aLF96ly:Data.Text.Lazy
>
> Text/Parsec/Prim.hs:80:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Trans.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Trans
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Trans
>
> Text/Parsec/Prim.hs:81:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Identity.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Identity
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Identity
>
> Text/Parsec/Prim.hs:83:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Reader/Class.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Reader.Class
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Reader.Class
>
> Text/Parsec/Prim.hs:84:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/State/Class.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.State.Class
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.State.Class
>
> Text/Parsec/Prim.hs:85:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Cont/Class.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Cont.Class
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Cont.Class
>
> Text/Parsec/Prim.hs:86:1: error:
>
>      Bad interface file:
> /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp/Control/Monad/Error/Class.hi
>
>          Something is amiss; requested module
> mtl-2.2.1 at mtl-2.2.1-fd5d2a6f3b4f2b35d982c365df381a09:Control.Monad.Error.Class
> differs from name found in the interface file
> mtl_29yPYQfz4VvKtYIFBb0Wdp:Control.Monad.Error.Class
>
> Failed to install parsec-3.1.9
>
> cabal: Error: some packages failed to install:
>
> parsec-3.1.9 failed during the building phase. The exception was:
>
> ExitFailure 1
>
> simonpj at cam-05-unx:~/5builds/HEAD-5$
> /home/simonpj/5builds/HEAD-5/inplace/bin/ghc-pkg list
>
> /5playpen/simonpj/HEAD-5/inplace/lib/package.conf.d:
>
>      Cabal-1.23.0.0
>
>      array-0.5.1.0
>
>      base-4.9.0.0
>
>      binary-0.7.5.0
>
>      bytestring-0.10.6.0
>
>      containers-0.5.6.2
>
>      deepseq-1.4.2.0
>
>      directory-1.2.5.0
>
>      filepath-1.4.1.0
>
>      (ghc-7.11.20151125)
>
>      ghc-boot-0.0.0.0
>
>      ghc-prim-0.5.0.0
>
>      haskeline-0.7.2.1
>
>      hoopl-3.10.2.0
>
>      hpc-0.6.0.2
>
>      integer-gmp-1.0.0.0
>
>      pretty-1.1.2.0
>
>      process-1.4.1.0
>
>      rts-1.0
>
>      template-haskell-2.11.0.0
>
>      terminfo-0.4.0.1
>
>      time-1.5.0.1
>
>      transformers-0.4.3.0
>
>      unix-2.7.1.0
>
>      xhtml-3000.2.1
>
> /home/simonpj/.ghc/x86_64-linux-7.11.20151125/package.conf.d:
>
>      mtl-2.2.1
>
>      text-1.2.1.3
>
> simonpj at cam-05-unx:~/5builds/HEAD-5$
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From eir at cis.upenn.edu  Thu Dec  3 18:43:11 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 3 Dec 2015 13:43:11 -0500
Subject: tyVarsOfTypeAcc
Message-ID: <31727DE0-FA40-44D3-B124-E77B11C4815F@cis.upenn.edu>

Hi devs,

I'm (once again) merging master into my type=kind branch. I see that we now have tyVarsOfTypeAcc :: Type -> FV, distinct from tyVarsOfType :: Type -> TyVarSet. I trust that this new version is more performant. However, I have a question: in the implementation of these functions, the three extra FV parameters (fv_cand in_scope acc) are bound and passed each time. 

Why?

I've always understood that eta-reducing in function definitions is better than expanding. Or is this just a style choice?

Thanks,
Richard

From xichekolas at gmail.com  Thu Dec  3 19:04:34 2015
From: xichekolas at gmail.com (Andrew Farmer)
Date: Thu, 3 Dec 2015 11:04:34 -0800
Subject: tyVarsOfTypeAcc
In-Reply-To: <31727DE0-FA40-44D3-B124-E77B11C4815F@cis.upenn.edu>
References: <31727DE0-FA40-44D3-B124-E77B11C4815F@cis.upenn.edu>
Message-ID: <CAJ14jR9=waTbHOwj2F=WcGiU1rvOZLc3HvtDzgF7dSw3=SzKmA@mail.gmail.com>

Bartosz left a note in the diff about it being faster this way:

https://github.com/niteria/deterministic-fvs/blob/master/results.txt#L83-L89

But yeah, I would have also thought it better eta-reduced.

On Thu, Dec 3, 2015 at 10:43 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Hi devs,
>
> I'm (once again) merging master into my type=kind branch. I see that we now have tyVarsOfTypeAcc :: Type -> FV, distinct from tyVarsOfType :: Type -> TyVarSet. I trust that this new version is more performant. However, I have a question: in the implementation of these functions, the three extra FV parameters (fv_cand in_scope acc) are bound and passed each time.
>
> Why?
>
> I've always understood that eta-reducing in function definitions is better than expanding. Or is this just a style choice?
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From niteria at gmail.com  Thu Dec  3 19:04:40 2015
From: niteria at gmail.com (Bartosz Nitka)
Date: Thu, 3 Dec 2015 19:04:40 +0000
Subject: tyVarsOfTypeAcc
In-Reply-To: <31727DE0-FA40-44D3-B124-E77B11C4815F@cis.upenn.edu>
References: <31727DE0-FA40-44D3-B124-E77B11C4815F@cis.upenn.edu>
Message-ID: <CAOSxnRguEaRKsduQS81NP9xEM3pd8FpSzNT=GAhr7Y6xJLQXRQ@mail.gmail.com>

Hi Richard,

I've introduced tyVarsOfTypeAcc recently and the main reason was to get
deterministic order (part of #4012) of free variables in places that
require it, like abstracting type variables when floating out expressions.
It does a bit more than tyVarsOfType, but it's algorithmically better (it
avoids set union) and in the end it comes out about equal in terms of
performance on GHC tests.

The reason for eta-expanding is performance, and I wrote a note [1] about
it.
I've also run some isolated benchmarks [2] if you're interested.

[1]
https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/utils/FV.hs;43a31fe4c0cc0f72dfe9e0c96e1576f5cfba6e19$105-140
[2] https://github.com/niteria/deterministic-fvs/

Cheers,
Bartosz

2015-12-03 18:43 GMT+00:00 Richard Eisenberg <eir at cis.upenn.edu>:

> Hi devs,
>
> I'm (once again) merging master into my type=kind branch. I see that we
> now have tyVarsOfTypeAcc :: Type -> FV, distinct from tyVarsOfType :: Type
> -> TyVarSet. I trust that this new version is more performant. However, I
> have a question: in the implementation of these functions, the three extra
> FV parameters (fv_cand in_scope acc) are bound and passed each time.
>
> Why?
>
> I've always understood that eta-reducing in function definitions is better
> than expanding. Or is this just a style choice?
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151203/6316d672/attachment.html>

From ezyang at mit.edu  Thu Dec  3 20:25:23 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 03 Dec 2015 12:25:23 -0800
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <566080ED.8010406@gmail.com>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org> <566080ED.8010406@gmail.com>
Message-ID: <1449174261-sup-4362@sabre>

Based on my cursory look at the patch, I think it's unlikely to
break existing functionality in subtle ways.  So I'm OK with
trying to ship it in 8.0

Edward

Excerpts from Simon Marlow's message of 2015-12-03 09:50:37 -0800:
> On 03/12/2015 13:50, Ben Gamari wrote:
> > Luite Stegeman <stegeman at gmail.com> writes:
> >
> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
> >> working on upgrading GHCJS to work with the master branch, but I haven't
> >> quite finished yet. This change would clearly require some restructuring of
> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
> >> to test the changes. Also the recent removal of boot file merging
> >> reintroduces a problem with that I'm not sure can be fixed without adding a
> >> new hook.
> >>
> > Simon, what do you think about this?
> >
> > I'm a bit worried that this patch is quite late and breaks users like
> > Luite. Nevertheless, I am willing to hear arguments for merging.
> 
> It doesn't have to go in, but I think it would be nice.  I'd like to 
> have it out for at least one major release in a disabled-by-default 
> state so that we can experiment with it.  But as far as my particular 
> goals for this feature are concerned, I'll backport the patch to 7.10 
> and use it in our local GHC build at Facebook regardless.
> 
> Luite - the hooks you use are still intact, so I don't think you have to 
> do any major restructuring in GHCJS until you're ready.  What I've 
> implemented will almost certainly need work to be usable or shareable 
> with GHCJS, and it's not clear to me exactly what the changes will look 
> like, but for the time being I thought the changes should not impact 
> GHCJS's implementation of TH & GHCi.  I could be wrong though, if so 
> please let me know how it breaks you.
> 
> Cheers,
> Simon
> 
> >> What's the policy on adding hooks or GHC API tweaks after the freeze?
> >>
> > We'll need to work that out when we get to that point. It largely
> > depends upon how confined and "safe" a change appears to be. That being
> > said, given how much other churn has happened for this release, I don't
> > think we want to be sloppy with merge discipline this time around.
> >
> > Austin, what do you think?
> >
> > Cheers,
> >
> > - Ben
> >

From marlowsd at gmail.com  Fri Dec  4 08:34:40 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 4 Dec 2015 08:34:40 +0000
Subject: Plugins: How to determine ghc vs ghci
In-Reply-To: <CACOpX0fwh4Ty05aFXereirQB=L_G3CHTwDJrfaA7=wAyA1M6dw@mail.gmail.com>
References: <CACOpX0fwh4Ty05aFXereirQB=L_G3CHTwDJrfaA7=wAyA1M6dw@mail.gmail.com>
Message-ID: <56615020.9070705@gmail.com>

On 24/11/2015 07:37, Levent Erkok wrote:
> I'm working on a plugin, and would like to be able to tell if it's GHC
> or GHCi that's running.
>
> I tried:
>
>     df   <- getDynFlags
>     let isGHCi = ghcMode df == CompManager
>
> Alas, while that correctly tells apart "ghci" from "ghc -c", it also
> returns True when ghc is called without the "-c" argument.
>
> Is there a better/more robust way of figuring out whether we're in an
> interactive session?

The best way is to check whether hscTarget df == HscInterpreted, and you 
can also check whether ghcLink df == LinkInMemory.

Checking for the `--interactive` flag only works for the standalone 
GHCi, and not users of the GHC API.

Cheers,
Simon

From ggreif at gmail.com  Fri Dec  4 12:41:31 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Fri, 4 Dec 2015 13:41:31 +0100
Subject: [commit: ghc] master: Check: More Clang/CPP wibbles (befc4e4)
In-Reply-To: <20151204120726.0C2403A300@ghc.haskell.org>
References: <20151204120726.0C2403A300@ghc.haskell.org>
Message-ID: <CAK-hX0mbuc9bD9AZ-HMQzNqrfrPz4oe0pbZpZWyudwoPm+JYZA@mail.gmail.com>

Hi Ben,

there are still a bunch left:

git grep "ASSERT ("

Cheers,

    Gabor

On 12/4/15, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/befc4e4c4c76fd89a092240935d9f508de2ee664/ghc
>
>>---------------------------------------------------------------
>
> commit befc4e4c4c76fd89a092240935d9f508de2ee664
> Author: Ben Gamari <ben at smart-cactus.org>
> Date:   Fri Dec 4 13:07:16 2015 +0100
>
>     Check: More Clang/CPP wibbles
>
>
>>---------------------------------------------------------------
>
> befc4e4c4c76fd89a092240935d9f508de2ee664
>  compiler/deSugar/Check.hs | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/compiler/deSugar/Check.hs b/compiler/deSugar/Check.hs
> index 55dcfc2..dcf3b23 100644
> --- a/compiler/deSugar/Check.hs
> +++ b/compiler/deSugar/Check.hs
> @@ -370,12 +370,12 @@ translateConPatVec  univ_tys  ex_tvs c (RecCon
> (HsRecFields fs _))
>      -- The data constructor was not defined using record syntax. For the
>      -- pattern to be in record syntax it should be empty (e.g. Just {}).
>      -- So just like the previous case.
> -  | null orig_lbls = ASSERT (null matched_lbls) mkPatternVarsSM arg_tys
> +  | null orig_lbls = ASSERT(null matched_lbls) mkPatternVarsSM arg_tys
>      -- Some of the fields appear, in the original order (there may be
> holes).
>      -- Generate a simple constructor pattern and make up fresh variables
> for
>      -- the rest of the fields
>    | matched_lbls `subsetOf` orig_lbls
> -  = ASSERT (length orig_lbls == length arg_tys)
> +  = ASSERT(length orig_lbls == length arg_tys)
>        let translateOne (lbl, ty) = case lookup lbl matched_pats of
>              Just p  -> translatePat p
>              Nothing -> mkPatternVarsSM [ty]
> @@ -616,7 +616,7 @@ process_guards us  gs
>  -- * Basic utilities
>
>  patternType :: Pattern -> Type
> -patternType (PmGuard pv _) = ASSERT (patVecArity pv == 1) (patternType p)
> +patternType (PmGuard pv _) = ASSERT(patVecArity pv == 1) (patternType p)
>    where Just p = find ((==1) . patternArity) pv
>  patternType (NonGuard pat) = pmPatType pat
>
> @@ -826,8 +826,8 @@ splitConstraints (c : rest)
>    = case c of
>        TyConstraint cs    -> (cs ++ ty_cs, tm_cs, bot_cs)
>        TmConstraint e1 e2 -> (ty_cs, (e1,e2):tm_cs, bot_cs)
> -      BtConstraint cs    -> ASSERT (isNothing bot_cs) -- NB: Only one x ~
> _|_
> -                                   (ty_cs, tm_cs, Just cs)
> +      BtConstraint cs    -> ASSERT(isNothing bot_cs) -- NB: Only one x ~
> _|_
> +                                  (ty_cs, tm_cs, Just cs)
>    where
>      (ty_cs, tm_cs, bot_cs) = splitConstraints rest
>
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>

From ben at smart-cactus.org  Fri Dec  4 13:05:44 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 04 Dec 2015 14:05:44 +0100
Subject: [commit: ghc] master: Check: More Clang/CPP wibbles (befc4e4)
In-Reply-To: <CAK-hX0mbuc9bD9AZ-HMQzNqrfrPz4oe0pbZpZWyudwoPm+JYZA@mail.gmail.com>
References: <20151204120726.0C2403A300@ghc.haskell.org>
 <CAK-hX0mbuc9bD9AZ-HMQzNqrfrPz4oe0pbZpZWyudwoPm+JYZA@mail.gmail.com>
Message-ID: <87mvtqs6s7.fsf@smart-cactus.org>

Gabor Greif <ggreif at gmail.com> writes:

> Hi Ben,
>
> there are still a bunch left:
>
Indeed there are many in the RTS but for some reason these have never
caused trouble. That being said, I have a patch removing them, as well
as a linter to ensure that they don't return in the future. I'm waiting
until the tree is green before I commit these, however.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151204/5634c1be/attachment.sig>

From simonpj at microsoft.com  Fri Dec  4 13:38:02 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Dec 2015 13:38:02 +0000
Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004
In-Reply-To: <CAEwUq_4VomWFqkgf65qkjf6Xj7UJ83pWdfjNqiFYa=yz8_PMYw@mail.gmail.com>
References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org>
 <061.2d20470d60b801e626e753537141c7d6@haskell.org>
 <CAEwUq_4VomWFqkgf65qkjf6Xj7UJ83pWdfjNqiFYa=yz8_PMYw@mail.gmail.com>
Message-ID: <2bbaa8a90be64d1da6b4ae0bc3ef5262@DB4PR30MB030.064d.mgd.msft.net>

No let?s not revert.  But:

?         Please put a list of the tickets (there are several) on the wiki page (where is the wiki page?)

o   perf/compiler/T783

o   #11163: perf/compiler/T5642

o

?         Let?s have a flag to skip overlap testing so that there is always a workaround

?         Are you happy to continue to work on these perf issues?

Simon

From: George Karachalias [mailto:george.karachalias at gmail.com]
Sent: 04 December 2015 09:41
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: [GHC] #11160: New exhaustiveness checker breaks ghcirun004

Simon,

On Fri, Dec 4, 2015 at 10:34 AM, GHC <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
Comment (by simonpj):

 Very fast response thank you.

 Your commit message is very informative.  Did you include the same
 information in a `Note` in the code, so that we don't lose the information
 here?

I haven't yet but I can. Actually, I wanted to ask you something. At the moment
I pass all the normal tests but I fail some performance tests. They do compile but there is a
deviation from the expected and HEAD is broken. For the additional expressive power I expected
some more memory and time. For example, for perf/compiler/T783.hs which has 500 guards in a
single function definition I take ~5 sec to compile but the deviation in allocated bytes is 753%,
compared to what the "expected" is. I feel terrible since we are really close to the freeze and I
think I am stalling everyone. I know of no good way to reduce memory consumption without
losing substantial expressivity. Do you think I shall revert?

George
--
things you own end up owning you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151204/eae76884/attachment-0001.html>

From stegeman at gmail.com  Fri Dec  4 14:04:22 2015
From: stegeman at gmail.com (Luite Stegeman)
Date: Fri, 04 Dec 2015 14:04:22 +0000
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <566080ED.8010406@gmail.com>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org> <566080ED.8010406@gmail.com>
Message-ID: <CALqQuohFPk_paoVnQJBhVvU4dm1+CBMYSUsW-jso2CUu_Q9Wbw@mail.gmail.com>

Oh I don't want to block anything from being merged, if anything I'd like
to see it get added and actually use the new intrastructure. Unfortunately
it looks like I already need some hook changes to make GHCJSi work
reasonably well, without having to copy/paste huge loads of GHC code into
GHCJS, but it'd feel a bit silly to add hooks for something where a proper
solution is already in place. So I would like to try to update GHCJS to use
this, if there's a good chance that this gets merged.

I just hope that I have enough time to do all of this and verify that
things work before the freeze. It's a bit unfortunate that I can only be
really sure when I actually have things running, and there's always a lot
of work involved in updating GHCJS and its dependencies to work with GHC
HEAD, with many big changes always landing right before the freeze.

cheers,

Luite

On Thu, Dec 3, 2015 at 5:50 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On 03/12/2015 13:50, Ben Gamari wrote:
> > Luite Stegeman <stegeman at gmail.com> writes:
> >
> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
> >> working on upgrading GHCJS to work with the master branch, but I haven't
> >> quite finished yet. This change would clearly require some
> restructuring of
> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is
> enough
> >> to test the changes. Also the recent removal of boot file merging
> >> reintroduces a problem with that I'm not sure can be fixed without
> adding a
> >> new hook.
> >>
> > Simon, what do you think about this?
> >
> > I'm a bit worried that this patch is quite late and breaks users like
> > Luite. Nevertheless, I am willing to hear arguments for merging.
>
> It doesn't have to go in, but I think it would be nice.  I'd like to
> have it out for at least one major release in a disabled-by-default
> state so that we can experiment with it.  But as far as my particular
> goals for this feature are concerned, I'll backport the patch to 7.10
> and use it in our local GHC build at Facebook regardless.
>
> Luite - the hooks you use are still intact, so I don't think you have to
> do any major restructuring in GHCJS until you're ready.  What I've
> implemented will almost certainly need work to be usable or shareable
> with GHCJS, and it's not clear to me exactly what the changes will look
> like, but for the time being I thought the changes should not impact
> GHCJS's implementation of TH & GHCi.  I could be wrong though, if so
> please let me know how it breaks you.
>
> Cheers,
> Simon
>
> >> What's the policy on adding hooks or GHC API tweaks after the freeze?
> >>
> > We'll need to work that out when we get to that point. It largely
> > depends upon how confined and "safe" a change appears to be. That being
> > said, given how much other churn has happened for this release, I don't
> > think we want to be sloppy with merge discipline this time around.
> >
> > Austin, what do you think?
> >
> > Cheers,
> >
> > - Ben
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151204/1f2d5554/attachment.html>

From alan.zimm at gmail.com  Fri Dec  4 14:12:43 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 4 Dec 2015 16:12:43 +0200
Subject: The GHC 8.0 feature freeze is coming
In-Reply-To: <CALqQuohFPk_paoVnQJBhVvU4dm1+CBMYSUsW-jso2CUu_Q9Wbw@mail.gmail.com>
References: <87lh9c4pcd.fsf@smart-cactus.org>
 <CALqQuoiZavuKwQn40whV_1JqZJ-R-URy3dbg++dVF4O-P7ZBLw@mail.gmail.com>
 <87h9jz3al9.fsf@smart-cactus.org> <566080ED.8010406@gmail.com>
 <CALqQuohFPk_paoVnQJBhVvU4dm1+CBMYSUsW-jso2CUu_Q9Wbw@mail.gmail.com>
Message-ID: <CANma=H-2zvfN2mUMMfqXHBeKta9QwS0g4n-=MHjWY+8uwBtdvA@mail.gmail.com>

Well, its a feature freeze, not a release, so I imagine bugs can still
be fixed as they come up.

Alan

On Fri, Dec 4, 2015 at 4:04 PM, Luite Stegeman <stegeman at gmail.com> wrote:
> Oh I don't want to block anything from being merged, if anything I'd like to
> see it get added and actually use the new intrastructure. Unfortunately it
> looks like I already need some hook changes to make GHCJSi work reasonably
> well, without having to copy/paste huge loads of GHC code into GHCJS, but
> it'd feel a bit silly to add hooks for something where a proper solution is
> already in place. So I would like to try to update GHCJS to use this, if
> there's a good chance that this gets merged.
>
> I just hope that I have enough time to do all of this and verify that things
> work before the freeze. It's a bit unfortunate that I can only be really
> sure when I actually have things running, and there's always a lot of work
> involved in updating GHCJS and its dependencies to work with GHC HEAD, with
> many big changes always landing right before the freeze.
>
> cheers,
>
> Luite
>
> On Thu, Dec 3, 2015 at 5:50 PM Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> On 03/12/2015 13:50, Ben Gamari wrote:
>> > Luite Stegeman <stegeman at gmail.com> writes:
>> >
>> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm
>> >> still
>> >> working on upgrading GHCJS to work with the master branch, but I
>> >> haven't
>> >> quite finished yet. This change would clearly require some
>> >> restructuring of
>> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is
>> >> enough
>> >> to test the changes. Also the recent removal of boot file merging
>> >> reintroduces a problem with that I'm not sure can be fixed without
>> >> adding a
>> >> new hook.
>> >>
>> > Simon, what do you think about this?
>> >
>> > I'm a bit worried that this patch is quite late and breaks users like
>> > Luite. Nevertheless, I am willing to hear arguments for merging.
>>
>> It doesn't have to go in, but I think it would be nice.  I'd like to
>> have it out for at least one major release in a disabled-by-default
>> state so that we can experiment with it.  But as far as my particular
>> goals for this feature are concerned, I'll backport the patch to 7.10
>> and use it in our local GHC build at Facebook regardless.
>>
>> Luite - the hooks you use are still intact, so I don't think you have to
>> do any major restructuring in GHCJS until you're ready.  What I've
>> implemented will almost certainly need work to be usable or shareable
>> with GHCJS, and it's not clear to me exactly what the changes will look
>> like, but for the time being I thought the changes should not impact
>> GHCJS's implementation of TH & GHCi.  I could be wrong though, if so
>> please let me know how it breaks you.
>>
>> Cheers,
>> Simon
>>
>> >> What's the policy on adding hooks or GHC API tweaks after the freeze?
>> >>
>> > We'll need to work that out when we get to that point. It largely
>> > depends upon how confined and "safe" a change appears to be. That being
>> > said, given how much other churn has happened for this release, I don't
>> > think we want to be sloppy with merge discipline this time around.
>> >
>> > Austin, what do you think?
>> >
>> > Cheers,
>> >
>> > - Ben
>> >
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From ben at well-typed.com  Fri Dec  4 14:22:54 2015
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 04 Dec 2015 15:22:54 +0100
Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004
In-Reply-To: <2bbaa8a90be64d1da6b4ae0bc3ef5262@DB4PR30MB030.064d.mgd.msft.net>
References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org>
 <061.2d20470d60b801e626e753537141c7d6@haskell.org>
 <CAEwUq_4VomWFqkgf65qkjf6Xj7UJ83pWdfjNqiFYa=yz8_PMYw@mail.gmail.com>
 <2bbaa8a90be64d1da6b4ae0bc3ef5262@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87h9jys37l.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> No let?s not revert.  But:
>
> ?         Please put a list of the tickets (there are several) on the wiki page (where is the wiki page?)
>
> o   perf/compiler/T783
>
> o   #11163: perf/compiler/T5642
>
> o
>
> ?         Let?s have a flag to skip overlap testing so that there is always a workaround
>
Indeed, given that there appear to be relatively few (and, moreover, fairly pathological)
programs that send things astray this should be a fine workaround for 8.0. While
you introduce the flag be sure to add a mention in the documentation:

  * Update the note in `docs/user_guide/bugs.rst` to reflect the current
    state of the pattern match check.

  * Add a point to `bugs.rst` to describe the performance issue and the
    workaround. Describe, if you can, some heuristics that users might
    use to determine whether skipping overlap testing might be necessary
    for their program.

  * A note in `docs/user_guide/using-warnings.rst` describing the
    new flag, linking to the description of the performance issue in
    `bugs.rst`
    
  * Add a description of the flag to `utils/mkUserGuidePart/Options/Warnings.hs`

Also, perhaps we could handle future work via the usual Phabricator
route? While we sometimes do deviate from Phabricator for larger patches
like the original exhaustiveness checker merge, typically all other
patches are processed through Phabricator, which offers the advantage
that we can easily see in advance whether things will break.


> From: George Karachalias [mailto:george.karachalias at gmail.com]
> Sent: 04 December 2015 09:41
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Subject: Re: [GHC] #11160: New exhaustiveness checker breaks ghcirun004
>
> I feel terrible since we are really close to the freeze and I think I am stalling everyone. 

Don't fret too much, it happens. Moreover, I deserve a large portion of
the blame as I neglected to mention the existence of our validation
script. Regardless things are pretty much back to normal at this point;
life goes on...

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151204/51f9ae63/attachment.sig>

From eir at cis.upenn.edu  Fri Dec  4 21:44:51 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 4 Dec 2015 16:44:51 -0500
Subject: warnings in stage1
Message-ID: <CAB03660-8193-423D-BC33-D201C1B93E51@cis.upenn.edu>

Hi devs,

I'm getting pattern-match warnings in my stage1 compiler. I assume that this is due to enhanced pattern-match checking. This is good! But I like to build (even stage1) with -Werror.

Is this expected? Is someone working on this?

Thanks!
Richard

From eir at cis.upenn.edu  Fri Dec  4 21:48:57 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 4 Dec 2015 16:48:57 -0500
Subject: warnings in stage1
In-Reply-To: <CAB03660-8193-423D-BC33-D201C1B93E51@cis.upenn.edu>
References: <CAB03660-8193-423D-BC33-D201C1B93E51@cis.upenn.edu>
Message-ID: <E8D26042-8ACF-43B7-96D2-8D49FB04AFFD@cis.upenn.edu>

For what it's worth, I would get behind a movement to allow warnings in stage1, as long as we keep stage2 warning-free. That is, I could forgo my -Werror during stage1 if we felt that it's just better that way.

Richard

On Dec 4, 2015, at 4:44 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi devs,
> 
> I'm getting pattern-match warnings in my stage1 compiler. I assume that this is due to enhanced pattern-match checking. This is good! But I like to build (even stage1) with -Werror.
> 
> Is this expected? Is someone working on this?
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From erkokl at gmail.com  Sat Dec  5 01:39:22 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Fri, 4 Dec 2015 17:39:22 -0800
Subject: Plugins: How to determine ghc vs ghci
In-Reply-To: <56615020.9070705@gmail.com>
References: <CACOpX0fwh4Ty05aFXereirQB=L_G3CHTwDJrfaA7=wAyA1M6dw@mail.gmail.com>
 <56615020.9070705@gmail.com>
Message-ID: <CACOpX0fVDjHbUhH6p7fj=rhObzcGy+2RAGK29nSbthyLASQyTQ@mail.gmail.com>

Thanks Simon.. I tried the 'hscTarget df == HscInterpreted' check, and it
works perfectly well.

-Levent.

On Fri, Dec 4, 2015 at 12:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 24/11/2015 07:37, Levent Erkok wrote:
>
>> I'm working on a plugin, and would like to be able to tell if it's GHC
>> or GHCi that's running.
>>
>> I tried:
>>
>>     df   <- getDynFlags
>>     let isGHCi = ghcMode df == CompManager
>>
>> Alas, while that correctly tells apart "ghci" from "ghc -c", it also
>> returns True when ghc is called without the "-c" argument.
>>
>> Is there a better/more robust way of figuring out whether we're in an
>> interactive session?
>>
>
> The best way is to check whether hscTarget df == HscInterpreted, and you
> can also check whether ghcLink df == LinkInMemory.
>
> Checking for the `--interactive` flag only works for the standalone GHCi,
> and not users of the GHC API.
>
> Cheers,
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151204/b1d0e3a2/attachment.html>

From eir at cis.upenn.edu  Sat Dec  5 03:48:06 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 4 Dec 2015 22:48:06 -0500
Subject: Phab out of memory
Message-ID: <626D231D-D1F4-4F7A-8B36-29B177A6CCC2@cis.upenn.edu>

I just tried to update D808, but the following happened. Any ideas?

Thanks,
Richard


rae:22:44:22 ~/Documents/ghc> arc diff origin/master --update D808 --allow-untracked --head HEAD --trace
libphutil loaded from '/Users/rae/local/share/libphutil/src'.
arcanist loaded from '/Users/rae/local/share/arcanist/src'.
Config: Reading user configuration file "/Users/rae/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/Users/rae/Documents/ghc/.arcconfig".
Working Copy: Path "/Users/rae/Documents/ghc" is part of `git` working copy "/Users/rae/Documents/ghc".
Working Copy: Project root is at "/Users/rae/Documents/ghc".
Config: Did not find local configuration at "/Users/rae/Documents/ghc/.git/arc/config".
Loading phutil library from '/Users/rae/Documents/ghc/.arc-linters/arcanist-external-json-linter'...
>>> [0] <conduit> conduit.connect() <bytes = 545>
>>> [1] <http> https://phabricator.haskell.org/api/conduit.connect
<<< [1] <http> 172,210 us
<<< [0] <conduit> 1,237,507 us
>>> [2] <event> diff.didCollectChanges <listeners = 0>
<<< [2] <event> 138 us
>>> [3] <conduit> differential.query() <bytes = 189>
>>> [4] <http> https://phabricator.haskell.org/api/differential.query
<<< [4] <http> 134,230 us
<<< [3] <conduit> 134,659 us
>>> [5] <conduit> differential.getcommitmessage() <bytes = 212>
>>> [6] <http> https://phabricator.haskell.org/api/differential.getcommitmessage
<<< [6] <http> 109,179 us
<<< [5] <conduit> 109,721 us
>>> [7] <conduit> differential.parsecommitmessage() <bytes = 1,358>
>>> [8] <http> https://phabricator.haskell.org/api/differential.parsecommitmessage
<<< [8] <http> 106,739 us
<<< [7] <conduit> 107,306 us
>>> [9] <event> diff.didBuildMessage <listeners = 0>
<<< [9] <event> 168 us
>>> [10] <exec> $ git rev-parse --git-dir
<<< [10] <exec> 8,502 us
>>> [11] <exec> $ git rev-parse 'HEAD'
<<< [11] <exec> 5,632 us
>>> [12] <exec> $ git merge-base 'origin/master' '9eb7237750f9409a4e1b00c509f2519983d97130'
<<< [12] <exec> 119,778 us
>>> [13] <exec> $ git log --first-parent --format=medium 'c865c425a37b0bc52f4dead9d70eb0ee2bc287d6'..'9eb7237750f9409a4e1b00c509f2519983d97130'
<<< [13] <exec> 117,008 us
>>> [14] <conduit> differential.querydiffs() <bytes = 191>
>>> [15] <http> https://phabricator.haskell.org/api/differential.querydiffs
<<< [15] <http> 3,462,000 us
<<< [14] <conduit> 3,462,526 us

[2015-12-05 03:44:31] EXCEPTION: (HTTPFutureHTTPResponseStatus) [HTTP/500] Internal Server Error
>>> UNRECOVERABLE FATAL ERROR <<<

Out of memory (allocated 501743616) (tried to allocate 70083487 bytes)

/opt/phabricator/src/aphront/response/AphrontResponse.php:167


??? ? ?\_(?)_/? ? ??? at [<phutil>/src/future/http/BaseHTTPFuture.php:339]
arcanist(head=master, ref.master=87306cfe1453), external-json-linter(), phutil(head=master, ref.master=e65ffd33db02)
  #0 BaseHTTPFuture::parseRawHTTPResponse(string) called at [<phutil>/src/future/http/HTTPSFuture.php:415]
  #1 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #2 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #3 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:58]
  #4 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:2231]
  #5 ArcanistDiffWorkflow::loadActiveLocalCommitInfo() called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:2129]
  #6 ArcanistDiffWorkflow::getGitUpdateMessage() called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:2095]
  #7 ArcanistDiffWorkflow::getDefaultUpdateMessage() called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:1882]
  #8 ArcanistDiffWorkflow::getUpdateMessage(array, NULL) called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:763]
  #9 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:469]
  #10 ArcanistDiffWorkflow::run() called at [<arcanist>/scripts/arcanist.php:382]


From ben at well-typed.com  Sat Dec  5 14:01:12 2015
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 05 Dec 2015 15:01:12 +0100
Subject: Phab out of memory
In-Reply-To: <626D231D-D1F4-4F7A-8B36-29B177A6CCC2@cis.upenn.edu>
References: <626D231D-D1F4-4F7A-8B36-29B177A6CCC2@cis.upenn.edu>
Message-ID: <87a8ppro47.fsf@smart-cactus.org>

Richard Eisenberg <eir at cis.upenn.edu> writes:

> I just tried to update D808, but the following happened. Any ideas?
>
I'm afraid I don't know what to say here. Austin, do you know what is
happening?

Does Phabricator's server-side routinely need over 500 MBytes of memory?
Perhaps there's something pathlogical about this Diff beyond its sheer
size (e.g. lots of lint warnings perhaps)?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151205/6e33a90c/attachment.sig>

From eir at cis.upenn.edu  Sat Dec  5 14:36:31 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 5 Dec 2015 09:36:31 -0500
Subject: Phab out of memory
In-Reply-To: <87a8ppro47.fsf@smart-cactus.org>
References: <626D231D-D1F4-4F7A-8B36-29B177A6CCC2@cis.upenn.edu>
 <87a8ppro47.fsf@smart-cactus.org>
Message-ID: <85FB20EE-2F29-4163-94F7-BA542AB7ABE0@cis.upenn.edu>


On Dec 5, 2015, at 9:01 AM, Ben Gamari <ben at well-typed.com> wrote:

> Richard Eisenberg <eir at cis.upenn.edu> writes:
> 
>> I just tried to update D808, but the following happened. Any ideas?
>> 
> I'm afraid I don't know what to say here. Austin, do you know what is
> happening?
> 
> Does Phabricator's server-side routinely need over 500 MBytes of memory?
> Perhaps there's something pathlogical about this Diff beyond its sheer
> size (e.g. lots of lint warnings perhaps)?

It's not lint, as the same problem happens with --nolint.

Thanks,
Richard

> 
> Cheers,
> 
> - Ben
> 


From david.feuer at gmail.com  Sat Dec  5 22:38:10 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 5 Dec 2015 17:38:10 -0500
Subject: Allow ambiguous types (with warning) by default
Message-ID: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>

The ambiguity check produces errors that are quite surprising to the
uninitiated. When the check is suppressed, the errors at use sites are
typically much easier to grasp. On the other hand, there's obviously a lot
of value to catching mistakes as soon as possible. Would it be possible to
turn that into a warning by default?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151205/5b36aaa3/attachment.html>

From kane at kane.cx  Sat Dec  5 23:21:50 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sun, 6 Dec 2015 00:21:50 +0100
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
Message-ID: <5663718E.1070408@kane.cx>

I'm strongly against this, for a multitude of reasons. There's already a
mechanism for doing what you want -- type defaulting. See also
https://ghc.haskell.org/trac/ghc/ticket/8171 .

On 12/5/2015 11:38 PM, David Feuer wrote:
> The ambiguity check produces errors that are quite surprising to the
> uninitiated. When the check is suppressed, the errors at use sites are
> typically much easier to grasp. On the other hand, there's obviously a lot
> of value to catching mistakes as soon as possible. Would it be possible to
> turn that into a warning by default?
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/bcc37503/attachment.bin>

From sumit.sahrawat.apm13 at iitbhu.ac.in  Sat Dec  5 23:26:11 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Sun, 6 Dec 2015 04:56:11 +0530
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <5663718E.1070408@kane.cx>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <5663718E.1070408@kane.cx>
Message-ID: <CAJbEW8MQBtz=HeGtuR6mm2H6ddi_n-bxQOENw4sFZajaofAeNA@mail.gmail.com>

We could have a LANGUAGE pragma that makes the language easier for
beginners.
Provided it would not change anything major, otherwise it will be hard to
decide how much to simplify the language.
We can restrict it to only enabling some other extensions, one of which
could be AllowAmbiguousTypes.

On 6 December 2015 at 04:51, David Kraeutmann <kane at kane.cx> wrote:

> I'm strongly against this, for a multitude of reasons. There's already a
> mechanism for doing what you want -- type defaulting. See also
> https://ghc.haskell.org/trac/ghc/ticket/8171 .
>
> On 12/5/2015 11:38 PM, David Feuer wrote:
> > The ambiguity check produces errors that are quite surprising to the
> > uninitiated. When the check is suppressed, the errors at use sites are
> > typically much easier to grasp. On the other hand, there's obviously a
> lot
> > of value to catching mistakes as soon as possible. Would it be possible
> to
> > turn that into a warning by default?
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/16f95f56/attachment.html>

From kane at kane.cx  Sat Dec  5 23:54:31 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sun, 6 Dec 2015 00:54:31 +0100
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAJbEW8MQBtz=HeGtuR6mm2H6ddi_n-bxQOENw4sFZajaofAeNA@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <5663718E.1070408@kane.cx>
 <CAJbEW8MQBtz=HeGtuR6mm2H6ddi_n-bxQOENw4sFZajaofAeNA@mail.gmail.com>
Message-ID: <56637937.5050606@kane.cx>

I don't think it'll make the language easier for beginners. It'd just be hidden type defaulting  with much more severe consequences (since it's uncontrolled). Never mind that this will cause instance selection to be nondeterministic and very weird in general (the type of an expression will depend on what instances are in scope).
On 12/6/2015 12:26 AM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
> We could have a LANGUAGE pragma that makes the language easier for
> beginners.
> Provided it would not change anything major, otherwise it will be hard to
> decide how much to simplify the language.
> We can restrict it to only enabling some other extensions, one of which
> could be AllowAmbiguousTypes.
>
> On 6 December 2015 at 04:51, David Kraeutmann <kane at kane.cx> wrote:
>
> > I'm strongly against this, for a multitude of reasons. There's already a
> > mechanism for doing what you want -- type defaulting. See also
> > https://ghc.haskell.org/trac/ghc/ticket/8171 .
> >
> > On 12/5/2015 11:38 PM, David Feuer wrote:
> >> The ambiguity check produces errors that are quite surprising to the
> >> uninitiated. When the check is suppressed, the errors at use sites are
> >> typically much easier to grasp. On the other hand, there's obviously a
> > lot
> >> of value to catching mistakes as soon as possible. Would it be possible
> > to
> >> turn that into a warning by default?
> >>
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/b6918f07/attachment-0001.bin>

From david.feuer at gmail.com  Sun Dec  6 01:16:08 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 5 Dec 2015 20:16:08 -0500
Subject: ambiguous type stuff
In-Reply-To: <CAMgWh9uGLLUK4-s4R-YKbjN-k9nZOdhrDDxNEwLLH6dzS32nuQ@mail.gmail.com>
References: <CAMgWh9uGLLUK4-s4R-YKbjN-k9nZOdhrDDxNEwLLH6dzS32nuQ@mail.gmail.com>
Message-ID: <CAMgWh9uzqarX=Fz74qQ2kL1z4ZPaw14-_=OD=N2oPXsMsn7S3Q@mail.gmail.com>

I think I didn't explain myself well enough. I'm not talking about expanded
defaulting, although that may be tied up with the same mechanisms. Perhaps
the best thing is just to work on the error message text for certain
ambiguous type situations. Notably, situations where adding a proxy
argument or similar is needed to avoid the error tend to be pretty
mysterious until you realize that the system is not complaining because it
can't determine a type, but rather because there is no way to pinpoint that
type at the use site.

If F is a type family then

f :: Foo x => F x

has a perfectly sensible translation, namely

f :: forall x . Foo x -> F x

The problem is purely one of inference on the Haskell side: there is no way
to add a signature *at the call site* that determines what value of x to
pass to f. The error message about x being ambiguous because F is a type
family has to be read a bit backwards. At a *use site*, it'll be pretty
clear-cut what's ambiguous, and it will soon become clear why it can't be
pinned down. Perhaps it would pay to change the error message to explain
why the type signature renders the term unusable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151205/23ff751e/attachment.html>

From kane at kane.cx  Sun Dec  6 01:43:52 2015
From: kane at kane.cx (David Kraeutmann)
Date: Sun, 6 Dec 2015 02:43:52 +0100
Subject: ambiguous type stuff
In-Reply-To: <CAMgWh9uzqarX=Fz74qQ2kL1z4ZPaw14-_=OD=N2oPXsMsn7S3Q@mail.gmail.com>
References: <CAMgWh9uGLLUK4-s4R-YKbjN-k9nZOdhrDDxNEwLLH6dzS32nuQ@mail.gmail.com>
 <CAMgWh9uzqarX=Fz74qQ2kL1z4ZPaw14-_=OD=N2oPXsMsn7S3Q@mail.gmail.com>
Message-ID: <566392D8.1080703@kane.cx>

Oh, you meant that kind of ambiguous type (I thought you meant the (show.read) kind of ambiguity).
So you'd like -XAllowAmbiguousTypes to be on by default?

On 12/6/2015 2:16 AM, David Feuer wrote:
> I think I didn't explain myself well enough. I'm not talking about expanded
> defaulting, although that may be tied up with the same mechanisms. Perhaps
> the best thing is just to work on the error message text for certain
> ambiguous type situations. Notably, situations where adding a proxy
> argument or similar is needed to avoid the error tend to be pretty
> mysterious until you realize that the system is not complaining because it
> can't determine a type, but rather because there is no way to pinpoint that
> type at the use site.
>
> If F is a type family then
>
> f :: Foo x => F x
>
> has a perfectly sensible translation, namely
>
> f :: forall x . Foo x -> F x
>
> The problem is purely one of inference on the Haskell side: there is no way
> to add a signature *at the call site* that determines what value of x to
> pass to f. The error message about x being ambiguous because F is a type
> family has to be read a bit backwards. At a *use site*, it'll be pretty
> clear-cut what's ambiguous, and it will soon become clear why it can't be
> pinned down. Perhaps it would pay to change the error message to explain
> why the type signature renders the term unusable.
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/0948ee44/attachment.bin>

From ekmett at gmail.com  Sun Dec  6 04:51:43 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 5 Dec 2015 23:51:43 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
Message-ID: <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>

So you are saying you want users to write a ton of code that happens to
have signatures that can never be called and only catch it when they go to
try to actually use it in a concrete situation much later?

I don't really show how this would be a better default.

When and if users see the problem later they have to worry about if they
are doing something wrong at the definition site or the call site. With the
status quo it complains at the right time that you aren't going to sit
there flailing around trying to fix a call site that can never be fixed.

-Edward

On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <david.feuer at gmail.com> wrote:

> The ambiguity check produces errors that are quite surprising to the
> uninitiated. When the check is suppressed, the errors at use sites are
> typically much easier to grasp. On the other hand, there's obviously a lot
> of value to catching mistakes as soon as possible. Would it be possible to
> turn that into a warning by default?
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151205/8989275b/attachment.html>

From david.feuer at gmail.com  Sun Dec  6 05:06:32 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 6 Dec 2015 00:06:32 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
Message-ID: <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>

No, I want it to *warn* by default. If I write

foo :: something that will fail the ambiguity check
bar = something that uses foo in a (necessarily) ambiguous way

the current default leads me to do this:

1. Attempt to compile. Get an ambiguity error on foo whose exact cause
is hard for me to see.
2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose
exact cause is completely obvious, and that makes it perfectly clear
what I need to do to fix foo.
3. Fix foo, and disable AllowAmbiguousTypes.

I'd much rather go with

1. Attempt to compile. Get an ambiguity *warning* on foo whose exact
cause is hard for me to see, but also an error on bar whose exact
cause is completely obvious, and that makes it perfectly clear what I
need to do to fix foo.
2. Fix foo.

Simple example of how it is currently:

> let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo

<interactive>:14:12:
    Couldn't match expected type ?F a? with actual type ?F a0?
    NB: ?F? is a type function, and may not be injective
    The type variable ?a0? is ambiguous
    In the ambiguity check for the type signature for ?foo?:
      foo :: forall a. Num a => F a
    To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
    In the type signature for ?foo?: foo :: Num a => F a

Couldn't match what with what? Huh? Where did a0 come from?

> :set -XAllowAmbiguousTypes
> let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo

<interactive>:16:61:
    Couldn't match expected type ?Int? with actual type ?F a0?
    The type variable ?a0? is ambiguous
    In the expression: foo
    In an equation for ?bar?: bar = foo

Aha! That's the problem! It doesn't know what a0 is! How can I tell it
what a0 is? Oh! I can't, because foo doesn't give me a handle on it.
Guess I have to fix foo.

I'd really, really like to get *both* of those messages in one go,
with the first one preferably explaining itself a bit better.

On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com> wrote:
> So you are saying you want users to write a ton of code that happens to have
> signatures that can never be called and only catch it when they go to try to
> actually use it in a concrete situation much later?
>
> I don't really show how this would be a better default.
>
> When and if users see the problem later they have to worry about if they are
> doing something wrong at the definition site or the call site. With the
> status quo it complains at the right time that you aren't going to sit there
> flailing around trying to fix a call site that can never be fixed.
>
> -Edward
>
> On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> The ambiguity check produces errors that are quite surprising to the
>> uninitiated. When the check is suppressed, the errors at use sites are
>> typically much easier to grasp. On the other hand, there's obviously a lot
>> of value to catching mistakes as soon as possible. Would it be possible to
>> turn that into a warning by default?
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From ekmett at gmail.com  Sun Dec  6 05:13:28 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 6 Dec 2015 00:13:28 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
 <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
Message-ID: <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>

If you aren't the one writing the code that can't be called you may never
see the warning. It'll be tucked away in a cabal or stack build log
somewhere.

-Edward

On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.feuer at gmail.com> wrote:

> No, I want it to *warn* by default. If I write
>
> foo :: something that will fail the ambiguity check
> bar = something that uses foo in a (necessarily) ambiguous way
>
> the current default leads me to do this:
>
> 1. Attempt to compile. Get an ambiguity error on foo whose exact cause
> is hard for me to see.
> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose
> exact cause is completely obvious, and that makes it perfectly clear
> what I need to do to fix foo.
> 3. Fix foo, and disable AllowAmbiguousTypes.
>
> I'd much rather go with
>
> 1. Attempt to compile. Get an ambiguity *warning* on foo whose exact
> cause is hard for me to see, but also an error on bar whose exact
> cause is completely obvious, and that makes it perfectly clear what I
> need to do to fix foo.
> 2. Fix foo.
>
> Simple example of how it is currently:
>
> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
>
> <interactive>:14:12:
>     Couldn't match expected type ?F a? with actual type ?F a0?
>     NB: ?F? is a type function, and may not be injective
>     The type variable ?a0? is ambiguous
>     In the ambiguity check for the type signature for ?foo?:
>       foo :: forall a. Num a => F a
>     To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
>     In the type signature for ?foo?: foo :: Num a => F a
>
> Couldn't match what with what? Huh? Where did a0 come from?
>
> > :set -XAllowAmbiguousTypes
> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
>
> <interactive>:16:61:
>     Couldn't match expected type ?Int? with actual type ?F a0?
>     The type variable ?a0? is ambiguous
>     In the expression: foo
>     In an equation for ?bar?: bar = foo
>
> Aha! That's the problem! It doesn't know what a0 is! How can I tell it
> what a0 is? Oh! I can't, because foo doesn't give me a handle on it.
> Guess I have to fix foo.
>
> I'd really, really like to get *both* of those messages in one go,
> with the first one preferably explaining itself a bit better.
>
> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com> wrote:
> > So you are saying you want users to write a ton of code that happens to
> have
> > signatures that can never be called and only catch it when they go to
> try to
> > actually use it in a concrete situation much later?
> >
> > I don't really show how this would be a better default.
> >
> > When and if users see the problem later they have to worry about if they
> are
> > doing something wrong at the definition site or the call site. With the
> > status quo it complains at the right time that you aren't going to sit
> there
> > flailing around trying to fix a call site that can never be fixed.
> >
> > -Edward
> >
> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> >>
> >> The ambiguity check produces errors that are quite surprising to the
> >> uninitiated. When the check is suppressed, the errors at use sites are
> >> typically much easier to grasp. On the other hand, there's obviously a
> lot
> >> of value to catching mistakes as soon as possible. Would it be possible
> to
> >> turn that into a warning by default?
> >>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/399de9be/attachment-0001.html>

From david.feuer at gmail.com  Sun Dec  6 05:15:51 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 6 Dec 2015 00:15:51 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
 <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
 <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>
Message-ID: <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>

OK, fine. Is there a way to make it an error, but keep checking the
rest of the module? My goal is *get both messages if possible*, within
a module. I'm not tied to any particular mechanism of doing so.

On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <ekmett at gmail.com> wrote:
> If you aren't the one writing the code that can't be called you may never
> see the warning. It'll be tucked away in a cabal or stack build log
> somewhere.
>
> -Edward
>
> On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> No, I want it to *warn* by default. If I write
>>
>> foo :: something that will fail the ambiguity check
>> bar = something that uses foo in a (necessarily) ambiguous way
>>
>> the current default leads me to do this:
>>
>> 1. Attempt to compile. Get an ambiguity error on foo whose exact cause
>> is hard for me to see.
>> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose
>> exact cause is completely obvious, and that makes it perfectly clear
>> what I need to do to fix foo.
>> 3. Fix foo, and disable AllowAmbiguousTypes.
>>
>> I'd much rather go with
>>
>> 1. Attempt to compile. Get an ambiguity *warning* on foo whose exact
>> cause is hard for me to see, but also an error on bar whose exact
>> cause is completely obvious, and that makes it perfectly clear what I
>> need to do to fix foo.
>> 2. Fix foo.
>>
>> Simple example of how it is currently:
>>
>> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
>>
>> <interactive>:14:12:
>>     Couldn't match expected type ?F a? with actual type ?F a0?
>>     NB: ?F? is a type function, and may not be injective
>>     The type variable ?a0? is ambiguous
>>     In the ambiguity check for the type signature for ?foo?:
>>       foo :: forall a. Num a => F a
>>     To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
>>     In the type signature for ?foo?: foo :: Num a => F a
>>
>> Couldn't match what with what? Huh? Where did a0 come from?
>>
>> > :set -XAllowAmbiguousTypes
>> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
>>
>> <interactive>:16:61:
>>     Couldn't match expected type ?Int? with actual type ?F a0?
>>     The type variable ?a0? is ambiguous
>>     In the expression: foo
>>     In an equation for ?bar?: bar = foo
>>
>> Aha! That's the problem! It doesn't know what a0 is! How can I tell it
>> what a0 is? Oh! I can't, because foo doesn't give me a handle on it.
>> Guess I have to fix foo.
>>
>> I'd really, really like to get *both* of those messages in one go,
>> with the first one preferably explaining itself a bit better.
>>
>> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> > So you are saying you want users to write a ton of code that happens to
>> > have
>> > signatures that can never be called and only catch it when they go to
>> > try to
>> > actually use it in a concrete situation much later?
>> >
>> > I don't really show how this would be a better default.
>> >
>> > When and if users see the problem later they have to worry about if they
>> > are
>> > doing something wrong at the definition site or the call site. With the
>> > status quo it complains at the right time that you aren't going to sit
>> > there
>> > flailing around trying to fix a call site that can never be fixed.
>> >
>> > -Edward
>> >
>> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <david.feuer at gmail.com>
>> > wrote:
>> >>
>> >> The ambiguity check produces errors that are quite surprising to the
>> >> uninitiated. When the check is suppressed, the errors at use sites are
>> >> typically much easier to grasp. On the other hand, there's obviously a
>> >> lot
>> >> of value to catching mistakes as soon as possible. Would it be possible
>> >> to
>> >> turn that into a warning by default?
>> >>
>> >>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >
>
>

From erkokl at gmail.com  Sun Dec  6 07:01:29 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Sat, 5 Dec 2015 23:01:29 -0800
Subject: Plugins: Accessing unexported bindings
Message-ID: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>

Hello,

The mg_binds field of the ModGuts seem to only contain the bindings that
are exported from the module being compiled.

I guess GHC must be running user-plugins after it drops the bindings that
are not exported, which makes perfect sense for most use cases. However,
I'm working on a plugin where the end-programmer embeds "properties" in the
form of functions inside his/her code, which are not necessarily exported
from the module under consideration.

Is there a way to access all top-level bindings in a module from a plugin,
even if those bindings are not exported?

Thanks,

-Levent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151205/55a6690b/attachment.html>

From ezyang at mit.edu  Sun Dec  6 08:31:16 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sun, 06 Dec 2015 00:31:16 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
Message-ID: <1449390644-sup-1091@sabre>

If you have control over the Ids for the properties, if you can
arrange for them to be marked "local exported" that should solve
your problem.

Edward

Excerpts from Levent Erkok's message of 2015-12-05 23:01:29 -0800:
> Hello,
> 
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
> 
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
> 
> Is there a way to access all top-level bindings in a module from a plugin,
> even if those bindings are not exported?
> 
> Thanks,
> 
> -Levent.

From omeragacan at gmail.com  Sun Dec  6 13:41:19 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 6 Dec 2015 08:41:19 -0500
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
Message-ID: <CAMQQO3naF3inoMsKBAR3RoucDcfcX8FMLwq-cNHAs=7O7+aJrA@mail.gmail.com>

2015-12-06 2:01 GMT-05:00 Levent Erkok <erkokl at gmail.com>:
> The mg_binds field of the ModGuts seem to only contain the bindings that are
> exported from the module being compiled.

This is not true, it contains all the definitions in the module and I'm relying
on this all the time. I just tested again and it definitely has all the
definitions in the module, exported or not.

If it doesn't export everything in the module some optimizers couldn't really
work. At least in my case the plugin API would be basically useless.

May I ask how are you testing this?

From omeragacan at gmail.com  Sun Dec  6 18:24:36 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 6 Dec 2015 13:24:36 -0500
Subject: question about coercions between primitive types in STG level
Message-ID: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>

Hi all,

In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe coercions
at the STG level. It works fine for lifted types, but for unlifted ones I'm
having some problems. What I'm trying to do is given a number of primitive
types I'm finding the one with biggest size, and then generating a constructor
that takes this biggest primitive type as argument.

The problem is that this is not working very well - GHC is generating illegal
instructions that try to load a F32 value to a register allocated for I64,
using movss instruction.

CoreLint is catching this error and printing this:

    Cmm lint error:
      in basic block c1hF
        in assignment:
          _g16W::I64 = 4.5 :: W32;   // CmmAssign
          Reg ty: I64
          Rhs ty: F32

So I have two questions about this:

1. Is there a way to safely do this? What are my options here? What I'm trying
   to do is to use a single data constructor field for different primitive
   types.  The field is guaranteed to be as big as necessary.

2. In the Cmm code shown above, the type annotation is showing `W32` but in the
   error message it says `F32`. I'm confused about this, is this error message
   given because the sizes don't match? (64bits vs 32bits) Why the type
   annotation says W32 while the value has type F32?

Thanks..

From omeragacan at gmail.com  Sun Dec  6 18:55:56 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 6 Dec 2015 13:55:56 -0500
Subject: Kinds of type synonym arguments
Message-ID: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>

In this program:

    {-# LANGUAGE MagicHash, UnboxedTuples #-}

    module Main where

    import GHC.Prim
    import GHC.Types

    type Tuple a b = (# a, b #)

    main = do
      let -- x :: Tuple Int# Float#
          x :: (# Int#, Float# #)
          x = (# 1#, 0.0# #)

      return ()

If I use the first type declaration for 'x' I'm getting this error message:

    Expecting a lifted type, but ?Int#? is unlifted

Indeed, if I look at the kinds of arguments of 'Tuple':

    ?:7> :k Tuple
    Tuple :: * -> * -> #

It's star. I was wondering why is this not 'OpenKind'(or whatever the
super-kind of star and hash). Is there a problem with this? Is this a bug?
Or is this simply because type synonyms are implemented before OpenKinds?

From eric at seidel.io  Sun Dec  6 19:08:55 2015
From: eric at seidel.io (Eric Seidel)
Date: Sun, 06 Dec 2015 11:08:55 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
Message-ID: <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>

GHC should only drop un-exported bindings from the ModGuts if they're
also unused, ie *dead code*.

The only way I know to get around this is to use the bindings somewhere,
or just export them.

On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> Hello,
> 
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
> 
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in
> the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
> 
> Is there a way to access all top-level bindings in a module from a
> plugin,
> even if those bindings are not exported?
> 
> Thanks,
> 
> -Levent.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From erkokl at gmail.com  Sun Dec  6 20:32:03 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Sun, 6 Dec 2015 12:32:03 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
Message-ID: <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>

Omer, Eric, Ed: Thanks for the comments.

Omer: I think Eric's observation is at play here. We're talking about
"dead-code," i.e., a binding that is neither exported, nor used by any
binding inside the module. Those seem to be getting dropped by the time
user-plugins are run. Unfortunately, this is precisely what one would do
with "properties" embedded in code. They serve as documentation perhaps,
but are otherwise not needed by any other binding nor it makes sense to
export them.

Edward: Can you provide some more info into your solution? Sounds like a
chicken-egg issue to me: As a plugin author, I need the bindings to access
the Ids, and looks like I need the Ids to access the binders?

A simple solution would be to simply keep all top-level bindings around
while the plugin are running, but that obviously can lead to unnecessary
work if the code is truly dead. A compromise could be that the annotations
can serve as entry points as well: I.e., if there's an annotation on a
top-level binder, then it should *not* be considered dead-code at least
until after all the plugins are run. That would definitely simplify life.
Would that be an acceptable alternative?

In the mean time, I'm still looking for a solution that doesn't involve
exporting such identifiers from modules. As Eric pointed out, that seems to
be the only current work-around for the time being.

Thanks,

-Levent.

On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io> wrote:

> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
>
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
>
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
> > The mg_binds field of the ModGuts seem to only contain the bindings that
> > are exported from the module being compiled.
> >
> > I guess GHC must be running user-plugins after it drops the bindings that
> > are not exported, which makes perfect sense for most use cases. However,
> > I'm working on a plugin where the end-programmer embeds "properties" in
> > the
> > form of functions inside his/her code, which are not necessarily exported
> > from the module under consideration.
> >
> > Is there a way to access all top-level bindings in a module from a
> > plugin,
> > even if those bindings are not exported?
> >
> > Thanks,
> >
> > -Levent.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/d2241cac/attachment.html>

From carter.schonwald at gmail.com  Mon Dec  7 00:13:52 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 6 Dec 2015 19:13:52 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
 <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
 <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>
 <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>
Message-ID: <CAHYVw0ya1uQU6q5gqe-n-peMUHJer68cExn+u4gBUe+YS2S4gg@mail.gmail.com>

That gets into making the whole parser / renamer / type checker a bit more
incremental, and while that would be awesome, and an excellent example of
that user experience can be seen in the lean theorem prover, its certainly
trickier to see how to realize it in Haskell because the order in the
module of top level decls has no bearing on what may be a mutually
recursive knot of definitions.

Likewise, while I definitely think that it's good to have the maximal set
of independent type errors reported back, this is the same type error just
deferred to a new location.  Likewise, as ed notes, this would push a lot
of errors out of libraries and into library clients , which just seems bad
On Dec 6, 2015 12:15 AM, "David Feuer" <david.feuer at gmail.com> wrote:

> OK, fine. Is there a way to make it an error, but keep checking the
> rest of the module? My goal is *get both messages if possible*, within
> a module. I'm not tied to any particular mechanism of doing so.
>
> On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <ekmett at gmail.com> wrote:
> > If you aren't the one writing the code that can't be called you may never
> > see the warning. It'll be tucked away in a cabal or stack build log
> > somewhere.
> >
> > -Edward
> >
> > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.feuer at gmail.com>
> wrote:
> >>
> >> No, I want it to *warn* by default. If I write
> >>
> >> foo :: something that will fail the ambiguity check
> >> bar = something that uses foo in a (necessarily) ambiguous way
> >>
> >> the current default leads me to do this:
> >>
> >> 1. Attempt to compile. Get an ambiguity error on foo whose exact cause
> >> is hard for me to see.
> >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose
> >> exact cause is completely obvious, and that makes it perfectly clear
> >> what I need to do to fix foo.
> >> 3. Fix foo, and disable AllowAmbiguousTypes.
> >>
> >> I'd much rather go with
> >>
> >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose exact
> >> cause is hard for me to see, but also an error on bar whose exact
> >> cause is completely obvious, and that makes it perfectly clear what I
> >> need to do to fix foo.
> >> 2. Fix foo.
> >>
> >> Simple example of how it is currently:
> >>
> >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
> >>
> >> <interactive>:14:12:
> >>     Couldn't match expected type ?F a? with actual type ?F a0?
> >>     NB: ?F? is a type function, and may not be injective
> >>     The type variable ?a0? is ambiguous
> >>     In the ambiguity check for the type signature for ?foo?:
> >>       foo :: forall a. Num a => F a
> >>     To defer the ambiguity check to use sites, enable
> AllowAmbiguousTypes
> >>     In the type signature for ?foo?: foo :: Num a => F a
> >>
> >> Couldn't match what with what? Huh? Where did a0 come from?
> >>
> >> > :set -XAllowAmbiguousTypes
> >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
> >>
> >> <interactive>:16:61:
> >>     Couldn't match expected type ?Int? with actual type ?F a0?
> >>     The type variable ?a0? is ambiguous
> >>     In the expression: foo
> >>     In an equation for ?bar?: bar = foo
> >>
> >> Aha! That's the problem! It doesn't know what a0 is! How can I tell it
> >> what a0 is? Oh! I can't, because foo doesn't give me a handle on it.
> >> Guess I have to fix foo.
> >>
> >> I'd really, really like to get *both* of those messages in one go,
> >> with the first one preferably explaining itself a bit better.
> >>
> >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com> wrote:
> >> > So you are saying you want users to write a ton of code that happens
> to
> >> > have
> >> > signatures that can never be called and only catch it when they go to
> >> > try to
> >> > actually use it in a concrete situation much later?
> >> >
> >> > I don't really show how this would be a better default.
> >> >
> >> > When and if users see the problem later they have to worry about if
> they
> >> > are
> >> > doing something wrong at the definition site or the call site. With
> the
> >> > status quo it complains at the right time that you aren't going to sit
> >> > there
> >> > flailing around trying to fix a call site that can never be fixed.
> >> >
> >> > -Edward
> >> >
> >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <david.feuer at gmail.com>
> >> > wrote:
> >> >>
> >> >> The ambiguity check produces errors that are quite surprising to the
> >> >> uninitiated. When the check is suppressed, the errors at use sites
> are
> >> >> typically much easier to grasp. On the other hand, there's obviously
> a
> >> >> lot
> >> >> of value to catching mistakes as soon as possible. Would it be
> possible
> >> >> to
> >> >> turn that into a warning by default?
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> ghc-devs mailing list
> >> >> ghc-devs at haskell.org
> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> >>
> >> >
> >
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/985f684d/attachment-0001.html>

From eir at cis.upenn.edu  Mon Dec  7 02:45:38 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 6 Dec 2015 21:45:38 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
Message-ID: <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>

I think this is a consequence of the rule that we never abstract over types of kind #. But I believe this should work with my branch:

> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)

The user would have to request that the synonym be used over both * and #, but the synonym should work. The need to request the special treatment might be lifted, but we'd have to think hard about where we want the generality by default and where we want simpler behavior by default.

Richard

On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:

> In this program:
> 
>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
> 
>    module Main where
> 
>    import GHC.Prim
>    import GHC.Types
> 
>    type Tuple a b = (# a, b #)
> 
>    main = do
>      let -- x :: Tuple Int# Float#
>          x :: (# Int#, Float# #)
>          x = (# 1#, 0.0# #)
> 
>      return ()
> 
> If I use the first type declaration for 'x' I'm getting this error message:
> 
>    Expecting a lifted type, but ?Int#? is unlifted
> 
> Indeed, if I look at the kinds of arguments of 'Tuple':
> 
>    ?:7> :k Tuple
>    Tuple :: * -> * -> #
> 
> It's star. I was wondering why is this not 'OpenKind'(or whatever the
> super-kind of star and hash). Is there a problem with this? Is this a bug?
> Or is this simply because type synonyms are implemented before OpenKinds?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From eir at cis.upenn.edu  Mon Dec  7 04:43:08 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 6 Dec 2015 23:43:08 -0500
Subject: How do I use CallStack?
Message-ID: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>

Hi devs,

I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this?

I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance.

Help?

Thanks!
Richard

From erkokl at gmail.com  Mon Dec  7 04:48:42 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Sun, 6 Dec 2015 20:48:42 -0800
Subject: How do I use CallStack?
In-Reply-To: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
Message-ID: <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>

There's a function for that:
https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showCallStack



On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi devs,
>
> I wish to use the new CallStack feature to track call sites of a function.
> I want my function to print out where it was called from. I do not want to
> call `error`. How do I do this?
>
> I looked in the release notes. They describe the CallStack feature at an
> overview, and the docs suggest that it has a Show instance. But the notes
> don't say where to import CallStack from. I found it in GHC.Stack, but I'm
> unsure this is the right place to take it from. The GHC release notes also
> refer me to the ghc-prim release notes. These (which I assume are ghc-prim/
> changelog.md) don't discuss CallStack. In any case, when I try to `show
> ?callstack`, I learn that CallStack is not an instance of Show, or I
> somehow haven't imported the instance.
>
> Help?
>
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/72bc445e/attachment.html>

From eir at cis.upenn.edu  Mon Dec  7 04:56:09 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 6 Dec 2015 23:56:09 -0500
Subject: How do I use CallStack?
In-Reply-To: <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
Message-ID: <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>

That looks like exactly what I want. Thanks.

There remain two mysteries:
- I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9.

- That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception.

Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance?

Thanks!
Richard

On Dec 6, 2015, at 11:48 PM, Levent Erkok <erkokl at gmail.com> wrote:

> There's a function for that: https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showCallStack
> 
> 
> 
> On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Hi devs,
> 
> I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this?
> 
> I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance.
> 
> Help?
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151206/18be58b4/attachment.html>

From qdunkan at gmail.com  Mon Dec  7 05:15:06 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 6 Dec 2015 21:15:06 -0800
Subject: How do I use CallStack?
In-Reply-To: <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
Message-ID: <CACbaDy5gCrO94N42=UF1-4X=B99DTEUwcnv04cHP91oDFtvWGw@mail.gmail.com>

Also, a call stack frame is just a (name, srcloc) pair, so you can
format it yourself.  I use:

show_stack :: CallStack -> String
show_stack = maybe "<empty-stack>" show_frame . Seq.last . Stack.getCallStack
    where
    show_frame (name, srcloc) =
        SrcLoc.srcLocFile srcloc ++ ":" ++ show (SrcLoc.srcLocStartLine srcloc)
        ++ " [" ++ name ++ "]"


On Sun, Dec 6, 2015 at 8:56 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> That looks like exactly what I want. Thanks.
>
> There remain two mysteries:
> - I thought that CallStacks were a new feature that would come with GHC 8.0.
> Yet it seems the datatype is present in base-4.8.x. Even though the docs
> even say (wrongly, evidently) that it's in base since 4.9.

I've been using it since 7.10, with base 4.8.  There's also a back
port to 7.8, but it's not in the official distribution.

From rwbarton at gmail.com  Mon Dec  7 05:51:03 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Mon, 7 Dec 2015 00:51:03 -0500
Subject: How do I use CallStack?
In-Reply-To: <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
Message-ID: <CADmwj46vh2fWOe==R5yVa5jLHb0smnAtRsihkeaWOBdMdswfXw@mail.gmail.com>

On Sun, Dec 6, 2015 at 11:56 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> That looks like exactly what I want. Thanks.
>
> There remain two mysteries:
> - I thought that CallStacks were a new feature that would come with GHC
> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
> docs even say (wrongly, evidently) that it's in base since 4.9.
>

Somehow some CallStack-related things snuck in between 7.10.1 and 7.10.2.
Compare https://hackage.haskell.org/package/base-4.8.0.0/docs/GHC-Stack.html
and https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html.

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/9c599082/attachment.html>

From eric at seidel.io  Mon Dec  7 06:39:11 2015
From: eric at seidel.io (Eric Seidel)
Date: Sun, 06 Dec 2015 22:39:11 -0800
Subject: How do I use CallStack?
In-Reply-To: <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
Message-ID: <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>

Hi Richard,

Sorry for all of the confusion, it seems the docs do indeed need some
love!

On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
> That looks like exactly what I want. Thanks.
> 
> There remain two mysteries:
> - I thought that CallStacks were a new feature that would come with GHC
> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
> docs even say (wrongly, evidently) that it's in base since 4.9.

They were originally merged into 7.11, but were backported to the
official 7.10.2 release due to popular demand. It appears the @since
annotation wasn't updated correspondingly.

> - That function seems missing in HEAD. Or maybe it moved. A little
> searching says it *did* move, to GHC.Exception.

In HEAD we are now using CallStacks for error and undefined, which was
not the case for the 7.10.2 release. This means the type needs to be
defined much earlier in base, before we even have enough functionality
to write a sensible formatter. showCallStack currently lives in
GHC.Exception because that's where it's used, but that's not a good
reason... I'll take another look at moving it back to GHC.Stack.

> Well, my problem is solved. But I think the documentation needs a pass
> here. And is there a reason not to have a Show instance?

I usually only use compiler-derived Show instances so that Read
automatically works, as well as some nice formatting libraries like
http://hackage.haskell.org/package/pretty-show for debugging. For
pretty-printing like showCallStack I prefer a standalone function or a
separate type-class.

If the name "showCallStack" suggests the compiler-derived output, we
could change it to something like "prettyCallStack" or
"formatCallStack", I don't have a strong opinion there.

Thanks for the comments!
Eric

From simonpj at microsoft.com  Mon Dec  7 10:28:08 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 10:28:08 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
Message-ID: <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.

So I think it does just what you want.

Simon

data ExportFlag   -- See Note [ExportFlag on binders]
  = NotExported   -- ^ Not exported: may be discarded as dead code.
  | Exported      -- ^ Exported: kept alive

{- Note [ExportFlag on binders]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An ExportFlag of "Exported" on a top-level binder says "keep this
binding alive; do not drop it as dead code".  This transititively
keeps alive all the other top-level bindings that this binding refers
to.  This property is persisted all the way down the pipeline, so that
the binding will be compiled all the way to object code, and its
symbols will appear in the linker symbol table.

However, note that this use of "exported" is quite different to the
export list on a Haskell module.  Setting the ExportFlag on an Id does
/not/ mean that if you import the module (in Haskell source code you
will see this Id.  Of course, things that appear in the export list
of the source Haskell module do indeed have their ExportFlag set.
But many other things, such as dictionary functions, are kept alive
by having their ExportFlag set, even though they are not exported
in the source-code sense.

We should probably use a different term for ExportFlag, like
KeepAlive.

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
Sent: 06 December 2015 20:32
To: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu
Cc: ghc-devs at haskell.org
Subject: Re: Plugins: Accessing unexported bindings

Omer, Eric, Ed: Thanks for the comments.

Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.

Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?

A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

Thanks,

-Levent.

On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
GHC should only drop un-exported bindings from the ModGuts if they're
also unused, ie *dead code*.

The only way I know to get around this is to use the bindings somewhere,
or just export them.

On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> Hello,
>
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
>
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in
> the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
>
> Is there a way to access all top-level bindings in a module from a
> plugin,
> even if those bindings are not exported?
>
> Thanks,
>
> -Levent.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/0b823b07/attachment-0001.html>

From niteria at gmail.com  Mon Dec  7 10:45:25 2015
From: niteria at gmail.com (Bartosz Nitka)
Date: Mon, 7 Dec 2015 10:45:25 +0000
Subject: How do I use CallStack?
In-Reply-To: <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
Message-ID: <CAOSxnRhr54Z4JVA+Ld+pPkMD3iSJSuF=LQ+xTWM6FCfu8uyxGw@mail.gmail.com>

If you're debugging GHC, I've recently added pprSTrace ::  (?location ::
CallStack) => SDoc -> a -> a in Outputable. It's been a great help for me
in understanding where the calls were coming from. You can just use it
without importing anything extra, and when you want more context you just
add (?location :: CallStack) => to the function you're debugging, plus
necessary imports (GHC.Stack) and extensions (ImplicitParams). I think it
improved my workflow by an order of magnitude.


2015-12-07 6:39 GMT+00:00 Eric Seidel <eric at seidel.io>:

> Hi Richard,
>
> Sorry for all of the confusion, it seems the docs do indeed need some
> love!
>
> On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
> > That looks like exactly what I want. Thanks.
> >
> > There remain two mysteries:
> > - I thought that CallStacks were a new feature that would come with GHC
> > 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
> > docs even say (wrongly, evidently) that it's in base since 4.9.
>
> They were originally merged into 7.11, but were backported to the
> official 7.10.2 release due to popular demand. It appears the @since
> annotation wasn't updated correspondingly.
>
> > - That function seems missing in HEAD. Or maybe it moved. A little
> > searching says it *did* move, to GHC.Exception.
>
> In HEAD we are now using CallStacks for error and undefined, which was
> not the case for the 7.10.2 release. This means the type needs to be
> defined much earlier in base, before we even have enough functionality
> to write a sensible formatter. showCallStack currently lives in
> GHC.Exception because that's where it's used, but that's not a good
> reason... I'll take another look at moving it back to GHC.Stack.
>
> > Well, my problem is solved. But I think the documentation needs a pass
> > here. And is there a reason not to have a Show instance?
>
> I usually only use compiler-derived Show instances so that Read
> automatically works, as well as some nice formatting libraries like
> http://hackage.haskell.org/package/pretty-show for debugging. For
> pretty-printing like showCallStack I prefer a standalone function or a
> separate type-class.
>
> If the name "showCallStack" suggests the compiler-derived output, we
> could change it to something like "prettyCallStack" or
> "formatCallStack", I don't have a strong opinion there.
>
> Thanks for the comments!
> Eric
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/eb32689b/attachment.html>

From ben at smart-cactus.org  Mon Dec  7 10:59:37 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 07 Dec 2015 11:59:37 +0100
Subject: How do I use CallStack?
In-Reply-To: <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
Message-ID: <87y4d6r0bq.fsf@smart-cactus.org>

Eric Seidel <eric at seidel.io> writes:

> Hi Richard,
>
> Sorry for all of the confusion, it seems the docs do indeed need some
> love!
>
> On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
>> That looks like exactly what I want. Thanks.
>> 
>> There remain two mysteries:
>> - I thought that CallStacks were a new feature that would come with GHC
>> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
>> docs even say (wrongly, evidently) that it's in base since 4.9.
>
> They were originally merged into 7.11, but were backported to the
> official 7.10.2 release due to popular demand. It appears the @since
> annotation wasn't updated correspondingly.
>
>> - That function seems missing in HEAD. Or maybe it moved. A little
>> searching says it *did* move, to GHC.Exception.
>
> In HEAD we are now using CallStacks for error and undefined, which was
> not the case for the 7.10.2 release. This means the type needs to be
> defined much earlier in base, before we even have enough functionality
> to write a sensible formatter. showCallStack currently lives in
> GHC.Exception because that's where it's used, but that's not a good
> reason... I'll take another look at moving it back to GHC.Stack.

Indeed, this is probably a more logical place for them to live. Recent
experience tells me that there is a great potential for import cycles in this
area, however. I wish you luck ;)

>> Well, my problem is solved. But I think the documentation needs a pass
>> here. And is there a reason not to have a Show instance?
>
> I usually only use compiler-derived Show instances so that Read
> automatically works, as well as some nice formatting libraries like
> http://hackage.haskell.org/package/pretty-show for debugging. For
> pretty-printing like showCallStack I prefer a standalone function or a
> separate type-class.

Sure, I don't see any harm in deriving a Show instances, however. You
may want to derive it with standalone deriving so you can then attach a
Haddock pointing to the pretty version. e.g.,

    data CallStack = ...

    -- | See also 'prettyCallStack'.
    deriving instance Show CallStack

> If the name "showCallStack" suggests the compiler-derived output, we
> could change it to something like "prettyCallStack" or
> "formatCallStack", I don't have a strong opinion there.

I have also struggled with these sorts of naming decisions. The
overloading of the word "show" is a bit problematic. (+1) for "pretty".

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/83b9f2d8/attachment.sig>

From ben at well-typed.com  Mon Dec  7 11:02:01 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Dec 2015 12:02:01 +0100
Subject: Phab out of memory
In-Reply-To: <85FB20EE-2F29-4163-94F7-BA542AB7ABE0@cis.upenn.edu>
References: <626D231D-D1F4-4F7A-8B36-29B177A6CCC2@cis.upenn.edu>
 <87a8ppro47.fsf@smart-cactus.org>
 <85FB20EE-2F29-4163-94F7-BA542AB7ABE0@cis.upenn.edu>
Message-ID: <87vb8ar07q.fsf@smart-cactus.org>

Richard Eisenberg <eir at cis.upenn.edu> writes:

> On Dec 5, 2015, at 9:01 AM, Ben Gamari <ben at well-typed.com> wrote:
>
>> Richard Eisenberg <eir at cis.upenn.edu> writes:
>> 
>>> I just tried to update D808, but the following happened. Any ideas?
>>> 
>> I'm afraid I don't know what to say here. Austin, do you know what is
>> happening?
>> 
>> Does Phabricator's server-side routinely need over 500 MBytes of memory?
>> Perhaps there's something pathlogical about this Diff beyond its sheer
>> size (e.g. lots of lint warnings perhaps)?
>
> It's not lint, as the same problem happens with --nolint.
>
Hrm, can you still reproduce this? Phabricator was under a great deal of
load late last week due to a high patch volume. Perhaps the issue has
now resolved itself?

If not, I'm afraid that Austin, our local Phabricator expert, is our
only hope.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/487c9bf2/attachment.sig>

From erkokl at gmail.com  Mon Dec  7 12:04:33 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Mon, 7 Dec 2015 04:04:33 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>

Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?

That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?

> On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> ?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.
>  
> So I think it does just what you want.
>  
> Simon
>  
> data ExportFlag   -- See Note [ExportFlag on binders]
>   = NotExported   -- ^ Not exported: may be discarded as dead code.
>   | Exported      -- ^ Exported: kept alive
>  
> {- Note [ExportFlag on binders]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An ExportFlag of "Exported" on a top-level binder says "keep this
> binding alive; do not drop it as dead code".  This transititively
> keeps alive all the other top-level bindings that this binding refers
> to.  This property is persisted all the way down the pipeline, so that
> the binding will be compiled all the way to object code, and its
> symbols will appear in the linker symbol table.
>  
> However, note that this use of "exported" is quite different to the
> export list on a Haskell module.  Setting the ExportFlag on an Id does
> /not/ mean that if you import the module (in Haskell source code you
> will see this Id.  Of course, things that appear in the export list
> of the source Haskell module do indeed have their ExportFlag set.
> But many other things, such as dictionary functions, are kept alive
> by having their ExportFlag set, even though they are not exported
> in the source-code sense.
>  
> We should probably use a different term for ExportFlag, like
> KeepAlive.
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
> Sent: 06 December 2015 20:32
> To: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu
> Cc: ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Omer, Eric, Ed: Thanks for the comments.
>  
> Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.
>  
> Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?
>  
> A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?
>  
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> Thanks,
>  
> -Levent.
>  
> On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io> wrote:
> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
> 
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
> 
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
> > The mg_binds field of the ModGuts seem to only contain the bindings that
> > are exported from the module being compiled.
> >
> > I guess GHC must be running user-plugins after it drops the bindings that
> > are not exported, which makes perfect sense for most use cases. However,
> > I'm working on a plugin where the end-programmer embeds "properties" in
> > the
> > form of functions inside his/her code, which are not necessarily exported
> > from the module under consideration.
> >
> > Is there a way to access all top-level bindings in a module from a
> > plugin,
> > even if those bindings are not exported?
> >
> > Thanks,
> >
> > -Levent.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/98bf876f/attachment.html>

From simonpj at microsoft.com  Mon Dec  7 12:14:37 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 12:14:37 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
Message-ID: <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>

If it's "dead" in this sense, it's already removed from ModGuts, no?

Yes, if it?s dead it?s gone.   That?s not too surprising, is it?

So you need a way to keep it alive. Maybe we need a pragma for that.   Or how would you like to signal it in the source code?

Simon

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 12:05
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
Subject: Re: Plugins: Accessing unexported bindings

Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?

That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?

On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.

So I think it does just what you want.

Simon

data ExportFlag   -- See Note [ExportFlag on binders]
  = NotExported   -- ^ Not exported: may be discarded as dead code.
  | Exported      -- ^ Exported: kept alive

{- Note [ExportFlag on binders]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An ExportFlag of "Exported" on a top-level binder says "keep this
binding alive; do not drop it as dead code".  This transititively
keeps alive all the other top-level bindings that this binding refers
to.  This property is persisted all the way down the pipeline, so that
the binding will be compiled all the way to object code, and its
symbols will appear in the linker symbol table.

However, note that this use of "exported" is quite different to the
export list on a Haskell module.  Setting the ExportFlag on an Id does
/not/ mean that if you import the module (in Haskell source code you
will see this Id.  Of course, things that appear in the export list
of the source Haskell module do indeed have their ExportFlag set.
But many other things, such as dictionary functions, are kept alive
by having their ExportFlag set, even though they are not exported
in the source-code sense.

We should probably use a different term for ExportFlag, like
KeepAlive.

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
Sent: 06 December 2015 20:32
To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Omer, Eric, Ed: Thanks for the comments.

Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.

Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?

A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

Thanks,

-Levent.

On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
GHC should only drop un-exported bindings from the ModGuts if they're
also unused, ie *dead code*.

The only way I know to get around this is to use the bindings somewhere,
or just export them.

On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> Hello,
>
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
>
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in
> the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
>
> Is there a way to access all top-level bindings in a module from a
> plugin,
> even if those bindings are not exported?
>
> Thanks,
>
> -Levent.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/7ebb3e21/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec  7 12:23:25 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 12:23:25 +0000
Subject: question about coercions between primitive types in STG level
In-Reply-To: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
Message-ID: <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>

If memory serves, there are primops for converting between unboxed values of different widths.

Certainly converting between a float and a non-float will require an instruction on some architectures, since they use different register sets.

Re (2) I have no idea.  You'll need to get more information... pprTrace or something.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
|  Sinan Agacan
|  Sent: 06 December 2015 18:25
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: question about coercions between primitive types in STG level
|  
|  Hi all,
|  
|  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
|  coercions at the STG level. It works fine for lifted types, but for
|  unlifted ones I'm having some problems. What I'm trying to do is given
|  a number of primitive types I'm finding the one with biggest size, and
|  then generating a constructor that takes this biggest primitive type
|  as argument.
|  
|  The problem is that this is not working very well - GHC is generating
|  illegal instructions that try to load a F32 value to a register
|  allocated for I64, using movss instruction.
|  
|  CoreLint is catching this error and printing this:
|  
|      Cmm lint error:
|        in basic block c1hF
|          in assignment:
|            _g16W::I64 = 4.5 :: W32;   // CmmAssign
|            Reg ty: I64
|            Rhs ty: F32
|  
|  So I have two questions about this:
|  
|  1. Is there a way to safely do this? What are my options here? What
|  I'm trying
|     to do is to use a single data constructor field for different
|  primitive
|     types.  The field is guaranteed to be as big as necessary.
|  
|  2. In the Cmm code shown above, the type annotation is showing `W32`
|  but in the
|     error message it says `F32`. I'm confused about this, is this error
|  message
|     given because the sizes don't match? (64bits vs 32bits) Why the
|  type
|     annotation says W32 while the value has type F32?
|  
|  Thanks..
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa6254e5
|  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
|  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d

From mail at nh2.me  Mon Dec  7 12:25:14 2015
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Mon, 7 Dec 2015 13:25:14 +0100
Subject: How do I use CallStack?
In-Reply-To: <87y4d6r0bq.fsf@smart-cactus.org>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
 <87y4d6r0bq.fsf@smart-cactus.org>
Message-ID: <56657AAA.5070107@nh2.me>

On 07/12/15 11:59, Ben Gamari wrote:
>> If the name "showCallStack" suggests the compiler-derived output, we
>> could change it to something like "prettyCallStack" or
>> "formatCallStack", I don't have a strong opinion there.
> 
> I have also struggled with these sorts of naming decisions. The
> overloading of the word "show" is a bit problematic. (+1) for "pretty".

As a total proponent of Show-is-derived, +1 for a better name.

From erkokl at gmail.com  Mon Dec  7 12:41:35 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Mon, 7 Dec 2015 04:41:35 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.

Is that something one of the core-developers can implement? Happy to open a ticket if that helps. 

> On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> If it's "dead" in this sense, it's already removed from ModGuts, no?
>  
> Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
>  
> So you need a way to keep it alive. Maybe we need a pragma for that.   Or how would you like to signal it in the source code?
>  
> Simon
>  
> From: Levent Erkok [mailto:erkokl at gmail.com] 
> Sent: 07 December 2015 12:05
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?
>  
> That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?
> 
> On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> ?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.
>  
> So I think it does just what you want.
>  
> Simon
>  
> data ExportFlag   -- See Note [ExportFlag on binders]
>   = NotExported   -- ^ Not exported: may be discarded as dead code.
>   | Exported      -- ^ Exported: kept alive
>  
> {- Note [ExportFlag on binders]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An ExportFlag of "Exported" on a top-level binder says "keep this
> binding alive; do not drop it as dead code".  This transititively
> keeps alive all the other top-level bindings that this binding refers
> to.  This property is persisted all the way down the pipeline, so that
> the binding will be compiled all the way to object code, and its
> symbols will appear in the linker symbol table.
>  
> However, note that this use of "exported" is quite different to the
> export list on a Haskell module.  Setting the ExportFlag on an Id does
> /not/ mean that if you import the module (in Haskell source code you
> will see this Id.  Of course, things that appear in the export list
> of the source Haskell module do indeed have their ExportFlag set.
> But many other things, such as dictionary functions, are kept alive
> by having their ExportFlag set, even though they are not exported
> in the source-code sense.
>  
> We should probably use a different term for ExportFlag, like
> KeepAlive.
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
> Sent: 06 December 2015 20:32
> To: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu
> Cc: ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Omer, Eric, Ed: Thanks for the comments.
>  
> Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.
>  
> Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?
>  
> A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?
>  
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> Thanks,
>  
> -Levent.
>  
> On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io> wrote:
> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
> 
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
> 
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
> > The mg_binds field of the ModGuts seem to only contain the bindings that
> > are exported from the module being compiled.
> >
> > I guess GHC must be running user-plugins after it drops the bindings that
> > are not exported, which makes perfect sense for most use cases. However,
> > I'm working on a plugin where the end-programmer embeds "properties" in
> > the
> > form of functions inside his/her code, which are not necessarily exported
> > from the module under consideration.
> >
> > Is there a way to access all top-level bindings in a module from a
> > plugin,
> > even if those bindings are not exported?
> >
> > Thanks,
> >
> > -Levent.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/54cf82ef/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec  7 12:45:24 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 12:45:24 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
Message-ID: <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.

Really?  It might be something like ?don?t give warnings for this binding? or ?don?t inline me? or something.   To say *any* annotation seems a bit brutal doesn?t it?    Mind you I don?t have a better idea.

One thought: your plugin could add a pass right at the start, which marks everything you want as keep-alive.

S

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 12:42
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
Subject: Re: Plugins: Accessing unexported bindings

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.

Is that something one of the core-developers can implement? Happy to open a ticket if that helps.

On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
If it's "dead" in this sense, it's already removed from ModGuts, no?

Yes, if it?s dead it?s gone.   That?s not too surprising, is it?

So you need a way to keep it alive. Maybe we need a pragma for that.   Or how would you like to signal it in the source code?

Simon

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 12:05
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?

That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?

On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.

So I think it does just what you want.

Simon

data ExportFlag   -- See Note [ExportFlag on binders]
  = NotExported   -- ^ Not exported: may be discarded as dead code.
  | Exported      -- ^ Exported: kept alive

{- Note [ExportFlag on binders]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An ExportFlag of "Exported" on a top-level binder says "keep this
binding alive; do not drop it as dead code".  This transititively
keeps alive all the other top-level bindings that this binding refers
to.  This property is persisted all the way down the pipeline, so that
the binding will be compiled all the way to object code, and its
symbols will appear in the linker symbol table.

However, note that this use of "exported" is quite different to the
export list on a Haskell module.  Setting the ExportFlag on an Id does
/not/ mean that if you import the module (in Haskell source code you
will see this Id.  Of course, things that appear in the export list
of the source Haskell module do indeed have their ExportFlag set.
But many other things, such as dictionary functions, are kept alive
by having their ExportFlag set, even though they are not exported
in the source-code sense.

We should probably use a different term for ExportFlag, like
KeepAlive.

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
Sent: 06 December 2015 20:32
To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Omer, Eric, Ed: Thanks for the comments.

Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.

Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?

A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

Thanks,

-Levent.

On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
GHC should only drop un-exported bindings from the ModGuts if they're
also unused, ie *dead code*.

The only way I know to get around this is to use the bindings somewhere,
or just export them.

On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> Hello,
>
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
>
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in
> the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
>
> Is there a way to access all top-level bindings in a module from a
> plugin,
> even if those bindings are not exported?
>
> Thanks,
>
> -Levent.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/30a34d73/attachment-0001.html>

From erkokl at gmail.com  Mon Dec  7 13:10:40 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Mon, 7 Dec 2015 05:10:40 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>

That's a good point; keeping all annotated bindings alive seems to be an overkill..

Regarding implementing "pass at the start." I'm not sure if plugin authors have any freedom as to decide when their plugin actually runs. It seems GHC magically determines the order and runs them. Can you point me to some code/docs that tells me how to go "first" in that sense? (Or at least before the pass that drops dead code.)

> On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.
>  
> Really?  It might be something like ?don?t give warnings for this binding? or ?don?t inline me? or something.   To say *any* annotation seems a bit brutal doesn?t it?    Mind you I don?t have a better idea.
>  
> One thought: your plugin could add a pass right at the start, which marks everything you want as keep-alive.
>  
> S
>  
> From: Levent Erkok [mailto:erkokl at gmail.com] 
> Sent: 07 December 2015 12:42
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.
>  
> Is that something one of the core-developers can implement? Happy to open a ticket if that helps. 
>  
> On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> If it's "dead" in this sense, it's already removed from ModGuts, no?
>  
> Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
>  
> So you need a way to keep it alive. Maybe we need a pragma for that.   Or how would you like to signal it in the source code?
>  
> Simon
>  
> From: Levent Erkok [mailto:erkokl at gmail.com] 
> Sent: 07 December 2015 12:05
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?
>  
> That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?
> 
> On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> ?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.
>  
> So I think it does just what you want.
>  
> Simon
>  
> data ExportFlag   -- See Note [ExportFlag on binders]
>   = NotExported   -- ^ Not exported: may be discarded as dead code.
>   | Exported      -- ^ Exported: kept alive
>  
> {- Note [ExportFlag on binders]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An ExportFlag of "Exported" on a top-level binder says "keep this
> binding alive; do not drop it as dead code".  This transititively
> keeps alive all the other top-level bindings that this binding refers
> to.  This property is persisted all the way down the pipeline, so that
> the binding will be compiled all the way to object code, and its
> symbols will appear in the linker symbol table.
>  
> However, note that this use of "exported" is quite different to the
> export list on a Haskell module.  Setting the ExportFlag on an Id does
> /not/ mean that if you import the module (in Haskell source code you
> will see this Id.  Of course, things that appear in the export list
> of the source Haskell module do indeed have their ExportFlag set.
> But many other things, such as dictionary functions, are kept alive
> by having their ExportFlag set, even though they are not exported
> in the source-code sense.
>  
> We should probably use a different term for ExportFlag, like
> KeepAlive.
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
> Sent: 06 December 2015 20:32
> To: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu
> Cc: ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
>  
> Omer, Eric, Ed: Thanks for the comments.
>  
> Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.
>  
> Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?
>  
> A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?
>  
> In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.
>  
> Thanks,
>  
> -Levent.
>  
> On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io> wrote:
> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
> 
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
> 
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
> > The mg_binds field of the ModGuts seem to only contain the bindings that
> > are exported from the module being compiled.
> >
> > I guess GHC must be running user-plugins after it drops the bindings that
> > are not exported, which makes perfect sense for most use cases. However,
> > I'm working on a plugin where the end-programmer embeds "properties" in
> > the
> > form of functions inside his/her code, which are not necessarily exported
> > from the module under consideration.
> >
> > Is there a way to access all top-level bindings in a module from a
> > plugin,
> > even if those bindings are not exported?
> >
> > Thanks,
> >
> > -Levent.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/a3cd2002/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec  7 13:14:17 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 13:14:17 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
Message-ID: <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>

Plugins get to edit the entire core-to-core pipeline!  There is no magic.  At least I don?t think so

file:///Z:/tmp/users_guide/compiler-plugins.html

S

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 13:11
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
Subject: Re: Plugins: Accessing unexported bindings

That's a good point; keeping all annotated bindings alive seems to be an overkill..

Regarding implementing "pass at the start." I'm not sure if plugin authors have any freedom as to decide when their plugin actually runs. It seems GHC magically determines the order and runs them. Can you point me to some code/docs that tells me how to go "first" in that sense? (Or at least before the pass that drops dead code.)

On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.

Really?  It might be something like ?don?t give warnings for this binding? or ?don?t inline me? or something.   To say *any* annotation seems a bit brutal doesn?t it?    Mind you I don?t have a better idea.

One thought: your plugin could add a pass right at the start, which marks everything you want as keep-alive.

S

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 12:42
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive.

Is that something one of the core-developers can implement? Happy to open a ticket if that helps.

On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
If it's "dead" in this sense, it's already removed from ModGuts, no?

Yes, if it?s dead it?s gone.   That?s not too surprising, is it?

So you need a way to keep it alive. Maybe we need a pragma for that.   Or how would you like to signal it in the source code?

Simon

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 07 December 2015 12:05
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no?

That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it "Local Exported." Is that not correct?

On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

?Exported? in this context only means ?keep alive?. It does not mean exported in the Haskell source code sense. I?ve just added this comment to Var.hs.

So I think it does just what you want.

Simon

data ExportFlag   -- See Note [ExportFlag on binders]
  = NotExported   -- ^ Not exported: may be discarded as dead code.
  | Exported      -- ^ Exported: kept alive

{- Note [ExportFlag on binders]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An ExportFlag of "Exported" on a top-level binder says "keep this
binding alive; do not drop it as dead code".  This transititively
keeps alive all the other top-level bindings that this binding refers
to.  This property is persisted all the way down the pipeline, so that
the binding will be compiled all the way to object code, and its
symbols will appear in the linker symbol table.

However, note that this use of "exported" is quite different to the
export list on a Haskell module.  Setting the ExportFlag on an Id does
/not/ mean that if you import the module (in Haskell source code you
will see this Id.  Of course, things that appear in the export list
of the source Haskell module do indeed have their ExportFlag set.
But many other things, such as dictionary functions, are kept alive
by having their ExportFlag set, even though they are not exported
in the source-code sense.

We should probably use a different term for ExportFlag, like
KeepAlive.

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent Erkok
Sent: 06 December 2015 20:32
To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>; ezyang at mit.edu<mailto:ezyang at mit.edu>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Plugins: Accessing unexported bindings

Omer, Eric, Ed: Thanks for the comments.

Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them.

Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders?

A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative?

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being.

Thanks,

-Levent.

On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:
GHC should only drop un-exported bindings from the ModGuts if they're
also unused, ie *dead code*.

The only way I know to get around this is to use the bindings somewhere,
or just export them.

On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> Hello,
>
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
>
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in
> the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
>
> Is there a way to access all top-level bindings in a module from a
> plugin,
> even if those bindings are not exported?
>
> Thanks,
>
> -Levent.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/d67395cb/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec  7 13:30:55 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 13:30:55 +0000
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
 <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
 <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>
 <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>
Message-ID: <af17934a19324aca8cac5852cfe6bf49@DB4PR30MB030.064d.mgd.msft.net>

|  OK, fine. Is there a way to make it an error, but keep checking the
|  rest of the module? My goal is *get both messages if possible*, within
|  a module. I'm not tied to any particular mechanism of doing so.

Yes it'd be possible.  A bit fiddly, but certainly possible.

Of course, doing so can lead to a cascade of other errors, but in this case you seem to actively want those follow-on errors.

Would you like to open a ticket with a few illustrative examples to motivate your proposal?

Simon

|  
|  On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <ekmett at gmail.com>
|  wrote:
|  > If you aren't the one writing the code that can't be called you may
|  > never see the warning. It'll be tucked away in a cabal or stack
|  build
|  > log somewhere.
|  >
|  > -Edward
|  >
|  > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.feuer at gmail.com>
|  wrote:
|  >>
|  >> No, I want it to *warn* by default. If I write
|  >>
|  >> foo :: something that will fail the ambiguity check bar = something
|  >> that uses foo in a (necessarily) ambiguous way
|  >>
|  >> the current default leads me to do this:
|  >>
|  >> 1. Attempt to compile. Get an ambiguity error on foo whose exact
|  >> cause is hard for me to see.
|  >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar
|  >> whose exact cause is completely obvious, and that makes it
|  perfectly
|  >> clear what I need to do to fix foo.
|  >> 3. Fix foo, and disable AllowAmbiguousTypes.
|  >>
|  >> I'd much rather go with
|  >>
|  >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose
|  exact
|  >> cause is hard for me to see, but also an error on bar whose exact
|  >> cause is completely obvious, and that makes it perfectly clear what
|  I
|  >> need to do to fix foo.
|  >> 2. Fix foo.
|  >>
|  >> Simple example of how it is currently:
|  >>
|  >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
|  >>
|  >> <interactive>:14:12:
|  >>     Couldn't match expected type ?F a? with actual type ?F a0?
|  >>     NB: ?F? is a type function, and may not be injective
|  >>     The type variable ?a0? is ambiguous
|  >>     In the ambiguity check for the type signature for ?foo?:
|  >>       foo :: forall a. Num a => F a
|  >>     To defer the ambiguity check to use sites, enable
|  AllowAmbiguousTypes
|  >>     In the type signature for ?foo?: foo :: Num a => F a
|  >>
|  >> Couldn't match what with what? Huh? Where did a0 come from?
|  >>
|  >> > :set -XAllowAmbiguousTypes
|  >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
|  >>
|  >> <interactive>:16:61:
|  >>     Couldn't match expected type ?Int? with actual type ?F a0?
|  >>     The type variable ?a0? is ambiguous
|  >>     In the expression: foo
|  >>     In an equation for ?bar?: bar = foo
|  >>
|  >> Aha! That's the problem! It doesn't know what a0 is! How can I tell
|  >> it what a0 is? Oh! I can't, because foo doesn't give me a handle on
|  it.
|  >> Guess I have to fix foo.
|  >>
|  >> I'd really, really like to get *both* of those messages in one go,
|  >> with the first one preferably explaining itself a bit better.
|  >>
|  >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com>
|  wrote:
|  >> > So you are saying you want users to write a ton of code that
|  >> > happens to have signatures that can never be called and only
|  catch
|  >> > it when they go to try to actually use it in a concrete situation
|  >> > much later?
|  >> >
|  >> > I don't really show how this would be a better default.
|  >> >
|  >> > When and if users see the problem later they have to worry about
|  if
|  >> > they are doing something wrong at the definition site or the call
|  >> > site. With the status quo it complains at the right time that you
|  >> > aren't going to sit there flailing around trying to fix a call
|  site
|  >> > that can never be fixed.
|  >> >
|  >> > -Edward
|  >> >
|  >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer
|  <david.feuer at gmail.com>
|  >> > wrote:
|  >> >>
|  >> >> The ambiguity check produces errors that are quite surprising to
|  >> >> the uninitiated. When the check is suppressed, the errors at use
|  >> >> sites are typically much easier to grasp. On the other hand,
|  >> >> there's obviously a lot of value to catching mistakes as soon as
|  >> >> possible. Would it be possible to turn that into a warning by
|  >> >> default?
|  >> >>
|  >> >>
|  >> >> _______________________________________________
|  >> >> ghc-devs mailing list
|  >> >> ghc-devs at haskell.org
|  >> >>
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fma
|  >> >> il.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7
|  >> >>
|  c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db692644c7b2d408d2f
|  >> >>
|  dfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tzknS1bYbEs2G
|  >> >> NPvXuu6o1st%2b2VMSTTmRSH1L%2f9BSsk%3d
|  >> >>
|  >> >
|  >
|  >
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db6926
|  44c7b2d408d2fdfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kYhH
|  Q00HzSxbbNyqFt2OmHWSpPTyxsbeJPCF1tDzAA0%3d

From ben at well-typed.com  Mon Dec  7 13:37:59 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Dec 2015 14:37:59 +0100
Subject: Haddock for GHC 8.0
Message-ID: <87oae2qszs.fsf@smart-cactus.org>


tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release.


Hello everyone,

As you likely know, the GHC 8.0 release cycle is quickly drawing to a
close. One of the tasks that remains outstanding is porting the patches
on Haddock's `ghc-head` branch to `master`. This task is bound to
require a bit more work than usual this time around as both GHC and
Haddock have evolved significantly (which is a good thing!). Sadly,
Austin and I are quite busy at the moment and would be hard-pressed to
undertake such a task ourselves. Consequently, we need a volunteer to
pick up this work.

At the moment the GHC release schedule is largely determined by progress
on the no-kinds branch but we expect to have a release candidate out
within the next two weeks. If we aren't able to find someone to bring
haddock up-to-date by mid-January I'm afraid we'll have to release GHC
8.0 with the current state of the `ghc-head` branch. Considering the
significant effort that went into this summer's GSoC projects, this
would be a shame.

If you think you might be able to contribute to this effort, please say
so in this thread.

Thanks for all of your effort,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/52bff35b/attachment.sig>

From ben at smart-cactus.org  Mon Dec  7 13:41:19 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 07 Dec 2015 14:41:19 +0100
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87lh96qsu8.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Plugins get to edit the entire core-to-core pipeline!  There is no magic.  At least I don?t think so
>
> file:///Z:/tmp/users_guide/compiler-plugins.html
>
Or for those of us who aren't using Simon's desktop...

http://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#compiler-plugins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/c8db2cae/attachment.sig>

From eir at cis.upenn.edu  Mon Dec  7 14:15:26 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 7 Dec 2015 09:15:26 -0500
Subject: How do I use CallStack?
In-Reply-To: <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
Message-ID: <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>

And sorry if my tone on those emails was a bit snarky. It was late... though snarkiness at any hour is unwelcome. :)

I understand the concerns about the Show instance, though I have no opinion about the name of the pretty-printer. My only request is that the pretty-print function is easily discoverable. In my case, I never would have looked in GHC.Exception, because I wasn't throwing (or dealing with) any exceptions. Perhaps a new module GHC.CallStack that bundles everything together and is the official export point?

Bartosz, thanks for alerting me about pprSTrace. But I now realize that there is an annoying free variable in all of this: the name of the CallStack. Consider this:

> foo :: (?location :: CallStack) => ...
> foo = pprSTrace ...       -- pprSTrace uses ?location
> bar :: (?callstack :: CallStack) => ...
> bar = foo

If I understand correctly, I'll get a redundant constraint warning on bar, and I won't see bar's location in the output from pprSTrace. In other words, the choice for the CallStack name is infectious. I have no problem with ?location, but it's different from `error`'s choice (?callStack) and this choice seems to matter. Should we choose a common name? Advertise this widely with the docs for CallStack? (I imagine it's best for the ecosystem if everyone, everywhere uses the same name.) Or do I understand the feature wrongly?

As quite a separate point from above, I may have found a bug: I put a (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained about a redundant constraint on rewriteEqEvidence, and indeed its call information wasn't propagated. rewriteEqEvidence uses pattern guards and do-notation, but that shouldn't muck with CallStack, should it? I've not tried to reproduce this in a smaller test case.

Many thanks,
Richard

On Dec 7, 2015, at 1:39 AM, Eric Seidel <eric at seidel.io> wrote:

> Hi Richard,
> 
> Sorry for all of the confusion, it seems the docs do indeed need some
> love!
> 
> On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
>> That looks like exactly what I want. Thanks.
>> 
>> There remain two mysteries:
>> - I thought that CallStacks were a new feature that would come with GHC
>> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
>> docs even say (wrongly, evidently) that it's in base since 4.9.
> 
> They were originally merged into 7.11, but were backported to the
> official 7.10.2 release due to popular demand. It appears the @since
> annotation wasn't updated correspondingly.
> 
>> - That function seems missing in HEAD. Or maybe it moved. A little
>> searching says it *did* move, to GHC.Exception.
> 
> In HEAD we are now using CallStacks for error and undefined, which was
> not the case for the 7.10.2 release. This means the type needs to be
> defined much earlier in base, before we even have enough functionality
> to write a sensible formatter. showCallStack currently lives in
> GHC.Exception because that's where it's used, but that's not a good
> reason... I'll take another look at moving it back to GHC.Stack.
> 
>> Well, my problem is solved. But I think the documentation needs a pass
>> here. And is there a reason not to have a Show instance?
> 
> I usually only use compiler-derived Show instances so that Read
> automatically works, as well as some nice formatting libraries like
> http://hackage.haskell.org/package/pretty-show for debugging. For
> pretty-printing like showCallStack I prefer a standalone function or a
> separate type-class.
> 
> If the name "showCallStack" suggests the compiler-derived output, we
> could change it to something like "prettyCallStack" or
> "formatCallStack", I don't have a strong opinion there.
> 
> Thanks for the comments!
> Eric
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Mon Dec  7 15:26:32 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 15:26:32 +0000
Subject: Kind equalities
Message-ID: <708207423a34472a87f3e46f1772ad98@DB4PR30MB030.064d.mgd.msft.net>

Richard

What?s your ETA on the kind-equality stuff?  We wondered in today?s call.  We want to make an RC next week.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/92a00d3c/attachment.html>

From eric at seidel.io  Mon Dec  7 15:35:01 2015
From: eric at seidel.io (Eric Seidel)
Date: Mon, 07 Dec 2015 07:35:01 -0800
Subject: How do I use CallStack?
In-Reply-To: <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
 <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>
Message-ID: <1449502501.1611800.460357641.5B7770E8@webmail.messagingengine.com>



On Mon, Dec 7, 2015, at 06:15, Richard Eisenberg wrote:
> And sorry if my tone on those emails was a bit snarky. It was late...
> though snarkiness at any hour is unwelcome. :)
> 
> I understand the concerns about the Show instance, though I have no
> opinion about the name of the pretty-printer. My only request is that the
> pretty-print function is easily discoverable. In my case, I never would
> have looked in GHC.Exception, because I wasn't throwing (or dealing with)
> any exceptions. Perhaps a new module GHC.CallStack that bundles
> everything together and is the official export point?

I think the existing GHC.Stack makes sense, it already exports the -prof
stacks and could re-export the dwarf stacks. Then we'd have a single
access point for all stack trace functionality. 

> Bartosz, thanks for alerting me about pprSTrace. But I now realize that
> there is an annoying free variable in all of this: the name of the
> CallStack. Consider this:
> 
> > foo :: (?location :: CallStack) => ...
> > foo = pprSTrace ...       -- pprSTrace uses ?location
> > bar :: (?callstack :: CallStack) => ...
> > bar = foo
> 
> If I understand correctly, I'll get a redundant constraint warning on
> bar, and I won't see bar's location in the output from pprSTrace. In
> other words, the choice for the CallStack name is infectious. I have no
> problem with ?location, but it's different from `error`'s choice
> (?callStack) and this choice seems to matter. Should we choose a common
> name? Advertise this widely with the docs for CallStack? (I imagine it's
> best for the ecosystem if everyone, everywhere uses the same name.) Or do
> I understand the feature wrongly?

That is correct. I'll advertise the ?callStack convention in the docs. 

> 
> As quite a separate point from above, I may have found a bug: I put a
> (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then
> put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained
> about a redundant constraint on rewriteEqEvidence, and indeed its call
> information wasn't propagated. rewriteEqEvidence uses pattern guards and
> do-notation, but that shouldn't muck with CallStack, should it? I've not
> tried to reproduce this in a smaller test case.

I have a patch waiting to land that reworks the CallStack solver due to
a similar bug with let binders. I suspect it will fix this bug too, I'll
check it out in my branch. 

> 
> Many thanks,
> Richard
> 
> On Dec 7, 2015, at 1:39 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> > Hi Richard,
> > 
> > Sorry for all of the confusion, it seems the docs do indeed need some
> > love!
> > 
> > On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
> >> That looks like exactly what I want. Thanks.
> >> 
> >> There remain two mysteries:
> >> - I thought that CallStacks were a new feature that would come with GHC
> >> 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the
> >> docs even say (wrongly, evidently) that it's in base since 4.9.
> > 
> > They were originally merged into 7.11, but were backported to the
> > official 7.10.2 release due to popular demand. It appears the @since
> > annotation wasn't updated correspondingly.
> > 
> >> - That function seems missing in HEAD. Or maybe it moved. A little
> >> searching says it *did* move, to GHC.Exception.
> > 
> > In HEAD we are now using CallStacks for error and undefined, which was
> > not the case for the 7.10.2 release. This means the type needs to be
> > defined much earlier in base, before we even have enough functionality
> > to write a sensible formatter. showCallStack currently lives in
> > GHC.Exception because that's where it's used, but that's not a good
> > reason... I'll take another look at moving it back to GHC.Stack.
> > 
> >> Well, my problem is solved. But I think the documentation needs a pass
> >> here. And is there a reason not to have a Show instance?
> > 
> > I usually only use compiler-derived Show instances so that Read
> > automatically works, as well as some nice formatting libraries like
> > http://hackage.haskell.org/package/pretty-show for debugging. For
> > pretty-printing like showCallStack I prefer a standalone function or a
> > separate type-class.
> > 
> > If the name "showCallStack" suggests the compiler-derived output, we
> > could change it to something like "prettyCallStack" or
> > "formatCallStack", I don't have a strong opinion there.
> > 
> > Thanks for the comments!
> > Eric
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

From asr at eafit.edu.co  Mon Dec  7 15:39:43 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Mon, 7 Dec 2015 10:39:43 -0500
Subject: [ANNOUNCE] 7.10.3 release candidate 3
In-Reply-To: <CAEDGBq+bfHAtpUDBfnVWw0QTD=S_rKC-DBwpxtnS9yoXOXju7Q@mail.gmail.com>
References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org>
 <CAEDGBqJgvaq9Ty3wm-nJ7uUU0PUWjKtFUY-djFQMyT-32CmcsA@mail.gmail.com>
 <87si3o7t5n.fsf@smart-cactus.org>
 <CAEDGBq+bfHAtpUDBfnVWw0QTD=S_rKC-DBwpxtnS9yoXOXju7Q@mail.gmail.com>
Message-ID: <CAOUWSGCk+0nY2sPk9y-3y_jZ_iXUuyt-63c8prc5MEQd7pa3pg@mail.gmail.com>

On 2 December 2015 at 01:54, Jens Petersen <juhpetersen at gmail.com> wrote:
> On 29 November 2015 at 23:54, Ben Gamari <ben at well-typed.com> wrote:
>> On that note, 7.10.3 is coming. At the moment I am blocked on getting a
>> Cabal release tagged but hopefully this will happen Real Soon Now(TM).
>
> Cool - Cabal-1.22.5.0 went into Stackage Nightly yesterday. :-)

I saw that GHC 7.10.3 is available at

  http://downloads.haskell.org/~ghc/7.10.3/

Does anyone have an ETA for GHC 7.10.3?

(In Agda headquarters we are trying to decide between waiting or
realising a new version not tested with GHC 7.10.3)

-- 
Andr?s

From eric at seidel.io  Mon Dec  7 15:44:24 2015
From: eric at seidel.io (Eric Seidel)
Date: Mon, 07 Dec 2015 07:44:24 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>

The problem, as I recall, is that GHC does an initial bit of dead-code
elimination in the desugarer, before the plugins have a chance to run.
(I believe this is part of simpleOptPgm, but may be mistaken)

I'm not sure why this is done in the desugarer, it seems to be out of
place there. 

On Mon, Dec 7, 2015, at 05:14, Simon Peyton Jones wrote:
> Plugins get to edit the entire core-to-core pipeline!  There is no magic.
>  At least I don?t think so
> 
> file:///Z:/tmp/users_guide/compiler-plugins.html
> 
> S
> 
> From: Levent Erkok [mailto:erkokl at gmail.com]
> Sent: 07 December 2015 13:11
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu;
> ghc-devs at haskell.org
> Subject: Re: Plugins: Accessing unexported bindings
> 
> That's a good point; keeping all annotated bindings alive seems to be an
> overkill..
> 
> Regarding implementing "pass at the start." I'm not sure if plugin
> authors have any freedom as to decide when their plugin actually runs. It
> seems GHC magically determines the order and runs them. Can you point me
> to some code/docs that tells me how to go "first" in that sense? (Or at
> least before the pass that drops dead code.)
> 
> On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC
> should keep it alive.
> 
> Really?  It might be something like ?don?t give warnings for this
> binding? or ?don?t inline me? or something.   To say *any* annotation
> seems a bit brutal doesn?t it?    Mind you I don?t have a better idea.
> 
> One thought: your plugin could add a pass right at the start, which marks
> everything you want as keep-alive.
> 
> S
> 
> From: Levent Erkok [mailto:erkokl at gmail.com]
> Sent: 07 December 2015 12:42
> To: Simon Peyton Jones
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> ezyang at mit.edu<mailto:ezyang at mit.edu>;
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Re: Plugins: Accessing unexported bindings
> 
> Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC
> should keep it alive.
> 
> Is that something one of the core-developers can implement? Happy to open
> a ticket if that helps.
> 
> On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> If it's "dead" in this sense, it's already removed from ModGuts, no?
> 
> Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
> 
> So you need a way to keep it alive. Maybe we need a pragma for that.   Or
> how would you like to signal it in the source code?
> 
> Simon
> 
> From: Levent Erkok [mailto:erkokl at gmail.com]
> Sent: 07 December 2015 12:05
> To: Simon Peyton Jones
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> ezyang at mit.edu<mailto:ezyang at mit.edu>;
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Re: Plugins: Accessing unexported bindings
> 
> Thanks Simon.. But I remain utterly confused. As a "plugin" author, how
> do I get my hands on the Id associated with a top-level binder? If it's
> "dead" in this sense, it's already removed from ModGuts, no?
> 
> That is, by the time GHC runs my plugin, the Id has already disappeared
> for me to mark it "Local Exported." Is that not correct?
> 
> On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones
> <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> In the mean time, I'm still looking for a solution that doesn't involve
> exporting such identifiers from modules. As Eric pointed out, that seems
> to be the only current work-around for the time being.
> 
> ?Exported? in this context only means ?keep alive?. It does not mean
> exported in the Haskell source code sense. I?ve just added this comment
> to Var.hs.
> 
> So I think it does just what you want.
> 
> Simon
> 
> data ExportFlag   -- See Note [ExportFlag on binders]
>   = NotExported   -- ^ Not exported: may be discarded as dead code.
>   | Exported      -- ^ Exported: kept alive
> 
> {- Note [ExportFlag on binders]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An ExportFlag of "Exported" on a top-level binder says "keep this
> binding alive; do not drop it as dead code".  This transititively
> keeps alive all the other top-level bindings that this binding refers
> to.  This property is persisted all the way down the pipeline, so that
> the binding will be compiled all the way to object code, and its
> symbols will appear in the linker symbol table.
> 
> However, note that this use of "exported" is quite different to the
> export list on a Haskell module.  Setting the ExportFlag on an Id does
> /not/ mean that if you import the module (in Haskell source code you
> will see this Id.  Of course, things that appear in the export list
> of the source Haskell module do indeed have their ExportFlag set.
> But many other things, such as dictionary functions, are kept alive
> by having their ExportFlag set, even though they are not exported
> in the source-code sense.
> 
> We should probably use a different term for ExportFlag, like
> KeepAlive.
> 
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Levent
> Erkok
> Sent: 06 December 2015 20:32
> To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> ezyang at mit.edu<mailto:ezyang at mit.edu>
> Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> Subject: Re: Plugins: Accessing unexported bindings
> 
> Omer, Eric, Ed: Thanks for the comments.
> 
> Omer: I think Eric's observation is at play here. We're talking about
> "dead-code," i.e., a binding that is neither exported, nor used by any
> binding inside the module. Those seem to be getting dropped by the time
> user-plugins are run. Unfortunately, this is precisely what one would do
> with "properties" embedded in code. They serve as documentation perhaps,
> but are otherwise not needed by any other binding nor it makes sense to
> export them.
> 
> Edward: Can you provide some more info into your solution? Sounds like a
> chicken-egg issue to me: As a plugin author, I need the bindings to
> access the Ids, and looks like I need the Ids to access the binders?
> 
> A simple solution would be to simply keep all top-level bindings around
> while the plugin are running, but that obviously can lead to unnecessary
> work if the code is truly dead. A compromise could be that the
> annotations can serve as entry points as well: I.e., if there's an
> annotation on a top-level binder, then it should *not* be considered
> dead-code at least until after all the plugins are run. That would
> definitely simplify life. Would that be an acceptable alternative?
> 
> In the mean time, I'm still looking for a solution that doesn't involve
> exporting such identifiers from modules. As Eric pointed out, that seems
> to be the only current work-around for the time being.
> 
> Thanks,
> 
> -Levent.
> 
> On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel
> <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> GHC should only drop un-exported bindings from the ModGuts if they're
> also unused, ie *dead code*.
> 
> The only way I know to get around this is to use the bindings somewhere,
> or just export them.
> 
> On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> > Hello,
> >
> > The mg_binds field of the ModGuts seem to only contain the bindings that
> > are exported from the module being compiled.
> >
> > I guess GHC must be running user-plugins after it drops the bindings that
> > are not exported, which makes perfect sense for most use cases. However,
> > I'm working on a plugin where the end-programmer embeds "properties" in
> > the
> > form of functions inside his/her code, which are not necessarily exported
> > from the module under consideration.
> >
> > Is there a way to access all top-level bindings in a module from a
> > plugin,
> > even if those bindings are not exported?
> >
> > Thanks,
> >
> > -Levent.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> 

From omeragacan at gmail.com  Mon Dec  7 16:21:59 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 7 Dec 2015 11:21:59 -0500
Subject: question about coercions between primitive types in STG level
In-Reply-To: <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMQQO3kyDeZ8i3=pj9pkTomz_LwcBuEQHiBxRjntVgLos8H3Hw@mail.gmail.com>

Thanks Simon, primops worked fine, but not I'm getting assembler errors(even
though -dcore-lint, -dstg-lint and -dcmm-lint are all passing).

The error is caused by this STG expression:

    case (#,#) [ds_gX8 ds_gX9] of _ {
      (#,#) tag_gWR ubx_gWS ->
          case tag_gWR of tag_gWR {
            __DEFAULT -> GHC.Err.undefined;
            1# ->
                let {
                  sat_sWD :: [GHC.Types.Char] =
                      \u srt:SRT:[roK :-> GHC.Show.$fShowInt] []
                          let { sat_sWC :: GHC.Types.Int = NO_CCS
GHC.Types.I#! [ubx_gWS];
                          } in  GHC.Show.show GHC.Show.$fShowInt sat_sWC; } in
                let {
                  sat_sWB :: [GHC.Types.Char] =
                      \u srt:SRT:[0k :-> GHC.CString.unpackCString#] []
                          GHC.CString.unpackCString# "Left "#;
                } in  GHC.Base.++ sat_sWB sat_sWD;
            2# ->
                let {
                  co_gWT :: GHC.Prim.Float# =
                      sat-only \s [] int2Float# [ubx_gWS]; } in
                let {
                  sat_sWH :: [GHC.Types.Char] =
                      \u srt:SRT:[rd2 :-> GHC.Float.$fShowFloat] []
                          let { sat_sWG :: GHC.Types.Float = NO_CCS
GHC.Types.F#! [co_gWT];
                          } in  GHC.Show.show GHC.Float.$fShowFloat
sat_sWG; } in
                let {
                  sat_sWF :: [GHC.Types.Char] =
                      \u srt:SRT:[0k :-> GHC.CString.unpackCString#] []
                          GHC.CString.unpackCString# "Right "#;
                } in  GHC.Base.++ sat_sWF sat_sWH;
          };
    };

In the first case(when the tag is 1#) I'm not doing any coercions, second
argument of the tuple is directly used. In the second case(when the tag is 2#),
I'm generating this let-binding:

    let {
      co_gWT :: GHC.Prim.Float# =
          sat-only \s [] int2Float# [ubx_gWS]; }

And then in the RHS of case alternative I'm using co_gWT instead of ubx_gWS,
but for some reason GHC is generating invalid assembly for this expression:

    /tmp/ghc2889_0/ghc_2.s: Assembler messages:

    /tmp/ghc2889_0/ghc_2.s:125:0: error:
         Error: `16(%xmm1)' is not a valid base/index expression
    `gcc' failed in phase `Assembler'. (Exit code: 1)

The assembly seems to be:

    ==================== Asm code ====================
    .section .text
    .align 8
    .quad 4294967296
    .quad 18
    co_gWT_info:
    _cY7:
    _cY9:
    movq 16(%xmm1),%rax
    cvtsi2ssq %rax,%xmm0
    movss %xmm0,%xmm1
    jmp *(%rbp)
    .size co_gWT_info, .-co_gWT_info

Do you have any ideas why this may be happening?

2015-12-07 7:23 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
> If memory serves, there are primops for converting between unboxed values of different widths.
>
> Certainly converting between a float and a non-float will require an instruction on some architectures, since they use different register sets.
>
> Re (2) I have no idea.  You'll need to get more information... pprTrace or something.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
> |  Sinan Agacan
> |  Sent: 06 December 2015 18:25
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: question about coercions between primitive types in STG level
> |
> |  Hi all,
> |
> |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
> |  coercions at the STG level. It works fine for lifted types, but for
> |  unlifted ones I'm having some problems. What I'm trying to do is given
> |  a number of primitive types I'm finding the one with biggest size, and
> |  then generating a constructor that takes this biggest primitive type
> |  as argument.
> |
> |  The problem is that this is not working very well - GHC is generating
> |  illegal instructions that try to load a F32 value to a register
> |  allocated for I64, using movss instruction.
> |
> |  CoreLint is catching this error and printing this:
> |
> |      Cmm lint error:
> |        in basic block c1hF
> |          in assignment:
> |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
> |            Reg ty: I64
> |            Rhs ty: F32
> |
> |  So I have two questions about this:
> |
> |  1. Is there a way to safely do this? What are my options here? What
> |  I'm trying
> |     to do is to use a single data constructor field for different
> |  primitive
> |     types.  The field is guaranteed to be as big as necessary.
> |
> |  2. In the Cmm code shown above, the type annotation is showing `W32`
> |  but in the
> |     error message it says `F32`. I'm confused about this, is this error
> |  message
> |     given because the sizes don't match? (64bits vs 32bits) Why the
> |  type
> |     annotation says W32 while the value has type F32?
> |
> |  Thanks..
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa6254e5
> |  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
> |  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d

From simonpj at microsoft.com  Mon Dec  7 16:22:55 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 16:22:55 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
 <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>
Message-ID: <57a1c733401f434d9815375017760ebd@DB4PR30MB030.064d.mgd.msft.net>

It would not be hard to stop the desugarer dropping dead bindings, if that was helpful.

S

|  -----Original Message-----
|  From: Eric Seidel [mailto:eric at seidel.io]
|  Sent: 07 December 2015 15:44
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Levent Erkok <erkokl at gmail.com>; omeragacan at gmail.com;
|  ezyang at mit.edu; ghc-devs at haskell.org
|  Subject: Re: Plugins: Accessing unexported bindings
|  
|  The problem, as I recall, is that GHC does an initial bit of dead-code
|  elimination in the desugarer, before the plugins have a chance to run.
|  (I believe this is part of simpleOptPgm, but may be mistaken)
|  
|  I'm not sure why this is done in the desugarer, it seems to be out of
|  place there.
|  
|  On Mon, Dec 7, 2015, at 05:14, Simon Peyton Jones wrote:
|  > Plugins get to edit the entire core-to-core pipeline!  There is no
|  magic.
|  >  At least I don?t think so
|  >
|  > file:///Z:/tmp/users_guide/compiler-plugins.html
|  >
|  > S
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com]
|  > Sent: 07 December 2015 13:11
|  > To: Simon Peyton Jones <simonpj at microsoft.com>
|  > Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com;
|  > ezyang at mit.edu; ghc-devs at haskell.org
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > That's a good point; keeping all annotated bindings alive seems to
|  be
|  > an overkill..
|  >
|  > Regarding implementing "pass at the start." I'm not sure if plugin
|  > authors have any freedom as to decide when their plugin actually
|  runs.
|  > It seems GHC magically determines the order and runs them. Can you
|  > point me to some code/docs that tells me how to go "first" in that
|  > sense? (Or at least before the pass that drops dead code.)
|  >
|  > On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  > Indeed. How about this: if there's an ANN on a binder (any ANN),
|  then
|  > GHC should keep it alive.
|  >
|  > Really?  It might be something like ?don?t give warnings for this
|  > binding? or ?don?t inline me? or something.   To say *any*
|  annotation
|  > seems a bit brutal doesn?t it?    Mind you I don?t have a better
|  idea.
|  >
|  > One thought: your plugin could add a pass right at the start, which
|  > marks everything you want as keep-alive.
|  >
|  > S
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com]
|  > Sent: 07 December 2015 12:42
|  > To: Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Indeed. How about this: if there's an ANN on a binder (any ANN),
|  then
|  > GHC should keep it alive.
|  >
|  > Is that something one of the core-developers can implement? Happy to
|  > open a ticket if that helps.
|  >
|  > On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  > If it's "dead" in this sense, it's already removed from ModGuts, no?
|  >
|  > Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
|  >
|  > So you need a way to keep it alive. Maybe we need a pragma for that.
|  Or
|  > how would you like to signal it in the source code?
|  >
|  > Simon
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com]
|  > Sent: 07 December 2015 12:05
|  > To: Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Thanks Simon.. But I remain utterly confused. As a "plugin" author,
|  > how do I get my hands on the Id associated with a top-level binder?
|  If
|  > it's "dead" in this sense, it's already removed from ModGuts, no?
|  >
|  > That is, by the time GHC runs my plugin, the Id has already
|  > disappeared for me to mark it "Local Exported." Is that not correct?
|  >
|  > On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  > In the mean time, I'm still looking for a solution that doesn't
|  > involve exporting such identifiers from modules. As Eric pointed
|  out,
|  > that seems to be the only current work-around for the time being.
|  >
|  > ?Exported? in this context only means ?keep alive?. It does not mean
|  > exported in the Haskell source code sense. I?ve just added this
|  > comment to Var.hs.
|  >
|  > So I think it does just what you want.
|  >
|  > Simon
|  >
|  > data ExportFlag   -- See Note [ExportFlag on binders]
|  >   = NotExported   -- ^ Not exported: may be discarded as dead code.
|  >   | Exported      -- ^ Exported: kept alive
|  >
|  > {- Note [ExportFlag on binders]
|  > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  > An ExportFlag of "Exported" on a top-level binder says "keep this
|  > binding alive; do not drop it as dead code".  This transititively
|  > keeps alive all the other top-level bindings that this binding
|  refers
|  > to.  This property is persisted all the way down the pipeline, so
|  that
|  > the binding will be compiled all the way to object code, and its
|  > symbols will appear in the linker symbol table.
|  >
|  > However, note that this use of "exported" is quite different to the
|  > export list on a Haskell module.  Setting the ExportFlag on an Id
|  does
|  > /not/ mean that if you import the module (in Haskell source code you
|  > will see this Id.  Of course, things that appear in the export list
|  of
|  > the source Haskell module do indeed have their ExportFlag set.
|  > But many other things, such as dictionary functions, are kept alive
|  by
|  > having their ExportFlag set, even though they are not exported in
|  the
|  > source-code sense.
|  >
|  > We should probably use a different term for ExportFlag, like
|  > KeepAlive.
|  >
|  > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > Levent Erkok
|  > Sent: 06 December 2015 20:32
|  > To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu>
|  > Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Omer, Eric, Ed: Thanks for the comments.
|  >
|  > Omer: I think Eric's observation is at play here. We're talking
|  about
|  > "dead-code," i.e., a binding that is neither exported, nor used by
|  any
|  > binding inside the module. Those seem to be getting dropped by the
|  > time user-plugins are run. Unfortunately, this is precisely what one
|  > would do with "properties" embedded in code. They serve as
|  > documentation perhaps, but are otherwise not needed by any other
|  > binding nor it makes sense to export them.
|  >
|  > Edward: Can you provide some more info into your solution? Sounds
|  like
|  > a chicken-egg issue to me: As a plugin author, I need the bindings
|  to
|  > access the Ids, and looks like I need the Ids to access the binders?
|  >
|  > A simple solution would be to simply keep all top-level bindings
|  > around while the plugin are running, but that obviously can lead to
|  > unnecessary work if the code is truly dead. A compromise could be
|  that
|  > the annotations can serve as entry points as well: I.e., if there's
|  an
|  > annotation on a top-level binder, then it should *not* be considered
|  > dead-code at least until after all the plugins are run. That would
|  > definitely simplify life. Would that be an acceptable alternative?
|  >
|  > In the mean time, I'm still looking for a solution that doesn't
|  > involve exporting such identifiers from modules. As Eric pointed
|  out,
|  > that seems to be the only current work-around for the time being.
|  >
|  > Thanks,
|  >
|  > -Levent.
|  >
|  > On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel
|  > <eric at seidel.io<mailto:eric at seidel.io>> wrote:
|  > GHC should only drop un-exported bindings from the ModGuts if
|  they're
|  > also unused, ie *dead code*.
|  >
|  > The only way I know to get around this is to use the bindings
|  > somewhere, or just export them.
|  >
|  > On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
|  > > Hello,
|  > >
|  > > The mg_binds field of the ModGuts seem to only contain the
|  bindings
|  > > that are exported from the module being compiled.
|  > >
|  > > I guess GHC must be running user-plugins after it drops the
|  bindings
|  > > that are not exported, which makes perfect sense for most use
|  cases.
|  > > However, I'm working on a plugin where the end-programmer embeds
|  > > "properties" in the form of functions inside his/her code, which
|  are
|  > > not necessarily exported from the module under consideration.
|  > >
|  > > Is there a way to access all top-level bindings in a module from a
|  > > plugin, even if those bindings are not exported?
|  > >
|  > > Thanks,
|  > >
|  > > -Levent.
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
|  > > .haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%
|  > >
|  7csimonpj%40064d.mgd.microsoft.com%7cf6e3a9d4ad9f4e53a3ab08d2ff1d493
|  > >
|  4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NY
|  > >
|  fBqR90%2bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.
|  > > outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-
|  bin%2fmailman%2
|  > > flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
|  > >
|  %7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db
|  > > 47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csi
|  >
|  monpj%40064d.mgd.microsoft.com%7cf6e3a9d4ad9f4e53a3ab08d2ff1d4934%7c72
|  >
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NYfBqR90%2
|  >
|  bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.outlook.co
|  > m/?url=http%3a%2f%2fmail.haskell.org%2fcgi-
|  bin%2fmailman%2flistinfo%2f
|  > ghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e3
|  >
|  14080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6
|  > DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
|  >

From rwbarton at gmail.com  Mon Dec  7 16:58:40 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Mon, 7 Dec 2015 11:58:40 -0500
Subject: question about coercions between primitive types in STG level
In-Reply-To: <CAMQQO3kyDeZ8i3=pj9pkTomz_LwcBuEQHiBxRjntVgLos8H3Hw@mail.gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3kyDeZ8i3=pj9pkTomz_LwcBuEQHiBxRjntVgLos8H3Hw@mail.gmail.com>
Message-ID: <CADmwj473rtHK_6gQDs6rLXo9_NxX2oSsnuL1Ei502V2rkhKxSQ@mail.gmail.com>

Note that int2Float# converts an Int# to the Float# with the same numeric
value (e.g. 72 -> 72.0), not the one with the same bit representation
(which doesn't really make sense anyways since Int# and Float# may be
different sizes). So I think it's not what you want.

At least on x86_64, it's rather expensive to move a bit representation
between a general-purpose register and a floating-point (xmm) register. As
far as I know, the only way is to go through memory. This may have design
implications for your work. For example, if you have an unboxed sum of two
Double#s, it would certainly be better to store the data part in a
floating-point register than a general-purpose register. If you have a sum
that contains both integral and floating-point variants, it may be better
depending on the situation to store its data in integer registers,
floating-point registers, or a combination (using extra space). I doubt you
want to give the programmer that much control though... One option would
be, at least for a first version, treat Int# and Double# and Float# as
three incompatible kinds of memory/registers that cannot alias each other.

As for your assembly code, can you provide the Cmm code that compiles to
it? But in any case "movq 16(%xmm1),%rax" is certainly wrong, it should be
offseting 16 bytes from a register like Sp or R1.

Regards,
Reid Barton

On Mon, Dec 7, 2015 at 11:21 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> Thanks Simon, primops worked fine, but not I'm getting assembler
> errors(even
> though -dcore-lint, -dstg-lint and -dcmm-lint are all passing).
>
> The error is caused by this STG expression:
>
>     case (#,#) [ds_gX8 ds_gX9] of _ {
>       (#,#) tag_gWR ubx_gWS ->
>           case tag_gWR of tag_gWR {
>             __DEFAULT -> GHC.Err.undefined;
>             1# ->
>                 let {
>                   sat_sWD :: [GHC.Types.Char] =
>                       \u srt:SRT:[roK :-> GHC.Show.$fShowInt] []
>                           let { sat_sWC :: GHC.Types.Int = NO_CCS
> GHC.Types.I#! [ubx_gWS];
>                           } in  GHC.Show.show GHC.Show.$fShowInt sat_sWC;
> } in
>                 let {
>                   sat_sWB :: [GHC.Types.Char] =
>                       \u srt:SRT:[0k :-> GHC.CString.unpackCString#] []
>                           GHC.CString.unpackCString# "Left "#;
>                 } in  GHC.Base.++ sat_sWB sat_sWD;
>             2# ->
>                 let {
>                   co_gWT :: GHC.Prim.Float# =
>                       sat-only \s [] int2Float# [ubx_gWS]; } in
>                 let {
>                   sat_sWH :: [GHC.Types.Char] =
>                       \u srt:SRT:[rd2 :-> GHC.Float.$fShowFloat] []
>                           let { sat_sWG :: GHC.Types.Float = NO_CCS
> GHC.Types.F#! [co_gWT];
>                           } in  GHC.Show.show GHC.Float.$fShowFloat
> sat_sWG; } in
>                 let {
>                   sat_sWF :: [GHC.Types.Char] =
>                       \u srt:SRT:[0k :-> GHC.CString.unpackCString#] []
>                           GHC.CString.unpackCString# "Right "#;
>                 } in  GHC.Base.++ sat_sWF sat_sWH;
>           };
>     };
>
> In the first case(when the tag is 1#) I'm not doing any coercions, second
> argument of the tuple is directly used. In the second case(when the tag is
> 2#),
> I'm generating this let-binding:
>
>     let {
>       co_gWT :: GHC.Prim.Float# =
>           sat-only \s [] int2Float# [ubx_gWS]; }
>
> And then in the RHS of case alternative I'm using co_gWT instead of
> ubx_gWS,
> but for some reason GHC is generating invalid assembly for this expression:
>
>     /tmp/ghc2889_0/ghc_2.s: Assembler messages:
>
>     /tmp/ghc2889_0/ghc_2.s:125:0: error:
>          Error: `16(%xmm1)' is not a valid base/index expression
>     `gcc' failed in phase `Assembler'. (Exit code: 1)
>
> The assembly seems to be:
>
>     ==================== Asm code ====================
>     .section .text
>     .align 8
>     .quad 4294967296
>     .quad 18
>     co_gWT_info:
>     _cY7:
>     _cY9:
>     movq 16(%xmm1),%rax
>     cvtsi2ssq %rax,%xmm0
>     movss %xmm0,%xmm1
>     jmp *(%rbp)
>     .size co_gWT_info, .-co_gWT_info
>
> Do you have any ideas why this may be happening?
>
> 2015-12-07 7:23 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
> > If memory serves, there are primops for converting between unboxed
> values of different widths.
> >
> > Certainly converting between a float and a non-float will require an
> instruction on some architectures, since they use different register sets.
> >
> > Re (2) I have no idea.  You'll need to get more information... pprTrace
> or something.
> >
> > Simon
> >
> > |  -----Original Message-----
> > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> ?mer
> > |  Sinan Agacan
> > |  Sent: 06 December 2015 18:25
> > |  To: ghc-devs <ghc-devs at haskell.org>
> > |  Subject: question about coercions between primitive types in STG level
> > |
> > |  Hi all,
> > |
> > |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
> > |  coercions at the STG level. It works fine for lifted types, but for
> > |  unlifted ones I'm having some problems. What I'm trying to do is given
> > |  a number of primitive types I'm finding the one with biggest size, and
> > |  then generating a constructor that takes this biggest primitive type
> > |  as argument.
> > |
> > |  The problem is that this is not working very well - GHC is generating
> > |  illegal instructions that try to load a F32 value to a register
> > |  allocated for I64, using movss instruction.
> > |
> > |  CoreLint is catching this error and printing this:
> > |
> > |      Cmm lint error:
> > |        in basic block c1hF
> > |          in assignment:
> > |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
> > |            Reg ty: I64
> > |            Rhs ty: F32
> > |
> > |  So I have two questions about this:
> > |
> > |  1. Is there a way to safely do this? What are my options here? What
> > |  I'm trying
> > |     to do is to use a single data constructor field for different
> > |  primitive
> > |     types.  The field is guaranteed to be as big as necessary.
> > |
> > |  2. In the Cmm code shown above, the type annotation is showing `W32`
> > |  but in the
> > |     error message it says `F32`. I'm confused about this, is this error
> > |  message
> > |     given because the sizes don't match? (64bits vs 32bits) Why the
> > |  type
> > |     annotation says W32 while the value has type F32?
> > |
> > |  Thanks..
> > |  _______________________________________________
> > |  ghc-devs mailing list
> > |  ghc-devs at haskell.org
> > |
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> > |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> > |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> %7ced6a1fbfa6254e5
> > |  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
> > |  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/d1ce064b/attachment.html>

From marlowsd at gmail.com  Mon Dec  7 18:57:22 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 7 Dec 2015 18:57:22 +0000
Subject: question about coercions between primitive types in STG level
In-Reply-To: <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <5665D692.30506@gmail.com>

Simon's right, you need an explicit conversion, and unfortunately those 
conversions don't currently exist.  You would have to add them to the 
MachOp type, and implement them in each of the native code generators.

The good news is that if you did this, we could implement cheap 
conversions between the IEEE floating point types and their 
representations as unboxed integers, which is currently done by poking 
the values to memory and then peeking them back at the desired type. 
There's a ticket for this around somewhere....

Cheers
Simon

On 07/12/2015 12:23, Simon Peyton Jones wrote:
> If memory serves, there are primops for converting between unboxed values of different widths.
>
> Certainly converting between a float and a non-float will require an instruction on some architectures, since they use different register sets.
>
> Re (2) I have no idea.  You'll need to get more information... pprTrace or something.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
> |  Sinan Agacan
> |  Sent: 06 December 2015 18:25
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: question about coercions between primitive types in STG level
> |
> |  Hi all,
> |
> |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
> |  coercions at the STG level. It works fine for lifted types, but for
> |  unlifted ones I'm having some problems. What I'm trying to do is given
> |  a number of primitive types I'm finding the one with biggest size, and
> |  then generating a constructor that takes this biggest primitive type
> |  as argument.
> |
> |  The problem is that this is not working very well - GHC is generating
> |  illegal instructions that try to load a F32 value to a register
> |  allocated for I64, using movss instruction.
> |
> |  CoreLint is catching this error and printing this:
> |
> |      Cmm lint error:
> |        in basic block c1hF
> |          in assignment:
> |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
> |            Reg ty: I64
> |            Rhs ty: F32
> |
> |  So I have two questions about this:
> |
> |  1. Is there a way to safely do this? What are my options here? What
> |  I'm trying
> |     to do is to use a single data constructor field for different
> |  primitive
> |     types.  The field is guaranteed to be as big as necessary.
> |
> |  2. In the Cmm code shown above, the type annotation is showing `W32`
> |  but in the
> |     error message it says `F32`. I'm confused about this, is this error
> |  message
> |     given because the sizes don't match? (64bits vs 32bits) Why the
> |  type
> |     annotation says W32 while the value has type F32?
> |
> |  Thanks..
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa6254e5
> |  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
> |  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From eric at seidel.io  Mon Dec  7 19:23:14 2015
From: eric at seidel.io (Eric Seidel)
Date: Mon, 07 Dec 2015 11:23:14 -0800
Subject: How do I use CallStack?
In-Reply-To: <1449502501.1611800.460357641.5B7770E8@webmail.messagingengine.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
 <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>
 <1449502501.1611800.460357641.5B7770E8@webmail.messagingengine.com>
Message-ID: <1449516194.1200113.460653793.3E651804@webmail.messagingengine.com>

> > As quite a separate point from above, I may have found a bug: I put a
> > (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then
> > put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained
> > about a redundant constraint on rewriteEqEvidence, and indeed its call
> > information wasn't propagated. rewriteEqEvidence uses pattern guards and
> > do-notation, but that shouldn't muck with CallStack, should it? I've not
> > tried to reproduce this in a smaller test case.

After staring at your bug confusedly for a few minutes, wondering why I
couldn't simplify it, I realized that the actual warning I was getting
was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in
fact use a CallStack (by default) so the redundant constraint warning
there would be correct. If I add a call to error, everything seems to
check out.

Can you confirm?

Thanks!
Eric

From jan.stolarek at p.lodz.pl  Mon Dec  7 19:23:04 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 7 Dec 2015 20:23:04 +0100
Subject: A GHC Library
In-Reply-To: <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <ACD046E5-3AC9-473F-9B5F-DC4E5E892AEA@cis.upenn.edu>
 <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
Message-ID: <201512072023.04367.jan.stolarek@p.lodz.pl>

I know this is a bit old, but I just had a thought that perhaps we could archive GHC papers on 
arxiv.org? This should be permanent and with a bit of effort we can get around copyright issues 
(I think). Surprisingly little Haskell research can be found on arXiv and perhaps it is time we 
changed that?

Janek

Dnia ?roda, 29 lipca 2015, Richard Eisenberg napisa?:
> Done -- merged into ReadingList.
>
> On Jul 28, 2015, at 9:39 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> > On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> >> Good plan; maybe you can merge your list into the existing Reading List
> >> that Jan pointed you to?
> >>
> >> I think there would be merit in actually snapshotting the bits into one
> >> safe place.  Links go dead etc, and having a single archive location
> >> might be a very good thing.  If anyone feels like doing that.
> >
> > That was actually my original intent. But then I worried about copyright
> > issues. So instead I just pointed to doi.org links, which should at least
> > give our future selves a fighting shot at getting the original resource.
> >
> > Will merge with the other page (which I was clearly unaware of) tomorrow.
> > I actually think most of my entries are distinct from those on the other
> > page, so my work wasn't wasted.
> >
> > Richard
> >
> >> Simon
> >>
> >> | -----Original Message-----
> >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> >> | Richard Eisenberg
> >> | Sent: 28 July 2015 16:15
> >> | To: ghc-devs Devs
> >> | Subject: A GHC Library
> >> |
> >> | Hi devs,
> >> |
> >> | It has struck me that we have a vast trove of documentation about GHC
> >> | in the form of academic papers, but little organization to this trove.
> >> | The papers are scattered across authors' websites, and sometimes it is
> >> | hard to remember what a paper is titled when searching for it.
> >> |
> >> | I have thus started a wiki page here:
> >> | https://ghc.haskell.org/trac/ghc/wiki/Library
> >> |
> >> | I would love for this page to be the Definitive List of GHC-related
> >> | papers. The list I've included is, of course, woefully short, but it
> >> | is a starting point. Please add to it!
> >> |
> >> | Have you written a GHC paper? If so, make sure it's included.
> >> |
> >> | Thanks,
> >> | Richard
> >> | _______________________________________________
> >> | ghc-devs mailing list
> >> | ghc-devs at haskell.org
> >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at 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.

From eir at cis.upenn.edu  Mon Dec  7 19:25:26 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 7 Dec 2015 14:25:26 -0500
Subject: How do I use CallStack?
In-Reply-To: <1449516194.1200113.460653793.3E651804@webmail.messagingengine.com>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
 <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>
 <1449502501.1611800.460357641.5B7770E8@webmail.messagingengine.com>
 <1449516194.1200113.460653793.3E651804@webmail.messagingengine.com>
Message-ID: <3EF1F63A-DC81-421C-81D4-5A999341669F@cis.upenn.edu>


On Dec 7, 2015, at 2:23 PM, Eric Seidel <eric at seidel.io> wrote:

> After staring at your bug confusedly for a few minutes, wondering why I
> couldn't simplify it, I realized that the actual warning I was getting
> was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in
> fact use a CallStack (by default) so the redundant constraint warning
> there would be correct. If I add a call to error, everything seems to
> check out.
> 
> Can you confirm?

No. I had modified mkTcTransCo to print out the call-stack, so that wasn't the problem. If you can't reproduce quickly, I'll take another look at this when I get a chance. Thanks for taking a pass.

Richard

> 
> Thanks!
> Eric


From eric at seidel.io  Mon Dec  7 19:35:57 2015
From: eric at seidel.io (Eric Seidel)
Date: Mon, 7 Dec 2015 11:35:57 -0800
Subject: How do I use CallStack?
In-Reply-To: <3EF1F63A-DC81-421C-81D4-5A999341669F@cis.upenn.edu>
References: <9B2FEB61-0FA6-488C-9E0A-925156EED526@cis.upenn.edu>
 <CACOpX0eorRjr7iLoDW=a97CsL7rZ4mK28o6T6msEBaxe_a+Y9g@mail.gmail.com>
 <79861AF7-D2F2-4D81-9993-31F03F7D4816@cis.upenn.edu>
 <1449470351.1502449.459960553.4B5B3437@webmail.messagingengine.com>
 <D2DDE3EE-3A32-4969-9A3F-0FFAFC76DA0D@cis.upenn.edu>
 <1449502501.1611800.460357641.5B7770E8@webmail.messagingengine.com>
 <1449516194.1200113.460653793.3E651804@webmail.messagingengine.com>
 <3EF1F63A-DC81-421C-81D4-5A999341669F@cis.upenn.edu>
Message-ID: <4ACCE826-6970-4D67-9B90-D4279886B924@seidel.io>

Oh I forgot to mention that I was testing on my local branch which fixes precisely this kind of bug when the CallStack is used inside a let-binder, which is what happens in rewriteEqEvidence. 

So it looks like my patch takes care of this issue. Thanks for the report!

Sent from my iPhone

> On Dec 7, 2015, at 11:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> 
>> On Dec 7, 2015, at 2:23 PM, Eric Seidel <eric at seidel.io> wrote:
>> 
>> After staring at your bug confusedly for a few minutes, wondering why I
>> couldn't simplify it, I realized that the actual warning I was getting
>> was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in
>> fact use a CallStack (by default) so the redundant constraint warning
>> there would be correct. If I add a call to error, everything seems to
>> check out.
>> 
>> Can you confirm?
> 
> No. I had modified mkTcTransCo to print out the call-stack, so that wasn't the problem. If you can't reproduce quickly, I'll take another look at this when I get a chance. Thanks for taking a pass.
> 
> Richard
> 
>> 
>> Thanks!
>> Eric
> 

From ben at well-typed.com  Mon Dec  7 20:38:16 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 07 Dec 2015 21:38:16 +0100
Subject: [ANNOUNCE] 7.10.3 release candidate 3
In-Reply-To: <CAOUWSGCk+0nY2sPk9y-3y_jZ_iXUuyt-63c8prc5MEQd7pa3pg@mail.gmail.com>
References: <87pozltpfv.fsf@smart-cactus.org> <87610zxt1r.fsf@smart-cactus.org>
 <CAEDGBqJgvaq9Ty3wm-nJ7uUU0PUWjKtFUY-djFQMyT-32CmcsA@mail.gmail.com>
 <87si3o7t5n.fsf@smart-cactus.org>
 <CAEDGBq+bfHAtpUDBfnVWw0QTD=S_rKC-DBwpxtnS9yoXOXju7Q@mail.gmail.com>
 <CAOUWSGCk+0nY2sPk9y-3y_jZ_iXUuyt-63c8prc5MEQd7pa3pg@mail.gmail.com>
Message-ID: <87h9juq9jb.fsf@smart-cactus.org>

Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:

> On 2 December 2015 at 01:54, Jens Petersen <juhpetersen at gmail.com> wrote:
>> On 29 November 2015 at 23:54, Ben Gamari <ben at well-typed.com> wrote:
>>> On that note, 7.10.3 is coming. At the moment I am blocked on getting a
>>> Cabal release tagged but hopefully this will happen Real Soon Now(TM).
>>
>> Cool - Cabal-1.22.5.0 went into Stackage Nightly yesterday. :-)
>
> I saw that GHC 7.10.3 is available at
>
>   http://downloads.haskell.org/~ghc/7.10.3/
>
> Does anyone have an ETA for GHC 7.10.3?
>
Indeed; hopefully it will be out within the day. Currently the Haskell
Platform packagers are working their magic with it.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/0f1c9ba8/attachment.sig>

From eir at cis.upenn.edu  Mon Dec  7 20:47:45 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 7 Dec 2015 15:47:45 -0500
Subject: Kind equalities
In-Reply-To: <708207423a34472a87f3e46f1772ad98@DB4PR30MB030.064d.mgd.msft.net>
References: <708207423a34472a87f3e46f1772ad98@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <DCAA5CF4-2B60-4852-A917-EBEDC30754FE@cis.upenn.edu>

I'm on track for that. Did a bunch of performance-related debugging over the weekend, and I can observe nice improvements. Just checking those fixes now. If the results are acceptable, I have to double-check testsuite wibbles and then I'll rebase, validate, and push.

Richard

On Dec 7, 2015, at 10:26 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Richard
>  
> What?s your ETA on the kind-equality stuff?  We wondered in today?s call.  We want to make an RC next week.
>  
> Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/e53db2df/attachment.html>

From simonpj at microsoft.com  Mon Dec  7 21:44:24 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Dec 2015 21:44:24 +0000
Subject: A GHC Library
In-Reply-To: <201512072023.04367.jan.stolarek@p.lodz.pl>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <ACD046E5-3AC9-473F-9B5F-DC4E5E892AEA@cis.upenn.edu>
 <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
 <201512072023.04367.jan.stolarek@p.lodz.pl>
Message-ID: <004d31d397ad43439e185dd58edb4650@DB4PR30MB030.064d.mgd.msft.net>

Fine with me!

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 07 December 2015 19:23
| To: ghc-devs at haskell.org
| Subject: Re: A GHC Library
| 
| I know this is a bit old, but I just had a thought that perhaps we could
| archive GHC papers on
| https://na01.safelinks.protection.outlook.com/?url=arxiv.org%3f&data=01%7c
| 01%7csimonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd4049062fdc08d2ff3be049%7
| c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DPsbkXORwm0j%2b2rliDrxdtlrAiJs
| i2YuKene5w5NXvo%3d This should be permanent and with a bit of effort we
| can get around copyright issues
| (I think). Surprisingly little Haskell research can be found on arXiv and
| perhaps it is time we
| changed that?
| 
| Janek
| 
| Dnia ?roda, 29 lipca 2015, Richard Eisenberg napisa?:
| > Done -- merged into ReadingList.
| >
| > On Jul 28, 2015, at 9:39 PM, Richard Eisenberg <eir at cis.upenn.edu>
| wrote:
| > > On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones
| <simonpj at microsoft.com> wrote:
| > >> Good plan; maybe you can merge your list into the existing Reading
| List
| > >> that Jan pointed you to?
| > >>
| > >> I think there would be merit in actually snapshotting the bits into
| one
| > >> safe place.  Links go dead etc, and having a single archive location
| > >> might be a very good thing.  If anyone feels like doing that.
| > >
| > > That was actually my original intent. But then I worried about
| copyright
| > > issues. So instead I just pointed to
| https://na01.safelinks.protection.outlook.com/?url=doi.org&data=01%7c01%7c
| simonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd4049062fdc08d2ff3be049%7c72f9
| 88bf86f141af91ab2d7cd011db47%7c1&sdata=6O8IR4OhzQFszmQlGx%2fmODrhhLU7%2fV0
| qKXOUk3Az8l4%3d links, which should at least
| > > give our future selves a fighting shot at getting the original
| resource.
| > >
| > > Will merge with the other page (which I was clearly unaware of)
| tomorrow.
| > > I actually think most of my entries are distinct from those on the
| other
| > > page, so my work wasn't wasted.
| > >
| > > Richard
| > >
| > >> Simon
| > >>
| > >> | -----Original Message-----
| > >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| > >> | Richard Eisenberg
| > >> | Sent: 28 July 2015 16:15
| > >> | To: ghc-devs Devs
| > >> | Subject: A GHC Library
| > >> |
| > >> | Hi devs,
| > >> |
| > >> | It has struck me that we have a vast trove of documentation about
| GHC
| > >> | in the form of academic papers, but little organization to this
| trove.
| > >> | The papers are scattered across authors' websites, and sometimes it
| is
| > >> | hard to remember what a paper is titled when searching for it.
| > >> |
| > >> | I have thus started a wiki page here:
| > >> | https://ghc.haskell.org/trac/ghc/wiki/Library
| > >> |
| > >> | I would love for this page to be the Definitive List of GHC-related
| > >> | papers. The list I've included is, of course, woefully short, but
| it
| > >> | is a starting point. Please add to it!
| > >> |
| > >> | Have you written a GHC paper? If so, make sure it's included.
| > >> |
| > >> | Thanks,
| > >> | Richard
| > >> | _______________________________________________
| > >> | ghc-devs mailing list
| > >> | ghc-devs at haskell.org
| > >> |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd4049062fd
| c08d2ff3be049%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pLYi9Dtywsq1M3F
| 3LsmokXvmN%2fgqQUTpZZuvh3RdbdQ%3d
| > >
| > > _______________________________________________
| > > ghc-devs mailing list
| > > ghc-devs at haskell.org
| > >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd4049062fd
| c08d2ff3be049%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pLYi9Dtywsq1M3F
| 3LsmokXvmN%2fgqQUTpZZuvh3RdbdQ%3d
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd4049062fd
| c08d2ff3be049%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pLYi9Dtywsq1M3F
| 3LsmokXvmN%2fgqQUTpZZuvh3RdbdQ%3d
| 
| 
| 
| ---
| 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 at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ca2adbaa6bd404906
| 2fdc08d2ff3be049%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7Th8Z4W1cPM0
| ISJSELmY3EhlQbGjRAcLecBMNhu92Kc%3d

From omeragacan at gmail.com  Tue Dec  8 01:40:34 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 7 Dec 2015 20:40:34 -0500
Subject: -XStrict: Why some binders are not made strict?
Message-ID: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>

Let's say I have this code:

    zip :: [a] -> [b] -> [(a, b)]
    zip [] [] = []
    zip (x : xs) (y : ys) = (x, y) : zip xs ys

With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering about
the motivation behind this, I found this interesting. I always thought -XStrict
gives me this guarantee: If I'm using an already-defined variable(bound by a
let or pattern matching) in an expression, I can be sure that the variable
won't be bottom in that expression, because it would be `seq`d before the
expression is evaluated.

So if I have

    case ... of
        D x y -> <body>

or

    let x = ...
        y = ...
     in <body>

In both cases I was thinking that in <body> 'x' and 'y' can't be bottom(with
-XStrict). This would make -XStrict programs evaluate like they would in a
call-by-value language(even though in the RTS level thunks will be built).
Variables can't range over computations; all binders evaluated strictly etc.

Can anyone tell me about the motivation behind this decision?

I think the wiki page actually conflicts with itself. It says "...
bindings to be
strict by default" but then in "case expressions" sections says

    case x of (a,b) -> rhs

    is interpreted as

    case x of !(a,b) -> rhs

Here bindings 'a' and 'b' are not made strict. I'd expect something like:

    case x of (!a,!b) -> rhs

(Which seems to be invalid Haskell, but same effect could be achieved with `seq
a (seq b rhs)`)

Thanks..

(I also realized that the wiki page doesn't mention bindings in do syntax, is
it because this case is implied by "function definitions"? That is, bangs are
added after do syntax is desugared and so they become strict?)

From allbery.b at gmail.com  Tue Dec  8 01:43:06 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 7 Dec 2015 20:43:06 -0500
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
Message-ID: <CAKFCL4XaOvj7ox0YPQ-uh4mDsMmpP=jpOV9DXxF-hu1_Sev-2A@mail.gmail.com>

On Mon, Dec 7, 2015 at 8:40 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
> about
> the motivation behind this, I found this interesting. I always thought
> -XStrict
> gives me this guarantee: If I'm using an already-defined variable(bound by
> a
> let or pattern matching) in an expression, I can be sure that the variable
> won't be bottom in that expression, because it would be `seq`d before the
> expression is evaluated.
>

Aren't those already guaranteed to be strict because of pattern matching?
Try it again with irrefutable patterns.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/758937ff/attachment.html>

From omeragacan at gmail.com  Tue Dec  8 01:47:21 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 7 Dec 2015 20:47:21 -0500
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAKFCL4XaOvj7ox0YPQ-uh4mDsMmpP=jpOV9DXxF-hu1_Sev-2A@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <CAKFCL4XaOvj7ox0YPQ-uh4mDsMmpP=jpOV9DXxF-hu1_Sev-2A@mail.gmail.com>
Message-ID: <CAMQQO3nBgndOpj+5Bjc1m_kuBwj1yPjCkVh-fFM87mmuTqm1wg@mail.gmail.com>

> Aren't those already guaranteed to be strict because of pattern matching? Try
> it again with irrefutable patterns.

But pattern matching only forces the evaluation up to the pattern that is
matched. We need another pattern matching(or seq etc.) on x, y, xs and ys here.
If you look at the generated Core you'll see it more clearly I think(you'll see
that no pattern matching on x y xs and ys are done in Core).

2015-12-07 20:43 GMT-05:00 Brandon Allbery <allbery.b at gmail.com>:
> On Mon, Dec 7, 2015 at 8:40 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
>>
>> With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
>> about
>> the motivation behind this, I found this interesting. I always thought
>> -XStrict
>> gives me this guarantee: If I'm using an already-defined variable(bound by
>> a
>> let or pattern matching) in an expression, I can be sure that the variable
>> won't be bottom in that expression, because it would be `seq`d before the
>> expression is evaluated.
>
>
> Aren't those already guaranteed to be strict because of pattern matching?
> Try it again with irrefutable patterns.
>
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

From eir at cis.upenn.edu  Tue Dec  8 02:08:05 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 7 Dec 2015 21:08:05 -0500
Subject: A GHC Library
In-Reply-To: <201512072023.04367.jan.stolarek@p.lodz.pl>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <ACD046E5-3AC9-473F-9B5F-DC4E5E892AEA@cis.upenn.edu>
 <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
 <201512072023.04367.jan.stolarek@p.lodz.pl>
Message-ID: <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>

How do you suggest getting around copyright issues? I think that's a real barrier to this (good) idea.

Richard

On Dec 7, 2015, at 2:23 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> I know this is a bit old, but I just had a thought that perhaps we could archive GHC papers on 
> arxiv.org? This should be permanent and with a bit of effort we can get around copyright issues 
> (I think). Surprisingly little Haskell research can be found on arXiv and perhaps it is time we 
> changed that?
> 
> Janek
> 
> Dnia ?roda, 29 lipca 2015, Richard Eisenberg napisa?:
>> Done -- merged into ReadingList.
>> 
>> On Jul 28, 2015, at 9:39 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>>> Good plan; maybe you can merge your list into the existing Reading List
>>>> that Jan pointed you to?
>>>> 
>>>> I think there would be merit in actually snapshotting the bits into one
>>>> safe place.  Links go dead etc, and having a single archive location
>>>> might be a very good thing.  If anyone feels like doing that.
>>> 
>>> That was actually my original intent. But then I worried about copyright
>>> issues. So instead I just pointed to doi.org links, which should at least
>>> give our future selves a fighting shot at getting the original resource.
>>> 
>>> Will merge with the other page (which I was clearly unaware of) tomorrow.
>>> I actually think most of my entries are distinct from those on the other
>>> page, so my work wasn't wasted.
>>> 
>>> Richard
>>> 
>>>> Simon
>>>> 
>>>> | -----Original Message-----
>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>>>> | Richard Eisenberg
>>>> | Sent: 28 July 2015 16:15
>>>> | To: ghc-devs Devs
>>>> | Subject: A GHC Library
>>>> |
>>>> | Hi devs,
>>>> |
>>>> | It has struck me that we have a vast trove of documentation about GHC
>>>> | in the form of academic papers, but little organization to this trove.
>>>> | The papers are scattered across authors' websites, and sometimes it is
>>>> | hard to remember what a paper is titled when searching for it.
>>>> |
>>>> | I have thus started a wiki page here:
>>>> | https://ghc.haskell.org/trac/ghc/wiki/Library
>>>> |
>>>> | I would love for this page to be the Definitive List of GHC-related
>>>> | papers. The list I've included is, of course, woefully short, but it
>>>> | is a starting point. Please add to it!
>>>> |
>>>> | Have you written a GHC paper? If so, make sure it's included.
>>>> |
>>>> | Thanks,
>>>> | Richard
>>>> | _______________________________________________
>>>> | ghc-devs mailing list
>>>> | ghc-devs at haskell.org
>>>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at 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.
> 


From eric at seidel.io  Tue Dec  8 02:35:25 2015
From: eric at seidel.io (Eric Seidel)
Date: Mon, 07 Dec 2015 18:35:25 -0800
Subject: A GHC Library
In-Reply-To: <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <ACD046E5-3AC9-473F-9B5F-DC4E5E892AEA@cis.upenn.edu>
 <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
 <201512072023.04367.jan.stolarek@p.lodz.pl>
 <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>
Message-ID: <1449542125.1758167.461043265.1B06D2F6@webmail.messagingengine.com>

I think a lot of conferences allow authors to host pre-prints elsewhere,
like arXiv. We could ask the authors of the relevant papers to make the
submission and then update the links on the Reading List. (Perhaps arXiv
even has some sort of collection feature?)

But you're right that we probably can't post the papers to arXiv
ourselves due to copyright issues.

Eric

On Mon, Dec 7, 2015, at 18:08, Richard Eisenberg wrote:
> How do you suggest getting around copyright issues? I think that's a real
> barrier to this (good) idea.
> 
> Richard
> 
> On Dec 7, 2015, at 2:23 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> 
> > I know this is a bit old, but I just had a thought that perhaps we could archive GHC papers on 
> > arxiv.org? This should be permanent and with a bit of effort we can get around copyright issues 
> > (I think). Surprisingly little Haskell research can be found on arXiv and perhaps it is time we 
> > changed that?
> > 
> > Janek
> > 
> > Dnia ?roda, 29 lipca 2015, Richard Eisenberg napisa?:
> >> Done -- merged into ReadingList.
> >> 
> >> On Jul 28, 2015, at 9:39 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> >>> On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> >>>> Good plan; maybe you can merge your list into the existing Reading List
> >>>> that Jan pointed you to?
> >>>> 
> >>>> I think there would be merit in actually snapshotting the bits into one
> >>>> safe place.  Links go dead etc, and having a single archive location
> >>>> might be a very good thing.  If anyone feels like doing that.
> >>> 
> >>> That was actually my original intent. But then I worried about copyright
> >>> issues. So instead I just pointed to doi.org links, which should at least
> >>> give our future selves a fighting shot at getting the original resource.
> >>> 
> >>> Will merge with the other page (which I was clearly unaware of) tomorrow.
> >>> I actually think most of my entries are distinct from those on the other
> >>> page, so my work wasn't wasted.
> >>> 
> >>> Richard
> >>> 
> >>>> Simon
> >>>> 
> >>>> | -----Original Message-----
> >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> >>>> | Richard Eisenberg
> >>>> | Sent: 28 July 2015 16:15
> >>>> | To: ghc-devs Devs
> >>>> | Subject: A GHC Library
> >>>> |
> >>>> | Hi devs,
> >>>> |
> >>>> | It has struck me that we have a vast trove of documentation about GHC
> >>>> | in the form of academic papers, but little organization to this trove.
> >>>> | The papers are scattered across authors' websites, and sometimes it is
> >>>> | hard to remember what a paper is titled when searching for it.
> >>>> |
> >>>> | I have thus started a wiki page here:
> >>>> | https://ghc.haskell.org/trac/ghc/wiki/Library
> >>>> |
> >>>> | I would love for this page to be the Definitive List of GHC-related
> >>>> | papers. The list I've included is, of course, woefully short, but it
> >>>> | is a starting point. Please add to it!
> >>>> |
> >>>> | Have you written a GHC paper? If so, make sure it's included.
> >>>> |
> >>>> | Thanks,
> >>>> | Richard
> >>>> | _______________________________________________
> >>>> | ghc-devs mailing list
> >>>> | ghc-devs at haskell.org
> >>>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>> 
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> 
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From erkokl at gmail.com  Tue Dec  8 03:32:04 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Mon, 7 Dec 2015 19:32:04 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <57a1c733401f434d9815375017760ebd@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
 <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>
 <57a1c733401f434d9815375017760ebd@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACOpX0eQti2pz+rQBgWLGAkVJHQYSGUFvtA7TyWafHDbOOKW=A@mail.gmail.com>

Thanks for the explanation, Simon. I think Eric is spot on. Looking at some
of the "ghc -v3" output, it appears GHC always runs the following passes
before any plugins are run:

   *** Simplify:
   *** CorePrep:
   *** ByteCodeGen:
   *** Desugar:

Just judging by the name, it could either be the first "Simplify" or the
"Desugar" that gets rid of the dead-code at this point, I'm not sure which.

It would help if this stage didn't remove dead-bindings. If doing so
automatically is not the best option, requiring a user given pragma like
'KeepAlive' wouldn't be too onerous either.

-Levent.

On Mon, Dec 7, 2015 at 8:22 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> It would not be hard to stop the desugarer dropping dead bindings, if that
> was helpful.
>
> S
>
> |  -----Original Message-----
> |  From: Eric Seidel [mailto:eric at seidel.io]
> |  Sent: 07 December 2015 15:44
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: Levent Erkok <erkokl at gmail.com>; omeragacan at gmail.com;
> |  ezyang at mit.edu; ghc-devs at haskell.org
> |  Subject: Re: Plugins: Accessing unexported bindings
> |
> |  The problem, as I recall, is that GHC does an initial bit of dead-code
> |  elimination in the desugarer, before the plugins have a chance to run.
> |  (I believe this is part of simpleOptPgm, but may be mistaken)
> |
> |  I'm not sure why this is done in the desugarer, it seems to be out of
> |  place there.
> |
> |  On Mon, Dec 7, 2015, at 05:14, Simon Peyton Jones wrote:
> |  > Plugins get to edit the entire core-to-core pipeline!  There is no
> |  magic.
> |  >  At least I don?t think so
> |  >
> |  > file:///Z:/tmp/users_guide/compiler-plugins.html
> |  >
> |  > S
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 13:11
> |  > To: Simon Peyton Jones <simonpj at microsoft.com>
> |  > Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com;
> |  > ezyang at mit.edu; ghc-devs at haskell.org
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > That's a good point; keeping all annotated bindings alive seems to
> |  be
> |  > an overkill..
> |  >
> |  > Regarding implementing "pass at the start." I'm not sure if plugin
> |  > authors have any freedom as to decide when their plugin actually
> |  runs.
> |  > It seems GHC magically determines the order and runs them. Can you
> |  > point me to some code/docs that tells me how to go "first" in that
> |  > sense? (Or at least before the pass that drops dead code.)
> |  >
> |  > On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > Indeed. How about this: if there's an ANN on a binder (any ANN),
> |  then
> |  > GHC should keep it alive.
> |  >
> |  > Really?  It might be something like ?don?t give warnings for this
> |  > binding? or ?don?t inline me? or something.   To say *any*
> |  annotation
> |  > seems a bit brutal doesn?t it?    Mind you I don?t have a better
> |  idea.
> |  >
> |  > One thought: your plugin could add a pass right at the start, which
> |  > marks everything you want as keep-alive.
> |  >
> |  > S
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 12:42
> |  > To: Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Indeed. How about this: if there's an ANN on a binder (any ANN),
> |  then
> |  > GHC should keep it alive.
> |  >
> |  > Is that something one of the core-developers can implement? Happy to
> |  > open a ticket if that helps.
> |  >
> |  > On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > If it's "dead" in this sense, it's already removed from ModGuts, no?
> |  >
> |  > Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
> |  >
> |  > So you need a way to keep it alive. Maybe we need a pragma for that.
> |  Or
> |  > how would you like to signal it in the source code?
> |  >
> |  > Simon
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 12:05
> |  > To: Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Thanks Simon.. But I remain utterly confused. As a "plugin" author,
> |  > how do I get my hands on the Id associated with a top-level binder?
> |  If
> |  > it's "dead" in this sense, it's already removed from ModGuts, no?
> |  >
> |  > That is, by the time GHC runs my plugin, the Id has already
> |  > disappeared for me to mark it "Local Exported." Is that not correct?
> |  >
> |  > On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > In the mean time, I'm still looking for a solution that doesn't
> |  > involve exporting such identifiers from modules. As Eric pointed
> |  out,
> |  > that seems to be the only current work-around for the time being.
> |  >
> |  > ?Exported? in this context only means ?keep alive?. It does not mean
> |  > exported in the Haskell source code sense. I?ve just added this
> |  > comment to Var.hs.
> |  >
> |  > So I think it does just what you want.
> |  >
> |  > Simon
> |  >
> |  > data ExportFlag   -- See Note [ExportFlag on binders]
> |  >   = NotExported   -- ^ Not exported: may be discarded as dead code.
> |  >   | Exported      -- ^ Exported: kept alive
> |  >
> |  > {- Note [ExportFlag on binders]
> |  > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> |  > An ExportFlag of "Exported" on a top-level binder says "keep this
> |  > binding alive; do not drop it as dead code".  This transititively
> |  > keeps alive all the other top-level bindings that this binding
> |  refers
> |  > to.  This property is persisted all the way down the pipeline, so
> |  that
> |  > the binding will be compiled all the way to object code, and its
> |  > symbols will appear in the linker symbol table.
> |  >
> |  > However, note that this use of "exported" is quite different to the
> |  > export list on a Haskell module.  Setting the ExportFlag on an Id
> |  does
> |  > /not/ mean that if you import the module (in Haskell source code you
> |  > will see this Id.  Of course, things that appear in the export list
> |  of
> |  > the source Haskell module do indeed have their ExportFlag set.
> |  > But many other things, such as dictionary functions, are kept alive
> |  by
> |  > having their ExportFlag set, even though they are not exported in
> |  the
> |  > source-code sense.
> |  >
> |  > We should probably use a different term for ExportFlag, like
> |  > KeepAlive.
> |  >
> |  > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  > Levent Erkok
> |  > Sent: 06 December 2015 20:32
> |  > To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>
> |  > Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Omer, Eric, Ed: Thanks for the comments.
> |  >
> |  > Omer: I think Eric's observation is at play here. We're talking
> |  about
> |  > "dead-code," i.e., a binding that is neither exported, nor used by
> |  any
> |  > binding inside the module. Those seem to be getting dropped by the
> |  > time user-plugins are run. Unfortunately, this is precisely what one
> |  > would do with "properties" embedded in code. They serve as
> |  > documentation perhaps, but are otherwise not needed by any other
> |  > binding nor it makes sense to export them.
> |  >
> |  > Edward: Can you provide some more info into your solution? Sounds
> |  like
> |  > a chicken-egg issue to me: As a plugin author, I need the bindings
> |  to
> |  > access the Ids, and looks like I need the Ids to access the binders?
> |  >
> |  > A simple solution would be to simply keep all top-level bindings
> |  > around while the plugin are running, but that obviously can lead to
> |  > unnecessary work if the code is truly dead. A compromise could be
> |  that
> |  > the annotations can serve as entry points as well: I.e., if there's
> |  an
> |  > annotation on a top-level binder, then it should *not* be considered
> |  > dead-code at least until after all the plugins are run. That would
> |  > definitely simplify life. Would that be an acceptable alternative?
> |  >
> |  > In the mean time, I'm still looking for a solution that doesn't
> |  > involve exporting such identifiers from modules. As Eric pointed
> |  out,
> |  > that seems to be the only current work-around for the time being.
> |  >
> |  > Thanks,
> |  >
> |  > -Levent.
> |  >
> |  > On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel
> |  > <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> |  > GHC should only drop un-exported bindings from the ModGuts if
> |  they're
> |  > also unused, ie *dead code*.
> |  >
> |  > The only way I know to get around this is to use the bindings
> |  > somewhere, or just export them.
> |  >
> |  > On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> |  > > Hello,
> |  > >
> |  > > The mg_binds field of the ModGuts seem to only contain the
> |  bindings
> |  > > that are exported from the module being compiled.
> |  > >
> |  > > I guess GHC must be running user-plugins after it drops the
> |  bindings
> |  > > that are not exported, which makes perfect sense for most use
> |  cases.
> |  > > However, I'm working on a plugin where the end-programmer embeds
> |  > > "properties" in the form of functions inside his/her code, which
> |  are
> |  > > not necessarily exported from the module under consideration.
> |  > >
> |  > > Is there a way to access all top-level bindings in a module from a
> |  > > plugin, even if those bindings are not exported?
> |  > >
> |  > > Thanks,
> |  > >
> |  > > -Levent.
> |  > > _______________________________________________
> |  > > ghc-devs mailing list
> |  > > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
> |  > > .haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%
> |  > >
> |  7csimonpj%40064d.mgd.microsoft.com%7cf6e3a9d4ad9f4e53a3ab08d2ff1d493
> |  > >
> |  4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NY
> |  > >
> |  fBqR90%2bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.
> |  > > outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-
> |  bin%2fmailman%2
> |  > > flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> |  > >
> |  %7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db
> |  > > 47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csi
> |  >
> |  monpj%40064d.mgd.microsoft.com%7cf6e3a9d4ad9f4e53a3ab08d2ff1d4934%7c72
> |  >
> |  f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NYfBqR90%2
> |  >
> |  bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.outlook.co
> |  > m/?url=http%3a%2f%2fmail.haskell.org%2fcgi-
> |  bin%2fmailman%2flistinfo%2f
> |  > ghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cac4cbfe22e3
> |  >
> |  14080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6
> |  > DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> |  >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/833edbc5/attachment-0001.html>

From jan.stolarek at p.lodz.pl  Tue Dec  8 07:22:06 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 8 Dec 2015 08:22:06 +0100
Subject: A GHC Library
In-Reply-To: <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <201512072023.04367.jan.stolarek@p.lodz.pl>
 <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>
Message-ID: <201512080822.06712.jan.stolarek@p.lodz.pl>

> How do you suggest getting around copyright issues?
LIke Eric said - by posting pre-prints. I think this should be legal.

Note also these two clauses in the ACM Copyright Agreement:

1. "Copyright to the Work (...)  is hereby transferred to the ACM (...) effective as of the date 
of this agreement" - which means that until you sign the agreement you can do whatever you want 
with your work, including posting it on arXiv. This does not help with any papers published in 
the past but I suppose it's worth noting for the future papers.

2. "Permitted Uses (...) Post the Accepted Version of the Work on (...) any repository legally 
mandated by an agency funding the research on which the Work is based." So if anyone manages to 
convice their university that they require all published papers to be posted to arXiv, then it 
will be legal to post the accepted versions of the paper on arXiv :-)

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.

From simonpj at microsoft.com  Tue Dec  8 08:20:26 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 08:20:26 +0000
Subject: A GHC Library
In-Reply-To: <1449542125.1758167.461043265.1B06D2F6@webmail.messagingengine.com>
References: <0A0C5419-2D74-446F-BF6F-7866B1BFE52C@cis.upenn.edu>
 <ACD046E5-3AC9-473F-9B5F-DC4E5E892AEA@cis.upenn.edu>
 <1DB21525-8AE6-40F8-A20D-03A7DC0F3451@cis.upenn.edu>
 <201512072023.04367.jan.stolarek@p.lodz.pl>
 <297918C9-173B-4727-815C-67CD0276A2FF@cis.upenn.edu>
 <1449542125.1758167.461043265.1B06D2F6@webmail.messagingengine.com>
Message-ID: <2eb9f2a1672247e8a79f469936bdbf5e@DB4PR30MB030.064d.mgd.msft.net>

I'm happy to give blanket permission for my papers for myself. But they are almost all ACM copyright, so someone would need to check on the ACM rules.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Eric
| Seidel
| Sent: 08 December 2015 02:35
| To: ghc-devs at haskell.org
| Subject: Re: A GHC Library
| 
| I think a lot of conferences allow authors to host pre-prints elsewhere,
| like arXiv. We could ask the authors of the relevant papers to make the
| submission and then update the links on the Reading List. (Perhaps arXiv
| even has some sort of collection feature?)
| 
| But you're right that we probably can't post the papers to arXiv
| ourselves due to copyright issues.
| 
| Eric
| 
| On Mon, Dec 7, 2015, at 18:08, Richard Eisenberg wrote:
| > How do you suggest getting around copyright issues? I think that's a
| real
| > barrier to this (good) idea.
| >
| > Richard
| >
| > On Dec 7, 2015, at 2:23 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
| >
| > > I know this is a bit old, but I just had a thought that perhaps we
| could archive GHC papers on
| > >
| https://na01.safelinks.protection.outlook.com/?url=arxiv.org%3f&data=01%7c
| 01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32c08d2ff783cc0%7
| c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldFQ4gqUKvdgrkgKwXTyaYqqGqVIWN
| VOpuFg6U6wwc0%3d This should be permanent and with a bit of effort we can
| get around copyright issues
| > > (I think). Surprisingly little Haskell research can be found on arXiv
| and perhaps it is time we
| > > changed that?
| > >
| > > Janek
| > >
| > > Dnia ?roda, 29 lipca 2015, Richard Eisenberg napisa?:
| > >> Done -- merged into ReadingList.
| > >>
| > >> On Jul 28, 2015, at 9:39 PM, Richard Eisenberg <eir at cis.upenn.edu>
| wrote:
| > >>> On Jul 28, 2015, at 5:23 PM, Simon Peyton Jones
| <simonpj at microsoft.com> wrote:
| > >>>> Good plan; maybe you can merge your list into the existing Reading
| List
| > >>>> that Jan pointed you to?
| > >>>>
| > >>>> I think there would be merit in actually snapshotting the bits into
| one
| > >>>> safe place.  Links go dead etc, and having a single archive
| location
| > >>>> might be a very good thing.  If anyone feels like doing that.
| > >>>
| > >>> That was actually my original intent. But then I worried about
| copyright
| > >>> issues. So instead I just pointed to
| https://na01.safelinks.protection.outlook.com/?url=doi.org&data=01%7c01%7c
| simonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32c08d2ff783cc0%7c72f9
| 88bf86f141af91ab2d7cd011db47%7c1&sdata=TQurcyJsYBANxjzUCURy616QBWKe7NxW39A
| kGgcJGn0%3d links, which should at least
| > >>> give our future selves a fighting shot at getting the original
| resource.
| > >>>
| > >>> Will merge with the other page (which I was clearly unaware of)
| tomorrow.
| > >>> I actually think most of my entries are distinct from those on the
| other
| > >>> page, so my work wasn't wasted.
| > >>>
| > >>> Richard
| > >>>
| > >>>> Simon
| > >>>>
| > >>>> | -----Original Message-----
| > >>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| > >>>> | Richard Eisenberg
| > >>>> | Sent: 28 July 2015 16:15
| > >>>> | To: ghc-devs Devs
| > >>>> | Subject: A GHC Library
| > >>>> |
| > >>>> | Hi devs,
| > >>>> |
| > >>>> | It has struck me that we have a vast trove of documentation about
| GHC
| > >>>> | in the form of academic papers, but little organization to this
| trove.
| > >>>> | The papers are scattered across authors' websites, and sometimes
| it is
| > >>>> | hard to remember what a paper is titled when searching for it.
| > >>>> |
| > >>>> | I have thus started a wiki page here:
| > >>>> | https://ghc.haskell.org/trac/ghc/wiki/Library
| > >>>> |
| > >>>> | I would love for this page to be the Definitive List of GHC-
| related
| > >>>> | papers. The list I've included is, of course, woefully short, but
| it
| > >>>> | is a starting point. Please add to it!
| > >>>> |
| > >>>> | Have you written a GHC paper? If so, make sure it's included.
| > >>>> |
| > >>>> | Thanks,
| > >>>> | Richard
| > >>>> | _______________________________________________
| > >>>> | ghc-devs mailing list
| > >>>> | ghc-devs at haskell.org
| > >>>> |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32
| c08d2ff783cc0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=N6GWv26zD1q7QW8
| qcDPYVsZkngQcFMrkEthbUg32VHs%3d
| > >>>
| > >>> _______________________________________________
| > >>> ghc-devs mailing list
| > >>> ghc-devs at haskell.org
| > >>>
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32
| c08d2ff783cc0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=N6GWv26zD1q7QW8
| qcDPYVsZkngQcFMrkEthbUg32VHs%3d
| > >>
| > >> _______________________________________________
| > >> ghc-devs mailing list
| > >> ghc-devs at haskell.org
| > >>
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32
| c08d2ff783cc0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=N6GWv26zD1q7QW8
| qcDPYVsZkngQcFMrkEthbUg32VHs%3d
| > >
| > >
| > >
| > > ---
| > > 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 at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998c32
| c08d2ff783cc0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=N6GWv26zD1q7QW8
| qcDPYVsZkngQcFMrkEthbUg32VHs%3d
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c915f4d05834e4998
| c32c08d2ff783cc0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=87iep1zsPQva
| opd5KzemVlxWKJDnaqrtZq6HbmAs2ew%3d

From simonpj at microsoft.com  Tue Dec  8 12:22:38 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 12:22:38 +0000
Subject: D808 progress report
In-Reply-To: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
Message-ID: <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>

Kind equalities are the Big New Thing in 8.0.  Let's just get it in and deal with the fallout.

After all, there is no reason for performance to be worse. For programs that 7.10 accepts, 8.0 should yield essentially the same coercions.  They might need a bit of optimisation to squeeze them down but the result should be essentially identical.  If not, let's investigate.

I could imagine the typechecker being a bit slower, but not a lot.

For T3738, compile the compiler before and after with -ticky and compare.

|  In light of all this, I propose the following:
|  - Scramble to fix all non-perf failures. I expect I can finish this by
|  Wed evening.
|  - Hope that one of you (or another dev) can take a look at T3738 and
|  friends. That clearly needs to get fixed.
|  - Adjust perf targets to get validation to work, clearly labeling the
|  remaining problems as the fault of type=kind.
|  - Commit to fixing #8095 in the next two weeks. But probably not by
|  early next week, I'm afraid.
|  

In short, yes.

Simon


|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 08 December 2015 03:35
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at well-
|  typed.com>; Austin Seipp <aseipp at pobox.com>
|  Subject: D808 progress report
|  
|  Hi Simon, Ben, Austin,
|  
|  First, the bad news:
|  I'm a bit stalled on performance issues. When I sent my earlier email,
|  I was celebrating having gotten one test case from 319M of allocation
|  down to 182M via several seemingly general-purpose optimizations. But
|  this was with -fno-opt-coercion. Once I re-enabled coercion
|  optimization, that particular test case still fails
|  (pert/compiler/T5030), along with 22 others. This is bad. But many ~4
|  hours of effort this evening I've made no substantive progress at all,
|  shaving off maybe 1% of allocation via a few tiny tweaks. Even
|  characterizing what's going wrong is proving difficult. I've only
|  analyzed a few of the failing tests, but each one is stubbornly
|  refusing to break, so I'm losing hope about the others.
|  
|  Then, the good news:
|  I think the idea posited in #8095 (not to bother building coercions
|  unless -dcore-lint is on) will solve all of these problems and more,
|  as long as users don't use -dcore-lint. With one exception that I've
|  noticed (see below), my performance failures aren't catastrophic: on
|  the performance tests, which tend to be pathological, my branch is
|  running 10-20% worse than HEAD. Not good, but not so bad that -dcore-
|  lint users can't cope. So, with #8095 addressed, I think we'll be OK.
|  And #8095 should be very straightforward and done in a few hours'
|  work.
|  
|  Finally, the ugly:
|  The exception to the non-catastrophic nature of the failures is this:
|  perf/should_run/T3738 fails with 3479.1% overage. (Yes, the percentage
|  is in the thousands.) Worse, this is at runtime, not in the compiler.
|  Yet the Core produced in my branch (as observed by -ddump-simpl) and
|  in HEAD appears identical. There are a few other should_run failures
|  that have me nervous, but my guess is that they're all from one
|  source. I'd love an offer of help to debug this.
|  
|  
|  In light of all this, I propose the following:
|  - Scramble to fix all non-perf failures. I expect I can finish this by
|  Wed evening.
|  - Hope that one of you (or another dev) can take a look at T3738 and
|  friends. That clearly needs to get fixed.
|  - Adjust perf targets to get validation to work, clearly labeling the
|  remaining problems as the fault of type=kind.
|  - Commit to fixing #8095 in the next two weeks. But probably not by
|  early next week, I'm afraid.
|  
|  What do we think?
|  
|  Thanks,
|  Richard

From simonpj at microsoft.com  Tue Dec  8 12:33:36 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 12:33:36 +0000
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <CACOpX0eQti2pz+rQBgWLGAkVJHQYSGUFvtA7TyWafHDbOOKW=A@mail.gmail.com>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
 <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>
 <57a1c733401f434d9815375017760ebd@DB4PR30MB030.064d.mgd.msft.net>
 <CACOpX0eQti2pz+rQBgWLGAkVJHQYSGUFvtA7TyWafHDbOOKW=A@mail.gmail.com>
Message-ID: <683062959eb0403fb783c50d7f23dc90@DB4PR30MB030.064d.mgd.msft.net>

I think it?s probably the desugarer, and the plugin can?t do anything before desugaring!

By all means open a ticket.  I can advise if anyone wants to take it up.

Simon

From: Levent Erkok [mailto:erkokl at gmail.com]
Sent: 08 December 2015 03:32
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu; ghc-devs at haskell.org
Subject: Re: Plugins: Accessing unexported bindings

Thanks for the explanation, Simon. I think Eric is spot on. Looking at some of the "ghc -v3" output, it appears GHC always runs the following passes before any plugins are run:

   *** Simplify:
   *** CorePrep:
   *** ByteCodeGen:
   *** Desugar:

Just judging by the name, it could either be the first "Simplify" or the "Desugar" that gets rid of the dead-code at this point, I'm not sure which.

It would help if this stage didn't remove dead-bindings. If doing so automatically is not the best option, requiring a user given pragma like 'KeepAlive' wouldn't be too onerous either.

-Levent.

On Mon, Dec 7, 2015 at 8:22 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
It would not be hard to stop the desugarer dropping dead bindings, if that was helpful.

S

|  -----Original Message-----
|  From: Eric Seidel [mailto:eric at seidel.io<mailto:eric at seidel.io>]
|  Sent: 07 December 2015 15:44
|  To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  Cc: Levent Erkok <erkokl at gmail.com<mailto:erkokl at gmail.com>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
|  ezyang at mit.edu<mailto:ezyang at mit.edu>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  Subject: Re: Plugins: Accessing unexported bindings
|
|  The problem, as I recall, is that GHC does an initial bit of dead-code
|  elimination in the desugarer, before the plugins have a chance to run.
|  (I believe this is part of simpleOptPgm, but may be mistaken)
|
|  I'm not sure why this is done in the desugarer, it seems to be out of
|  place there.
|
|  On Mon, Dec 7, 2015, at 05:14, Simon Peyton Jones wrote:
|  > Plugins get to edit the entire core-to-core pipeline!  There is no
|  magic.
|  >  At least I don?t think so
|  >
|  > file:///Z:/tmp/users_guide/compiler-plugins.html
|  >
|  > S
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com<mailto:erkokl at gmail.com>]
|  > Sent: 07 December 2015 13:11
|  > To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > That's a good point; keeping all annotated bindings alive seems to
|  be
|  > an overkill..
|  >
|  > Regarding implementing "pass at the start." I'm not sure if plugin
|  > authors have any freedom as to decide when their plugin actually
|  runs.
|  > It seems GHC magically determines the order and runs them. Can you
|  > point me to some code/docs that tells me how to go "first" in that
|  > sense? (Or at least before the pass that drops dead code.)
|  >
|  > On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com><mailto:simonpj at microsoft.com<mailto:simonpj at microsoft.com>>> wrote:
|  > Indeed. How about this: if there's an ANN on a binder (any ANN),
|  then
|  > GHC should keep it alive.
|  >
|  > Really?  It might be something like ?don?t give warnings for this
|  > binding? or ?don?t inline me? or something.   To say *any*
|  annotation
|  > seems a bit brutal doesn?t it?    Mind you I don?t have a better
|  idea.
|  >
|  > One thought: your plugin could add a pass right at the start, which
|  > marks everything you want as keep-alive.
|  >
|  > S
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com<mailto:erkokl at gmail.com>]
|  > Sent: 07 December 2015 12:42
|  > To: Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com><mailto:simonpj at microsoft.com<mailto:simonpj at microsoft.com>>>
|  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io><mailto:eric at seidel.io<mailto:eric at seidel.io>>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com><mailto:omeragacan at gmail.com<mailto:omeragacan at gmail.com>>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu><mailto:ezyang at mit.edu<mailto:ezyang at mit.edu>>;
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org><mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Indeed. How about this: if there's an ANN on a binder (any ANN),
|  then
|  > GHC should keep it alive.
|  >
|  > Is that something one of the core-developers can implement? Happy to
|  > open a ticket if that helps.
|  >
|  > On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com><mailto:simonpj at microsoft.com<mailto:simonpj at microsoft.com>>> wrote:
|  > If it's "dead" in this sense, it's already removed from ModGuts, no?
|  >
|  > Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
|  >
|  > So you need a way to keep it alive. Maybe we need a pragma for that.
|  Or
|  > how would you like to signal it in the source code?
|  >
|  > Simon
|  >
|  > From: Levent Erkok [mailto:erkokl at gmail.com<mailto:erkokl at gmail.com>]
|  > Sent: 07 December 2015 12:05
|  > To: Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com><mailto:simonpj at microsoft.com<mailto:simonpj at microsoft.com>>>
|  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io><mailto:eric at seidel.io<mailto:eric at seidel.io>>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com><mailto:omeragacan at gmail.com<mailto:omeragacan at gmail.com>>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu><mailto:ezyang at mit.edu<mailto:ezyang at mit.edu>>;
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org><mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Thanks Simon.. But I remain utterly confused. As a "plugin" author,
|  > how do I get my hands on the Id associated with a top-level binder?
|  If
|  > it's "dead" in this sense, it's already removed from ModGuts, no?
|  >
|  > That is, by the time GHC runs my plugin, the Id has already
|  > disappeared for me to mark it "Local Exported." Is that not correct?
|  >
|  > On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones
|  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com><mailto:simonpj at microsoft.com<mailto:simonpj at microsoft.com>>> wrote:
|  > In the mean time, I'm still looking for a solution that doesn't
|  > involve exporting such identifiers from modules. As Eric pointed
|  out,
|  > that seems to be the only current work-around for the time being.
|  >
|  > ?Exported? in this context only means ?keep alive?. It does not mean
|  > exported in the Haskell source code sense. I?ve just added this
|  > comment to Var.hs.
|  >
|  > So I think it does just what you want.
|  >
|  > Simon
|  >
|  > data ExportFlag   -- See Note [ExportFlag on binders]
|  >   = NotExported   -- ^ Not exported: may be discarded as dead code.
|  >   | Exported      -- ^ Exported: kept alive
|  >
|  > {- Note [ExportFlag on binders]
|  > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  > An ExportFlag of "Exported" on a top-level binder says "keep this
|  > binding alive; do not drop it as dead code".  This transititively
|  > keeps alive all the other top-level bindings that this binding
|  refers
|  > to.  This property is persisted all the way down the pipeline, so
|  that
|  > the binding will be compiled all the way to object code, and its
|  > symbols will appear in the linker symbol table.
|  >
|  > However, note that this use of "exported" is quite different to the
|  > export list on a Haskell module.  Setting the ExportFlag on an Id
|  does
|  > /not/ mean that if you import the module (in Haskell source code you
|  > will see this Id.  Of course, things that appear in the export list
|  of
|  > the source Haskell module do indeed have their ExportFlag set.
|  > But many other things, such as dictionary functions, are kept alive
|  by
|  > having their ExportFlag set, even though they are not exported in
|  the
|  > source-code sense.
|  >
|  > We should probably use a different term for ExportFlag, like
|  > KeepAlive.
|  >
|  > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of
|  > Levent Erkok
|  > Sent: 06 December 2015 20:32
|  > To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io><mailto:eric at seidel.io<mailto:eric at seidel.io>>>;
|  > omeragacan at gmail.com<mailto:omeragacan at gmail.com><mailto:omeragacan at gmail.com<mailto:omeragacan at gmail.com>>;
|  > ezyang at mit.edu<mailto:ezyang at mit.edu><mailto:ezyang at mit.edu<mailto:ezyang at mit.edu>>
|  > Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org><mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  > Subject: Re: Plugins: Accessing unexported bindings
|  >
|  > Omer, Eric, Ed: Thanks for the comments.
|  >
|  > Omer: I think Eric's observation is at play here. We're talking
|  about
|  > "dead-code," i.e., a binding that is neither exported, nor used by
|  any
|  > binding inside the module. Those seem to be getting dropped by the
|  > time user-plugins are run. Unfortunately, this is precisely what one
|  > would do with "properties" embedded in code. They serve as
|  > documentation perhaps, but are otherwise not needed by any other
|  > binding nor it makes sense to export them.
|  >
|  > Edward: Can you provide some more info into your solution? Sounds
|  like
|  > a chicken-egg issue to me: As a plugin author, I need the bindings
|  to
|  > access the Ids, and looks like I need the Ids to access the binders?
|  >
|  > A simple solution would be to simply keep all top-level bindings
|  > around while the plugin are running, but that obviously can lead to
|  > unnecessary work if the code is truly dead. A compromise could be
|  that
|  > the annotations can serve as entry points as well: I.e., if there's
|  an
|  > annotation on a top-level binder, then it should *not* be considered
|  > dead-code at least until after all the plugins are run. That would
|  > definitely simplify life. Would that be an acceptable alternative?
|  >
|  > In the mean time, I'm still looking for a solution that doesn't
|  > involve exporting such identifiers from modules. As Eric pointed
|  out,
|  > that seems to be the only current work-around for the time being.
|  >
|  > Thanks,
|  >
|  > -Levent.
|  >
|  > On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel
|  > <eric at seidel.io<mailto:eric at seidel.io><mailto:eric at seidel.io<mailto:eric at seidel.io>>> wrote:
|  > GHC should only drop un-exported bindings from the ModGuts if
|  they're
|  > also unused, ie *dead code*.
|  >
|  > The only way I know to get around this is to use the bindings
|  > somewhere, or just export them.
|  >
|  > On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
|  > > Hello,
|  > >
|  > > The mg_binds field of the ModGuts seem to only contain the
|  bindings
|  > > that are exported from the module being compiled.
|  > >
|  > > I guess GHC must be running user-plugins after it drops the
|  bindings
|  > > that are not exported, which makes perfect sense for most use
|  cases.
|  > > However, I'm working on a plugin where the end-programmer embeds
|  > > "properties" in the form of functions inside his/her code, which
|  are
|  > > not necessarily exported from the module under consideration.
|  > >
|  > > Is there a way to access all top-level bindings in a module from a
|  > > plugin, even if those bindings are not exported?
|  > >
|  > > Thanks,
|  > >
|  > > -Levent.
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org><mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
|  > > .haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qk2h3pMEX2WFCux6QLm4rXk%2faqydq4W13J5U%2bOPZKWo%3d>%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%
|  > >
|  7csimonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>%7cf6e3a9d4ad9f4e53a3ab08d2ff1d493
|  > >
|  4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NY
|  > >
|  fBqR90%2bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.
|  > > outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foutlook.com%2f%3furl%3dhttp%253a%252f%252fmail.haskell.org%252fcgi-&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VxOGYDnOtuRJ0X%2fgNtZoxIA5lzCe9vIGSZNbq2Nj0Tc%3d>
|  bin%2fmailman%2
|  > > flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>
|  > >
|  %7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db
|  > > 47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org><mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  > askell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GX53BhjqknGuX4oZVWqLVbz%2b7Up6NY9YLKjWTkwoeck%3d>%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csi
|  >
|  monpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>%7cf6e3a9d4ad9f4e53a3ab08d2ff1d4934%7c72
|  >
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NYfBqR90%2
|  >
|  bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.outlook.co
|  > m/?url=http%3a%2f%2fmail.haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f2fmail.haskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BiZsEZyyTCvpit0cBcPceGv2E6hQ172kSrf6kcDp0so%3d>%2fcgi-
|  bin%2fmailman%2flistinfo%2f
|  > ghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>%7cac4cbfe22e3
|  >
|  14080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6
|  > DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
|  >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/95eb60e4/attachment-0001.html>

From alan.zimm at gmail.com  Tue Dec  8 13:00:20 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Tue, 8 Dec 2015 15:00:20 +0200
Subject: [GHC] #11177: panic! tc_hs_type: record
In-Reply-To: <062.5ef5e1336841fc5055e1858fac6c59ed@haskell.org>
References: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org>
 <062.5ef5e1336841fc5055e1858fac6c59ed@haskell.org>
Message-ID: <CANma=H_frMK8khzOVZ8rP5M-ZOd-MNTq80B6YwnqtSjH0OSJWw@mail.gmail.com>

I am travelling until Thursday,  will only be able to look on Friday.

Alan
On 08 Dec 2015 2:44 PM, "GHC" <ghc-devs at haskell.org> wrote:

> #11177: panic!     tc_hs_type: record
> ---------------------------------+-----------------------------
>         Reporter:  apanagio      |                Owner:
>             Type:  bug           |               Status:  new
>         Priority:  normal        |            Milestone:
>        Component:  Compiler      |              Version:  7.6.3
>       Resolution:                |             Keywords:
> Operating System:  Linux         |         Architecture:  x86
>  Type of failure:  None/Unknown  |            Test Case:
>       Blocked By:                |             Blocking:
>  Related Tickets:                |  Differential Rev(s):
>        Wiki Page:                |
> ---------------------------------+-----------------------------
> Changes (by simonpj):
>
>  * cc: alanz (added)
>
>
> Comment:
>
>  This looks like fallout from the 'refactor `ConDecl` patch.
>
>  Alan?
>
>  Simon
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11177#comment:1>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/cebfbbe6/attachment.html>

From hsyl20 at gmail.com  Tue Dec  8 13:43:25 2015
From: hsyl20 at gmail.com (Sylvain Henry)
Date: Tue, 8 Dec 2015 14:43:25 +0100
Subject: RTS linker refactoring
Message-ID: <CAPmptcWCbJU7v+Qh+7kSdKe-sKJFVm9XLMQ7QZdiAy+CuORgLg@mail.gmail.com>

Hi devs,

I have made a patch to refactor the RTS linker, especially to drastically
reduce its memory usage: https://phabricator.haskell.org/D1470

We need to test it on differrent OS/architectures before it can be merged.
Here is the current state:
 - Linux/x86-64: OK (Harbormaster and I)
 - Solaris/x86-64: was OK, maybe needs to be retested (@kgardas)
 - OpenBSD/x86-64: was OK, maybe needs to be tetested (@kgardas)
 - Solaris/i386: was failing with unrelated error, needs to be retested
(@kgardas)
 - Linux/PowerPC: OK (@erikd)
 - Linux/ARM: was failing with unrelated #11123 (@erikd), OK? (@bgamari)
 - Windows: ?
 - MacOS: ?
 - ia64: ?

I don't have access to Windows and Mac OS boxes so I don't even know if it
compiles there. Could someone test it (validate) on these OSes and report
any issue they encounter to me (by mail or on phabricator)?

Do we support ia64 architecture?

Thanks!
Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/b7e20faa/attachment.html>

From ben at well-typed.com  Tue Dec  8 14:28:31 2015
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 08 Dec 2015 15:28:31 +0100
Subject: RTS linker refactoring
In-Reply-To: <CAPmptcWCbJU7v+Qh+7kSdKe-sKJFVm9XLMQ7QZdiAy+CuORgLg@mail.gmail.com>
References: <CAPmptcWCbJU7v+Qh+7kSdKe-sKJFVm9XLMQ7QZdiAy+CuORgLg@mail.gmail.com>
Message-ID: <87oae1ovzk.fsf@smart-cactus.org>

Sylvain Henry <hsyl20 at gmail.com> writes:

> Hi devs,
>
> I have made a patch to refactor the RTS linker, especially to drastically
> reduce its memory usage: https://phabricator.haskell.org/D1470
>
> We need to test it on differrent OS/architectures before it can be merged.
> Here is the current state:
>  - Linux/x86-64: OK (Harbormaster and I)
>  - Solaris/x86-64: was OK, maybe needs to be retested (@kgardas)
>  - OpenBSD/x86-64: was OK, maybe needs to be tetested (@kgardas)
>  - Solaris/i386: was failing with unrelated error, needs to be retested
> (@kgardas)
>  - Linux/PowerPC: OK (@erikd)
>  - Linux/ARM: was failing with unrelated #11123 (@erikd), OK? (@bgamari)

Unfortunately my ARM box crashed hard during the build for unrelated
reasons (I believe). I'll give it another shot.

>  - Windows: ?

This failed validation on mingw64 with a few warnings,

    rts\Linker.c: In function 'mkOc':

    rts\Linker.c:2048:32: error:
        error: implicit declaration of function 'strdup_' [-Werror=implicit-function-declaration]
                oc->archiveMemberName = strdup_(archiveMemberName);
                                        ^

    rts\Linker.c:2048:8: error:
        error: nested extern declaration of 'strdup_' [-Werror=nested-externs]
                oc->archiveMemberName = strdup_(archiveMemberName);
                ^

    rts\Linker.c:2048:30: error:
        error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
                oc->archiveMemberName = strdup_(archiveMemberName);
                                      ^
    rts\Linker.c: At top level:

    rts\Linker.c:3113:7: error:
        error: unknown type name 'UInt8'
              UInt8  MajorLinkerVersion;
              ^

    rts\Linker.c:3114:7: error:
        error: unknown type name 'UInt8'
              UInt8  MinorLinkerVersion;
              ^
    rts\Linker.c: In function 'ocAllocateSymbolExtras_PEi386':

    rts\Linker.c:4000:38: error:
        error: 'ObjectCode {aka struct _ObjectCode}' has no member named 'fileSize'
                  + ((PEi386_IMAGE_OFFSET + oc->fileSize + 0x7) & ~0x7));
                                              ^
    rts\Linker.c: At top level:

    rts\Linker.c:1796:15: error:
        error: 'allocMem' defined but not used [-Werror=unused-function]
        static void * allocMem(StgWord size, StgWord alignment,


>  - MacOS: ?

This is running.

>  - ia64: ?
>
> I don't have access to Windows and Mac OS boxes so I don't even know if it
> compiles there. Could someone test it (validate) on these OSes and report
> any issue they encounter to me (by mail or on phabricator)?
>
> Do we support ia64 architecture?
>
It worked once. It's now a second tier platform at best. If someone
steps up they can fix the pieces.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/35b20725/attachment.sig>

From ben at well-typed.com  Tue Dec  8 14:41:12 2015
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 08 Dec 2015 15:41:12 +0100
Subject: RTS linker refactoring
In-Reply-To: <87oae1ovzk.fsf@smart-cactus.org>
References: <CAPmptcWCbJU7v+Qh+7kSdKe-sKJFVm9XLMQ7QZdiAy+CuORgLg@mail.gmail.com>
 <87oae1ovzk.fsf@smart-cactus.org>
Message-ID: <87lh95ovef.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Sylvain Henry <hsyl20 at gmail.com> writes:
>
>> Hi devs,
>>
>> I have made a patch to refactor the RTS linker, especially to drastically
>> reduce its memory usage: https://phabricator.haskell.org/D1470
>>
>> We need to test it on differrent OS/architectures before it can be merged.
>> Here is the current state:
>>  - Linux/x86-64: OK (Harbormaster and I)
>>  - Solaris/x86-64: was OK, maybe needs to be retested (@kgardas)
>>  - OpenBSD/x86-64: was OK, maybe needs to be tetested (@kgardas)
>>  - Solaris/i386: was failing with unrelated error, needs to be retested
>> (@kgardas)
>>  - Linux/PowerPC: OK (@erikd)
>>  - Linux/ARM: was failing with unrelated #11123 (@erikd), OK? (@bgamari)
>
> Unfortunately my ARM box crashed hard during the build for unrelated
> reasons (I believe). I'll give it another shot.
>
snip
>
>>  - MacOS: ?
>
> This is running.
>

OS X failed with errors,

    rts/Linker.c:6943:37: error:
        error: no member named 'alignment' in 'struct section_64'
                StgWord alignment = shdr[i].alignment;
                                    ~~~~~~~ ^

    rts/Linker.c:6954:13: error:
        error: use of undeclared identifier 'addr'
                    addr = allocMem(size,alignment,&alloc,&misalignment);
                    ^

    rts/Linker.c:6954:45: error:
        error: use of undeclared identifier 'alloc'
                    addr = allocMem(size,alignment,&alloc,&misalignment);
                                                    ^

    rts/Linker.c:6954:52: error:
        error: use of undeclared identifier 'misalignment'; did you mean 'alignment'?
                    addr = allocMem(size,alignment,&alloc,&misalignment);
                                                          ^~~~~~~~~~~~
                                                          alignment

    rts/Linker.c:6943:17: error:
        note: 'alignment' declared here
                StgWord alignment = shdr[i].alignment;
                        ^

    rts/Linker.c:6955:20: error:
        error: use of undeclared identifier 'addr'; did you mean 'shdr'?
                    memset(addr,0,size);
                          ^~~~
                          shdr

    /usr/include/secure/_string.h:77:27: error:
        note: expanded from macro 'memset'
          __builtin___memset_chk (dest, val, len, __darwin_obsz0 (dest))
                                  ^

    rts/Linker.c:6771:21: error:
        note: 'shdr' declared here
            struct section *shdr;
                            ^

    rts/Linker.c:6955:20: error:
        error: use of undeclared identifier 'addr'; did you mean 'shdr'?
                    memset(addr,0,size);
                          ^~~~
                          shdr

    /usr/include/secure/_string.h:77:59: error:
        note: expanded from macro 'memset'
          __builtin___memset_chk (dest, val, len, __darwin_obsz0 (dest))
                                                                  ^

    /usr/include/secure/_common.h:38:55: error:
        note: expanded from macro '__darwin_obsz0'
    #define __darwin_obsz0(object) __builtin_object_size (object, 0)
                                                          ^

    rts/Linker.c:6771:21: error:
        note: 'shdr' declared here
            struct section *shdr;
                            ^

    rts/Linker.c:6963:39: error:
        error: use of undeclared identifier 'offset'
                      && ((oc->memberOffset + offset) % alignment == 0)) {
                                              ^

    rts/Linker.c:6964:21: error:
        error: use of undeclared identifier 'fd'
                        if (fd == -1) {
                            ^

    rts/Linker.c:6965:21: error:
        error: use of undeclared identifier 'fd'
                            fd = open_(oc->memberPath, O_RDONLY);
                            ^

    rts/Linker.c:6967:21: error:
        error: use of undeclared identifier 'fd'
                        if (fd != -1) {
                            ^

    rts/Linker.c:6974:21: error:
        error: use of undeclared identifier 'addr'
                            addr = mapObjectFileSection(fd,
                            ^

    rts/Linker.c:6974:28: error:
        error: implicit declaration of function 'mapObjectFileSection' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                            addr = mapObjectFileSection(fd,
                                  ^

    rts/Linker.c:6975:68: error:
        error: use of undeclared identifier 'offset'
                                                        oc->memberOffset + offset,
                                                                          ^

    rts/Linker.c:6974:49: error:
        error: use of undeclared identifier 'fd'
                            addr = mapObjectFileSection(fd,
                                                        ^

    rts/Linker.c:6977:50: error:
        error: use of undeclared identifier 'misalignment'; did you mean 'alignment'?
                                                        &misalignment);
                                                        ^~~~~~~~~~~~
                                                        alignment

    rts/Linker.c:6943:17: error:
        note: 'alignment' declared here
                StgWord alignment = shdr[i].alignment;
                        ^

    rts/Linker.c:6978:25: error:
        error: use of undeclared identifier 'addr'; did you mean 'shdr'?
                            if (addr == NULL) goto fail;
                                ^~~~
                                shdr

    rts/Linker.c:6771:21: error:
        note: 'shdr' declared here
            struct section *shdr;
                            ^

    rts/Linker.c:6979:21: error:
        error: use of undeclared identifier 'alloc'
                            alloc = ALLOC_MMAP;
                            ^

    rts/Linker.c:7003:17: error:
        error: use of undeclared identifier 'addr'
                        addr = allocMem(size,alignment,&alloc,&misalignment);
                        ^

    rts/Linker.c:7003:49: error:
        error: use of undeclared identifier 'alloc'
                        addr = allocMem(size,alignment,&alloc,&misalignment);
                                                        ^
    fatal error: too many errors emitted, stopping now [-ferror-limit=]

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/d7b57c36/attachment.sig>

From simonpj at microsoft.com  Tue Dec  8 14:42:13 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 14:42:13 +0000
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
Message-ID: <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>

Adam, Johan,

Looking at the user manual
http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell, 
and indeed the wiki page
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
it's not really clear whether the sub-components of a pattern are strict.  That is, is the second equation of zip strict in x, and xs?   (Supposing for now that the list data structure is lazy).  The manual doesn't say one way or the other.

What's the answer?  And could the user manual please say?

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
| Sinan Agacan
| Sent: 08 December 2015 01:41
| To: ghc-devs <ghc-devs at haskell.org>
| Subject: -XStrict: Why some binders are not made strict?
| 
| Let's say I have this code:
| 
|     zip :: [a] -> [b] -> [(a, b)]
|     zip [] [] = []
|     zip (x : xs) (y : ys) = (x, y) : zip xs ys
| 
| With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
| about
| the motivation behind this, I found this interesting. I always thought -
| XStrict
| gives me this guarantee: If I'm using an already-defined variable(bound by
| a
| let or pattern matching) in an expression, I can be sure that the variable
| won't be bottom in that expression, because it would be `seq`d before the
| expression is evaluated.
| 
| So if I have
| 
|     case ... of
|         D x y -> <body>
| 
| or
| 
|     let x = ...
|         y = ...
|      in <body>
| 
| In both cases I was thinking that in <body> 'x' and 'y' can't be
| bottom(with
| -XStrict). This would make -XStrict programs evaluate like they would in a
| call-by-value language(even though in the RTS level thunks will be built).
| Variables can't range over computations; all binders evaluated strictly
| etc.
| 
| Can anyone tell me about the motivation behind this decision?
| 
| I think the wiki page actually conflicts with itself. It says "...
| bindings to be
| strict by default" but then in "case expressions" sections says
| 
|     case x of (a,b) -> rhs
| 
|     is interpreted as
| 
|     case x of !(a,b) -> rhs
| 
| Here bindings 'a' and 'b' are not made strict. I'd expect something like:
| 
|     case x of (!a,!b) -> rhs
| 
| (Which seems to be invalid Haskell, but same effect could be achieved with
| `seq
| a (seq b rhs)`)
| 
| Thanks..
| 
| (I also realized that the wiki page doesn't mention bindings in do syntax,
| is
| it because this case is implied by "function definitions"? That is, bangs
| are
| added after do syntax is desugared and so they become strict?)
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbc68c0830f574466efd
| 308d2ff70aba9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c2VBbt%2f%2fR2c
| yFecGEuQotO%2bV71VSbpmWnZJyV9d8KRk%3d

From simonpj at microsoft.com  Tue Dec  8 14:43:43 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 14:43:43 +0000
Subject: User manual sub-sections
Message-ID: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>

Ben, Austin,
Could we see the sub-sub-sections of the user manual in the table of contents
http://downloads.haskell.org/~ghc/master/users-guide/
The section titles are often very helpful.  C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/bcdaecde/attachment.html>

From ben at smart-cactus.org  Tue Dec  8 15:02:24 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 08 Dec 2015 16:02:24 +0100
Subject: User manual sub-sections
In-Reply-To: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
References: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87io49ouf3.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Ben, Austin,
> Could we see the sub-sub-sections of the user manual in the table of contents
> http://downloads.haskell.org/~ghc/master/users-guide/
> The section titles are often very helpful. C.f. the old version
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html

Sure. I've pushed e7927110bd1c1336bb4cb17eb52cf5b6adae3902 to make this so.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/5baf64d4/attachment.sig>

From ben at smart-cactus.org  Tue Dec  8 15:41:49 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 08 Dec 2015 16:41:49 +0100
Subject: User manual sub-sections
In-Reply-To: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
References: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87fuzdosle.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Ben, Austin,
> Could we see the sub-sub-sections of the user manual in the table of contents
> http://downloads.haskell.org/~ghc/master/users-guide/
> The section titles are often very helpful.  C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html
>
If you look at http://downloads.haskell.org/~ghc/master/users-guide//
you'll find that sub-sub-sections are now shown. Unfortunately it looks
quite cluttered now. I feel like it is now quite easy to get lost in the
forest while scanning for your desired section. Perhaps it would make
sense to make the sub-sections expandable but collapsed by default?
Opinions?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/9e964c8e/attachment.sig>

From simonpj at microsoft.com  Tue Dec  8 15:55:14 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 15:55:14 +0000
Subject: User manual sub-sections
In-Reply-To: <87fuzdosle.fsf@smart-cactus.org>
References: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
 <87fuzdosle.fsf@smart-cactus.org>
Message-ID: <4ee27163dd76424fb23642db4586b6f3@DB4PR30MB030.064d.mgd.msft.net>

I like it better. 
Better still to be able to collapse/expand.
But it should be possible to collapse-all and expand-all, so you can then search in the web page.

S

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at smart-cactus.org]
|  Sent: 08 December 2015 15:42
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Cc: Austin Seipp <austin at well-typed.com>
|  Subject: Re: User manual sub-sections
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > Ben, Austin,
|  > Could we see the sub-sub-sections of the user manual in the table of
|  > contents http://downloads.haskell.org/~ghc/master/users-guide/
|  > The section titles are often very helpful.  C.f. the old version
|  >
|  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.
|  > html
|  >
|  If you look at http://downloads.haskell.org/~ghc/master/users-guide//
|  you'll find that sub-sub-sections are now shown. Unfortunately it
|  looks quite cluttered now. I feel like it is now quite easy to get
|  lost in the forest while scanning for your desired section. Perhaps it
|  would make sense to make the sub-sections expandable but collapsed by
|  default?
|  Opinions?
|  
|  Cheers,
|  
|  - Ben

From simon at joyful.com  Tue Dec  8 15:59:00 2015
From: simon at joyful.com (Simon Michael)
Date: Tue, 8 Dec 2015 07:59:00 -0800
Subject: User manual sub-sections
In-Reply-To: <87fuzdosle.fsf@smart-cactus.org>
References: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
 <87fuzdosle.fsf@smart-cactus.org>
Message-ID: <n46uo5$81e$1@ger.gmane.org>

On 12/8/15 7:41 AM, Ben Gamari wrote:
> Simon Peyton Jones <simonpj at microsoft.com> writes:
>> Could we see the sub-sub-sections of the user manual in the table of contents
>> http://downloads.haskell.org/~ghc/master/users-guide/
>> The section titles are often very helpful.  C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html
>>
> If you look at http://downloads.haskell.org/~ghc/master/users-guide//
> you'll find that sub-sub-sections are now shown. Unfortunately it looks
> quite cluttered now. I feel like it is now quite easy to get lost in the
> forest while scanning for your desired section. Perhaps it would make
> sense to make the sub-sections expandable but collapsed by default?
> Opinions?

It is long, but count me as a +1 vote for the fully expanded contents -
these always help me find things. Perhaps add a short listing (just the
chapters) above it ?



From david.feuer at gmail.com  Tue Dec  8 16:36:34 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 8 Dec 2015 11:36:34 -0500
Subject: Allow ambiguous types (with warning) by default
In-Reply-To: <af17934a19324aca8cac5852cfe6bf49@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMgWh9t3VNAq6sjePc1OTmsF4xme1sOvCvLVfPmCpo5EdEUA7Q@mail.gmail.com>
 <CAJumaK9Yi4EpeQ69Aqgo27YLYJaVy5=o70RHuE0mQzSGT_sC3A@mail.gmail.com>
 <CAMgWh9vLmHYjrnytk5DtrDaDmUOt+UynGsTe1eOX=ZnVetoMPw@mail.gmail.com>
 <CAJumaK8jzFcTa6B-=dEMH9BWwRO=GV74Df8U+J0vyd0pnj537A@mail.gmail.com>
 <CAMgWh9vCikjksoPBZ4rcBQTpnUbwDAN5u1XZaUG+vSXFb7MFCA@mail.gmail.com>
 <af17934a19324aca8cac5852cfe6bf49@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMgWh9vpn85nNRxHqu_iOOo8kkx-T2QQgVka47jenPqzNtiP=g@mail.gmail.com>

Sure, I'll open the ticket. It may well turn out that there's a less
invasive way to accomplish my ultimate goal (more useful error messages for
ambiguous types) without allowing the cascade you're worried about. In

foo :: Num a => F a -> G a

Something more like the following would be much better than what we
currently get:

The type variable `a' in the type of `foo :: Num a => F a -> G a' is
ambiguous. This means that code attempting to use `foo' will not be able to
give it a signature determining `a'. In particular: `a' appears only as an
argument to the type families `F' and `G', which may not be injective.
Therefore a signature at the use site fixing `F a' and `G a' to particular
types will not fix `a' to a particular type.
On Dec 7, 2015 8:31 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

> |  OK, fine. Is there a way to make it an error, but keep checking the
> |  rest of the module? My goal is *get both messages if possible*, within
> |  a module. I'm not tied to any particular mechanism of doing so.
>
> Yes it'd be possible.  A bit fiddly, but certainly possible.
>
> Of course, doing so can lead to a cascade of other errors, but in this
> case you seem to actively want those follow-on errors.
>
> Would you like to open a ticket with a few illustrative examples to
> motivate your proposal?
>
> Simon
>
> |
> |  On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <ekmett at gmail.com>
> |  wrote:
> |  > If you aren't the one writing the code that can't be called you may
> |  > never see the warning. It'll be tucked away in a cabal or stack
> |  build
> |  > log somewhere.
> |  >
> |  > -Edward
> |  >
> |  > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.feuer at gmail.com>
> |  wrote:
> |  >>
> |  >> No, I want it to *warn* by default. If I write
> |  >>
> |  >> foo :: something that will fail the ambiguity check bar = something
> |  >> that uses foo in a (necessarily) ambiguous way
> |  >>
> |  >> the current default leads me to do this:
> |  >>
> |  >> 1. Attempt to compile. Get an ambiguity error on foo whose exact
> |  >> cause is hard for me to see.
> |  >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar
> |  >> whose exact cause is completely obvious, and that makes it
> |  perfectly
> |  >> clear what I need to do to fix foo.
> |  >> 3. Fix foo, and disable AllowAmbiguousTypes.
> |  >>
> |  >> I'd much rather go with
> |  >>
> |  >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose
> |  exact
> |  >> cause is hard for me to see, but also an error on bar whose exact
> |  >> cause is completely obvious, and that makes it perfectly clear what
> |  I
> |  >> need to do to fix foo.
> |  >> 2. Fix foo.
> |  >>
> |  >> Simple example of how it is currently:
> |  >>
> |  >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
> |  >>
> |  >> <interactive>:14:12:
> |  >>     Couldn't match expected type ?F a? with actual type ?F a0?
> |  >>     NB: ?F? is a type function, and may not be injective
> |  >>     The type variable ?a0? is ambiguous
> |  >>     In the ambiguity check for the type signature for ?foo?:
> |  >>       foo :: forall a. Num a => F a
> |  >>     To defer the ambiguity check to use sites, enable
> |  AllowAmbiguousTypes
> |  >>     In the type signature for ?foo?: foo :: Num a => F a
> |  >>
> |  >> Couldn't match what with what? Huh? Where did a0 come from?
> |  >>
> |  >> > :set -XAllowAmbiguousTypes
> |  >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo
> |  >>
> |  >> <interactive>:16:61:
> |  >>     Couldn't match expected type ?Int? with actual type ?F a0?
> |  >>     The type variable ?a0? is ambiguous
> |  >>     In the expression: foo
> |  >>     In an equation for ?bar?: bar = foo
> |  >>
> |  >> Aha! That's the problem! It doesn't know what a0 is! How can I tell
> |  >> it what a0 is? Oh! I can't, because foo doesn't give me a handle on
> |  it.
> |  >> Guess I have to fix foo.
> |  >>
> |  >> I'd really, really like to get *both* of those messages in one go,
> |  >> with the first one preferably explaining itself a bit better.
> |  >>
> |  >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <ekmett at gmail.com>
> |  wrote:
> |  >> > So you are saying you want users to write a ton of code that
> |  >> > happens to have signatures that can never be called and only
> |  catch
> |  >> > it when they go to try to actually use it in a concrete situation
> |  >> > much later?
> |  >> >
> |  >> > I don't really show how this would be a better default.
> |  >> >
> |  >> > When and if users see the problem later they have to worry about
> |  if
> |  >> > they are doing something wrong at the definition site or the call
> |  >> > site. With the status quo it complains at the right time that you
> |  >> > aren't going to sit there flailing around trying to fix a call
> |  site
> |  >> > that can never be fixed.
> |  >> >
> |  >> > -Edward
> |  >> >
> |  >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer
> |  <david.feuer at gmail.com>
> |  >> > wrote:
> |  >> >>
> |  >> >> The ambiguity check produces errors that are quite surprising to
> |  >> >> the uninitiated. When the check is suppressed, the errors at use
> |  >> >> sites are typically much easier to grasp. On the other hand,
> |  >> >> there's obviously a lot of value to catching mistakes as soon as
> |  >> >> possible. Would it be possible to turn that into a warning by
> |  >> >> default?
> |  >> >>
> |  >> >>
> |  >> >> _______________________________________________
> |  >> >> ghc-devs mailing list
> |  >> >> ghc-devs at haskell.org
> |  >> >>
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fma
> |  >> >> il.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7
> |  >> >>
> |  c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db692644c7b2d408d2f
> |  >> >>
> |  dfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tzknS1bYbEs2G
> |  >> >> NPvXuu6o1st%2b2VMSTTmRSH1L%2f9BSsk%3d
> |  >> >>
> |  >> >
> |  >
> |  >
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db6926
> |  44c7b2d408d2fdfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kYhH
> |  Q00HzSxbbNyqFt2OmHWSpPTyxsbeJPCF1tDzAA0%3d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/7f0bf1a3/attachment.html>

From simonpj at microsoft.com  Tue Dec  8 16:49:29 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 16:49:29 +0000
Subject: Submodules  on a branch
Message-ID: <3d22d31463bc47bea28b50606409d948@DB4PR30MB030.064d.mgd.msft.net>

?         I?m on a branch wip/T11067.

?         I do a ?git merge origin/master?, resolve source code conflicts and commit

?         Then ?git submodule update?

?         I have not touched libraries/unix

?         Yet when I say ?git submodule? in a different HEAD tree, I get a different commit for libraries/unix than in my branch

Question (sticking plaster): how can I say ?Just make my sub-modules match HEAD please??

Question (cause): how can I ensure that I do update my branch to the submodule of HEAD when doing ?git merge??

Getting submodules out of sync is very tiresome.

Thanks

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/48eeec02/attachment-0001.html>

From simonpj at microsoft.com  Tue Dec  8 17:06:54 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Dec 2015 17:06:54 +0000
Subject: Questions concerning the LLVM backend - i.e. 'proc point
 splitting'
In-Reply-To: <56587ECA.3070104@fim.uni-passau.de>
References: <5644BD6B.8060105@fim.uni-passau.de>
 <0d142c3bd7da47a9b869481dcef9a374@DB4PR30MB030.064d.mgd.msft.net>
 <87h9kgwa29.fsf@smart-cactus.org> <56587ECA.3070104@fim.uni-passau.de>
Message-ID: <08fc3bedd25a4a35baa82b7d44d96167@DB4PR30MB030.064d.mgd.msft.net>

David

|  Could you explain the need of further info-tables for 'inner'
|  proc-points (those, which are not the entry-block of a function) to
|  me, please?

The main purpose of inner info tables is this.  Given (case e of blah) we push a return address (for 'blah') on the stack and evaluate 'e'.  During evaluation of 'e', garbage collection may take place.  So the garbage collector needs to walk the stack to follow live pointers.  Who knows what pointers are live?  Answer: the code for 'blah' clearly knows what pointers are alive in the current stack frame, because it is going to access them.  So the return address gets an info table that makes that implicit knowledge explicit, as a bitmap describing the liveness/pointer-hood of the stack frame.

Addresses that are only jumped to don?t need info tables.

It would be great if, as you learn about this stuff, you could add to the Commentary
https://ghc.haskell.org/trac/ghc/wiki/Commentary
to capture what you have learned.


 
|  The documentation states, that proc-point splitting is only required
|  by the LLVM backend (see [2]). Does the cmm-pipeline perform proc-
|  point splitting even when using the native code generator?

I'm not certain, but I don't think so.

|  As stated above, the major problem of LLVM seems to be inferring
|  control flow when it comes to call proc-points. As it's hard to avoid
|  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the

I regard the whole proc-point thing as a major wart.  I think we should work hard to eliminate it.  So: another line of thought might be: how could we influence LLVM so that we didn't need proc-point splitting?

|  To make control flow more apparent to LLVM, they came up with the
|  following idea. Remark before showing the idea: I know that it greatly

I'm sorry to say that I didn't really understand the idea.  Maybe someone else did?  David Terei?

If you are seriously about investing effort in the back end, I'd be happy to help; in that case a Skype call is probably the best way.

Simon

|  interferes with CPS. It leaves parts of the continuation-handling to
|  the implicit LLVM call-stack. Further, this does not solve the problem
|  of proc-point splitting at all. It is more a workaround than a
|  solution.
|  But it would greatly increase LLVM's possibilities to optimize code
|  later on. That's why I found this idea worth mentioning. Especially
|  because after reading your answer, Ben, I'm somewhat convinced that
|  solving the problem of proc-point splitting is nearly impossible with
|  the capabilities of LLVM IR available at the moment. Now back to the
|  idea.
|  
|  As stated above, the major problem of LLVM seems to be inferring
|  control flow when it comes to call proc-points. As it's hard to avoid
|  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the
|  code, llvmGen produces when it comes to call proc-points instead. All
|  other types of proc-points remain unchanged.
|  
|  Initial situation in pseudo cmm:
|  
|  foo() {
|  ...
|  call bar() returns to cont // bar defined externally
|  
|  cont:
|  ...
|  }
|  
|  After proc-point splitting, this is converted into LLVM IR similar to
|  the following:
|  
|  @foo() {
|  ...
|  store @cont(), %Sp ; push continuation on the stack tail call @bar() ;
|  @bar defined externally }
|  
|  @cont() {
|  ...
|  }
|  
|  To fix the above issue, we introduce a method, which restores the
|  pointers Sp, Hp and the register R1 (among everything else, what has
|  to be restored) and 'fakes' the continuation. Note, that '@restore'
|  returns without calling into the continuation. This way, the call into
|  the continuation can be made direct. The above code would be
|  transformed into something similar to the following:
|  
|  @foo() {
|  ...
|  store @restore(), %Sp ; 'fake' continuation call @bar() ; br label
|  restore
|  
|  restore:
|  %Sp = load (getelementptr @environment 0, 0) ; restore what has to be
|  ... ; restored tail call @cont() }
|  
|  @cont() {
|  ...
|  }
|  
|  @restore(%Sp, %Hp, %R1, ...) {
|  store %Sp, (getelementptr @environment 0, 0) ; store everything into
|  ... ; global variable ret void }
|  
|  @environment ; structure of type similar to {i64*, i64*, i64*, i64,
|  i64, ..}
|  
|  As an alternative, the above transformation could be done by a LLVM
|  pass. llvmGen could then annotate the continuation of calls call cite.
|  This would greatly simplify the detection of the correct continuation.
|  
|  What do you think about this idea? Especially when thinking about the
|  interference with CPS?
|  
|  Regards,
|  
|  David
|  
|  
|  
|  
|  [1]
|  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCod
|  e#Importantconceptsinthemachine
|  
|  [2]
|  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeGen#Seco
|  ndstage:theCmmpipeline
|  
|  
|  
|  
|  On 11/21/2015 12:00 AM, Ben Gamari wrote:
|  > Simon Peyton Jones <simonpj at microsoft.com> writes:
|  >
|  >> David
|  >>
|  >> All this stuff is terribly paged-out for me. But I'd love someone
|  to
|  >> pay attention to some of this back-end stuff, so if you'd like to
|  >> work there, I'd like to help you.
|  >>
|  >> David Terei was also thinking of getting rid of proc point
|  splitting
|  >> for LLVM (see attached email and the notes attached to it)
|  >>
|  >> Simon Marlow also was thinking about this; see his attached email.
|  >>
|  >> The main *reason* for establishing a proc-point is so that, when
|  >> generating C code (which we don't do any more) you can take its
|  >> address. E.g.
|  >>
|  >> foo() { ... Push &bar onto the stack (effectively a return address)
|  >>   Jump to thingumpy }
|  >>
|  >> bar() { ... }
|  >>
|  >> Really bar is part of foo, but we have make it a separate top level
|  >> thing so that we can take the address of bar and push it on the
|  stack.
|  >>
|  >> The trouble is that if there is a label inside bar that foo wants
|  to
|  >> jump to (i.e. without pushing &bar etc) then we have to make that
|  >> label too into a proc-point, so that both foo and bar can see it.
|  >> Urgh.
|  >>
|  >> In LLVM this probably is not true; presumably you can take the
|  >> address of any label?
|  >>
|  > This is true. While labels themselves have function-local scope in
|  > LLVM, there is an expression, `blockaddress`, which allows you to
|  take
|  > an address to a label in another function [1]. That being said, in
|  > reading through the documentation it's not at all clear to me that
|  it
|  > would be safe to jump to such an address. In fact, given that the
|  > instruction that this expression is supposed to be used with,
|  > `indirectbr`, can only be used for local blocks, I suspect it is
|  not.
|  > More information about this feature can be found here [2].
|  >
|  > The jump issue aside, I don't know how you would deal with
|  > tables-next-to-code. The prefix data support that currently
|  available
|  > in LLVM is attached to functions and I unfortunately don't see that
|  > changing any time soon.
|  >
|  > Ultimately it seems that trying to refer to labels defined in other
|  > functions is using LLVM against the way it was intended. One
|  > alternative would be to teach llvmGen to merge mutually recusive
|  > top-level functions into a single LLVM function during code
|  > generation. Otherwise I'm afraid you are stuck with either the
|  status
|  > quo or attempting to improve on LLVM's own cross-procedure
|  optimization ability.
|  >
|  > That being said, it sounds as though eliminating proc-point
|  splitting
|  > would make for quite a nice project in the native code generator.
|  >
|  > Cheers,
|  >
|  > - Ben
|  >
|  >
|  > [1]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
|  > rg%2fdocs%2fLangRef.html%23addresses-of-basic-
|  blocks&data=01%7c01%7csi
|  >
|  monpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72
|  >
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=nKVLgmZezUdEYL%2fma1exMMPLbcT
|  > RkaE1JrvVaR1EesY%3d [2]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblog.l
|  > lvm.org%2f2010%2f01%2faddress-of-label-and-indirect-
|  branches.html&data
|  >
|  =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2
|  >
|  f74448f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BTMdZESwYS4tZa5W
|  > sOAqyFutoI5xNNFDe0b%2bdKC3ODs%3d [3]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
|  > rg%2fdocs%2fLangRef.html%23prefix-
|  data&data=01%7c01%7csimonpj%40064d.m
|  >
|  gd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72f988bf86f141af
|  >
|  91ab2d7cd011db47%7c1&sdata=rdo4ZLjjE%2bWxNykVL%2bSuToWioY6nzQpflSk296E
|  > 8W70%3d
|  >

From robstewart57 at gmail.com  Tue Dec  8 17:22:17 2015
From: robstewart57 at gmail.com (Rob Stewart)
Date: Tue, 8 Dec 2015 17:22:17 +0000
Subject: Does the Strict extension make monadic bindings strict?
Message-ID: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>

Are the following two programs equivalent with respect to the strictness
of `readFile`?

--8<---------------cut here---------------start------------->8---
{-# LANGUAGE BangPatterns #-}

module Main where

main = do
  !contents <- readFile "foo.txt"
  print contents
--8<---------------cut here---------------end--------------->8---

And:

--8<---------------cut here---------------start------------->8---
{-# LANGAUGE Strict #-}

module Main where

main = do
  contents <- readFile "foo.txt"
  print contents
--8<---------------cut here---------------end--------------->8---

The documentation on "Strict-by-default pattern bindings" gives
let/where binding as an example, but there is not a monadic bind example.
http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings

Inspecting GHC Core for these two programs suggests that

!contents <- readFile "foo.txt"

is not equivalent to (with Strict enabled):

contents <- readFile "foo.txt"

Here's core using BangPatterns:

(readFile (unpackCString# "foo.txt"#))
(\ (contents_asg :: String) ->
   case contents_asg of contents1_Xsk { __DEFAULT ->
   print @ String $dShow_rYy contents1_Xsk
   })

Here's core using Strict:

(readFile (unpackCString# "foo.txt"#))
(\ (contents_asg :: String) ->
   print @ String $dShow_rYv contents_asg)

Does this core align with the design of the Strict extension?

If it does, are users going to understand that using Strict is going to
make let/where bindings strict, but is not going to make <- or >>=
bindings strict?

--
Rob Stewart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/b0031ba5/attachment.html>

From kane at kane.cx  Tue Dec  8 17:27:28 2015
From: kane at kane.cx (David Kraeutmann)
Date: Tue, 8 Dec 2015 18:27:28 +0100
Subject: Does the Strict extension make monadic bindings strict?
In-Reply-To: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
References: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
Message-ID: <56671300.9020404@kane.cx>

While there's a fundamental difference between (>>=) and let-bindings,
it might be worth adding to the docs that -XStrict only makes let
bindings strict.

On 12/08/2015 06:22 PM, Rob Stewart wrote:
> Are the following two programs equivalent with respect to the strictness
> of `readFile`?
>
> --8<---------------cut here---------------start------------->8---
> {-# LANGUAGE BangPatterns #-}
>
> module Main where
>
> main = do
>   !contents <- readFile "foo.txt"
>   print contents
> --8<---------------cut here---------------end--------------->8---
>
> And:
>
> --8<---------------cut here---------------start------------->8---
> {-# LANGAUGE Strict #-}
>
> module Main where
>
> main = do
>   contents <- readFile "foo.txt"
>   print contents
> --8<---------------cut here---------------end--------------->8---
>
> The documentation on "Strict-by-default pattern bindings" gives
> let/where binding as an example, but there is not a monadic bind example.
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> <http://downloads.haskell.org/%7Eghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings>
>
> Inspecting GHC Core for these two programs suggests that
>
> !contents <- readFile "foo.txt"
>
> is not equivalent to (with Strict enabled):
>
> contents <- readFile "foo.txt"
>
> Here's core using BangPatterns:
>
> (readFile (unpackCString# "foo.txt"#))
> (\ (contents_asg :: String) ->
>    case contents_asg of contents1_Xsk { __DEFAULT ->
>    print @ String $dShow_rYy contents1_Xsk
>    })
>
> Here's core using Strict:
>
> (readFile (unpackCString# "foo.txt"#))
> (\ (contents_asg :: String) ->
>    print @ String $dShow_rYv contents_asg)
>
> Does this core align with the design of the Strict extension?
>
> If it does, are users going to understand that using Strict is going to
> make let/where bindings strict, but is not going to make <- or >>=
> bindings strict?
>
> --
> Rob Stewart
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/15580249/attachment-0001.html>

From omeragacan at gmail.com  Tue Dec  8 17:35:03 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 8 Dec 2015 12:35:03 -0500
Subject: Does the Strict extension make monadic bindings strict?
In-Reply-To: <56671300.9020404@kane.cx>
References: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
 <56671300.9020404@kane.cx>
Message-ID: <CAMQQO3=CjpS5s5z-oXOre-KixeVYDZvY0v=2HZz5fKfwj3Pgjg@mail.gmail.com>

I think this is a problem/bug in the implementation. In the "function
definitions" section of the wiki page it says the argument will have a
bang pattern. But then this code:

    do x <- ...
       return (x + 1)

which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
doesn't have the bang pattern in `x`.

(See also a related email I sent to ghc-devs yesterday:
https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)

2015-12-08 12:27 GMT-05:00 David Kraeutmann <kane at kane.cx>:
> While there's a fundamental difference between (>>=) and let-bindings, it
> might be worth adding to the docs that -XStrict only makes let bindings
> strict.
>
>
> On 12/08/2015 06:22 PM, Rob Stewart wrote:
>
> Are the following two programs equivalent with respect to the strictness
> of `readFile`?
>
> --8<---------------cut here---------------start------------->8---
> {-# LANGUAGE BangPatterns #-}
>
> module Main where
>
> main = do
>   !contents <- readFile "foo.txt"
>   print contents
> --8<---------------cut here---------------end--------------->8---
>
> And:
>
> --8<---------------cut here---------------start------------->8---
> {-# LANGAUGE Strict #-}
>
> module Main where
>
> main = do
>   contents <- readFile "foo.txt"
>   print contents
> --8<---------------cut here---------------end--------------->8---
>
> The documentation on "Strict-by-default pattern bindings" gives
> let/where binding as an example, but there is not a monadic bind example.
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
>
> Inspecting GHC Core for these two programs suggests that
>
> !contents <- readFile "foo.txt"
>
> is not equivalent to (with Strict enabled):
>
> contents <- readFile "foo.txt"
>
> Here's core using BangPatterns:
>
> (readFile (unpackCString# "foo.txt"#))
> (\ (contents_asg :: String) ->
>    case contents_asg of contents1_Xsk { __DEFAULT ->
>    print @ String $dShow_rYy contents1_Xsk
>    })
>
> Here's core using Strict:
>
> (readFile (unpackCString# "foo.txt"#))
> (\ (contents_asg :: String) ->
>    print @ String $dShow_rYv contents_asg)
>
> Does this core align with the design of the Strict extension?
>
> If it does, are users going to understand that using Strict is going to
> make let/where bindings strict, but is not going to make <- or >>=
> bindings strict?
>
> --
> Rob Stewart
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From erkokl at gmail.com  Tue Dec  8 17:38:07 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Tue, 8 Dec 2015 09:38:07 -0800
Subject: Plugins: Accessing unexported bindings
In-Reply-To: <683062959eb0403fb783c50d7f23dc90@DB4PR30MB030.064d.mgd.msft.net>
References: <CACOpX0fVumww-LSTAcJ+KQ_684af758608GkVQgq1UwKMUu5Yw@mail.gmail.com>
 <1449428935.1340991.459599705.2946B1F8@webmail.messagingengine.com>
 <CACOpX0c=gZerXbfA+=B5YrCC96PayVRXyjQ+OCCM_9qPLiYZgA@mail.gmail.com>
 <f2094e30c5124c0d9209c9ca970aa493@DB4PR30MB030.064d.mgd.msft.net>
 <E74A7097-8EEE-4572-9B2B-3DBEC6CA7BDD@gmail.com>
 <c9f7301f7b9b4404a8141460f72951e5@DB4PR30MB030.064d.mgd.msft.net>
 <771583B3-F62A-4A75-81A5-23367E188CE5@gmail.com>
 <cdf81a4e347c4c1a9a7fbb337923812a@DB4PR30MB030.064d.mgd.msft.net>
 <966FFCCD-0FD6-4CC9-8CD2-BB28059E7380@gmail.com>
 <fee87ac8b8e9457f977584c3104d8c5f@DB4PR30MB030.064d.mgd.msft.net>
 <1449503064.1613765.460378393.24359A24@webmail.messagingengine.com>
 <57a1c733401f434d9815375017760ebd@DB4PR30MB030.064d.mgd.msft.net>
 <CACOpX0eQti2pz+rQBgWLGAkVJHQYSGUFvtA7TyWafHDbOOKW=A@mail.gmail.com>
 <683062959eb0403fb783c50d7f23dc90@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACOpX0fgBTts9fG0vMcUNkhB22qqjxH4RrUXpRsXiWS0j31qSA@mail.gmail.com>

http://ghc.haskell.org/trac/ghc/ticket/11179#ticket

Thanks!

-Levent.

On Tue, Dec 8, 2015 at 4:33 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I think it?s probably the desugarer, and the plugin can?t do anything
> before desugaring!
>
>
>
> By all means open a ticket.  I can advise if anyone wants to take it up.
>
>
>
> Simon
>
>
>
> *From:* Levent Erkok [mailto:erkokl at gmail.com]
> *Sent:* 08 December 2015 03:32
>
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Eric Seidel <eric at seidel.io>; omeragacan at gmail.com; ezyang at mit.edu;
> ghc-devs at haskell.org
> *Subject:* Re: Plugins: Accessing unexported bindings
>
>
>
> Thanks for the explanation, Simon. I think Eric is spot on. Looking at
> some of the "ghc -v3" output, it appears GHC always runs the following
> passes before any plugins are run:
>
>
>
>    *** Simplify:
>
>    *** CorePrep:
>
>    *** ByteCodeGen:
>
>    *** Desugar:
>
>
>
> Just judging by the name, it could either be the first "Simplify" or the
> "Desugar" that gets rid of the dead-code at this point, I'm not sure which.
>
>
>
> It would help if this stage didn't remove dead-bindings. If doing so
> automatically is not the best option, requiring a user given pragma like
> 'KeepAlive' wouldn't be too onerous either.
>
>
>
> -Levent.
>
>
>
> On Mon, Dec 7, 2015 at 8:22 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> It would not be hard to stop the desugarer dropping dead bindings, if that
> was helpful.
>
> S
>
> |  -----Original Message-----
> |  From: Eric Seidel [mailto:eric at seidel.io]
> |  Sent: 07 December 2015 15:44
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>
> |  Cc: Levent Erkok <erkokl at gmail.com>; omeragacan at gmail.com;
> |  ezyang at mit.edu; ghc-devs at haskell.org
> |  Subject: Re: Plugins: Accessing unexported bindings
> |
> |  The problem, as I recall, is that GHC does an initial bit of dead-code
> |  elimination in the desugarer, before the plugins have a chance to run.
> |  (I believe this is part of simpleOptPgm, but may be mistaken)
> |
> |  I'm not sure why this is done in the desugarer, it seems to be out of
> |  place there.
> |
> |  On Mon, Dec 7, 2015, at 05:14, Simon Peyton Jones wrote:
> |  > Plugins get to edit the entire core-to-core pipeline!  There is no
> |  magic.
> |  >  At least I don?t think so
> |  >
> |  > file:///Z:/tmp/users_guide/compiler-plugins.html
> |  >
> |  > S
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 13:11
> |  > To: Simon Peyton Jones <simonpj at microsoft.com>
> |  > Cc: Eric Seidel <eric at seidel.io>; omeragacan at gmail.com;
> |  > ezyang at mit.edu; ghc-devs at haskell.org
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > That's a good point; keeping all annotated bindings alive seems to
> |  be
> |  > an overkill..
> |  >
> |  > Regarding implementing "pass at the start." I'm not sure if plugin
> |  > authors have any freedom as to decide when their plugin actually
> |  runs.
> |  > It seems GHC magically determines the order and runs them. Can you
> |  > point me to some code/docs that tells me how to go "first" in that
> |  > sense? (Or at least before the pass that drops dead code.)
> |  >
> |  > On Dec 7, 2015, at 4:45 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > Indeed. How about this: if there's an ANN on a binder (any ANN),
> |  then
> |  > GHC should keep it alive.
> |  >
> |  > Really?  It might be something like ?don?t give warnings for this
> |  > binding? or ?don?t inline me? or something.   To say *any*
> |  annotation
> |  > seems a bit brutal doesn?t it?    Mind you I don?t have a better
> |  idea.
> |  >
> |  > One thought: your plugin could add a pass right at the start, which
> |  > marks everything you want as keep-alive.
> |  >
> |  > S
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 12:42
> |  > To: Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Indeed. How about this: if there's an ANN on a binder (any ANN),
> |  then
> |  > GHC should keep it alive.
> |  >
> |  > Is that something one of the core-developers can implement? Happy to
> |  > open a ticket if that helps.
> |  >
> |  > On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > If it's "dead" in this sense, it's already removed from ModGuts, no?
> |  >
> |  > Yes, if it?s dead it?s gone.   That?s not too surprising, is it?
> |  >
> |  > So you need a way to keep it alive. Maybe we need a pragma for that.
> |  Or
> |  > how would you like to signal it in the source code?
> |  >
> |  > Simon
> |  >
> |  > From: Levent Erkok [mailto:erkokl at gmail.com]
> |  > Sent: 07 December 2015 12:05
> |  > To: Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> |  > Cc: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>;
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Thanks Simon.. But I remain utterly confused. As a "plugin" author,
> |  > how do I get my hands on the Id associated with a top-level binder?
> |  If
> |  > it's "dead" in this sense, it's already removed from ModGuts, no?
> |  >
> |  > That is, by the time GHC runs my plugin, the Id has already
> |  > disappeared for me to mark it "Local Exported." Is that not correct?
> |  >
> |  > On Dec 7, 2015, at 2:28 AM, Simon Peyton Jones
> |  > <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> |  > In the mean time, I'm still looking for a solution that doesn't
> |  > involve exporting such identifiers from modules. As Eric pointed
> |  out,
> |  > that seems to be the only current work-around for the time being.
> |  >
> |  > ?Exported? in this context only means ?keep alive?. It does not mean
> |  > exported in the Haskell source code sense. I?ve just added this
> |  > comment to Var.hs.
> |  >
> |  > So I think it does just what you want.
> |  >
> |  > Simon
> |  >
> |  > data ExportFlag   -- See Note [ExportFlag on binders]
> |  >   = NotExported   -- ^ Not exported: may be discarded as dead code.
> |  >   | Exported      -- ^ Exported: kept alive
> |  >
> |  > {- Note [ExportFlag on binders]
> |  > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> |  > An ExportFlag of "Exported" on a top-level binder says "keep this
> |  > binding alive; do not drop it as dead code".  This transititively
> |  > keeps alive all the other top-level bindings that this binding
> |  refers
> |  > to.  This property is persisted all the way down the pipeline, so
> |  that
> |  > the binding will be compiled all the way to object code, and its
> |  > symbols will appear in the linker symbol table.
> |  >
> |  > However, note that this use of "exported" is quite different to the
> |  > export list on a Haskell module.  Setting the ExportFlag on an Id
> |  does
> |  > /not/ mean that if you import the module (in Haskell source code you
> |  > will see this Id.  Of course, things that appear in the export list
> |  of
> |  > the source Haskell module do indeed have their ExportFlag set.
> |  > But many other things, such as dictionary functions, are kept alive
> |  by
> |  > having their ExportFlag set, even though they are not exported in
> |  the
> |  > source-code sense.
> |  >
> |  > We should probably use a different term for ExportFlag, like
> |  > KeepAlive.
> |  >
> |  > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  > Levent Erkok
> |  > Sent: 06 December 2015 20:32
> |  > To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>;
> |  > omeragacan at gmail.com<mailto:omeragacan at gmail.com>;
> |  > ezyang at mit.edu<mailto:ezyang at mit.edu>
> |  > Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > Subject: Re: Plugins: Accessing unexported bindings
> |  >
> |  > Omer, Eric, Ed: Thanks for the comments.
> |  >
> |  > Omer: I think Eric's observation is at play here. We're talking
> |  about
> |  > "dead-code," i.e., a binding that is neither exported, nor used by
> |  any
> |  > binding inside the module. Those seem to be getting dropped by the
> |  > time user-plugins are run. Unfortunately, this is precisely what one
> |  > would do with "properties" embedded in code. They serve as
> |  > documentation perhaps, but are otherwise not needed by any other
> |  > binding nor it makes sense to export them.
> |  >
> |  > Edward: Can you provide some more info into your solution? Sounds
> |  like
> |  > a chicken-egg issue to me: As a plugin author, I need the bindings
> |  to
> |  > access the Ids, and looks like I need the Ids to access the binders?
> |  >
> |  > A simple solution would be to simply keep all top-level bindings
> |  > around while the plugin are running, but that obviously can lead to
> |  > unnecessary work if the code is truly dead. A compromise could be
> |  that
> |  > the annotations can serve as entry points as well: I.e., if there's
> |  an
> |  > annotation on a top-level binder, then it should *not* be considered
> |  > dead-code at least until after all the plugins are run. That would
> |  > definitely simplify life. Would that be an acceptable alternative?
> |  >
> |  > In the mean time, I'm still looking for a solution that doesn't
> |  > involve exporting such identifiers from modules. As Eric pointed
> |  out,
> |  > that seems to be the only current work-around for the time being.
> |  >
> |  > Thanks,
> |  >
> |  > -Levent.
> |  >
> |  > On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel
> |  > <eric at seidel.io<mailto:eric at seidel.io>> wrote:
> |  > GHC should only drop un-exported bindings from the ModGuts if
> |  they're
> |  > also unused, ie *dead code*.
> |  >
> |  > The only way I know to get around this is to use the bindings
> |  > somewhere, or just export them.
> |  >
> |  > On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote:
> |  > > Hello,
> |  > >
> |  > > The mg_binds field of the ModGuts seem to only contain the
> |  bindings
> |  > > that are exported from the module being compiled.
> |  > >
> |  > > I guess GHC must be running user-plugins after it drops the
> |  bindings
> |  > > that are not exported, which makes perfect sense for most use
> |  cases.
> |  > > However, I'm working on a plugin where the end-programmer embeds
> |  > > "properties" in the form of functions inside his/her code, which
> |  are
> |  > > not necessarily exported from the module under consideration.
> |  > >
> |  > > Is there a way to access all top-level bindings in a module from a
> |  > > plugin, even if those bindings are not exported?
> |  > >
> |  > > Thanks,
> |  > >
> |  > > -Levent.
> |  > > _______________________________________________
> |  > > ghc-devs mailing list
> |  > > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  > >
>
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
> |  > > .haskell.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qk2h3pMEX2WFCux6QLm4rXk%2faqydq4W13J5U%2bOPZKWo%3d>
> %2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%
> |  > >
> |  7csimonpj%40064d.mgd.microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>
> %7cf6e3a9d4ad9f4e53a3ab08d2ff1d493
> |  > >
> |  4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NY
> |  > >
> |  fBqR90%2bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.
> |  > > outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foutlook.com%2f%3furl%3dhttp%253a%252f%252fmail.haskell.org%252fcgi-&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VxOGYDnOtuRJ0X%2fgNtZoxIA5lzCe9vIGSZNbq2Nj0Tc%3d>
> |  bin%2fmailman%2
> |  > > flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>
> |  > >
> |  %7cac4cbfe22e314080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db
> |  > > 47%7c1&sdata=1z6DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  > askell.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GX53BhjqknGuX4oZVWqLVbz%2b7Up6NY9YLKjWTkwoeck%3d>
> %2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csi
> |  >
> |  monpj%40064d.mgd.microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>
> %7cf6e3a9d4ad9f4e53a3ab08d2ff1d4934%7c72
> |  >
> |  f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv7lpsB%2fD88nSMuB7NYfBqR90%2
> |  >
> |  bBq%2fwpJJ0JU9%2b6E4RI%3d<https://na01.safelinks.protection.outlook.co
> |  > m/?url=http%3a%2f%2fmail.haskell.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f2fmail.haskell.org&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BiZsEZyyTCvpit0cBcPceGv2E6hQ172kSrf6kcDp0so%3d>
> %2fcgi-
> |  bin%2fmailman%2flistinfo%2f
> |  > ghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40064d.mgd.microsoft.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce3d9fc32f78e4a42bc8108d2ff80251a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9om7aGmNLkTw%2bvUYADKPk7040LjeLAwT2DQz511Wi5M%3d>
> %7cac4cbfe22e3
> |  >
> |  14080909908d2fe7c4ed8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1z6
> |  > DcZxjIAKj0PcsLeALphRLWJ3i%2fxvyaPtq0qo6elY%3d>
> |  >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/5ce8c8b2/attachment-0001.html>

From ben at well-typed.com  Tue Dec  8 17:40:42 2015
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 08 Dec 2015 18:40:42 +0100
Subject: Submodules  on a branch
In-Reply-To: <3d22d31463bc47bea28b50606409d948@DB4PR30MB030.064d.mgd.msft.net>
References: <3d22d31463bc47bea28b50606409d948@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <877fkoq1np.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> ?         I?m on a branch wip/T11067.
>
Hi Simon!

> ? I do a ?git merge origin/master?, resolve source code conflicts and
> commit
>
> ? Then ?git submodule update?
>
> ? I have not touched libraries/unix
>
> ? Yet when I say ?git submodule? in a different HEAD tree, I get a
> different commit for libraries/unix than in my branch
>
> Question (sticking plaster): how can I say ?Just make my sub-modules match HEAD please??
>
I've written a script to do just this [1],

    $ wget https://gist.github.com/bgamari/919e1279c1615b9b1cb4/raw/bbb1be6106b73f05d35eff256351187931d43ac3/checkout-submodules
    $ chmod ugo+rx checkout-submodules
    [ensure it's in $PATH]
    $ cd $path_to_ghc
    $ checkout-submodules master
    [a bit of output is produced]
    $ git commit -m "synchronize submodules with master branch"

This should checkout the submodule revisions of the master branch in the
$path_to_ghc tree and commit them.


> Question (cause): how can I ensure that I do update my branch to the
> submodule of HEAD when doing ?git merge??
>
The cause is indeed a bit perplexing. I'll try to reproduce tonight with
the pre-merge state of your T11067 branch.

Cheers,

- Ben

[1] https://gist.github.com/bgamari/919e1279c1615b9b1cb4

From omeragacan at gmail.com  Tue Dec  8 17:50:17 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 8 Dec 2015 12:50:17 -0500
Subject: Another question about -XStrict: Why not implement it as a Core pass?
Message-ID: <CAMQQO3mwVexVkJL86EAdEeScVEJSD9=SZmfGy85ne5ohiMqfCA@mail.gmail.com>

So this is another question comes to mind. It seems to me like it
would be a lot easier to implement, we could even implement it as a
plugin, without changing anything in GHC. (I mean -XStrict, not
-XStrictData)

I'm wondering why it's currently implemented on Haskell syntax. Any
ideas? Is it because of some typechecking related things?

From david.feuer at gmail.com  Tue Dec  8 18:50:35 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 8 Dec 2015 13:50:35 -0500
Subject: Non-exported class constraints in errors
Message-ID: <CAMgWh9vhGEhF1vvBOJV+j7A1vos4A8h4_WFcRr3=9TCw4Nm0Dw@mail.gmail.com>

The latest implementation of Data.Constraint.Forall uses

type family Forall (p :: k -> Constraint) :: Constraint where
  Forall p = Forall_ p
class p (Skolem p) => Forall_ (p :: k -> Constraint)
instance p (Skolem p) => Forall_ (p :: k -> Constraint)

The trouble is that errors relating to Forall are reported with Skolem
verbiage, making them incomprehensible to users -- the Skolem type family
is not exported. It would be nice if GHC could keep track of what led to
the p (Skolem p) constraint, and report that. The sanest idea I've come up
with thus far is a "buck stops here" pragma. When GHC attempts to solve a
constraint so marked, it will hold onto that fact, and report any failures
against that. So

{-# TheBuckStopsHere Forall #-}

would make GHC take note when trying to solve Forall p, and report that it
failed to solve Forall p, rather than that it failed to solve constraints
further down the line.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/6a5ea3a9/attachment.html>

From ryan.gl.scott at gmail.com  Tue Dec  8 21:00:34 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 8 Dec 2015 13:00:34 -0800
Subject: runghc fails on Windows with GHC HEAD
Message-ID: <CADdQpRBO0NzNZomF+xOABW4NxS3LjxQqtDcyi43K3Xa16_6N=Q@mail.gmail.com>

For some reason, I can't get runghc to work with GHC HEAD. Compiling with
ghc-stage2 and running ghc-stage2 --interactive both work okay, it's just
runghc that doesn't want to cooperate for some reason:

    $ .\ghc\inplace\bin\runghc.exe Z.hs
    runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc:
rawSystem: does not exist (No such file or directory)

Does anyone have an idea of what might be happening here?

Ryan S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/0302e6c7/attachment.html>

From ryan.gl.scott at gmail.com  Tue Dec  8 23:19:14 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 8 Dec 2015 15:19:14 -0800
Subject: runghc fails on Windows with GHC HEAD
Message-ID: <CADdQpRDDDkLfd=N5o3BjfM19uRcN+7BHvrEfxM1wn3icHiHL_A@mail.gmail.com>

Actually, this might not be Windows-related at all. It turns out that
runghc was failing because there wasn't a ghc.exe located in inplace/bin
(just ghc-stage1.exe and ghc-stage2.exe). Adding a ghc.exe symlink to
ghc-stage2.exe made runghc.exe work correctly.

Is this a bug, or the intended behavior?

Ryan S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/80b6c7d1/attachment.html>

From austin at well-typed.com  Tue Dec  8 23:22:31 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 8 Dec 2015 17:22:31 -0600
Subject: runghc fails on Windows with GHC HEAD
In-Reply-To: <CADdQpRDDDkLfd=N5o3BjfM19uRcN+7BHvrEfxM1wn3icHiHL_A@mail.gmail.com>
References: <CADdQpRDDDkLfd=N5o3BjfM19uRcN+7BHvrEfxM1wn3icHiHL_A@mail.gmail.com>
Message-ID: <CAEs96n0uQctj0D2N+HSKetOWwEN=HH0eCD8EN9jskONwVN0EZg@mail.gmail.com>

Definitely a bug, the in-place runghc should properly use the in-place
compiler. Not sure when it regressed though, but it wouldn't be
surprising if this has been happening for a while.

On Tue, Dec 8, 2015 at 5:19 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> Actually, this might not be Windows-related at all. It turns out that runghc
> was failing because there wasn't a ghc.exe located in inplace/bin (just
> ghc-stage1.exe and ghc-stage2.exe). Adding a ghc.exe symlink to
> ghc-stage2.exe made runghc.exe work correctly.
>
> Is this a bug, or the intended behavior?
>
> Ryan S.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eir at cis.upenn.edu  Tue Dec  8 14:35:27 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Dec 2015 09:35:27 -0500
Subject: D808 progress report
In-Reply-To: <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>


On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Kind equalities are the Big New Thing in 8.0.  Let's just get it in and deal with the fallout.
> 
> After all, there is no reason for performance to be worse. For programs that 7.10 accepts, 8.0 should yield essentially the same coercions.  They might need a bit of optimisation to squeeze them down but the result should be essentially identical.  If not, let's investigate.

Yes. Modulo levity polymorphism, I agree. However, I just can't find a "smoking gun" in any of the profiling that might indicate what's causing the regressions. It seems to be that everything is just a bit more sluggish. Of course, what that suggests is that there is some low-level function, used a ton, which is slower, but I just haven't found it yet.

Richard

> 
> I could imagine the typechecker being a bit slower, but not a lot.
> 
> For T3738, compile the compiler before and after with -ticky and compare.
> 
> |  In light of all this, I propose the following:
> |  - Scramble to fix all non-perf failures. I expect I can finish this by
> |  Wed evening.
> |  - Hope that one of you (or another dev) can take a look at T3738 and
> |  friends. That clearly needs to get fixed.
> |  - Adjust perf targets to get validation to work, clearly labeling the
> |  remaining problems as the fault of type=kind.
> |  - Commit to fixing #8095 in the next two weeks. But probably not by
> |  early next week, I'm afraid.
> |  
> 
> In short, yes.
> 
> Simon
> 
> 
> |  -----Original Message-----
> |  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
> |  Sent: 08 December 2015 03:35
> |  To: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at well-
> |  typed.com>; Austin Seipp <aseipp at pobox.com>
> |  Subject: D808 progress report
> |  
> |  Hi Simon, Ben, Austin,
> |  
> |  First, the bad news:
> |  I'm a bit stalled on performance issues. When I sent my earlier email,
> |  I was celebrating having gotten one test case from 319M of allocation
> |  down to 182M via several seemingly general-purpose optimizations. But
> |  this was with -fno-opt-coercion. Once I re-enabled coercion
> |  optimization, that particular test case still fails
> |  (pert/compiler/T5030), along with 22 others. This is bad. But many ~4
> |  hours of effort this evening I've made no substantive progress at all,
> |  shaving off maybe 1% of allocation via a few tiny tweaks. Even
> |  characterizing what's going wrong is proving difficult. I've only
> |  analyzed a few of the failing tests, but each one is stubbornly
> |  refusing to break, so I'm losing hope about the others.
> |  
> |  Then, the good news:
> |  I think the idea posited in #8095 (not to bother building coercions
> |  unless -dcore-lint is on) will solve all of these problems and more,
> |  as long as users don't use -dcore-lint. With one exception that I've
> |  noticed (see below), my performance failures aren't catastrophic: on
> |  the performance tests, which tend to be pathological, my branch is
> |  running 10-20% worse than HEAD. Not good, but not so bad that -dcore-
> |  lint users can't cope. So, with #8095 addressed, I think we'll be OK.
> |  And #8095 should be very straightforward and done in a few hours'
> |  work.
> |  
> |  Finally, the ugly:
> |  The exception to the non-catastrophic nature of the failures is this:
> |  perf/should_run/T3738 fails with 3479.1% overage. (Yes, the percentage
> |  is in the thousands.) Worse, this is at runtime, not in the compiler.
> |  Yet the Core produced in my branch (as observed by -ddump-simpl) and
> |  in HEAD appears identical. There are a few other should_run failures
> |  that have me nervous, but my guess is that they're all from one
> |  source. I'd love an offer of help to debug this.
> |  
> |  
> |  In light of all this, I propose the following:
> |  - Scramble to fix all non-perf failures. I expect I can finish this by
> |  Wed evening.
> |  - Hope that one of you (or another dev) can take a look at T3738 and
> |  friends. That clearly needs to get fixed.
> |  - Adjust perf targets to get validation to work, clearly labeling the
> |  remaining problems as the fault of type=kind.
> |  - Commit to fixing #8095 in the next two weeks. But probably not by
> |  early next week, I'm afraid.
> |  
> |  What do we think?
> |  
> |  Thanks,
> |  Richard
> 


From erkokl at gmail.com  Wed Dec  9 02:51:10 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Tue, 8 Dec 2015 18:51:10 -0800
Subject: A comment on Introspective-Haskell
Message-ID: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>

I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the
corresponding wiki-page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective

I think this is a terrific idea. In the past, I've tried both TH and
haskell-src-exts to do relatively simple things, but ended-up abandoning
them due to the inherent complexity of source level haskell that had very
little to do with what I really cared about. Being able to get your hands
on Core at the regular Haskell level would truly simplify life, and I
suspect would open the flood-gates for a lot of people to develop extremely
cool/useful artifacts, making the GHC/Haskell experience even better.

I hope this idea is taken further and sees the light-of-day.

Richard: Did you have any further thoughts about possible plans?

-Levent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/66a54c6b/attachment.html>

From eir at cis.upenn.edu  Wed Dec  9 05:05:07 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 9 Dec 2015 00:05:07 -0500
Subject: D808 progress report
In-Reply-To: <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
Message-ID: <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>

I've just updated the nokinds-dev branch with the latest. It should compile with bootstrapping from 7.8. 

Haddock should also compile, but only after doing this from utils/haddock:

 > git remote add goldfire git://github.com/goldfirere/haddock.git
 > git fetch goldfire

For some reason, I couldn't push a wip/rae-nokinds branch to haddock.git at git.haskell.org.

I'm also still hitting the out-of-memory error when posting to Phab. :(

Nothing particularly interesting to report otherwise. I still have hope that I'll be able to validate cleanly (modulo performance) by Wed evening.

Thanks,
Richard

On Dec 8, 2015, at 9:35 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> 
> On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
>> Kind equalities are the Big New Thing in 8.0.  Let's just get it in and deal with the fallout.
>> 
>> After all, there is no reason for performance to be worse. For programs that 7.10 accepts, 8.0 should yield essentially the same coercions.  They might need a bit of optimisation to squeeze them down but the result should be essentially identical.  If not, let's investigate.
> 
> Yes. Modulo levity polymorphism, I agree. However, I just can't find a "smoking gun" in any of the profiling that might indicate what's causing the regressions. It seems to be that everything is just a bit more sluggish. Of course, what that suggests is that there is some low-level function, used a ton, which is slower, but I just haven't found it yet.
> 
> Richard
> 
>> 
>> I could imagine the typechecker being a bit slower, but not a lot.
>> 
>> For T3738, compile the compiler before and after with -ticky and compare.
>> 
>> |  In light of all this, I propose the following:
>> |  - Scramble to fix all non-perf failures. I expect I can finish this by
>> |  Wed evening.
>> |  - Hope that one of you (or another dev) can take a look at T3738 and
>> |  friends. That clearly needs to get fixed.
>> |  - Adjust perf targets to get validation to work, clearly labeling the
>> |  remaining problems as the fault of type=kind.
>> |  - Commit to fixing #8095 in the next two weeks. But probably not by
>> |  early next week, I'm afraid.
>> |  
>> 
>> In short, yes.
>> 
>> Simon
>> 
>> 
>> |  -----Original Message-----
>> |  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
>> |  Sent: 08 December 2015 03:35
>> |  To: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari <ben at well-
>> |  typed.com>; Austin Seipp <aseipp at pobox.com>
>> |  Subject: D808 progress report
>> |  
>> |  Hi Simon, Ben, Austin,
>> |  
>> |  First, the bad news:
>> |  I'm a bit stalled on performance issues. When I sent my earlier email,
>> |  I was celebrating having gotten one test case from 319M of allocation
>> |  down to 182M via several seemingly general-purpose optimizations. But
>> |  this was with -fno-opt-coercion. Once I re-enabled coercion
>> |  optimization, that particular test case still fails
>> |  (pert/compiler/T5030), along with 22 others. This is bad. But many ~4
>> |  hours of effort this evening I've made no substantive progress at all,
>> |  shaving off maybe 1% of allocation via a few tiny tweaks. Even
>> |  characterizing what's going wrong is proving difficult. I've only
>> |  analyzed a few of the failing tests, but each one is stubbornly
>> |  refusing to break, so I'm losing hope about the others.
>> |  
>> |  Then, the good news:
>> |  I think the idea posited in #8095 (not to bother building coercions
>> |  unless -dcore-lint is on) will solve all of these problems and more,
>> |  as long as users don't use -dcore-lint. With one exception that I've
>> |  noticed (see below), my performance failures aren't catastrophic: on
>> |  the performance tests, which tend to be pathological, my branch is
>> |  running 10-20% worse than HEAD. Not good, but not so bad that -dcore-
>> |  lint users can't cope. So, with #8095 addressed, I think we'll be OK.
>> |  And #8095 should be very straightforward and done in a few hours'
>> |  work.
>> |  
>> |  Finally, the ugly:
>> |  The exception to the non-catastrophic nature of the failures is this:
>> |  perf/should_run/T3738 fails with 3479.1% overage. (Yes, the percentage
>> |  is in the thousands.) Worse, this is at runtime, not in the compiler.
>> |  Yet the Core produced in my branch (as observed by -ddump-simpl) and
>> |  in HEAD appears identical. There are a few other should_run failures
>> |  that have me nervous, but my guess is that they're all from one
>> |  source. I'd love an offer of help to debug this.
>> |  
>> |  
>> |  In light of all this, I propose the following:
>> |  - Scramble to fix all non-perf failures. I expect I can finish this by
>> |  Wed evening.
>> |  - Hope that one of you (or another dev) can take a look at T3738 and
>> |  friends. That clearly needs to get fixed.
>> |  - Adjust perf targets to get validation to work, clearly labeling the
>> |  remaining problems as the fault of type=kind.
>> |  - Commit to fixing #8095 in the next two weeks. But probably not by
>> |  early next week, I'm afraid.
>> |  
>> |  What do we think?
>> |  
>> |  Thanks,
>> |  Richard
>> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Wed Dec  9 08:52:29 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Dec 2015 08:52:29 +0000
Subject: D808 progress report
In-Reply-To: <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
Message-ID: <1dde8cbf30a643cdb93ddc0384b22c03@DB4PR30MB030.064d.mgd.msft.net>

But if we generate identical Core after desugaring there just aren't any downstream changes.  Or are there?

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 08 December 2015 14:35
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Ben Gamari <ben at well-typed.com>; Austin Seipp <aseipp at pobox.com>;
|  ghc-devs at haskell.org
|  Subject: Re: D808 progress report
|  
|  
|  On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  
|  > Kind equalities are the Big New Thing in 8.0.  Let's just get it in
|  and deal with the fallout.
|  >
|  > After all, there is no reason for performance to be worse. For
|  programs that 7.10 accepts, 8.0 should yield essentially the same
|  coercions.  They might need a bit of optimisation to squeeze them down
|  but the result should be essentially identical.  If not, let's
|  investigate.
|  
|  Yes. Modulo levity polymorphism, I agree. However, I just can't find a
|  "smoking gun" in any of the profiling that might indicate what's
|  causing the regressions. It seems to be that everything is just a bit
|  more sluggish. Of course, what that suggests is that there is some
|  low-level function, used a ton, which is slower, but I just haven't
|  found it yet.
|  
|  Richard
|  
|  >
|  > I could imagine the typechecker being a bit slower, but not a lot.
|  >
|  > For T3738, compile the compiler before and after with -ticky and
|  compare.
|  >
|  > |  In light of all this, I propose the following:
|  > |  - Scramble to fix all non-perf failures. I expect I can finish
|  this
|  > | by  Wed evening.
|  > |  - Hope that one of you (or another dev) can take a look at T3738
|  > | and  friends. That clearly needs to get fixed.
|  > |  - Adjust perf targets to get validation to work, clearly labeling
|  > | the  remaining problems as the fault of type=kind.
|  > |  - Commit to fixing #8095 in the next two weeks. But probably not
|  by
|  > | early next week, I'm afraid.
|  > |
|  >
|  > In short, yes.
|  >
|  > Simon
|  >
|  >
|  > |  -----Original Message-----
|  > |  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  > |  Sent: 08 December 2015 03:35
|  > |  To: Simon Peyton Jones <simonpj at microsoft.com>; Ben Gamari
|  > | <ben at well-
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=typed.com&data=01
|  > |
|  %7c01%7csimonpj%40064d.mgd.microsoft.com%7cdcf30e53878843801e5908d30
|  > |
|  0335b8b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YFFgz5PA5Oh7Ehq
|  > | qbtST23860krFwxHQrWRf4MRksyU%3d>; Austin Seipp <aseipp at pobox.com>
|  > |  Subject: D808 progress report
|  > |
|  > |  Hi Simon, Ben, Austin,
|  > |
|  > |  First, the bad news:
|  > |  I'm a bit stalled on performance issues. When I sent my earlier
|  > | email,  I was celebrating having gotten one test case from 319M of
|  > | allocation  down to 182M via several seemingly general-purpose
|  > | optimizations. But  this was with -fno-opt-coercion. Once I
|  > | re-enabled coercion  optimization, that particular test case still
|  > | fails  (pert/compiler/T5030), along with 22 others. This is bad.
|  But
|  > | many ~4  hours of effort this evening I've made no substantive
|  > | progress at all,  shaving off maybe 1% of allocation via a few
|  tiny
|  > | tweaks. Even  characterizing what's going wrong is proving
|  > | difficult. I've only  analyzed a few of the failing tests, but
|  each
|  > | one is stubbornly  refusing to break, so I'm losing hope about the
|  others.
|  > |
|  > |  Then, the good news:
|  > |  I think the idea posited in #8095 (not to bother building
|  coercions
|  > | unless -dcore-lint is on) will solve all of these problems and
|  more,
|  > | as long as users don't use -dcore-lint. With one exception that
|  I've
|  > | noticed (see below), my performance failures aren't catastrophic:
|  on
|  > | the performance tests, which tend to be pathological, my branch is
|  > | running 10-20% worse than HEAD. Not good, but not so bad that
|  > | -dcore-  lint users can't cope. So, with #8095 addressed, I think
|  we'll be OK.
|  > |  And #8095 should be very straightforward and done in a few hours'
|  > |  work.
|  > |
|  > |  Finally, the ugly:
|  > |  The exception to the non-catastrophic nature of the failures is
|  this:
|  > |  perf/should_run/T3738 fails with 3479.1% overage. (Yes, the
|  > | percentage  is in the thousands.) Worse, this is at runtime, not
|  in the compiler.
|  > |  Yet the Core produced in my branch (as observed by -ddump-simpl)
|  > | and  in HEAD appears identical. There are a few other should_run
|  > | failures  that have me nervous, but my guess is that they're all
|  > | from one  source. I'd love an offer of help to debug this.
|  > |
|  > |
|  > |  In light of all this, I propose the following:
|  > |  - Scramble to fix all non-perf failures. I expect I can finish
|  this
|  > | by  Wed evening.
|  > |  - Hope that one of you (or another dev) can take a look at T3738
|  > | and  friends. That clearly needs to get fixed.
|  > |  - Adjust perf targets to get validation to work, clearly labeling
|  > | the  remaining problems as the fault of type=kind.
|  > |  - Commit to fixing #8095 in the next two weeks. But probably not
|  by
|  > | early next week, I'm afraid.
|  > |
|  > |  What do we think?
|  > |
|  > |  Thanks,
|  > |  Richard
|  >


From ben at well-typed.com  Wed Dec  9 12:17:24 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 13:17:24 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
Message-ID: <874mfrlstn.fsf@smart-cactus.org>


Hello everyone,

We are pleased to announce the release of GHC 7.10.3:

    https://downloads.haskell.org/~ghc/7.10.3/

There can be found source tarballs and binary distributions for 64-bit and 32-bit
modern Linux (GMP 5.0 or later), CentOS (GMP 4.0), Windows, and 64-bit
Mac OS X platforms. These binaries and tarballs have an accompanying
SHA256SUMS file signed by my GPG key id (0x97DB64AD). Significant
fixes in release include changes to the simplifier's treatment of
rules, the handling of Mac OS X frameworks, and support for response
files to work around the restrictive command line length limit on
Windows. As always, a full accounting of the changes present in this
release can be found in the release notes [1].

The previous release, 7.10.2, was well-behaved save a couple notable
bugs; while we have merged a good number of bug fixes in 7.10.3 they
were were largely low risk and so we expect that this release should be
similiarly stable.

A notable exception is the upgrade of the Windows compiler toolchain to
GCC 5.2. Typically we would refrain from making such large changes in a
point release but Windows users have been long suffering at the hand of
the old toolchain (e.g. lack of response file support, #8596, and lack
of SEH support). We expect that this change should fix far more than
breaks.

Unfortunately, due to some oversights in the release process there are
two source tarballs for this release. The first,
ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the
users guide. This is fixed in the second patchlevel release,
ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a
source release use the ghc-7.10.3a-src tarballs.

GHC 7.10.3 will very likely be the last release in the GHC 7 series. In
the coming weeks we will be beginning the release process for GHC 8.0,
which will include a number of exciting features including the merger of
kinds with types, injective type families, imporved DWARF debugging
information, applicative-do syntax, a Strict language extension synonyms
mechanism, and more. See the GHC 8.0.1 status page for details [2].

Happy compiling!

Cheers,

- Ben


[1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html
[2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/d8af9de6/attachment.sig>

From ben at well-typed.com  Wed Dec  9 13:22:30 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 14:22:30 +0100
Subject: D808 progress report
In-Reply-To: <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
 <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>
Message-ID: <871tavlpt5.fsf@smart-cactus.org>

Richard Eisenberg <eir at cis.upenn.edu> writes:

> I've just updated the nokinds-dev branch with the latest. It should
> compile with bootstrapping from 7.8.
>
> Haddock should also compile, but only after doing this from
> utils/haddock:
>
>  > git remote add goldfire git://github.com/goldfirere/haddock.git
>  > git fetch goldfire
>
> For some reason, I couldn't push a wip/rae-nokinds branch to
> haddock.git at git.haskell.org.
>
> I'm also still hitting the out-of-memory error when posting to Phab.
> :(
>
Hmm. Austin, what is the status of the Phabricator migration? Perhaps
this has been fixed? It would be nice to know that this validates on
Harbormaster.

> Nothing particularly interesting to report otherwise. I still have
> hope that I'll be able to validate cleanly (modulo performance) by Wed
> evening.
>
I've opened a pull request against your branch fixing up some haddock
issues that were preventing a standard `make all` build from finishing.

Now since I have a build I'll be turning my attention to some of the
performance issues.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/49224a98/attachment.sig>

From ben at well-typed.com  Wed Dec  9 13:35:13 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 14:35:13 +0100
Subject: D808 progress report
In-Reply-To: <871tavlpt5.fsf@smart-cactus.org>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
 <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>
 <871tavlpt5.fsf@smart-cactus.org>
Message-ID: <87wpsnkani.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Now since I have a build I'll be turning my attention to some of the
> performance issues.
> 

Here is a list of the major (>10% delta) performance regressions
according to my testsuite run roughly in order of severity,

    mdo003:     compile never completes
    mdo006:     compile never completes
    T5336:      alloc +3479%
    T9872a:     alloc +78%
    T9872c:     alloc +58%
    T3294:      alloc +49%
    T9872c:     alloc +48%
    T9661:      max_bytes +29%, peak_allocated: +48%
    T6048:      alloc +40%
    T5837:      alloc +17%
    T9872b:     alloc +15%
    T9872a:     alloc +13%
    T9675:      alloc +11%
    WarningWildcardInstantiations: alloc +13%

I'll be starting with T5336.

The full set of testsuite failures that I saw was,

    TEST="landmines tc141 mod71 T6018rnfail rnfail026 readFail003 T7848 T2431 Defer01 T7861 T10284 tcrun044 tcrun043 T9858c rule2 T11077 T8958 Roles13 mdo006 mdo003 T10267 T8031 T7276a T3177a T7064 PolyKinds02 T8566 T7404 T7230 T8616 T7224 T7328 T10503 T7278 T9222 T7438 T7524 T6021 T6123 T3330c T5439 T3330a SimpleFail6 T2627b SimpleFail1a T9171 T2664 T4179 SimpleFail14 T7786 numsparks001 T10403 WarningWildcardInstantiations WildcardInstantiations T10045 UnsatFun Defer02 T7873 T8353 ghci059 T6018ghcirnfail T8674 ghci047 T3208b PushedInAsGivens T9201 T3540 TcCoercibleFail T9109 T9999 tcfail013 T8806 T7734 tcfail014 T8030 T7696 T8603 tcfail113 tcfail032 tcfail057 T2994 tcfail099 T4875 tcfail200 tcfail201 tcfail078 tcfail158 tcfail090 T7368 tcfail058 tcfail196 tcfail197 T5570 FrozenErrorTests tcfail063 tcfail146 T11112 T7778 T7368a T7609 T7410 tcfail004 tcfail005 T5853 T7645 T10285 tcfail002 T7453 tcfail212 T3950 tcfail140 T8262 tcfail161 tcfail160 T9196 T5022 DepFail1 TypeSkolEscape PromotedClass BadTelescope2 RAE_T32a drvfail009 T7959 drvfail005 gadt-escape1 gadt13 gadt7 T9161-2 RAE_T32b KindEqualities2 KindEqualities Rae31 T5536 T3738 MethSharing haddock.Cabal haddock.compiler haddock.base T5030 T9675 T6048 T5631 T9872c T9872a T9872d T9961 T3064 T9872b T1969 T5321Fun T5837 T3294"


Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/d37c9c40/attachment.sig>

From ben at well-typed.com  Wed Dec  9 13:56:49 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 14:56:49 +0100
Subject: D808 progress report
In-Reply-To: <87wpsnkani.fsf@smart-cactus.org>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
 <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>
 <871tavlpt5.fsf@smart-cactus.org> <87wpsnkani.fsf@smart-cactus.org>
Message-ID: <87si3bk9ni.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Ben Gamari <ben at well-typed.com> writes:
>
>> Now since I have a build I'll be turning my attention to some of the
>> performance issues.
>> 
>
> Here is a list of the major (>10% delta) performance regressions
> according to my testsuite run roughly in order of severity,
>
>     mdo003:     compile never completes
>     ...

My apologies, the test names in this list are entirely incorrect [1].
Let's try again,

    $ make test 2>&1 | tee log
    $ grep Deviation log | sort -t: -nk 2
    Deviation   T9872d(normal) bytes allocated:                  -21.8 %
    Deviation   T1969(normal) bytes allocated:                   7.2 %
    Deviation   T9961(normal) bytes allocated:                   7.3 %
    Deviation   T3294(normal) bytes allocated:                   8.5 %
    Deviation   T5536(normal) bytes allocated:                   8.9 %
    Deviation   T5837(normal) bytes allocated:                   11.1 %
    Deviation   haddock.compiler(normal) bytes allocated:        11.6 %
    Deviation   MethSharing(normal) bytes allocated:             12.5 %
    Deviation   T6048(optasm) bytes allocated:                   12.6 %
    Deviation   haddock.Cabal(normal) bytes allocated:           13.4 %
    Deviation   T5321Fun(normal) bytes allocated:                14.9 %
    Deviation   haddock.base(normal) bytes allocated:            16.6 %
    Deviation   T3064(normal) bytes allocated:                   16.6 %
    Deviation   T9675(optasm) peak_megabytes_allocated:          28.4 %
    Deviation   T9675(optasm) max_bytes_used:                    29.4 %
    Deviation   T5030(normal) bytes allocated:                   39.6 %
    Deviation   T5631(normal) bytes allocated:                   48.0 %
    Deviation   T9872a(normal) bytes allocated:                  48.5 %
    Deviation   T9872b(normal) bytes allocated:                  57.7 %
    Deviation   T9872c(normal) bytes allocated:                  78.1 %
    Deviation   T3738(normal) bytes allocated:                   3479.3 %

Consequently I'm looking at T3738.

Cheers,

- Ben



[1] note to self: don't succumb to the temptation to look at the
    "unexpected failure" line preceding a stat failure for the test
    name).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/91625a80/attachment.sig>

From eir at cis.upenn.edu  Wed Dec  9 14:10:47 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 9 Dec 2015 09:10:47 -0500
Subject: D808 progress report
In-Reply-To: <87si3bk9ni.fsf@smart-cactus.org>
References: <300C0C35-F14C-4212-AA0A-D4D9D0FD83E7@cis.upenn.edu>
 <799d352b9a12472895544b1537063761@DB4PR30MB030.064d.mgd.msft.net>
 <AA62C787-2B2D-48B6-BE8F-6AB7593F418E@cis.upenn.edu>
 <05E02806-74C2-4A3F-89D3-31E2CF6B37D6@cis.upenn.edu>
 <871tavlpt5.fsf@smart-cactus.org> <87wpsnkani.fsf@smart-cactus.org>
 <87si3bk9ni.fsf@smart-cactus.org>
Message-ID: <EF7E0974-3333-40CE-A989-C4DDC6EA3290@cis.upenn.edu>

Hi Ben,

Great. Thanks. I'll be working this morning on non-performance errors, starting with utter failures (wrong exit codes). I've also added you as a committer on github.com/goldfirere/ghc.git. Feel free to push changes to nokinds-dev -- I'll take a look at them when they come across.

I'm also on Skype. Feel free to call if you've got any questions.

Thanks for the hand!
Richard

On Dec 9, 2015, at 8:56 AM, Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> writes:
> 
>> Ben Gamari <ben at well-typed.com> writes:
>> 
>>> Now since I have a build I'll be turning my attention to some of the
>>> performance issues.
>>> 
>> 
>> Here is a list of the major (>10% delta) performance regressions
>> according to my testsuite run roughly in order of severity,
>> 
>>    mdo003:     compile never completes
>>    ...
> 
> My apologies, the test names in this list are entirely incorrect [1].
> Let's try again,
> 
>    $ make test 2>&1 | tee log
>    $ grep Deviation log | sort -t: -nk 2
>    Deviation   T9872d(normal) bytes allocated:                  -21.8 %
>    Deviation   T1969(normal) bytes allocated:                   7.2 %
>    Deviation   T9961(normal) bytes allocated:                   7.3 %
>    Deviation   T3294(normal) bytes allocated:                   8.5 %
>    Deviation   T5536(normal) bytes allocated:                   8.9 %
>    Deviation   T5837(normal) bytes allocated:                   11.1 %
>    Deviation   haddock.compiler(normal) bytes allocated:        11.6 %
>    Deviation   MethSharing(normal) bytes allocated:             12.5 %
>    Deviation   T6048(optasm) bytes allocated:                   12.6 %
>    Deviation   haddock.Cabal(normal) bytes allocated:           13.4 %
>    Deviation   T5321Fun(normal) bytes allocated:                14.9 %
>    Deviation   haddock.base(normal) bytes allocated:            16.6 %
>    Deviation   T3064(normal) bytes allocated:                   16.6 %
>    Deviation   T9675(optasm) peak_megabytes_allocated:          28.4 %
>    Deviation   T9675(optasm) max_bytes_used:                    29.4 %
>    Deviation   T5030(normal) bytes allocated:                   39.6 %
>    Deviation   T5631(normal) bytes allocated:                   48.0 %
>    Deviation   T9872a(normal) bytes allocated:                  48.5 %
>    Deviation   T9872b(normal) bytes allocated:                  57.7 %
>    Deviation   T9872c(normal) bytes allocated:                  78.1 %
>    Deviation   T3738(normal) bytes allocated:                   3479.3 %
> 
> Consequently I'm looking at T3738.
> 
> Cheers,
> 
> - Ben
> 
> 
> 
> [1] note to self: don't succumb to the temptation to look at the
>    "unexpected failure" line preceding a stat failure for the test
>    name).


From tomberek at gmail.com  Wed Dec  9 15:55:56 2015
From: tomberek at gmail.com (Thomas Bereknyei)
Date: Wed, 9 Dec 2015 10:55:56 -0500
Subject: A comment on Introspective-Haskell
In-Reply-To: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
Message-ID: <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>

This should be possible to start as a custom library. Appropriately
shimming the result back into TH. Then with some experience and lessons
learned we can investigate replacing TH with this new approach.

I ran across many similar issues with TH, haskell-src-exts,
haskell-src-meta, etc.

Levent: Would it be appropriate for us to start putting together this shim?
As Simon says in (https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5)
we can go a long ways with a plethora of pattern synonyms.


On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erkokl at gmail.com> wrote:

> I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the
> corresponding wiki-page:
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
>
> I think this is a terrific idea. In the past, I've tried both TH and
> haskell-src-exts to do relatively simple things, but ended-up abandoning
> them due to the inherent complexity of source level haskell that had very
> little to do with what I really cared about. Being able to get your hands
> on Core at the regular Haskell level would truly simplify life, and I
> suspect would open the flood-gates for a lot of people to develop extremely
> cool/useful artifacts, making the GHC/Haskell experience even better.
>
> I hope this idea is taken further and sees the light-of-day.
>
> Richard: Did you have any further thoughts about possible plans?
>
> -Levent.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/f85698a9/attachment.html>

From erkokl at gmail.com  Wed Dec  9 17:28:48 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Wed, 9 Dec 2015 09:28:48 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
Message-ID: <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>

Thomas: I honestly don't see why TH needs to go away. The way I viewed
Richard's proposal was a means for me to get my hands on Core-splices
inside my regular Haskell code. I think the two can co-exist happily.
Perhaps others can opine on why we can't have both, aside from perhaps an
argument about added complexity of having two different kinds of splices.

If there was an effort to allow Core-splices, I'd be happy to contribute so
much as I can. Whether that ends up replacing TH or a compatibility shim is
actually needed is a different question in my mind. That can be decided
based on the experience with having Core-splices working first?

Please correct me if I'm wrong; in that TH and Core-splices cannot coexist,
at least in theory, for some other reason.

-Levent.

On Wed, Dec 9, 2015 at 7:55 AM, Thomas Bereknyei <tomberek at gmail.com> wrote:

> This should be possible to start as a custom library. Appropriately
> shimming the result back into TH. Then with some experience and lessons
> learned we can investigate replacing TH with this new approach.
>
> I ran across many similar issues with TH, haskell-src-exts,
> haskell-src-meta, etc.
>
> Levent: Would it be appropriate for us to start putting together this
> shim? As Simon says in (
> https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5) we can go a long
> ways with a plethora of pattern synonyms.
>
>
> On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erkokl at gmail.com> wrote:
>
>> I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and
>> the corresponding wiki-page:
>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
>>
>> I think this is a terrific idea. In the past, I've tried both TH and
>> haskell-src-exts to do relatively simple things, but ended-up abandoning
>> them due to the inherent complexity of source level haskell that had very
>> little to do with what I really cared about. Being able to get your hands
>> on Core at the regular Haskell level would truly simplify life, and I
>> suspect would open the flood-gates for a lot of people to develop extremely
>> cool/useful artifacts, making the GHC/Haskell experience even better.
>>
>> I hope this idea is taken further and sees the light-of-day.
>>
>> Richard: Did you have any further thoughts about possible plans?
>>
>> -Levent.
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/3635407e/attachment-0001.html>

From ben at well-typed.com  Wed Dec  9 20:23:49 2015
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Dec 2015 21:23:49 +0100
Subject: [Haskell-cafe] [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <CA+u6gbw0eCsdvxvr3JiJE7wC1z2ACGQtmys9EQZYcsOGFZ6DyA@mail.gmail.com>
References: <874mfrlstn.fsf@smart-cactus.org>
 <CA+u6gbw0eCsdvxvr3JiJE7wC1z2ACGQtmys9EQZYcsOGFZ6DyA@mail.gmail.com>
Message-ID: <87zixjid62.fsf@smart-cactus.org>

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> writes:

> On 9 December 2015 at 23:17, Ben Gamari <ben at well-typed.com> wrote:
>>
>>
>> [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-10-3.html
>
> The links to Trac issues in that page seem to redirect to the same page.
>
Indeed, I'm trying to work out what went wrong here.

I am quite looking forward to being able to drop DocBook in 8.0.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151209/08ce6004/attachment.sig>

From omeragacan at gmail.com  Thu Dec 10 02:45:59 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 9 Dec 2015 21:45:59 -0500
Subject: question about coercions between primitive types in STG level
In-Reply-To: <5665D692.30506@gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
 <5665D692.30506@gmail.com>
Message-ID: <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>

Thanks for all the answers,

Simon, do you remember anything about the ticket about converting between
floating point types and integers? I spend quite a bit of time in Trac
searching for this but couldn't find it.


Before implementing a new primop, MachOp, and code generation functions for
that I tried this: Since type signature of this new primop will be same as
float2Int# I thought maybe I should first make current implementation working,
and then I can just change the primop to coerceFloat2Int# and it would work.

However I'm still this same problem(illegal assembly). What I changed is I
looked at the GHC-generated, working STG code that uses float2Int#, and tried
to generate a very similar code myself. The change I had to make for this was
to use a case expression instead of let expression to bind result of this
primop.

Here's an example. This STG is working fine:

    sat_s1Ic :: GHC.Types.Float -> GHC.Types.IO () =
        \r srt:SRT:[0B :-> System.IO.print,
                    rUB :-> GHC.Show.$fShowInt] [ds_s1I7]
            case
                ds_s1I7 :: GHC.Types.Float :: Alg GHC.Types.Float
            of
            (wild_s1I8 :: GHC.Types.Float)
            { GHC.Types.F# (f_s1I9 :: GHC.Prim.Float#) ->
                  case
                      float2Int# [(f_s1I9 :: GHC.Prim.Float#)] :: Prim
GHC.Prim.Int#
                  of
                  (sat_s1Ia :: GHC.Prim.Int#)
                  { __DEFAULT ->
                        let {
                          sat_s1Ib :: GHC.Types.Int =
                              NO_CCS GHC.Types.I#! [(sat_s1Ia ::
GHC.Prim.Int#)];
                        } in
                          System.IO.print
                            :: forall a_aUq. GHC.Show.Show a_aUq =>
a_aUq -> GHC.Types.IO ()
                              (GHC.Show.$fShowInt :: GHC.Show.Show
GHC.Types.Int)
                              (sat_s1Ib :: GHC.Types.Int);
                  };
            };

(Sorry for extra noisy output, I changed Outputable instances to print some
extra info)

This code is generated by GHC for a program that uses the primop directly and
it's working. This is the code generated by my pass:

    Main.main2 :: [GHC.Types.Char] =
        \u srt:SRT:[r4 :-> Main.showEither2] []
            case
                case
                    float2Int# [1.2#] :: Prim GHC.Prim.Int#
                of
                (co_g21m :: GHC.Prim.Int#)
                { __DEFAULT -> (#,#) [2## (co_g21m :: GHC.Prim.Int#)];
                } :: UbxTup 2
            of
            (sat_s21b :: (# GHC.Prim.Int#, GHC.Prim.Int# #))
            { (#,#) (sat_g21R :: GHC.Prim.Int#) (sat_g21S :: GHC.Prim.Int#) ->
                  Main.showEither2
                    :: (# GHC.Prim.Int#, GHC.Prim.Int# #) -> [GHC.Types.Char]
                      (sat_g21R :: GHC.Prim.Int#) (sat_g21S :: GHC.Prim.Int#);
            };

Types look correct, and I'm using a case expression to bind the result of the
primop. But generated assembly for this is still invalid! I'm wondering if
there are some invariants that I'm invalidating here, even although -dstg-lint
is passing. Does anyone know what I might be doing wrong here?

One thing that I'm not being very careful is the information about live
variables, but I don't see how it might be related with this illegal
instruction error.

Thanks again..

2015-12-07 13:57 GMT-05:00 Simon Marlow <marlowsd at gmail.com>:
> Simon's right, you need an explicit conversion, and unfortunately those
> conversions don't currently exist.  You would have to add them to the MachOp
> type, and implement them in each of the native code generators.
>
> The good news is that if you did this, we could implement cheap conversions
> between the IEEE floating point types and their representations as unboxed
> integers, which is currently done by poking the values to memory and then
> peeking them back at the desired type. There's a ticket for this around
> somewhere....
>
> Cheers
> Simon
>
>
> On 07/12/2015 12:23, Simon Peyton Jones wrote:
>>
>> If memory serves, there are primops for converting between unboxed values
>> of different widths.
>>
>> Certainly converting between a float and a non-float will require an
>> instruction on some architectures, since they use different register sets.
>>
>> Re (2) I have no idea.  You'll need to get more information... pprTrace or
>> something.
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
>> |  Sinan Agacan
>> |  Sent: 06 December 2015 18:25
>> |  To: ghc-devs <ghc-devs at haskell.org>
>> |  Subject: question about coercions between primitive types in STG level
>> |
>> |  Hi all,
>> |
>> |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
>> |  coercions at the STG level. It works fine for lifted types, but for
>> |  unlifted ones I'm having some problems. What I'm trying to do is given
>> |  a number of primitive types I'm finding the one with biggest size, and
>> |  then generating a constructor that takes this biggest primitive type
>> |  as argument.
>> |
>> |  The problem is that this is not working very well - GHC is generating
>> |  illegal instructions that try to load a F32 value to a register
>> |  allocated for I64, using movss instruction.
>> |
>> |  CoreLint is catching this error and printing this:
>> |
>> |      Cmm lint error:
>> |        in basic block c1hF
>> |          in assignment:
>> |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
>> |            Reg ty: I64
>> |            Rhs ty: F32
>> |
>> |  So I have two questions about this:
>> |
>> |  1. Is there a way to safely do this? What are my options here? What
>> |  I'm trying
>> |     to do is to use a single data constructor field for different
>> |  primitive
>> |     types.  The field is guaranteed to be as big as necessary.
>> |
>> |  2. In the Cmm code shown above, the type annotation is showing `W32`
>> |  but in the
>> |     error message it says `F32`. I'm confused about this, is this error
>> |  message
>> |     given because the sizes don't match? (64bits vs 32bits) Why the
>> |  type
>> |     annotation says W32 while the value has type F32?
>> |
>> |  Thanks..
>> |  _______________________________________________
>> |  ghc-devs mailing list
>> |  ghc-devs at haskell.org
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
>> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa6254e5
>> |  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
>> |  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From juhpetersen at gmail.com  Thu Dec 10 04:13:43 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 10 Dec 2015 13:13:43 +0900
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <874mfrlstn.fsf@smart-cactus.org>
References: <874mfrlstn.fsf@smart-cactus.org>
Message-ID: <CAEDGBqLLBAP9wmmfGJ+s3Nu+3dWA_vWUHLBEKfyP2h5f+bQuRA@mail.gmail.com>

On 9 December 2015 at 21:17, Ben Gamari <ben at well-typed.com> wrote:
> We are pleased to announce the release of GHC 7.10.3

Awesome, thank you!

I have build it for Fedora and RHEL/CentOS in my Fedora Copr repo:

  https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.3

The repos also include cabal-install.

Cheers, Jens

From johan.tibell at gmail.com  Thu Dec 10 14:34:03 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 10 Dec 2015 15:34:03 +0100
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>

I'm snowed under but I promise I will try to reply soon! To think about in
the mean time: what do existing strict languages with pattern matching do?

On Tue, Dec 8, 2015 at 3:42 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Adam, Johan,
>
> Looking at the user manual
>
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell
> ,
> and indeed the wiki page
> https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
> it's not really clear whether the sub-components of a pattern are strict.
> That is, is the second equation of zip strict in x, and xs?   (Supposing
> for now that the list data structure is lazy).  The manual doesn't say one
> way or the other.
>
> What's the answer?  And could the user manual please say?
>
> Thanks
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
> | Sinan Agacan
> | Sent: 08 December 2015 01:41
> | To: ghc-devs <ghc-devs at haskell.org>
> | Subject: -XStrict: Why some binders are not made strict?
> |
> | Let's say I have this code:
> |
> |     zip :: [a] -> [b] -> [(a, b)]
> |     zip [] [] = []
> |     zip (x : xs) (y : ys) = (x, y) : zip xs ys
> |
> | With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
> | about
> | the motivation behind this, I found this interesting. I always thought -
> | XStrict
> | gives me this guarantee: If I'm using an already-defined variable(bound
> by
> | a
> | let or pattern matching) in an expression, I can be sure that the
> variable
> | won't be bottom in that expression, because it would be `seq`d before the
> | expression is evaluated.
> |
> | So if I have
> |
> |     case ... of
> |         D x y -> <body>
> |
> | or
> |
> |     let x = ...
> |         y = ...
> |      in <body>
> |
> | In both cases I was thinking that in <body> 'x' and 'y' can't be
> | bottom(with
> | -XStrict). This would make -XStrict programs evaluate like they would in
> a
> | call-by-value language(even though in the RTS level thunks will be
> built).
> | Variables can't range over computations; all binders evaluated strictly
> | etc.
> |
> | Can anyone tell me about the motivation behind this decision?
> |
> | I think the wiki page actually conflicts with itself. It says "...
> | bindings to be
> | strict by default" but then in "case expressions" sections says
> |
> |     case x of (a,b) -> rhs
> |
> |     is interpreted as
> |
> |     case x of !(a,b) -> rhs
> |
> | Here bindings 'a' and 'b' are not made strict. I'd expect something like:
> |
> |     case x of (!a,!b) -> rhs
> |
> | (Which seems to be invalid Haskell, but same effect could be achieved
> with
> | `seq
> | a (seq b rhs)`)
> |
> | Thanks..
> |
> | (I also realized that the wiki page doesn't mention bindings in do
> syntax,
> | is
> | it because this case is implied by "function definitions"? That is, bangs
> | are
> | added after do syntax is desugared and so they become strict?)
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> |
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
> | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> %7cbc68c0830f574466efd
> |
> 308d2ff70aba9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c2VBbt%2f%2fR2c
> | yFecGEuQotO%2bV71VSbpmWnZJyV9d8KRk%3d
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/e507f541/attachment.html>

From johan.tibell at gmail.com  Thu Dec 10 14:34:39 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 10 Dec 2015 15:34:39 +0100
Subject: Does the Strict extension make monadic bindings strict?
In-Reply-To: <CAMQQO3=CjpS5s5z-oXOre-KixeVYDZvY0v=2HZz5fKfwj3Pgjg@mail.gmail.com>
References: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
 <56671300.9020404@kane.cx>
 <CAMQQO3=CjpS5s5z-oXOre-KixeVYDZvY0v=2HZz5fKfwj3Pgjg@mail.gmail.com>
Message-ID: <CAK-tuPbCiQVVH7U_P5eUmFAz4+5oXB905pn8rbamwNfJSd_dZA@mail.gmail.com>

I believe this is just a bug, since the desugaring ought to be strict in
the \x.

On Tue, Dec 8, 2015 at 6:35 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument will have a
> bang pattern. But then this code:
>
>     do x <- ...
>        return (x + 1)
>
> which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
> doesn't have the bang pattern in `x`.
>
> (See also a related email I sent to ghc-devs yesterday:
> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>
> 2015-12-08 12:27 GMT-05:00 David Kraeutmann <kane at kane.cx>:
> > While there's a fundamental difference between (>>=) and let-bindings, it
> > might be worth adding to the docs that -XStrict only makes let bindings
> > strict.
> >
> >
> > On 12/08/2015 06:22 PM, Rob Stewart wrote:
> >
> > Are the following two programs equivalent with respect to the strictness
> > of `readFile`?
> >
> > --8<---------------cut here---------------start------------->8---
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > main = do
> >   !contents <- readFile "foo.txt"
> >   print contents
> > --8<---------------cut here---------------end--------------->8---
> >
> > And:
> >
> > --8<---------------cut here---------------start------------->8---
> > {-# LANGAUGE Strict #-}
> >
> > module Main where
> >
> > main = do
> >   contents <- readFile "foo.txt"
> >   print contents
> > --8<---------------cut here---------------end--------------->8---
> >
> > The documentation on "Strict-by-default pattern bindings" gives
> > let/where binding as an example, but there is not a monadic bind example.
> >
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> >
> > Inspecting GHC Core for these two programs suggests that
> >
> > !contents <- readFile "foo.txt"
> >
> > is not equivalent to (with Strict enabled):
> >
> > contents <- readFile "foo.txt"
> >
> > Here's core using BangPatterns:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >    case contents_asg of contents1_Xsk { __DEFAULT ->
> >    print @ String $dShow_rYy contents1_Xsk
> >    })
> >
> > Here's core using Strict:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >    print @ String $dShow_rYv contents_asg)
> >
> > Does this core align with the design of the Strict extension?
> >
> > If it does, are users going to understand that using Strict is going to
> > make let/where bindings strict, but is not going to make <- or >>=
> > bindings strict?
> >
> > --
> > Rob Stewart
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/42121623/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Dec 10 14:48:59 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 10 Dec 2015 15:48:59 +0100
Subject: Unused type variables with non-linear patterns
Message-ID: <201512101548.59480.jan.stolarek@p.lodz.pl>

An intersting thing came up when implementing warnings for unused type variables in type family 
patterns (#10982 / D1576):

type family X a b where
  X a a = Int 

Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used 
because of non-linear pattern. We can fix this by prefixing both appearances of `a` with an 
underscore - this silences the warning and maintains semantics. Nevertheless, if a variable is 
unused it should be perfectly valid to replace it with an underscore - that is not the case in 
this example. Thoughts?

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.

From adam at sandbergericsson.se  Thu Dec 10 15:26:17 2015
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Thu, 10 Dec 2015 16:26:17 +0100
Subject: Does the Strict extension make monadic bindings strict?
In-Reply-To: <CAK-tuPbCiQVVH7U_P5eUmFAz4+5oXB905pn8rbamwNfJSd_dZA@mail.gmail.com>
References: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
 <56671300.9020404@kane.cx>
 <CAMQQO3=CjpS5s5z-oXOre-KixeVYDZvY0v=2HZz5fKfwj3Pgjg@mail.gmail.com>
 <CAK-tuPbCiQVVH7U_P5eUmFAz4+5oXB905pn8rbamwNfJSd_dZA@mail.gmail.com>
Message-ID: <1449761177.3811246.463699657.15FCED3F@webmail.messagingengine.com>

I agree that this seems to be a bug. I have a lot to do currently, but
might be able to look at it sometime during next week.

Adam Sandberg Eriksson


On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
> I believe this is just a bug, since the desugaring ought to be strict
> in the \x.
>
> On Tue, Dec 8, 2015 at 6:35 PM, ?mer Sinan A?acan
> <omeragacan at gmail.com> wrote:
>> I think this is a problem/bug in the implementation. In the "function
>>
definitions" section of the wiki page it says the argument will have a
>>
bang pattern. But then this code:
>>
>>
do x <- ...
>>
return (x + 1)
>>
>>
which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
>>
doesn't have the bang pattern in `x`.
>>
>>
(See also a related email I sent to ghc-devs yesterday:
>> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>>
>>
2015-12-08 12:27 GMT-05:00 David Kraeutmann <kane at kane.cx>:
>>
> While there's a fundamental difference between (>>=) and let-
> bindings, it
>>
> might be worth adding to the docs that -XStrict only makes let
> bindings
>>
> strict.
>>
>
>>
>
>>
> On 12/08/2015 06:22 PM, Rob Stewart wrote:
>>
>
>>
> Are the following two programs equivalent with respect to the
> strictness
>>
> of `readFile`?
>>
>
>>
> --8<---------------cut here---------------start------------->8---
>>
> {-# LANGUAGE BangPatterns #-}
>>
>
>>
> module Main where
>>
>
>>
> main = do
>>
>!contents <- readFile "foo.txt"
>>
>print contents
>>
> --8<---------------cut here---------------end--------------->8---
>>
>
>>
> And:
>>
>
>>
> --8<---------------cut here---------------start------------->8---
>>
> {-# LANGAUGE Strict #-}
>>
>
>>
> module Main where
>>
>
>>
> main = do
>>
>contents <- readFile "foo.txt"
>>
>print contents
>>
> --8<---------------cut here---------------end--------------->8---
>>
>
>>
> The documentation on "Strict-by-default pattern bindings" gives
>>
> let/where binding as an example, but there is not a monadic bind
> example.
>>
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
>>
>
>>
> Inspecting GHC Core for these two programs suggests that
>>
>
>>
> !contents <- readFile "foo.txt"
>>
>
>>
> is not equivalent to (with Strict enabled):
>>
>
>>
> contents <- readFile "foo.txt"
>>
>
>>
> Here's core using BangPatterns:
>>
>
>>
> (readFile (unpackCString# "foo.txt"#))
>>
> (\ (contents_asg :: String) ->
>>
>case contents_asg of contents1_Xsk { __DEFAULT ->
>>
>print @ String $dShow_rYy contents1_Xsk
>>
>})
>>
>
>>
> Here's core using Strict:
>>
>
>>
> (readFile (unpackCString# "foo.txt"#))
>>
> (\ (contents_asg :: String) ->
>>
>print @ String $dShow_rYv contents_asg)
>>
>
>>
> Does this core align with the design of the Strict extension?
>>
>
>>
> If it does, are users going to understand that using Strict is
> going to
>>
> make let/where bindings strict, but is not going to make <- or >>=
>>
> bindings strict?
>>
>
>>
> --
>>
> Rob Stewart
>>
>
>>
>
>>
> _______________________________________________
>>
> ghc-devs mailing list
>>
> ghc-devs at haskell.org
>>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>>
>
>>
>
>>
> _______________________________________________
>>
> ghc-devs mailing list
>>
> ghc-devs at haskell.org
>>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>>
_______________________________________________
>>
ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _________________________________________________
> ghc-devs mailing list ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/ee2a7ef2/attachment-0001.html>

From robstewart57 at gmail.com  Thu Dec 10 15:39:47 2015
From: robstewart57 at gmail.com (Rob Stewart)
Date: Thu, 10 Dec 2015 15:39:47 +0000
Subject: Does the Strict extension make monadic bindings strict?
In-Reply-To: <1449761177.3811246.463699657.15FCED3F@webmail.messagingengine.com>
References: <CA+ZOasJ=bw=Ahsakj9KmNxJ-kyoJevAUaUkMikCOhh9_M5azMQ@mail.gmail.com>
 <56671300.9020404@kane.cx>
 <CAMQQO3=CjpS5s5z-oXOre-KixeVYDZvY0v=2HZz5fKfwj3Pgjg@mail.gmail.com>
 <CAK-tuPbCiQVVH7U_P5eUmFAz4+5oXB905pn8rbamwNfJSd_dZA@mail.gmail.com>
 <1449761177.3811246.463699657.15FCED3F@webmail.messagingengine.com>
Message-ID: <CA+ZOasJBtZWJk_+dzFjY+s8_RiepZekxoFB9o4UgVS31N91WdQ@mail.gmail.com>

In which case, I've created a ticket to record this bug and to track its
fix:

https://ghc.haskell.org/trac/ghc/ticket/11193

On 10 December 2015 at 15:26, Adam Sandberg Eriksson <
adam at sandbergericsson.se> wrote:

> I agree that this seems to be a bug. I have a lot to do currently, but
> might be able to look at it sometime during next week.
>
> Adam Sandberg Eriksson
>
>
> On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
>
> I believe this is just a bug, since the desugaring ought to be strict in
> the \x.
>
> On Tue, Dec 8, 2015 at 6:35 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
>
> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument will have a
> bang pattern. But then this code:
>
>     do x <- ...
>        return (x + 1)
>
> which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
> doesn't have the bang pattern in `x`.
>
> (See also a related email I sent to ghc-devs yesterday:
> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>
> 2015-12-08 12:27 GMT-05:00 David Kraeutmann <kane at kane.cx>:
> > While there's a fundamental difference between (>>=) and let-bindings, it
> > might be worth adding to the docs that -XStrict only makes let bindings
> > strict.
> >
> >
> > On 12/08/2015 06:22 PM, Rob Stewart wrote:
> >
> > Are the following two programs equivalent with respect to the strictness
> > of `readFile`?
> >
> > --8<---------------cut here---------------start------------->8---
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > main = do
> >   !contents <- readFile "foo.txt"
> >   print contents
> > --8<---------------cut here---------------end--------------->8---
> >
> > And:
> >
> > --8<---------------cut here---------------start------------->8---
> > {-# LANGAUGE Strict #-}
> >
> > module Main where
> >
> > main = do
> >   contents <- readFile "foo.txt"
> >   print contents
> > --8<---------------cut here---------------end--------------->8---
> >
> > The documentation on "Strict-by-default pattern bindings" gives
> > let/where binding as an example, but there is not a monadic bind example.
> >
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> >
> > Inspecting GHC Core for these two programs suggests that
> >
> > !contents <- readFile "foo.txt"
> >
> > is not equivalent to (with Strict enabled):
> >
> > contents <- readFile "foo.txt"
> >
> > Here's core using BangPatterns:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >    case contents_asg of contents1_Xsk { __DEFAULT ->
> >    print @ String $dShow_rYy contents1_Xsk
> >    })
> >
> > Here's core using Strict:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >    print @ String $dShow_rYv contents_asg)
> >
> > Does this core align with the design of the Strict extension?
> >
> > If it does, are users going to understand that using Strict is going to
> > make let/where bindings strict, but is not going to make <- or >>=
> > bindings strict?
> >
> > --
> > Rob Stewart
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> *_______________________________________________*
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/12a63e7c/attachment.html>

From leo at halfaya.org  Thu Dec 10 15:51:04 2015
From: leo at halfaya.org (John Leo)
Date: Thu, 10 Dec 2015 07:51:04 -0800
Subject: type operators and colon in GHC
Message-ID: <CAHYM_Vnd0R4afd6oMaAkCa-TWdqbTtmX6XEvF7Zyu7_0MRZgzA@mail.gmail.com>

I sent this to haskell-cafe a little while ago but didn't get a response,
so I thought I'd try here.  I'd guess this is a case of the GHC user guide
needing an update, but I'd like an expert opinion.

---

According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
you can define (7.4.3) an infix type constructor as long as it begins with
a colon, for example
data a :*: b = Foo a b

and furthermore (7.4.4) you can define an infix operator without having to
use a colon if you enable the TypeOperators extension:
data a * b = Foo a b

However if I try the former without using TypeOperators I get this compiler
error in 7.10.2:
    Illegal declaration of a type or class operator ?:*:?
      Use TypeOperators to declare operators in type and declarations

Using TypeOperators fixes this, but then * without colon also works so I
don't see the point of using colon anymore.

My guess is this was some some kind of historical distinction which is no
longer valid and the documentation needs to be updated.  Is this true, or
am I missing something?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/9391fb9d/attachment.html>

From vagarenko at gmail.com  Thu Dec 10 15:54:59 2015
From: vagarenko at gmail.com (Alexey Vagarenko)
Date: Thu, 10 Dec 2015 20:54:59 +0500
Subject: type operators and colon in GHC
In-Reply-To: <CAHYM_Vnd0R4afd6oMaAkCa-TWdqbTtmX6XEvF7Zyu7_0MRZgzA@mail.gmail.com>
References: <CAHYM_Vnd0R4afd6oMaAkCa-TWdqbTtmX6XEvF7Zyu7_0MRZgzA@mail.gmail.com>
Message-ID: <CAGzSZM5hTWEqi+GVCw4_bPP=X9aBcmDER19s-nxTSJEvFCBhQQ@mail.gmail.com>

This ticket might be relevant https://ghc.haskell.org/trac/ghc/ticket/11046

2015-12-10 20:51 GMT+05:00 John Leo <leo at halfaya.org>:

> I sent this to haskell-cafe a little while ago but didn't get a response,
> so I thought I'd try here.  I'd guess this is a case of the GHC user guide
> needing an update, but I'd like an expert opinion.
>
> ---
>
> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
>
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
> you can define (7.4.3) an infix type constructor as long as it begins with
> a colon, for example
> data a :*: b = Foo a b
>
> and furthermore (7.4.4) you can define an infix operator without having to
> use a colon if you enable the TypeOperators extension:
> data a * b = Foo a b
>
> However if I try the former without using TypeOperators I get this
> compiler error in 7.10.2:
>     Illegal declaration of a type or class operator ?:*:?
>       Use TypeOperators to declare operators in type and declarations
>
> Using TypeOperators fixes this, but then * without colon also works so I
> don't see the point of using colon anymore.
>
> My guess is this was some some kind of historical distinction which is no
> longer valid and the documentation needs to be updated.  Is this true, or
> am I missing something?
>
> John
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/82044dea/attachment.html>

From leo at halfaya.org  Thu Dec 10 15:58:52 2015
From: leo at halfaya.org (John Leo)
Date: Thu, 10 Dec 2015 07:58:52 -0800
Subject: type operators and colon in GHC
In-Reply-To: <CAGzSZM5hTWEqi+GVCw4_bPP=X9aBcmDER19s-nxTSJEvFCBhQQ@mail.gmail.com>
References: <CAHYM_Vnd0R4afd6oMaAkCa-TWdqbTtmX6XEvF7Zyu7_0MRZgzA@mail.gmail.com>
 <CAGzSZM5hTWEqi+GVCw4_bPP=X9aBcmDER19s-nxTSJEvFCBhQQ@mail.gmail.com>
Message-ID: <CAHYM_VkRnGONDoU-osR2SPNxsx3BznBK=bCe0SR2w=F7KW+w1w@mail.gmail.com>

Thanks, that's helpful.  Sounds like the situation is even more complicated
than I realized.  It will be great if the documentation can be updated once
the behavior stabilizes.

John

On Thu, Dec 10, 2015 at 7:54 AM, Alexey Vagarenko <vagarenko at gmail.com>
wrote:

> This ticket might be relevant
> https://ghc.haskell.org/trac/ghc/ticket/11046
>
> 2015-12-10 20:51 GMT+05:00 John Leo <leo at halfaya.org>:
>
>> I sent this to haskell-cafe a little while ago but didn't get a response,
>> so I thought I'd try here.  I'd guess this is a case of the GHC user guide
>> needing an update, but I'd like an expert opinion.
>>
>> ---
>>
>> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
>>
>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
>> you can define (7.4.3) an infix type constructor as long as it begins
>> with a colon, for example
>> data a :*: b = Foo a b
>>
>> and furthermore (7.4.4) you can define an infix operator without having
>> to use a colon if you enable the TypeOperators extension:
>> data a * b = Foo a b
>>
>> However if I try the former without using TypeOperators I get this
>> compiler error in 7.10.2:
>>     Illegal declaration of a type or class operator ?:*:?
>>       Use TypeOperators to declare operators in type and declarations
>>
>> Using TypeOperators fixes this, but then * without colon also works so I
>> don't see the point of using colon anymore.
>>
>> My guess is this was some some kind of historical distinction which is no
>> longer valid and the documentation needs to be updated.  Is this true, or
>> am I missing something?
>>
>> John
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/41710cf7/attachment-0001.html>

From adam at sandbergericsson.se  Thu Dec 10 16:18:51 2015
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Thu, 10 Dec 2015 17:18:51 +0100
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
Message-ID: <1449764331.3823875.463750601.4E4CA10B@webmail.messagingengine.com>

When implementing I took this:

> Notice that we do not put bangs on nested patterns. For example? let
> (p,q) = if flob then (undefined, undefined) else (True, False)? ?in
> ... will behave like? let !(p,q) = if flob then (undefined, undefined)
> else (True, False)? in ...

(from the spec) and applied it to all bindings, but I don't know if this
is the best implementation.

Cheers, Adam


On Thu, 10 Dec 2015, at 03:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think
> about in the mean time: what do existing strict languages with pattern
> matching do?
>
> On Tue, Dec 8, 2015 at 3:42 PM, Simon Peyton Jones
> <simonpj at microsoft.com> wrote:
>> Adam, Johan,
>>
>>
Looking at the user manual
>> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell,
>>
and indeed the wiki page
>> https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>>
it's not really clear whether the sub-components of a pattern are
strict.? That is, is the second equation of zip strict in x, and xs?
(Supposing for now that the list data structure is lazy).? The manual
doesn't say one way or the other.
>>
>>
What's the answer?? And could the user manual please say?
>>
>>
Thanks
>>
>>
Simon
>>
>>
| -----Original Message-----
>>
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
>>
| Sinan Agacan
>>
| Sent: 08 December 2015 01:41
>>
| To: ghc-devs <ghc-devs at haskell.org>
>>
| Subject: -XStrict: Why some binders are not made strict?
>>
|
>>
| Let's say I have this code:
>>
|
>>
|zip :: [a] -> [b] -> [(a, b)]
>>
|zip [] [] = []
>>
|zip (x : xs) (y : ys) = (x, y) : zip xs ys
>>
|
>>
| With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm
| wondering
>>
| about
>>
| the motivation behind this, I found this interesting. I always
| thought -
>>
| XStrict
>>
| gives me this guarantee: If I'm using an already-defined
| variable(bound by
>>
| a
>>
| let or pattern matching) in an expression, I can be sure that the
| variable
>>
| won't be bottom in that expression, because it would be `seq`d
| before the
>>
| expression is evaluated.
>>
|
>>
| So if I have
>>
|
>>
|case ... of
>>
|D x y -> <body>
>>
|
>>
| or
>>
|
>>
|let x = ...
>>
|y = ...
>>
|in <body>
>>
|
>>
| In both cases I was thinking that in <body> 'x' and 'y' can't be
>>
| bottom(with
>>
| -XStrict). This would make -XStrict programs evaluate like they
| would in a
>>
| call-by-value language(even though in the RTS level thunks will
| be built).
>>
| Variables can't range over computations; all binders evaluated
| strictly
>>
| etc.
>>
|
>>
| Can anyone tell me about the motivation behind this decision?
>>
|
>>
| I think the wiki page actually conflicts with itself. It says "...
>>
| bindings to be
>>
| strict by default" but then in "case expressions" sections says
>>
|
>>
|case x of (a,b) -> rhs
>>
|
>>
|is interpreted as
>>
|
>>
|case x of !(a,b) -> rhs
>>
|
>>
| Here bindings 'a' and 'b' are not made strict. I'd expect
| something like:
>>
|
>>
|case x of (!a,!b) -> rhs
>>
|
>>
| (Which seems to be invalid Haskell, but same effect could be
| achieved with
>>
| `seq
>>
| a (seq b rhs)`)
>>
|
>>
| Thanks..
>>
|
>>
| (I also realized that the wiki page doesn't mention bindings in
| do syntax,
>>
| is
>>
| it because this case is implied by "function definitions"? That
| is, bangs
>>
| are
>>
| added after do syntax is desugared and so they become strict?)
>>
| _______________________________________________
>>
| ghc-devs mailing list
>>
| ghc-devs at haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
>>
| ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbc68c0830f5-
| 74466efd
>>
| 308d2ff70aba9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c2VBbt%-
| 2f%2fR2c
>>
| yFecGEuQotO%2bV71VSbpmWnZJyV9d8KRk%3d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/88c8da60/attachment.html>

From mgsloan at gmail.com  Thu Dec 10 21:32:35 2015
From: mgsloan at gmail.com (Michael Sloan)
Date: Thu, 10 Dec 2015 13:32:35 -0800
Subject: Unused type variables with non-linear patterns
In-Reply-To: <201512101548.59480.jan.stolarek@p.lodz.pl>
References: <201512101548.59480.jan.stolarek@p.lodz.pl>
Message-ID: <CAEDDsWfGFvVN7WeKOH=DYhY7g9yt1frwcR0MxHiUryCB2xSWtQ@mail.gmail.com>

I definitely think this should be considered a usage.  Ideally, you should
always be able to resolve warnings, but there'd be no straightforward way
to do so if LHS-only usages cause warnings.  Also, It's quite useful to use
type variables only on the LHS.  Usage example:
https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar

-Michael

On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek <jan.stolarek at p.lodz.pl>
wrote:

> An intersting thing came up when implementing warnings for unused type
> variables in type family
> patterns (#10982 / D1576):
>
> type family X a b where
>   X a a = Int
>
> Should we emit a warning that `a` is unused? It does not appear in the RHS
> but it is actually used
> because of non-linear pattern. We can fix this by prefixing both
> appearances of `a` with an
> underscore - this silences the warning and maintains semantics.
> Nevertheless, if a variable is
> unused it should be perfectly valid to replace it with an underscore -
> that is not the case in
> this example. Thoughts?
>
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151210/e31ab813/attachment.html>

From ezyang at mit.edu  Thu Dec 10 21:48:13 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 10 Dec 2015 13:48:13 -0800
Subject: arcanist-external-json-linter missing commits
Message-ID: <1449784060-sup-9465@sabre>

On a git submodule update on HEAD, I get:

    fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
    Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule path '.arc-linters/arcanist-external-json-linter'

Edward

From alan.zimm at gmail.com  Thu Dec 10 21:50:25 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 10 Dec 2015 23:50:25 +0200
Subject: arcanist-external-json-linter missing commits
In-Reply-To: <1449784060-sup-9465@sabre>
References: <1449784060-sup-9465@sabre>
Message-ID: <CANma=H98LRi=RMf86RBT4pFaPQvQScAankJMaX-iCHz4-khGQw@mail.gmail.com>

I was advised to

    git submodule update --init

and it did solve the problem

Alan

On Thu, Dec 10, 2015 at 11:48 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> On a git submodule update on HEAD, I get:
>
>     fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
>     Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule path '.arc-linters/arcanist-external-json-linter'
>
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ezyang at mit.edu  Thu Dec 10 21:56:56 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 10 Dec 2015 13:56:56 -0800
Subject: arcanist-external-json-linter missing commits
In-Reply-To: <CANma=H98LRi=RMf86RBT4pFaPQvQScAankJMaX-iCHz4-khGQw@mail.gmail.com>
References: <1449784060-sup-9465@sabre>
 <CANma=H98LRi=RMf86RBT4pFaPQvQScAankJMaX-iCHz4-khGQw@mail.gmail.com>
Message-ID: <1449784578-sup-815@sabre>

It does not, but I have discovered that the problem is related to
my git-new-workdir setup, so I think I'll just fix it myself.

(New submodule went into global .git but git-new-workdir can't deal
with that.)

Edward

Excerpts from Alan & Kim Zimmerman's message of 2015-12-10 13:50:25 -0800:
> I was advised to
> 
>     git submodule update --init
> 
> and it did solve the problem
> 
> Alan
> 
> On Thu, Dec 10, 2015 at 11:48 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > On a git submodule update on HEAD, I get:
> >
> >     fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
> >     Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule path '.arc-linters/arcanist-external-json-linter'
> >
> > Edward
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From roma at ro-che.info  Fri Dec 11 06:54:28 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 11 Dec 2015 08:54:28 +0200
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
Message-ID: <566A7324.2040706@ro-che.info>

On 12/10/2015 04:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think about
> in the mean time: what do existing strict languages with pattern
> matching do?

Well, strict languages do not have lazy data to force to begin with, do they?

Personally, I find the simple intuition of "all patterns are strict by default" rather appealing.

E.g. I wouldn't expect the expressions

  let (v1,v2) = a in f v2

and

  let (v1,v2) = a; v3 = v2 in f v3

to have different semantics.

If we decide to adopt this semantics, we need to address the meaning of the pattern

  ~(v1, v2)

under -XStrict. Intuitively, ~ should propagate to the subpatterns. An alternative is to disallow this pattern under -XStrict and require writing all ~s explicitly, which may get tedious:

  ~(~v1, ~v2)
  ~(~v1, ~(~v2, ~v3))
  etc.

We also need to ensure the consistency between this extension and the unlifted data types proposal [1], given their similarity. Interestingly, I don't see constructor patterns explained there either.

[1]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/473ed854/attachment.sig>

From ben at well-typed.com  Fri Dec 11 10:58:05 2015
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 11 Dec 2015 11:58:05 +0100
Subject: Performance of pattern checker on OptCoercions
Message-ID: <87lh91i75u.fsf@smart-cactus.org>


Hi George,

Richard has encountered a bit of a performance cliff when merging his
no-kinds work. In particular OptCoercions now results in multiple
gigabytes of memory consumption during compilation due to the pattern
checker. The problem seems to be the opt_trans_rule binding, which has
numerous equations, each of which has patterns of various complexities
and guards. Might this be another case where disabling the pattern
checker is unavoidable?

I've attached a testcase to the ticket (#11195) which depends only on
the `ghc` library built from Richard's nokinds-dev branch. If it would
help I could make it a fully free-standing testcase. It's not time
critical as we have just disabled the pattern checker for the time
being, but it would be nice to know whether you have any insight into
what is happening here.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/f4c527e9/attachment.sig>

From johan.tibell at gmail.com  Fri Dec 11 12:21:56 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 11 Dec 2015 13:21:56 +0100
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <566A7324.2040706@ro-che.info>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
Message-ID: <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>

I believe Scala has optional lazy values, but you could also consider in
strict languages if you do manual thunking.

If we force strictness all the way down it's not really call-by-value
either, because the caller doesn't know what to evaluate (I think).

In addition, making pattern matching strict in this way makes it hard to
mix and match strict and lazy data types (e.g. Maybe), because using a lazy
data type from another module will make it appear strict in your code
(hurting modularity).

On Fri, Dec 11, 2015 at 7:54 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> On 12/10/2015 04:34 PM, Johan Tibell wrote:
> > I'm snowed under but I promise I will try to reply soon! To think about
> > in the mean time: what do existing strict languages with pattern
> > matching do?
>
> Well, strict languages do not have lazy data to force to begin with, do
> they?
>
> Personally, I find the simple intuition of "all patterns are strict by
> default" rather appealing.
>
> E.g. I wouldn't expect the expressions
>
>   let (v1,v2) = a in f v2
>
> and
>
>   let (v1,v2) = a; v3 = v2 in f v3
>
> to have different semantics.
>
> If we decide to adopt this semantics, we need to address the meaning of
> the pattern
>
>   ~(v1, v2)
>
> under -XStrict. Intuitively, ~ should propagate to the subpatterns. An
> alternative is to disallow this pattern under -XStrict and require writing
> all ~s explicitly, which may get tedious:
>
>   ~(~v1, ~v2)
>   ~(~v1, ~(~v2, ~v3))
>   etc.
>
> We also need to ensure the consistency between this extension and the
> unlifted data types proposal [1], given their similarity. Interestingly, I
> don't see constructor patterns explained there either.
>
> [1]:
> https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/20e45850/attachment.html>

From roma at ro-che.info  Fri Dec 11 12:57:10 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 11 Dec 2015 14:57:10 +0200
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
Message-ID: <566AC826.9040301@ro-che.info>

On 12/11/2015 02:21 PM, Johan Tibell wrote:
> If we force strictness all the way down it's not really call-by-value
> either, because the caller doesn't know what to evaluate (I think).

Not sure what you mean here.

> In addition, making pattern matching strict in this way makes it hard to
> mix and match strict and lazy data types (e.g. Maybe), because using a
> lazy data type from another module will make it appear strict in your
> code (hurting modularity).

I don't think this is a case about modularity. A lazy Maybe value
defined in a lazy module remains lazy; and you can pass it to lazy
functions without forcing it. Only when you pattern match on it *in the
strict module*, the evaluation happens.

As I said, I prefer this semantics mainly because it's easier to
explain: all variables (and underscores) bound in a strict module refer
to WHNF values. Do you have a similarly simple explanation for the
semantics you're suggesting?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/b7b220c7/attachment.sig>

From tuncer.ayaz at gmail.com  Fri Dec 11 14:03:16 2015
From: tuncer.ayaz at gmail.com (Tuncer Ayaz)
Date: Fri, 11 Dec 2015 15:03:16 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <874mfrlstn.fsf@smart-cactus.org>
References: <874mfrlstn.fsf@smart-cactus.org>
Message-ID: <CAOvwQ4jM2LK=KfFDPody3-F=JwPqkGMuvMW=AU2M=dFpX1gjPA@mail.gmail.com>

On 9 December 2015 at 13:17, Ben Gamari <ben at well-typed.com> wrote:

> Unfortunately, due to some oversights in the release process there are
> two source tarballs for this release. The first,
> ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the
> users guide. This is fixed in the second patchlevel release,
> ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a
> source release use the ghc-7.10.3a-src tarballs.

https://www.haskell.org/ghc/download_ghc_7_10_3#sources does not
link to ghc-7.10.3a-src.tar.{bz2,xz}.

From ben at well-typed.com  Fri Dec 11 15:29:32 2015
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 11 Dec 2015 16:29:32 +0100
Subject: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
In-Reply-To: <CAOvwQ4jM2LK=KfFDPody3-F=JwPqkGMuvMW=AU2M=dFpX1gjPA@mail.gmail.com>
References: <874mfrlstn.fsf@smart-cactus.org>
 <CAOvwQ4jM2LK=KfFDPody3-F=JwPqkGMuvMW=AU2M=dFpX1gjPA@mail.gmail.com>
Message-ID: <87fuz9hulf.fsf@smart-cactus.org>

Tuncer Ayaz <tuncer.ayaz at gmail.com> writes:

> On 9 December 2015 at 13:17, Ben Gamari <ben at well-typed.com> wrote:
>
>> Unfortunately, due to some oversights in the release process there are
>> two source tarballs for this release. The first,
>> ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the
>> users guide. This is fixed in the second patchlevel release,
>> ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a
>> source release use the ghc-7.10.3a-src tarballs.
>
> https://www.haskell.org/ghc/download_ghc_7_10_3#sources does not
> link to ghc-7.10.3a-src.tar.{bz2,xz}.
>
Hmm, fair point. I'll fix this.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/09a3b749/attachment.sig>

From eir at cis.upenn.edu  Fri Dec 11 15:59:22 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 10:59:22 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
Message-ID: <3D88AA64-F1BF-4019-BCEB-2ECDF1FE1EF8@cis.upenn.edu>

If I understand correctly, you're saying that the problem is due to my use of guards, not anything with fancy types. If that's correct, then this sort of thing might be a trap anyone could stumble into. (The code in OptCoercion is fairly routine for Haskell.) It seems like disabling checking guards by default may be best, but I'd love a flag (not with -Wall) to enable it optionally.

Richard

On Dec 11, 2015, at 6:27 AM, George Karachalias <george.karachalias at gmail.com> wrote:

> Hello Ben,
> 
> On Fri, Dec 11, 2015 at 11:58 AM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Hi George,
> 
> Richard has encountered a bit of a performance cliff when merging his
> no-kinds work. In particular OptCoercions now results in multiple
> gigabytes of memory consumption during compilation due to the pattern
> checker. The problem seems to be the opt_trans_rule binding, which has
> numerous equations, each of which has patterns of various complexities
> and guards. Might this be another case where disabling the pattern
> checker is unavoidable?
> 
> I am afraid so. I have just responded to the ticket about it. The essence is the
> difference between `f` and `g` below:
> 
> f x = case x of
>   []      -> ...
>   (_:_) -> ...
> 
> g y | []      <- y = ...
>       | (_:_) <- y = ...
> 
> `f` will generate an empty uncovered set while g will generate:
> 
> uncovered =
>   { x |> { x ~ [], x ~ (_:_) }
>   , x |> { x ~ (_:_), x ~ [] } }
> 
> which is also semantically empty but this cannot be detected until we call the
> term oracle on it to see the inconsistency. Since pattern guards can pattern match
> against any variable whilst case expressions match a single expression (`x` above)
> I can not make the check treat them the same.
> 
> From what I see, until now the pattern guards in opt_trans_co involved mostly
> pattern matching with Maybe which has only two constructors. I can easily assume
> that this is the reason we did not have such a problem until now. So many guards
> are already a challenge for the pattern match checker but maybe changing this (by
> this I mean to not use pattern guards on types with many constructors because this
> is the most expensive thing for the whole check) is enough to make GHC bootstrap.
> 
> I hope this helps, I am really confident that this is the cause of the problem.
> Nevertheless, I will look into it more to see if I can find another source.
> 
> George
> 
> -- 
> things you own end up owning you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/ace00b31/attachment.html>

From eir at cis.upenn.edu  Fri Dec 11 16:02:14 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 11:02:14 -0500
Subject: Unused type variables with non-linear patterns
In-Reply-To: <CAEDDsWfGFvVN7WeKOH=DYhY7g9yt1frwcR0MxHiUryCB2xSWtQ@mail.gmail.com>
References: <201512101548.59480.jan.stolarek@p.lodz.pl>
 <CAEDDsWfGFvVN7WeKOH=DYhY7g9yt1frwcR0MxHiUryCB2xSWtQ@mail.gmail.com>
Message-ID: <CDE401FD-5125-4F2F-AEF3-256762E48B1E@cis.upenn.edu>

I agree with Michael. This should not emit a warning.

While you're in this area, make sure that

> type instance F _ _ = Int

indeed matches `F Char Bool`. It's easy to imagine both underscores being treated as the same variable, which is not what the user intends.

Thanks,
Richard

On Dec 10, 2015, at 4:32 PM, Michael Sloan <mgsloan at gmail.com> wrote:

> I definitely think this should be considered a usage.  Ideally, you should always be able to resolve warnings, but there'd be no straightforward way to do so if LHS-only usages cause warnings.  Also, It's quite useful to use type variables only on the LHS.  Usage example: https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar
> 
> -Michael
> 
> On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> An intersting thing came up when implementing warnings for unused type variables in type family
> patterns (#10982 / D1576):
> 
> type family X a b where
>   X a a = Int
> 
> Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used
> because of non-linear pattern. We can fix this by prefixing both appearances of `a` with an
> underscore - this silences the warning and maintains semantics. Nevertheless, if a variable is
> unused it should be perfectly valid to replace it with an underscore - that is not the case in
> this example. Thoughts?
> 
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/696deb9a/attachment-0001.html>

From eir at cis.upenn.edu  Fri Dec 11 16:12:25 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 11:12:25 -0500
Subject: type operators and colon in GHC
In-Reply-To: <CAHYM_VkRnGONDoU-osR2SPNxsx3BznBK=bCe0SR2w=F7KW+w1w@mail.gmail.com>
References: <CAHYM_Vnd0R4afd6oMaAkCa-TWdqbTtmX6XEvF7Zyu7_0MRZgzA@mail.gmail.com>
 <CAGzSZM5hTWEqi+GVCw4_bPP=X9aBcmDER19s-nxTSJEvFCBhQQ@mail.gmail.com>
 <CAHYM_VkRnGONDoU-osR2SPNxsx3BznBK=bCe0SR2w=F7KW+w1w@mail.gmail.com>
Message-ID: <886DD092-4EA6-423B-ACBA-150265CA45EC@cis.upenn.edu>

This behavior changed in 7.6 I believe.

It used to be that type operators needed to start with a colon, but that restriction was dropped. The documentation is out of date. Ticket #11046 is about updating Template Haskell to match the new behavior, but it doesn't affect the core story of type operators in (non-Template) Haskell. The core story is actually quite simple: all non-reserved symbols are type *constructors*, not type *variables*.

I'll post a bug about the documentation, which needs to be fixed, indeed.

Richard

On Dec 10, 2015, at 10:58 AM, John Leo <leo at halfaya.org> wrote:

> Thanks, that's helpful.  Sounds like the situation is even more complicated than I realized.  It will be great if the documentation can be updated once the behavior stabilizes.
> 
> John
> 
> On Thu, Dec 10, 2015 at 7:54 AM, Alexey Vagarenko <vagarenko at gmail.com> wrote:
> This ticket might be relevant https://ghc.haskell.org/trac/ghc/ticket/11046
> 
> 2015-12-10 20:51 GMT+05:00 John Leo <leo at halfaya.org>:
> I sent this to haskell-cafe a little while ago but didn't get a response, so I thought I'd try here.  I'd guess this is a case of the GHC user guide needing an update, but I'd like an expert opinion.
> 
> ---
> 
> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
> you can define (7.4.3) an infix type constructor as long as it begins with a colon, for example
> data a :*: b = Foo a b
> 
> and furthermore (7.4.4) you can define an infix operator without having to use a colon if you enable the TypeOperators extension:
> data a * b = Foo a b
> 
> However if I try the former without using TypeOperators I get this compiler error in 7.10.2:
>     Illegal declaration of a type or class operator ?:*:?
>       Use TypeOperators to declare operators in type and declarations
> 
> Using TypeOperators fixes this, but then * without colon also works so I don't see the point of using colon anymore.
> 
> My guess is this was some some kind of historical distinction which is no longer valid and the documentation needs to be updated.  Is this true, or am I missing something?
> 
> John
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/b13ca5fa/attachment.html>

From eir at cis.upenn.edu  Fri Dec 11 21:43:02 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 16:43:02 -0500
Subject: kind inference (#11203)
Message-ID: <1DF5C03D-571F-4CC8-8B11-4608CD6AB58A@cis.upenn.edu>

Hi Simon and other devs,

I struggled a bit today with some issues around kind inference that I wanted to write down.

Here are some illuminating test cases, explained below:

-- useful definition:
data SameKind :: k -> k -> *

1.
data T (a :: k1) x = MkT (S a ())
data S (b :: k2) y = MkS (T b ())

2.
data Q (a :: k1) (b :: k2) c = MkQ (SameKind a b)

3.
data D1 = MkD1 (forall p (a :: k). p a -> Int)

4.
data D2 a b = MkD2 (Proxy (a :: Maybe k)) | MkD3 (Proxy (b :: [k])


(1) should be accepted. But this is rather hard to arrange for, because T and S do not have CUSKs. Their kinds are generalized only after checking the mutually-recursive group. So, to accept this pair, we need to use SigTvs for k1 and k2, to allow them to unify with each other. (This works today.)

(2) should be rejected. But it is currently accepted, because k1 and k2 are SigTvs, and so they unify with each other.

(3) should be rejected. I have no idea where that k should be bound. Previously, the k was bound in the forall, but after the wildcards-refactor patch, that's no longer possible. (This is taken from test case ghci/scripts/T7873. HEAD accepts this definition, but produces a bogus tycon.) Note that this was accepted correctly before the wildcards-refactor.

(4) should be accepted. This demonstrates that k can be introduced in constructors but scopes over the entire definition. The difference with case (3) is that (4) has type variables whose kinds mention k, whereas (3) does not.

How should we arrange for all of this behavior? As stated in #11203, I think the use of SigTvs in PolyKinds is highly suspect. I have no good ideas here, though.

In case (3), k ends up in the hsq_kvs (soon to be renamed to hsq_implicit) field of the HsQTyVars for D1. After kind inference, I've written a check to make sure k appears free in the kind of a tyvar. That works. The problem is that the check also snags cases (1) and (2): my check uses the name from the LHsQTyVars, and with SigTvs in the mix, (1) and (2) end up with kind variables with names different from the names in the LHsQTyVars.

I'm sure there's some way to disentangle all of this, but I've given it a rest for now. This hit me in the fact that performance test case T9872d is like case (1), and the SigTvs threw my check off. But removing it caused problems elsewhere.

I'd enjoy discussing next week.

Thanks,
Richard

From omeragacan at gmail.com  Fri Dec 11 22:21:37 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 11 Dec 2015 17:21:37 -0500
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <566AC826.9040301@ro-che.info>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
Message-ID: <CAMQQO3ksro8e49uj4-9LgU2s89zzbYunT3=JUpo4MDq0b02-ug@mail.gmail.com>

I agree with Roman here.

Probably another reason for making every binding strict is this: (sorry if this
is mentioned)

Suppose I imported `data D = D ...` from another library and I'm in -XStrict.
In this code:

    case ... of
      D b1 b2 ... -> <body>

I should be able to assume that b1, b2 ... etc. are all strict(that is, WHNF in
<body>) becuase I'm in -XStrict. This also makes the behavior more consistent,
I think.

2015-12-11 7:57 GMT-05:00 Roman Cheplyaka <roma at ro-che.info>:
> On 12/11/2015 02:21 PM, Johan Tibell wrote:
>> If we force strictness all the way down it's not really call-by-value
>> either, because the caller doesn't know what to evaluate (I think).
>
> Not sure what you mean here.
>
>> In addition, making pattern matching strict in this way makes it hard to
>> mix and match strict and lazy data types (e.g. Maybe), because using a
>> lazy data type from another module will make it appear strict in your
>> code (hurting modularity).
>
> I don't think this is a case about modularity. A lazy Maybe value
> defined in a lazy module remains lazy; and you can pass it to lazy
> functions without forcing it. Only when you pattern match on it *in the
> strict module*, the evaluation happens.
>
> As I said, I prefer this semantics mainly because it's easier to
> explain: all variables (and underscores) bound in a strict module refer
> to WHNF values. Do you have a similarly simple explanation for the
> semantics you're suggesting?
>
> Roman
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From eir at cis.upenn.edu  Fri Dec 11 22:23:23 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 17:23:23 -0500
Subject: A comment on Introspective-Haskell
In-Reply-To: <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
Message-ID: <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>

I'm seeing several different directions here, and it may be helpful to clarify what's going on:

* My original proposal was about changing the implementation of Template Haskell in a way that casual TH users wouldn't notice (by going through the compatibility shim). Once this is done, it may be possible to extend the idea to Core, but that wasn't my primary motivation.

* It seems that Levant wants Template Core. This idea is actually orthogonal from my original proposal, in that Template Core can be implemented with introspection or not. I think it will be easier with introspection, but it's just a matter of engineering either way.

* I don't think any real movement can be made on either of these issues without editing GHC itself. I don't see what a purely-external library could do.

* Yes yes yes, lots lots lots of pattern synonyms.

Does this clarify anything?

Richard

On Dec 9, 2015, at 12:28 PM, Levent Erkok <erkokl at gmail.com> wrote:

> Thomas: I honestly don't see why TH needs to go away. The way I viewed Richard's proposal was a means for me to get my hands on Core-splices inside my regular Haskell code. I think the two can co-exist happily. Perhaps others can opine on why we can't have both, aside from perhaps an argument about added complexity of having two different kinds of splices.
> 
> If there was an effort to allow Core-splices, I'd be happy to contribute so much as I can. Whether that ends up replacing TH or a compatibility shim is actually needed is a different question in my mind. That can be decided based on the experience with having Core-splices working first?
> 
> Please correct me if I'm wrong; in that TH and Core-splices cannot coexist, at least in theory, for some other reason.
> 
> -Levent.
> 
> On Wed, Dec 9, 2015 at 7:55 AM, Thomas Bereknyei <tomberek at gmail.com> wrote:
> This should be possible to start as a custom library. Appropriately shimming the result back into TH. Then with some experience and lessons learned we can investigate replacing TH with this new approach.
> 
> I ran across many similar issues with TH, haskell-src-exts, haskell-src-meta, etc.
> 
> Levent: Would it be appropriate for us to start putting together this shim? As Simon says in (https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5) we can go a long ways with a plethora of pattern synonyms.
> 
> 
> On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erkokl at gmail.com> wrote:
> I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the corresponding wiki-page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
> 
> I think this is a terrific idea. In the past, I've tried both TH and haskell-src-exts to do relatively simple things, but ended-up abandoning them due to the inherent complexity of source level haskell that had very little to do with what I really cared about. Being able to get your hands on Core at the regular Haskell level would truly simplify life, and I suspect would open the flood-gates for a lot of people to develop extremely cool/useful artifacts, making the GHC/Haskell experience even better.
> 
> I hope this idea is taken further and sees the light-of-day.
> 
> Richard: Did you have any further thoughts about possible plans?
> 
> -Levent.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/20cc1f3d/attachment-0001.html>

From simonpj at microsoft.com  Fri Dec 11 22:38:41 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Dec 2015 22:38:41 +0000
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
Message-ID: <91c899b7da9b4d9490ae021c2c45df8f@DB4PR30MB030.064d.mgd.msft.net>

In addition, making pattern matching strict in this way makes it hard to mix and match strict and lazy data types (e.g. Maybe), because using a lazy data type from another module will make it appear strict in your code (hurting modularity).

I didn?t understand that.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell
Sent: 11 December 2015 12:22
To: Roman Cheplyaka <roma at ro-che.info>
Cc: ghc-devs at haskell.org
Subject: Re: -XStrict: Why some binders are not made strict?

I believe Scala has optional lazy values, but you could also consider in strict languages if you do manual thunking.

If we force strictness all the way down it's not really call-by-value either, because the caller doesn't know what to evaluate (I think).

In addition, making pattern matching strict in this way makes it hard to mix and match strict and lazy data types (e.g. Maybe), because using a lazy data type from another module will make it appear strict in your code (hurting modularity).

On Fri, Dec 11, 2015 at 7:54 AM, Roman Cheplyaka <roma at ro-che.info<mailto:roma at ro-che.info>> wrote:
On 12/10/2015 04:34 PM, Johan Tibell wrote:
> I'm snowed under but I promise I will try to reply soon! To think about
> in the mean time: what do existing strict languages with pattern
> matching do?

Well, strict languages do not have lazy data to force to begin with, do they?

Personally, I find the simple intuition of "all patterns are strict by default" rather appealing.

E.g. I wouldn't expect the expressions

  let (v1,v2) = a in f v2

and

  let (v1,v2) = a; v3 = v2 in f v3

to have different semantics.

If we decide to adopt this semantics, we need to address the meaning of the pattern

  ~(v1, v2)

under -XStrict. Intuitively, ~ should propagate to the subpatterns. An alternative is to disallow this pattern under -XStrict and require writing all ~s explicitly, which may get tedious:

  ~(~v1, ~v2)
  ~(~v1, ~(~v2, ~v3))
  etc.

We also need to ensure the consistency between this extension and the unlifted data types proposal [1], given their similarity. Interestingly, I don't see constructor patterns explained there either.

[1]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes



_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2faaa875c5764c6701d408d30225b68d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xaohOEQRieXHuSG%2btmcecSX%2fr7tQG1OMkt1YQe9kmT0%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/9c23631f/attachment.html>

From simonpj at microsoft.com  Fri Dec 11 22:38:39 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Dec 2015 22:38:39 +0000
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <566AC826.9040301@ro-che.info>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
Message-ID: <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>

| As I said, I prefer this semantics mainly because it's easier to
| explain: all variables (and underscores) bound in a strict module refer
| to WHNF values. Do you have a similarly simple explanation for the
| semantics you're suggesting?

Here's one, which is roughly what the current implementation does (modulo bugs):

* Code compiled under -XStrict constructs no thunks.

So consider

	module M1 where data T = C Int Int
	module M2 where f n = C (n+1) (n-1)
	module M3 where g x = let C y z = f x in ...

Look at M3.  Usually we'd get a thunk for (f 4), but not with -XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.   

If you compile M2 with -XStrict, function f won't build thunks for (n+1), (n-1) but will evaluate them instead.

If you compile M1 with StrictData, then C is made strict, so again M2 will build no thunks even if M2 was compiled without -XStrict.

I quite like this design.  It's not clear to me that anything useful is gained by forcing y and z in M3 before evaluating the body "...".


So Roman's design makes sense, but so does the implemented design (modulo any bugs).  The trouble is that the implemented design is not well described.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Roman
| Cheplyaka
| Sent: 11 December 2015 12:57
| To: Johan Tibell <johan.tibell at gmail.com>
| Cc: ghc-devs at haskell.org
| Subject: Re: -XStrict: Why some binders are not made strict?
| 
| On 12/11/2015 02:21 PM, Johan Tibell wrote:
| > If we force strictness all the way down it's not really call-by-value
| > either, because the caller doesn't know what to evaluate (I think).
| 
| Not sure what you mean here.
| 
| > In addition, making pattern matching strict in this way makes it hard to
| > mix and match strict and lazy data types (e.g. Maybe), because using a
| > lazy data type from another module will make it appear strict in your
| > code (hurting modularity).
| 
| I don't think this is a case about modularity. A lazy Maybe value
| defined in a lazy module remains lazy; and you can pass it to lazy
| functions without forcing it. Only when you pattern match on it *in the
| strict module*, the evaluation happens.
| 
| As I said, I prefer this semantics mainly because it's easier to
| explain: all variables (and underscores) bound in a strict module refer
| to WHNF values. Do you have a similarly simple explanation for the
| semantics you're suggesting?
| 
| Roman


From simonpj at microsoft.com  Fri Dec 11 22:41:34 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Dec 2015 22:41:34 +0000
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <3D88AA64-F1BF-4019-BCEB-2ECDF1FE1EF8@cis.upenn.edu>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <3D88AA64-F1BF-4019-BCEB-2ECDF1FE1EF8@cis.upenn.edu>
Message-ID: <f84c1b16a5a4451798b35d9214229e23@DB4PR30MB030.064d.mgd.msft.net>

Yes; but we should jolly well figure out a way to do better for guards.  These guards are no more than patterns really!

Simon

From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
Sent: 11 December 2015 15:59
To: George Karachalias <george.karachalias at gmail.com>
Cc: Ben Gamari <ben at well-typed.com>; Simon Peyton Jones <simonpj at microsoft.com>; GHC developers <ghc-devs at haskell.org>
Subject: Re: Performance of pattern checker on OptCoercions

If I understand correctly, you're saying that the problem is due to my use of guards, not anything with fancy types. If that's correct, then this sort of thing might be a trap anyone could stumble into. (The code in OptCoercion is fairly routine for Haskell.) It seems like disabling checking guards by default may be best, but I'd love a flag (not with -Wall) to enable it optionally.

Richard

On Dec 11, 2015, at 6:27 AM, George Karachalias <george.karachalias at gmail.com<mailto:george.karachalias at gmail.com>> wrote:


Hello Ben,

On Fri, Dec 11, 2015 at 11:58 AM, Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:

Hi George,

Richard has encountered a bit of a performance cliff when merging his
no-kinds work. In particular OptCoercions now results in multiple
gigabytes of memory consumption during compilation due to the pattern
checker. The problem seems to be the opt_trans_rule binding, which has
numerous equations, each of which has patterns of various complexities
and guards. Might this be another case where disabling the pattern
checker is unavoidable?

I am afraid so. I have just responded to the ticket about it. The essence is the
difference between `f` and `g` below:
f x = case x of
  []      -> ...
  (_:_) -> ...

g y | []      <- y = ...
      | (_:_) <- y = ...

`f` will generate an empty uncovered set while g will generate:
uncovered =
  { x |> { x ~ [], x ~ (_:_) }
  , x |> { x ~ (_:_), x ~ [] } }

which is also semantically empty but this cannot be detected until we call the
term oracle on it to see the inconsistency. Since pattern guards can pattern match
against any variable whilst case expressions match a single expression (`x` above)
I can not make the check treat them the same.
>From what I see, until now the pattern guards in opt_trans_co involved mostly
pattern matching with Maybe which has only two constructors. I can easily assume
that this is the reason we did not have such a problem until now. So many guards
are already a challenge for the pattern match checker but maybe changing this (by
this I mean to not use pattern guards on types with many constructors because this
is the most expensive thing for the whole check) is enough to make GHC bootstrap.

I hope this helps, I am really confident that this is the cause of the problem.
Nevertheless, I will look into it more to see if I can find another source.

George
--
things you own end up owning you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/dab35dde/attachment.html>

From erkokl at gmail.com  Fri Dec 11 22:54:36 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Fri, 11 Dec 2015 14:54:36 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
 <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
Message-ID: <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>

Spot on.. I really want "Template Core," independent of TH.

To be honest, "GHC Plugins" already provides "Template Core" in this sense;
but would be nicer if one can get his hands on the Core in the regular
Haskell context, not just in a plugin context. So, perhaps "Template Core"
is not the biggest priority in the big scheme of things.

On Fri, Dec 11, 2015 at 2:23 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I'm seeing several different directions here, and it may be helpful to
> clarify what's going on:
>
> * My original proposal was about changing the implementation of Template
> Haskell in a way that casual TH users wouldn't notice (by going through the
> compatibility shim). Once this is done, it may be possible to extend the
> idea to Core, but that wasn't my primary motivation.
>
> * It seems that Levant wants Template Core. This idea is actually
> orthogonal from my original proposal, in that Template Core can be
> implemented with introspection or not. I think it will be easier with
> introspection, but it's just a matter of engineering either way.
>
> * I don't think any real movement can be made on either of these issues
> without editing GHC itself. I don't see what a purely-external library
> could do.
>
> * Yes yes yes, lots lots lots of pattern synonyms.
>
> Does this clarify anything?
>
> Richard
>
> On Dec 9, 2015, at 12:28 PM, Levent Erkok <erkokl at gmail.com> wrote:
>
> Thomas: I honestly don't see why TH needs to go away. The way I viewed
> Richard's proposal was a means for me to get my hands on Core-splices
> inside my regular Haskell code. I think the two can co-exist happily.
> Perhaps others can opine on why we can't have both, aside from perhaps an
> argument about added complexity of having two different kinds of splices.
>
> If there was an effort to allow Core-splices, I'd be happy to contribute
> so much as I can. Whether that ends up replacing TH or a compatibility shim
> is actually needed is a different question in my mind. That can be decided
> based on the experience with having Core-splices working first?
>
> Please correct me if I'm wrong; in that TH and Core-splices cannot
> coexist, at least in theory, for some other reason.
>
> -Levent.
>
> On Wed, Dec 9, 2015 at 7:55 AM, Thomas Bereknyei <tomberek at gmail.com>
> wrote:
>
>> This should be possible to start as a custom library. Appropriately
>> shimming the result back into TH. Then with some experience and lessons
>> learned we can investigate replacing TH with this new approach.
>>
>> I ran across many similar issues with TH, haskell-src-exts,
>> haskell-src-meta, etc.
>>
>> Levent: Would it be appropriate for us to start putting together this
>> shim? As Simon says in (
>> https://ghc.haskell.org/trac/ghc/ticket/11081#comment:5) we can go a
>> long ways with a plethora of pattern synonyms.
>>
>>
>> On Tue, Dec 8, 2015 at 9:51 PM, Levent Erkok <erkokl at gmail.com> wrote:
>>
>>> I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and
>>> the corresponding wiki-page:
>>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
>>>
>>> I think this is a terrific idea. In the past, I've tried both TH and
>>> haskell-src-exts to do relatively simple things, but ended-up abandoning
>>> them due to the inherent complexity of source level haskell that had very
>>> little to do with what I really cared about. Being able to get your hands
>>> on Core at the regular Haskell level would truly simplify life, and I
>>> suspect would open the flood-gates for a lot of people to develop extremely
>>> cool/useful artifacts, making the GHC/Haskell experience even better.
>>>
>>> I hope this idea is taken further and sees the light-of-day.
>>>
>>> Richard: Did you have any further thoughts about possible plans?
>>>
>>> -Levent.
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/ac8d5add/attachment-0001.html>

From simonpj at microsoft.com  Fri Dec 11 23:01:22 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Dec 2015 23:01:22 +0000
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
Message-ID: <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>

`f` will generate an empty uncovered set while g will generate:
uncovered =
  { x |> { x ~ [], x ~ (_:_) }
  , x |> { x ~ (_:_), x ~ [] } }

which is also semantically empty but this cannot be detected until we call the
term oracle on it to see the inconsistency.

So, why not call the term oracle more aggressively (at every node of the tree), to prune empty sets?  It should not be hard to spot common cases; in what you show above it?s very easy.

Simon

From: George Karachalias [mailto:george.karachalias at gmail.com]
Sent: 11 December 2015 11:27
To: Ben Gamari <ben at well-typed.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <eir at cis.upenn.edu>; GHC developers <ghc-devs at haskell.org>
Subject: Re: Performance of pattern checker on OptCoercions

Hello Ben,

On Fri, Dec 11, 2015 at 11:58 AM, Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:

Hi George,

Richard has encountered a bit of a performance cliff when merging his
no-kinds work. In particular OptCoercions now results in multiple
gigabytes of memory consumption during compilation due to the pattern
checker. The problem seems to be the opt_trans_rule binding, which has
numerous equations, each of which has patterns of various complexities
and guards. Might this be another case where disabling the pattern
checker is unavoidable?

I am afraid so. I have just responded to the ticket about it. The essence is the
difference between `f` and `g` below:
f x = case x of
  []      -> ...
  (_:_) -> ...

g y | []      <- y = ...
      | (_:_) <- y = ...

`f` will generate an empty uncovered set while g will generate:
uncovered =
  { x |> { x ~ [], x ~ (_:_) }
  , x |> { x ~ (_:_), x ~ [] } }

which is also semantically empty but this cannot be detected until we call the
term oracle on it to see the inconsistency. Since pattern guards can pattern match
against any variable whilst case expressions match a single expression (`x` above)
I can not make the check treat them the same.
From what I see, until now the pattern guards in opt_trans_co involved mostly
pattern matching with Maybe which has only two constructors. I can easily assume
that this is the reason we did not have such a problem until now. So many guards
are already a challenge for the pattern match checker but maybe changing this (by
this I mean to not use pattern guards on types with many constructors because this
is the most expensive thing for the whole check) is enough to make GHC bootstrap.

I hope this helps, I am really confident that this is the cause of the problem.
Nevertheless, I will look into it more to see if I can find another source.

George
--
things you own end up owning you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/a49f24a4/attachment.html>

From eric at seidel.io  Fri Dec 11 23:13:13 2015
From: eric at seidel.io (Eric Seidel)
Date: Fri, 11 Dec 2015 15:13:13 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
 <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
 <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>
Message-ID: <1449875593.4157693.465081409.2E54C6BE@webmail.messagingengine.com>

On Fri, Dec 11, 2015, at 14:54, Levent Erkok wrote:
> Spot on.. I really want "Template Core," independent of TH.
> 
> To be honest, "GHC Plugins" already provides "Template Core" in this
> sense;
> but would be nicer if one can get his hands on the Core in the regular
> Haskell context, not just in a plugin context. So, perhaps "Template
> Core"
> is not the biggest priority in the big scheme of things.

I would caution against going the Core Plugin (or Template Core) route
unless you really need to work with Core, e.g. if you're doing some sort
of analysis and want to save your sanity by avoiding all of the surface
syntax.

Constructing and manipulating Core is quite tedious because Core is
explicitly typed. This means that you have to instantiate type
parameters of polymorphic functions/constructors yourself, and worse,
you have to provide type-class dictionaries yourself. It's not
impossible by any means, just a lot more work in my experience than
working with surface syntax and letting GHC handle the rest :)

I'm curious though, what specifically were you trying to use TH/HSE for
in the past, analysis or code-generation?

From erkokl at gmail.com  Fri Dec 11 23:28:05 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Fri, 11 Dec 2015 15:28:05 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <1449875593.4157693.465081409.2E54C6BE@webmail.messagingengine.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
 <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
 <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>
 <1449875593.4157693.465081409.2E54C6BE@webmail.messagingengine.com>
Message-ID: <CACOpX0eCMfUY333X6P1S=hrt-MX3BhvBSXXRundCDdaXn7BnVg@mail.gmail.com>

My "hidden agenda" is to liberate the SBV library to work on Haskell
programs directly. (http://hackage.haskell.org/package/sbv)

SBV allows programming with symbolic values, allowing a certain class of
"proofs" to be done. It uses SMT solvers to do the actual "solving." It's
limited in what it can do so far as reasoning goes: It's mostly limited to
number types really (Word/Int/Float/Double etc.), but when it works, it
really can be effective. Right now, users of this library have to write
things like this:

   foo x y = ite (x .> y) (x+2) (x .< y)

Since I "cannot" reliably steal if-then-else (yes, I'm aware of
RebindableSyntax; but it has its own problems.), nor I can just use
comparison operators that insist on returning Bool that I cannot change.
But those are smaller problems: The bigger issue is that I cannot support
"case" expressions, pattern-matching, and all that stuff; since all that
mechanism is baked into the compiler and I've no way to arrange for a
pattern to "symbolically" match. This latter issue with pattern-matching
and lack of support for case-expressions is why the library is sort of
"hard-to-use" for a newcomer.

I tried TH/HSE before to see if I can let users write regular-Haskell and
have the expressions automatically made "symbolic" aware, but ran into a
lot of accidental complexity due to the extremely rich surface syntax. I'm
currently working on a plugin to do the same, which is much nicer to work
with; though you are correct that dealing with explicitly-typed core has
its complexities as well. However, I do find it to be much easier to work
with as compared to surface Haskell.

I suspect you guys went down to the "stand-alone" route with LiquidHaskell
when you had similar problems. That definitely is a great approach as well,
though I don't have the luxury of an academic research team to pursue that
line of thought. (LiquidHaskell rocks by the way; I'm a real fan.)

-Levent.

On Fri, Dec 11, 2015 at 3:13 PM, Eric Seidel <eric at seidel.io> wrote:

> On Fri, Dec 11, 2015, at 14:54, Levent Erkok wrote:
> > Spot on.. I really want "Template Core," independent of TH.
> >
> > To be honest, "GHC Plugins" already provides "Template Core" in this
> > sense;
> > but would be nicer if one can get his hands on the Core in the regular
> > Haskell context, not just in a plugin context. So, perhaps "Template
> > Core"
> > is not the biggest priority in the big scheme of things.
>
> I would caution against going the Core Plugin (or Template Core) route
> unless you really need to work with Core, e.g. if you're doing some sort
> of analysis and want to save your sanity by avoiding all of the surface
> syntax.
>
> Constructing and manipulating Core is quite tedious because Core is
> explicitly typed. This means that you have to instantiate type
> parameters of polymorphic functions/constructors yourself, and worse,
> you have to provide type-class dictionaries yourself. It's not
> impossible by any means, just a lot more work in my experience than
> working with surface syntax and letting GHC handle the rest :)
>
> I'm curious though, what specifically were you trying to use TH/HSE for
> in the past, analysis or code-generation?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/5d3b4e90/attachment.html>

From roma at ro-che.info  Fri Dec 11 23:55:45 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 12 Dec 2015 01:55:45 +0200
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
 <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <566B6281.7060502@ro-che.info>

Thanks Simon, this is an interesting and compelling interpretation. But
I'm wondering whether it is enough to specify the dynamic semantics
unambiguously.

Two examples:

1.

  let _ = undefined in ()

Intuitively, since we are talking about /strictness/, this should
evaluate to bottom. However, it seems that your rule also admits () as
an answer; it is equivalent to () under lazy evaluation *and* it does
not create any thunks.

2.

  f g = g undefined

When compiled lazily, this code doesn't construct any thunks:

  f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;

So, under your rule, this is an admissible code for -XStrict, too. But
we can hardly call it strict.

On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
> | As I said, I prefer this semantics mainly because it's easier to
> | explain: all variables (and underscores) bound in a strict module refer
> | to WHNF values. Do you have a similarly simple explanation for the
> | semantics you're suggesting?
> 
> Here's one, which is roughly what the current implementation does (modulo bugs):
> 
> * Code compiled under -XStrict constructs no thunks.
> 
> So consider
> 
> 	module M1 where data T = C Int Int
> 	module M2 where f n = C (n+1) (n-1)
> 	module M3 where g x = let C y z = f x in ...
> 
> Look at M3.  Usually we'd get a thunk for (f 4), but not with -XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.   
> 
> If you compile M2 with -XStrict, function f won't build thunks for (n+1), (n-1) but will evaluate them instead.
> 
> If you compile M1 with StrictData, then C is made strict, so again M2 will build no thunks even if M2 was compiled without -XStrict.
> 
> I quite like this design.  It's not clear to me that anything useful is gained by forcing y and z in M3 before evaluating the body "...".
> 
> 
> So Roman's design makes sense, but so does the implemented design (modulo any bugs).  The trouble is that the implemented design is not well described.
> 
> Simon
> 
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Roman
> | Cheplyaka
> | Sent: 11 December 2015 12:57
> | To: Johan Tibell <johan.tibell at gmail.com>
> | Cc: ghc-devs at haskell.org
> | Subject: Re: -XStrict: Why some binders are not made strict?
> | 
> | On 12/11/2015 02:21 PM, Johan Tibell wrote:
> | > If we force strictness all the way down it's not really call-by-value
> | > either, because the caller doesn't know what to evaluate (I think).
> | 
> | Not sure what you mean here.
> | 
> | > In addition, making pattern matching strict in this way makes it hard to
> | > mix and match strict and lazy data types (e.g. Maybe), because using a
> | > lazy data type from another module will make it appear strict in your
> | > code (hurting modularity).
> | 
> | I don't think this is a case about modularity. A lazy Maybe value
> | defined in a lazy module remains lazy; and you can pass it to lazy
> | functions without forcing it. Only when you pattern match on it *in the
> | strict module*, the evaluation happens.
> | 
> | As I said, I prefer this semantics mainly because it's easier to
> | explain: all variables (and underscores) bound in a strict module refer
> | to WHNF values. Do you have a similarly simple explanation for the
> | semantics you're suggesting?
> | 
> | Roman
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151212/9fe24416/attachment.sig>

From eric at seidel.io  Sat Dec 12 00:01:06 2015
From: eric at seidel.io (Eric Seidel)
Date: Fri, 11 Dec 2015 16:01:06 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <CACOpX0eCMfUY333X6P1S=hrt-MX3BhvBSXXRundCDdaXn7BnVg@mail.gmail.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
 <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
 <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>
 <1449875593.4157693.465081409.2E54C6BE@webmail.messagingengine.com>
 <CACOpX0eCMfUY333X6P1S=hrt-MX3BhvBSXXRundCDdaXn7BnVg@mail.gmail.com>
Message-ID: <1449878466.4166601.465099465.6BE76EA3@webmail.messagingengine.com>

On Fri, Dec 11, 2015, at 15:28, Levent Erkok wrote:
> My "hidden agenda" is to liberate the SBV library to work on Haskell
> programs directly. (http://hackage.haskell.org/package/sbv)
> 

So the idea is to translate a Haskell expression to an SBV symbolic
expression, which you can then ship off to a solver? That's a perfectly
good reason to use Core instead of TH :) Though it's not clear to me why
you need to generate Core if your main concern is proving things (I
guess the question is whether you want the proving to happen at
compile-time or run-time).

> I tried TH/HSE before to see if I can let users write regular-Haskell and
> have the expressions automatically made "symbolic" aware, but ran into a
> lot of accidental complexity due to the extremely rich surface syntax.
> I'm
> currently working on a plugin to do the same, which is much nicer to work
> with; though you are correct that dealing with explicitly-typed core has
> its complexities as well. However, I do find it to be much easier to work
> with as compared to surface Haskell.

The best advice I've received wrt generating Core is to generate as
little as possible, and to make the generated Core as monomorphic as
possible (thanks to Iavor for the advice!). This is actually not that
hard to do; the trick is to write a library of helper functions that do
everything you need, compile that library normally with GHC, and then
generate Core that just calls the library functions. You probably
already have all the library functions you need in SBV!

> I suspect you guys went down to the "stand-alone" route with
> LiquidHaskell
> when you had similar problems. That definitely is a great approach as
> well,
> though I don't have the luxury of an academic research team to pursue
> that
> line of thought. (LiquidHaskell rocks by the way; I'm a real fan.)

LiquidHaskell uses GHC as a front-end, we extract the Core from GHC and
perform our type-checking on the Core. In theory we could be a Core
plugin, but there are some engineering issues that we haven't worked out
yet. Luckily we just *analyze* the Core, we don't try to produce any
Core of our own, so the explicit typing hardly affects us at all. 

(I'm a big fan of SBV too)

Eric

From erkokl at gmail.com  Sat Dec 12 00:26:38 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Fri, 11 Dec 2015 16:26:38 -0800
Subject: A comment on Introspective-Haskell
In-Reply-To: <1449878466.4166601.465099465.6BE76EA3@webmail.messagingengine.com>
References: <CACOpX0chYt5uPXyL56raLWYtk8hG+vi=WtVMER339O1wF3d4NA@mail.gmail.com>
 <CA+CkF222BL7hfWP8XDdMu+997P9QC6mbpYsDOpLSWP1d8giqHw@mail.gmail.com>
 <CACOpX0c8BUPBVWV1LhPhyrCN+SiaUOoG9hWGnH2Nyx65gCKuLQ@mail.gmail.com>
 <B93348AA-BA60-4D07-98C5-E78BBF0F1C55@cis.upenn.edu>
 <CACOpX0f5RoMh861ZDABe8QG7Dyb+FCs2X7mBcC3CTwbSmFAr-w@mail.gmail.com>
 <1449875593.4157693.465081409.2E54C6BE@webmail.messagingengine.com>
 <CACOpX0eCMfUY333X6P1S=hrt-MX3BhvBSXXRundCDdaXn7BnVg@mail.gmail.com>
 <1449878466.4166601.465099465.6BE76EA3@webmail.messagingengine.com>
Message-ID: <CACOpX0eAnaL7JDSrvrrRfXenv9AAcnp1yd0K0j7dU0i-fveYBA@mail.gmail.com>

Precisely.. If all goes well, one will be able to say:

import Data.SBV.Plugin {-# ANN f theorem #-}f :: Double -> Double -> Double
-> Boolf x y z = x + (y + z) == (x + y) + z
And have that theorem proven at "compile" time. (Of course, the above is
actually not true, so the user will get a counter-example and compilation
will abort.)

I've got this *mostly* working from a plugin, but it needs a ton more
polishing before it can be released to the wild. Here's the repo, though
it's in a constant state of flux for the time being and is in nowhere near
sufficient quality for a more public announcement:
http://github.com/LeventErkok/sbvPlugin/

-Levent.

On Fri, Dec 11, 2015 at 4:01 PM, Eric Seidel <eric at seidel.io> wrote:

> On Fri, Dec 11, 2015, at 15:28, Levent Erkok wrote:
> > My "hidden agenda" is to liberate the SBV library to work on Haskell
> > programs directly. (http://hackage.haskell.org/package/sbv)
> >
>
> So the idea is to translate a Haskell expression to an SBV symbolic
> expression, which you can then ship off to a solver? That's a perfectly
> good reason to use Core instead of TH :) Though it's not clear to me why
> you need to generate Core if your main concern is proving things (I
> guess the question is whether you want the proving to happen at
> compile-time or run-time).
>
> > I tried TH/HSE before to see if I can let users write regular-Haskell and
> > have the expressions automatically made "symbolic" aware, but ran into a
> > lot of accidental complexity due to the extremely rich surface syntax.
> > I'm
> > currently working on a plugin to do the same, which is much nicer to work
> > with; though you are correct that dealing with explicitly-typed core has
> > its complexities as well. However, I do find it to be much easier to work
> > with as compared to surface Haskell.
>
> The best advice I've received wrt generating Core is to generate as
> little as possible, and to make the generated Core as monomorphic as
> possible (thanks to Iavor for the advice!). This is actually not that
> hard to do; the trick is to write a library of helper functions that do
> everything you need, compile that library normally with GHC, and then
> generate Core that just calls the library functions. You probably
> already have all the library functions you need in SBV!
>
> > I suspect you guys went down to the "stand-alone" route with
> > LiquidHaskell
> > when you had similar problems. That definitely is a great approach as
> > well,
> > though I don't have the luxury of an academic research team to pursue
> > that
> > line of thought. (LiquidHaskell rocks by the way; I'm a real fan.)
>
> LiquidHaskell uses GHC as a front-end, we extract the Core from GHC and
> perform our type-checking on the Core. In theory we could be a Core
> plugin, but there are some engineering issues that we haven't worked out
> yet. Luckily we just *analyze* the Core, we don't try to produce any
> Core of our own, so the explicit typing hardly affects us at all.
>
> (I'm a big fan of SBV too)
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151211/1566f2a7/attachment-0001.html>

From eir at cis.upenn.edu  Sat Dec 12 03:19:35 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Dec 2015 22:19:35 -0500
Subject: kind inference (#11203)
In-Reply-To: <1DF5C03D-571F-4CC8-8B11-4608CD6AB58A@cis.upenn.edu>
References: <1DF5C03D-571F-4CC8-8B11-4608CD6AB58A@cis.upenn.edu>
Message-ID: <07CFB1DB-E471-4C77-AB5E-1C329F44CB6C@cis.upenn.edu>

Actually, I think I know how to fix the problem with (3) and (4), by unifying the kinds in any KindedTyVars in the tycon's LHsQTyVars with the tyvar kinds in the tycon's kind. I have some preliminary code toward this, and should return to the problem early next week.

(2), on the other hand, is a bit of a mystery how to solve.

Richard

On Dec 11, 2015, at 4:43 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi Simon and other devs,
> 
> I struggled a bit today with some issues around kind inference that I wanted to write down.
> 
> Here are some illuminating test cases, explained below:
> 
> -- useful definition:
> data SameKind :: k -> k -> *
> 
> 1.
> data T (a :: k1) x = MkT (S a ())
> data S (b :: k2) y = MkS (T b ())
> 
> 2.
> data Q (a :: k1) (b :: k2) c = MkQ (SameKind a b)
> 
> 3.
> data D1 = MkD1 (forall p (a :: k). p a -> Int)
> 
> 4.
> data D2 a b = MkD2 (Proxy (a :: Maybe k)) | MkD3 (Proxy (b :: [k])
> 
> 
> (1) should be accepted. But this is rather hard to arrange for, because T and S do not have CUSKs. Their kinds are generalized only after checking the mutually-recursive group. So, to accept this pair, we need to use SigTvs for k1 and k2, to allow them to unify with each other. (This works today.)
> 
> (2) should be rejected. But it is currently accepted, because k1 and k2 are SigTvs, and so they unify with each other.
> 
> (3) should be rejected. I have no idea where that k should be bound. Previously, the k was bound in the forall, but after the wildcards-refactor patch, that's no longer possible. (This is taken from test case ghci/scripts/T7873. HEAD accepts this definition, but produces a bogus tycon.) Note that this was accepted correctly before the wildcards-refactor.
> 
> (4) should be accepted. This demonstrates that k can be introduced in constructors but scopes over the entire definition. The difference with case (3) is that (4) has type variables whose kinds mention k, whereas (3) does not.
> 
> How should we arrange for all of this behavior? As stated in #11203, I think the use of SigTvs in PolyKinds is highly suspect. I have no good ideas here, though.
> 
> In case (3), k ends up in the hsq_kvs (soon to be renamed to hsq_implicit) field of the HsQTyVars for D1. After kind inference, I've written a check to make sure k appears free in the kind of a tyvar. That works. The problem is that the check also snags cases (1) and (2): my check uses the name from the LHsQTyVars, and with SigTvs in the mix, (1) and (2) end up with kind variables with names different from the names in the LHsQTyVars.
> 
> I'm sure there's some way to disentangle all of this, but I've given it a rest for now. This hit me in the fact that performance test case T9872d is like case (1), and the SigTvs threw my check off. But removing it caused problems elsewhere.
> 
> I'd enjoy discussing next week.
> 
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From roma at ro-che.info  Sat Dec 12 16:32:01 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 12 Dec 2015 18:32:01 +0200
Subject: User manual sub-sections
In-Reply-To: <87fuzdosle.fsf@smart-cactus.org>
References: <8d4f2e8afbd64ef08e332ae0082c1c51@DB4PR30MB030.064d.mgd.msft.net>
 <87fuzdosle.fsf@smart-cactus.org>
Message-ID: <566C4C01.9020401@ro-che.info>

On 12/08/2015 05:41 PM, Ben Gamari wrote:
> Simon Peyton Jones <simonpj at microsoft.com> writes:
> 
>> Ben, Austin,
>> Could we see the sub-sub-sections of the user manual in the table of contents
>> http://downloads.haskell.org/~ghc/master/users-guide/
>> The section titles are often very helpful.  C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html
>>
> If you look at http://downloads.haskell.org/~ghc/master/users-guide//
> you'll find that sub-sub-sections are now shown. Unfortunately it looks
> quite cluttered now. I feel like it is now quite easy to get lost in the
> forest while scanning for your desired section. Perhaps it would make
> sense to make the sub-sections expandable but collapsed by default?
> Opinions?

I like it.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151212/0ee8a9f6/attachment.sig>

From eir at cis.upenn.edu  Sat Dec 12 21:23:32 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 12 Dec 2015 16:23:32 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
Message-ID: <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>

Here's a thought: is there a way you can tell when you're in a bad case? There's surely one easy way: just count how many times your algorithm goes around. But perhaps you can do better, by looking for lots of guards, etc. My idea would be to enable guard checking by default, but to bail when the going gets tough. Bailing could issue a warning that such-and-such a function/case/multi-way-if is too ornate to be checked performantly. The user could then specify `-fno-warn-incomplete-pattern-guards` to turn off pattern-guard checking, `-fno-warn-ornate-guards` simply to disable the warning in the too-tough-to-handle case (but still check other guards in the module), or `-fwarn-incomplete-pattern-guards-at-any-cost` to instruct the check simply to work harder. Thus, pattern-guard checking would be enabled by default, but we would be protected from requiring 10GB of memory to compile a module.

I was inspired by the fact that I would be tempted to enable pattern-guard checking by default in my own code, even if the check is non-performant. Then, in years' time, I would have a module that inexplicably takes forever to compile and forget to look here. The design above lets me have my cake and eat it too -- that is, to have my code checked but not worry about surprising compilation times.

What do you think?

Richard

On Dec 12, 2015, at 1:05 PM, George Karachalias <george.karachalias at gmail.com> wrote:

> 
> 
> On Sat, Dec 12, 2015 at 12:01 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> `f` will generate an empty uncovered set while g will generate:
> 
> uncovered =
> 
>   { x |> { x ~ [], x ~ (_:_) }
> 
>   , x |> { x ~ (_:_), x ~ [] } }
> 
>  
> 
> which is also semantically empty but this cannot be detected until we call the
> 
> term oracle on it to see the inconsistency.
> 
>  
> 
> So, why not call the term oracle more aggressively (at every node of the tree), to prune empty sets?  It should not be hard to spot common cases; in what you show above it?s very easy.
> 
> 
> Yes, we've been tempted to do this before but it didn't work. Since the sets can be really
> big, we have relied on laziness a lot to save space and time. By calling the oracle more
> often we will evaluate more eagerly parts of the sets which may lead to more space leaks.
> 
> Additionally, in my reply for #11195 (https://ghc.haskell.org/trac/ghc/ticket/11195#comment:4)
> you can find another example for which solving the constraints eagerly does not necessarily
> improve the situation. Sometimes the sets are big and consistent. So checking eagerly does
> not actually prune anything. I can see now that my `f` and `g` above were bad examples for this.
> 
> Last but not least, the term oracle is not the most performant part of the checker. I would
> certainly avoid calling it more often than we already do.
> 
> Nevertheless, I do not want to drop the work we have done on pattern guards either so I
> think that the flag solution is a very good and realistic option for now. If we really manage to
> find a nice way to do better we can always update the code which will not be removed from
> GHC. I will certainly keep thinking about it :)
> 
> George
> 
> -- 
> things you own end up owning you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151212/f2f9ba1a/attachment.html>

From ben at well-typed.com  Mon Dec 14 13:38:43 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 14 Dec 2015 14:38:43 +0100
Subject: GHC 8.0 feature freeze imminent
Message-ID: <8737v5i1zw.fsf@smart-cactus.org>

Hello GHCers,

Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in
`master`. Being one of the defining features of the 8.0 release, we bent
the feature freeze schedule (initially slated for sometime last week) a
bit to accomodate this piece of work.

Now that Richard's work is in, we will set the official freeze date for
Monday December 21st so that there is time to review and merge some
queued work which we've been queuing for after the no-kinds merge. If
you have work still outstanding then you should talk to either me or
Austin ASAP if you have not done so already. We will be discussing the
release schedule for 8.0 during the GHC today.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/d8f20006/attachment.sig>

From edzhavoronkov at gmail.com  Mon Dec 14 13:52:06 2015
From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=)
Date: Mon, 14 Dec 2015 16:52:06 +0300
Subject: Warning suppression pragmas
In-Reply-To: <87si3j3ex8.fsf@smart-cactus.org>
References: <CAEvjXHSLBCtwx8UHe9vO62MYotU01Exm7bZNNh-VgrqBKytmpw@mail.gmail.com>
 <87si3j3ex8.fsf@smart-cactus.org>
Message-ID: <CAEvjXHT_vjsuJtfxj4xdcroCVAV9VuUfubQpjbtAL7EkWoWOrQ@mail.gmail.com>

Hi devs!

I edited wiki page [1] with my proposal about more than week ago. The main
idea is that we mark functins with pragma and filter all warnings that it
will throw. Although it is the question of bad design, i think users, who
have to support old libraries will find this helpful.

I don't know about suppressing specific kinds of warnings. I think, that it
would be more precise to filter them in one place instead of many.

Can someone review it? Sorry for bothering, if any

[1] - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas

---
? ?????????,
?????????? ?????

Best regards,
Edgar A. Zhavoronkov

2015-12-03 15:16 GMT+03:00 Ben Gamari <ben at smart-cactus.org>:

> ????? ?????????? <edzhavoronkov at gmail.com> writes:
>
> > Hello devs!
> >
> > I am trying to implement some kind of local warnings suppresion and i
> need
> > some help.
> >
> > I want to use a pragma to mark functions so compiler won't throw warnings
> > from them. I defined my pragma in lexer, parser and added type signature
> in
> > HsBinds.hs. And i am stuck. I don't know what to do. What should i
> consider
> > doing further?
> >
> I think it would be helpful to focus on further elaborating the
> specification before we move into the implementation. There are still a
> number of open questions about the design that the wiki page doesn't yet
> address.
>
> For instance, you should explicitly specify,
>
>  * What are the identifiers that appear after the `SUPPRESS` token?
>
>  * What exactly does the pragma apply to? For instance, if I have a case
>    like,
>
>        hello :: Int -> Int
>        {-# SUPPRESS some-warning #-}
>        helloAgain :: Type -> AnotherType
>        hello = (+1)
>        helloAgain = error "42"
>
>    or even just
>        hello = (+1)
>        {-# SUPPRESS another-warning #-}
>        helloAgain = error "oops"
>
>    What do you expect to happen? The behavior of the pragma in both of
>    these cases should be unambiguously stated in the specification.
>
>  * An concrete use-case motivating the change (preferably with examples
>    showing how the proposed syntax would address the motivation)
>
> I know this sounds repetitive, but the act of writing down a proposal
> will help you immensely when you do move on to implementing your ideas.
>
> Thanks for your persistence.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/a5906475/attachment.html>

From eir at cis.upenn.edu  Mon Dec 14 14:03:23 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 14 Dec 2015 09:03:23 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
Message-ID: <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>


On Dec 13, 2015, at 1:07 PM, George Karachalias <george.karachalias at gmail.com> wrote:

> Sounds nice and I think it is much better than giving up guards completely. The only thing I
> don't like much is having so many different flags concerning the check because I don't want
> it to become "too complex" for users. I guess we have to live with it though :)

Yes. I'd like this to be simpler. Perhaps there is a way to combine all of this into one flag. I see 4 settings:

1. No guard match checking.
2. Check guards; bail and issue warning on tough cases.
3. Check guards; bail with no warning on tough cases.
4. Check guards at any cost.

We could have these be

1. -fwarn-pattern-guards=none
2. -fwarn-pattern-guards=try
3. -fwarn-pattern-guards=try-quiet
4. -fwarn-pattern-guards=do   -- there is no "try"

Is that simpler? Maybe.

Richard

From eir at cis.upenn.edu  Mon Dec 14 14:34:41 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 14 Dec 2015 09:34:41 -0500
Subject: Remaining type=kind items
In-Reply-To: <874mfli2af.fsf@smart-cactus.org>
References: <874mfli2af.fsf@smart-cactus.org>
Message-ID: <4E1037F2-1367-4B0F-BA5F-2D741B54B5C4@cis.upenn.edu>

Yes -- these are very much on the TODO list.

Sadly, visible type application didn't make it. It could with another two weeks(?), but I don't think it's worth holding things up further. Unlike D808, visible type application doesn't touch wide swaths of code, so merging it after the ghc-8.0 branch won't cause backporting trouble.

I plan on writing a longish section in the user manual about GHC's kind system, updating the PolyKinds discussion already there. Should happen this week.

Richard

On Dec 14, 2015, at 8:32 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Hi Richard!
> 
> This is probably on your to-do list, but here are a few
> places where I think the no-kinds work could use some documentation,
> 
>    - the introduction of kind equalities could use a brief note in the
>      release notes
> 
>    - visible type application should be mentioned in the release notes
>      (this made it in, right?)
> 
>    - visible type application syntax should be described in the users
>      guide
> 
>    - `-XTypeInType` needs some discussion in the users guide. Be sure
>      to mention the fact that `*` needs to be imported explicitly and
>      state precisely how one would do this (since it is a symbol)
> 
>    - the notion of levity could use a bit of discussion in the users
>      guide
> 
> Cheers,
> 
> - Ben


From eir at cis.upenn.edu  Mon Dec 14 14:44:08 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 14 Dec 2015 09:44:08 -0500
Subject: Warning suppression pragmas
In-Reply-To: <CAEvjXHT_vjsuJtfxj4xdcroCVAV9VuUfubQpjbtAL7EkWoWOrQ@mail.gmail.com>
References: <CAEvjXHSLBCtwx8UHe9vO62MYotU01Exm7bZNNh-VgrqBKytmpw@mail.gmail.com>
 <87si3j3ex8.fsf@smart-cactus.org>
 <CAEvjXHT_vjsuJtfxj4xdcroCVAV9VuUfubQpjbtAL7EkWoWOrQ@mail.gmail.com>
Message-ID: <D78AFF60-78A3-4EB4-B29D-7B1C4C7DE84B@cis.upenn.edu>

This proposal is a good start, but it needs more fleshing out.

- What scopes are allowed to suppress over? For example, is it possible to suppress warnings for scopes other than a function (for example, within a case expression)? What about type declarations? Local declarations? In a type signature?

- Is there a way to control what warnings are suppressed? Presumably, a user would like to suppress only certain warnings in certain places.

- Your proposal contains motivation and examples. These are necessary parts of a proposal. But we also need a full specification of the feature, describing precisely the syntax (where, exactly, `SUPPRESS` is allowed) and semantics.

I hope this feedback is helpful!
Richard

On Dec 14, 2015, at 8:52 AM, ????? ?????????? <edzhavoronkov at gmail.com> wrote:

> Hi devs!
> 
> I edited wiki page [1] with my proposal about more than week ago. The main idea is that we mark functins with pragma and filter all warnings that it will throw. Although it is the question of bad design, i think users, who have to support old libraries will find this helpful.
> 
> I don't know about suppressing specific kinds of warnings. I think, that it would be more precise to filter them in one place instead of many.
> 
> Can someone review it? Sorry for bothering, if any
> 
> [1] - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas
> 
> ---
> ? ?????????,
> ?????????? ?????
> 
> Best regards,
> Edgar A. Zhavoronkov
> 
> 2015-12-03 15:16 GMT+03:00 Ben Gamari <ben at smart-cactus.org>:
> ????? ?????????? <edzhavoronkov at gmail.com> writes:
> 
> > Hello devs!
> >
> > I am trying to implement some kind of local warnings suppresion and i need
> > some help.
> >
> > I want to use a pragma to mark functions so compiler won't throw warnings
> > from them. I defined my pragma in lexer, parser and added type signature in
> > HsBinds.hs. And i am stuck. I don't know what to do. What should i consider
> > doing further?
> >
> I think it would be helpful to focus on further elaborating the
> specification before we move into the implementation. There are still a
> number of open questions about the design that the wiki page doesn't yet
> address.
> 
> For instance, you should explicitly specify,
> 
>  * What are the identifiers that appear after the `SUPPRESS` token?
> 
>  * What exactly does the pragma apply to? For instance, if I have a case
>    like,
> 
>        hello :: Int -> Int
>        {-# SUPPRESS some-warning #-}
>        helloAgain :: Type -> AnotherType
>        hello = (+1)
>        helloAgain = error "42"
> 
>    or even just
>        hello = (+1)
>        {-# SUPPRESS another-warning #-}
>        helloAgain = error "oops"
> 
>    What do you expect to happen? The behavior of the pragma in both of
>    these cases should be unambiguously stated in the specification.
> 
>  * An concrete use-case motivating the change (preferably with examples
>    showing how the proposed syntax would address the motivation)
> 
> I know this sounds repetitive, but the act of writing down a proposal
> will help you immensely when you do move on to implementing your ideas.
> 
> Thanks for your persistence.
> 
> Cheers,
> 
> - Ben
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/b1a23b94/attachment.html>

From spitzenb at fim.uni-passau.de  Mon Dec 14 17:16:30 2015
From: spitzenb at fim.uni-passau.de (David Spitzenberg)
Date: Mon, 14 Dec 2015 18:16:30 +0100
Subject: Questions concerning the LLVM backend - i.e. 'proc point
 splitting'
In-Reply-To: <566D6721.9050500@fim.uni-passau.de>
References: <566D6721.9050500@fim.uni-passau.de>
Message-ID: <566EF96E.2010302@fim.uni-passau.de>

Simon

> |  Could you explain the need of further info-tables for 'inner'
> |  proc-points (those, which are not the entry-block of a function) to
> |  me, please?
> 
> The main purpose of inner info tables is this.  Given (case e of blah) we push a return address (for 'blah') on the stack and evaluate 'e'.  During evaluation of 'e', garbage collection may take place.  So the garbage collector needs to walk the stack to follow live pointers.  Who knows what pointers are live?  Answer: the code for 'blah' clearly knows what pointers are alive in the current stack frame, because it is going to access them.  So the return address gets an info table that makes that implicit knowledge explicit, as a bitmap describing the liveness/pointer-hood of the stack frame.
> 
> Addresses that are only jumped to don?t need info tables.
> 
> It would be great if, as you learn about this stuff, you could add to the Commentary
> https://ghc.haskell.org/trac/ghc/wiki/Commentary
> to capture what you have learned.

Thank you very much! In cases I find the current description imprecise
or incomplete I can add what I've learned to the Commentary of course.

> |  The documentation states, that proc-point splitting is only required
> |  by the LLVM backend (see [2]). Does the cmm-pipeline perform proc-
> |  point splitting even when using the native code generator?
> 
> I'm not certain, but I don't think so.
> 
> |  As stated above, the major problem of LLVM seems to be inferring
> |  control flow when it comes to call proc-points. As it's hard to avoid
> |  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the
> 
> I regard the whole proc-point thing as a major wart.  I think we should work hard to eliminate it.  So: another line of thought might be: how could we influence LLVM so that we didn't need proc-point splitting?

I totally agree with you here. However, determining how LLVM needs to be
influenced to eliminate proc-point splitting is a thing I won't be
capable of doing mid term because of my current knowledge and lack of time.

> |  To make control flow more apparent to LLVM, they came up with the
> |  following idea. Remark before showing the idea: I know that it greatly
> 
> I'm sorry to say that I didn't really understand the idea.  Maybe someone else did?  David Terei?

My apologies for being imprecise. I hope to find the time to
work out a little demonstration during the upcoming holidays. I'm
currently fully occupied by university because of upcoming exams this week.

> If you are seriously about investing effort in the back end, I'd be happy to help; in that case a Skype call is probably the best way.

That is a great idea. Due to the above mentioned time constraints I
propose that we follow up in January.

Regards,

David





> Simon
> 
> |  interferes with CPS. It leaves parts of the continuation-handling to
> |  the implicit LLVM call-stack. Further, this does not solve the problem
> |  of proc-point splitting at all. It is more a workaround than a
> |  solution.
> |  But it would greatly increase LLVM's possibilities to optimize code
> |  later on. That's why I found this idea worth mentioning. Especially
> |  because after reading your answer, Ben, I'm somewhat convinced that
> |  solving the problem of proc-point splitting is nearly impossible with
> |  the capabilities of LLVM IR available at the moment. Now back to the
> |  idea.
> |  
> |  As stated above, the major problem of LLVM seems to be inferring
> |  control flow when it comes to call proc-points. As it's hard to avoid
> |  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the
> |  code, llvmGen produces when it comes to call proc-points instead. All
> |  other types of proc-points remain unchanged.
> |  
> |  Initial situation in pseudo cmm:
> |  
> |  foo() {
> |  ...
> |  call bar() returns to cont // bar defined externally
> |  
> |  cont:
> |  ...
> |  }
> |  
> |  After proc-point splitting, this is converted into LLVM IR similar to
> |  the following:
> |  
> |  @foo() {
> |  ...
> |  store @cont(), %Sp ; push continuation on the stack tail call @bar() ;
> |  @bar defined externally }
> |  
> |  @cont() {
> |  ...
> |  }
> |  
> |  To fix the above issue, we introduce a method, which restores the
> |  pointers Sp, Hp and the register R1 (among everything else, what has
> |  to be restored) and 'fakes' the continuation. Note, that '@restore'
> |  returns without calling into the continuation. This way, the call into
> |  the continuation can be made direct. The above code would be
> |  transformed into something similar to the following:
> |  
> |  @foo() {
> |  ...
> |  store @restore(), %Sp ; 'fake' continuation call @bar() ; br label
> |  restore
> |  
> |  restore:
> |  %Sp = load (getelementptr @environment 0, 0) ; restore what has to be
> |  ... ; restored tail call @cont() }
> |  
> |  @cont() {
> |  ...
> |  }
> |  
> |  @restore(%Sp, %Hp, %R1, ...) {
> |  store %Sp, (getelementptr @environment 0, 0) ; store everything into
> |  ... ; global variable ret void }
> |  
> |  @environment ; structure of type similar to {i64*, i64*, i64*, i64,
> |  i64, ..}
> |  
> |  As an alternative, the above transformation could be done by a LLVM
> |  pass. llvmGen could then annotate the continuation of calls call cite.
> |  This would greatly simplify the detection of the correct continuation.
> |  
> |  What do you think about this idea? Especially when thinking about the
> |  interference with CPS?
> |  
> |  Regards,
> |  
> |  David
> |  
> |  
> |  
> |  
> |  [1]
> |  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCod
> |  e#Importantconceptsinthemachine
> |  
> |  [2]
> |  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeGen#Seco
> |  ndstage:theCmmpipeline
> |  
> |  
> |  
> |  
> |  On 11/21/2015 12:00 AM, Ben Gamari wrote:
> |  > Simon Peyton Jones <simonpj at microsoft.com> writes:
> |  >
> |  >> David
> |  >>
> |  >> All this stuff is terribly paged-out for me. But I'd love someone
> |  to
> |  >> pay attention to some of this back-end stuff, so if you'd like to
> |  >> work there, I'd like to help you.
> |  >>
> |  >> David Terei was also thinking of getting rid of proc point
> |  splitting
> |  >> for LLVM (see attached email and the notes attached to it)
> |  >>
> |  >> Simon Marlow also was thinking about this; see his attached email.
> |  >>
> |  >> The main *reason* for establishing a proc-point is so that, when
> |  >> generating C code (which we don't do any more) you can take its
> |  >> address. E.g.
> |  >>
> |  >> foo() { ... Push &bar onto the stack (effectively a return address)
> |  >>   Jump to thingumpy }
> |  >>
> |  >> bar() { ... }
> |  >>
> |  >> Really bar is part of foo, but we have make it a separate top level
> |  >> thing so that we can take the address of bar and push it on the
> |  stack.
> |  >>
> |  >> The trouble is that if there is a label inside bar that foo wants
> |  to
> |  >> jump to (i.e. without pushing &bar etc) then we have to make that
> |  >> label too into a proc-point, so that both foo and bar can see it.
> |  >> Urgh.
> |  >>
> |  >> In LLVM this probably is not true; presumably you can take the
> |  >> address of any label?
> |  >>
> |  > This is true. While labels themselves have function-local scope in
> |  > LLVM, there is an expression, `blockaddress`, which allows you to
> |  take
> |  > an address to a label in another function [1]. That being said, in
> |  > reading through the documentation it's not at all clear to me that
> |  it
> |  > would be safe to jump to such an address. In fact, given that the
> |  > instruction that this expression is supposed to be used with,
> |  > `indirectbr`, can only be used for local blocks, I suspect it is
> |  not.
> |  > More information about this feature can be found here [2].
> |  >
> |  > The jump issue aside, I don't know how you would deal with
> |  > tables-next-to-code. The prefix data support that currently
> |  available
> |  > in LLVM is attached to functions and I unfortunately don't see that
> |  > changing any time soon.
> |  >
> |  > Ultimately it seems that trying to refer to labels defined in other
> |  > functions is using LLVM against the way it was intended. One
> |  > alternative would be to teach llvmGen to merge mutually recusive
> |  > top-level functions into a single LLVM function during code
> |  > generation. Otherwise I'm afraid you are stuck with either the
> |  status
> |  > quo or attempting to improve on LLVM's own cross-procedure
> |  optimization ability.
> |  >
> |  > That being said, it sounds as though eliminating proc-point
> |  splitting
> |  > would make for quite a nice project in the native code generator.
> |  >
> |  > Cheers,
> |  >
> |  > - Ben
> |  >
> |  >
> |  > [1]
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
> |  > rg%2fdocs%2fLangRef.html%23addresses-of-basic-
> |  blocks&data=01%7c01%7csi
> |  >
> |  monpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72
> |  >
> |  f988bf86f141af91ab2d7cd011db47%7c1&sdata=nKVLgmZezUdEYL%2fma1exMMPLbcT
> |  > RkaE1JrvVaR1EesY%3d [2]
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblog.l
> |  > lvm.org%2f2010%2f01%2faddress-of-label-and-indirect-
> |  branches.html&data
> |  >
> |  =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2
> |  >
> |  f74448f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BTMdZESwYS4tZa5W
> |  > sOAqyFutoI5xNNFDe0b%2bdKC3ODs%3d [3]
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
> |  > rg%2fdocs%2fLangRef.html%23prefix-
> |  data&data=01%7c01%7csimonpj%40064d.m
> |  >
> |  gd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72f988bf86f141af
> |  >
> |  91ab2d7cd011db47%7c1&sdata=rdo4ZLjjE%2bWxNykVL%2bSuToWioY6nzQpflSk296E
> |  > 8W70%3d
> |  >
> 



From ryan.gl.scott at gmail.com  Mon Dec 14 17:38:39 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 14 Dec 2015 09:38:39 -0800
Subject: GHC 8.0 feature freeze imminent
Message-ID: <CADdQpRAWp4Wb3ugPYwWr0gyurz2FDc+qfK0ZV2Z9gBp2L8teaw@mail.gmail.com>

One thing I definitely want to get in before the 8.0 release is:

* A fix for Trac #10716 [1] (adding strictness metadata to GHC
generics). This feels like a natural counterpart for Trac #10697 [2]
(reworking strictness information to Template Haskell), which
currently has a Phab Diff in review [3]. I'd like for these to be
released at the same time so that I can use Template Haskell to
backport the machinery in generic-deriving [4]. In addition, I
realized that my encoding of selector metadata is not very extensible
at the moment, and this would give me a good excuse to fix it.

Some things that I probably won't get in time for 8.0:

* Automatic derivation of Bifunctor/Bifoldable/Bitraversable, and of
Eq1/Eq2/Ord1/Ord2/Read1/Read2/Show1/Show2. These would require
resolving Trac #10448 [5] and #11135 [6] first, which might need more
discussion. Not only that, but I still need to write up a proposal for
how each of these classes would be derived, and there would need to be
additional discussion on those points... All in all, it doesn't sound
like something I could do in two weeks :)
* Making Generic1 kind-polymorphic, Trac #10604 [7]. The first step to
achieving this was done recently [8], but unfortunately, I wasn't able
to make the actual datatypes in GHC.Generics kind-polymorphic for
unknown reasons (I'd still like to talk to Richard Eisenberg about
this at some point). Not only that, but I'm not sure what the
implications of making Generic1 poly-kinded would be yet. I'd like to
talk to Andres L?h about this.

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/10716
[2] https://ghc.haskell.org/trac/ghc/ticket/10697
[3] https://phabricator.haskell.org/D1605
[4] http://hackage.haskell.org/package/generic-deriving
[5] https://ghc.haskell.org/trac/ghc/ticket/10448
[6] https://ghc.haskell.org/trac/ghc/ticket/11135
[7] https://ghc.haskell.org/trac/ghc/ticket/10604
[8] https://ghc.haskell.org/trac/ghc/ticket/10775

From dluposchainsky at googlemail.com  Mon Dec 14 17:43:03 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Mon, 14 Dec 2015 18:43:03 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <8737v5i1zw.fsf@smart-cactus.org>
References: <8737v5i1zw.fsf@smart-cactus.org>
Message-ID: <566EFFA7.8040805@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14.12.2015 14:38, Ben Gamari wrote:
> If you have work still outstanding then you should talk to either me or
> Austin ASAP if you have not done so already.

The addition of the -W warning syntax [1] is on its way [2]. Unfortunatly, the
- -Werror=... feature and improved warning messages [3] are out of scope for this
release.

David/quchen

[1]: https://ghc.haskell.org/trac/ghc/ticket/11218
[2]: https://phabricator.haskell.org/D1613
[3]: https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings#ProposedChange
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWbv+nAAoJELrQsaT5WQUs4o0H/2ZLyzAOA6wzY1E61ImrbcRx
iKszVak92nswExdojdHD9IBmcl0Z3ekwGzIwEymwTL/G6xMMu3z2SdZKivqKhyPe
T0yPGj6Ryua8qoA20Z8QTfb1KsVlGQDJBDrAk6zcwscoBSsoxzMKPqcJuvyYNdmK
FElDbklcUEX/JWAFWXEWoUo2eg/5RD9noa1RYDdtPRLYeiNk049SQJTSgC1ORtHW
8iUqRV1EzL2ahM5NM1U1CkLGTHduI2SOYSS3GC7sHGBxnA3HOLBk+baGxeMcyxOs
4J8f9RREYHKo+HSRAhWjdZqOUdKTKLrHS0sQGbUC0Xg+9zWhhqH3UX3K73jKjRI=
=BDQB
-----END PGP SIGNATURE-----

From adam at sandbergericsson.se  Mon Dec 14 17:50:27 2015
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Mon, 14 Dec 2015 18:50:27 +0100
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <566B6281.7060502@ro-che.info>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
 <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
 <566B6281.7060502@ro-che.info>
Message-ID: <1450115427.3319700.467146145.4987568B@webmail.messagingengine.com>

Hello,

Given the upcoming 8.0 feature freeze I think the correct approach for
8.0 is to document the current implementation (I'll try to do that this
week).

It would probably be good if interested parties would document their
input in a ticket.

Cheers,
--Adam


On Sat, 12 Dec 2015, at 12:55 AM, Roman Cheplyaka wrote:
> Thanks Simon, this is an interesting and compelling interpretation. But
> I'm wondering whether it is enough to specify the dynamic semantics
> unambiguously.
> 
> Two examples:
> 
> 1.
> 
>   let _ = undefined in ()
> 
> Intuitively, since we are talking about /strictness/, this should
> evaluate to bottom. However, it seems that your rule also admits () as
> an answer; it is equivalent to () under lazy evaluation *and* it does
> not create any thunks.
> 
> 2.
> 
>   f g = g undefined
> 
> When compiled lazily, this code doesn't construct any thunks:
> 
>   f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;
> 
> So, under your rule, this is an admissible code for -XStrict, too. But
> we can hardly call it strict.
> 
> On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
> > | As I said, I prefer this semantics mainly because it's easier to
> > | explain: all variables (and underscores) bound in a strict module refer
> > | to WHNF values. Do you have a similarly simple explanation for the
> > | semantics you're suggesting?
> > 
> > Here's one, which is roughly what the current implementation does (modulo bugs):
> > 
> > * Code compiled under -XStrict constructs no thunks.
> > 
> > So consider
> > 
> > 	module M1 where data T = C Int Int
> > 	module M2 where f n = C (n+1) (n-1)
> > 	module M3 where g x = let C y z = f x in ...
> > 
> > Look at M3.  Usually we'd get a thunk for (f 4), but not with -XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.   
> > 
> > If you compile M2 with -XStrict, function f won't build thunks for (n+1), (n-1) but will evaluate them instead.
> > 
> > If you compile M1 with StrictData, then C is made strict, so again M2 will build no thunks even if M2 was compiled without -XStrict.
> > 
> > I quite like this design.  It's not clear to me that anything useful is gained by forcing y and z in M3 before evaluating the body "...".
> > 
> > 
> > So Roman's design makes sense, but so does the implemented design (modulo any bugs).  The trouble is that the implemented design is not well described.
> > 
> > Simon
> > 
> > | -----Original Message-----
> > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Roman
> > | Cheplyaka
> > | Sent: 11 December 2015 12:57
> > | To: Johan Tibell <johan.tibell at gmail.com>
> > | Cc: ghc-devs at haskell.org
> > | Subject: Re: -XStrict: Why some binders are not made strict?
> > | 
> > | On 12/11/2015 02:21 PM, Johan Tibell wrote:
> > | > If we force strictness all the way down it's not really call-by-value
> > | > either, because the caller doesn't know what to evaluate (I think).
> > | 
> > | Not sure what you mean here.
> > | 
> > | > In addition, making pattern matching strict in this way makes it hard to
> > | > mix and match strict and lazy data types (e.g. Maybe), because using a
> > | > lazy data type from another module will make it appear strict in your
> > | > code (hurting modularity).
> > | 
> > | I don't think this is a case about modularity. A lazy Maybe value
> > | defined in a lazy module remains lazy; and you can pass it to lazy
> > | functions without forcing it. Only when you pattern match on it *in the
> > | strict module*, the evaluation happens.
> > | 
> > | As I said, I prefer this semantics mainly because it's easier to
> > | explain: all variables (and underscores) bound in a strict module refer
> > | to WHNF values. Do you have a similarly simple explanation for the
> > | semantics you're suggesting?
> > | 
> > | Roman
> > 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

From johan.tibell at gmail.com  Mon Dec 14 17:58:38 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 14 Dec 2015 18:58:38 +0100
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <1450115427.3319700.467146145.4987568B@webmail.messagingengine.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
 <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
 <566B6281.7060502@ro-che.info>
 <1450115427.3319700.467146145.4987568B@webmail.messagingengine.com>
Message-ID: <CAK-tuPYVTSXsuJP4kpZp++-RVUgAqhhiATu7AoPPjHMyack9cw@mail.gmail.com>

Agreed.

(Sorry for the sporadic communication. This is a very busy time at work.)

I thought about this a bit more recently.

Here's one way where I think "force every binder" goes wrong:

-- In a Strict module
f (Just x) = Just x

This is not the identity. This might matter in practice if a user defines a
data type, in a lazy module, that uses a lazy field to cache an expensive
calculation:

-- In a lazy module:
data CachedHash = CH a Int
mkCH x = CH x (expensiveHash x)

The intention here is that we only evaluate the expensive hash function
when needed. However, if we evaluate every binder this is no longer
transparent to users of the module, because doing this forces both fields:

f (CH x h) = CH x h

This also seems a bit "one sided" in that we do not evaluate expr in `Just
<expr>` under Strict, to not break modularity, but we would do it if you
pattern-matched on the contents of Just.

I'm also worried that we might make a choice here that we can't undo. I at
least understand the meaning of Strict in relation to strict languages.
"Evaluate every binder" is a new thing. Perhaps it deserves its own pragma,
StrictBinders.

On Mon, Dec 14, 2015 at 6:50 PM, Adam Sandberg Eriksson <
adam at sandbergericsson.se> wrote:

> Hello,
>
> Given the upcoming 8.0 feature freeze I think the correct approach for
> 8.0 is to document the current implementation (I'll try to do that this
> week).
>
> It would probably be good if interested parties would document their
> input in a ticket.
>
> Cheers,
> --Adam
>
>
> On Sat, 12 Dec 2015, at 12:55 AM, Roman Cheplyaka wrote:
> > Thanks Simon, this is an interesting and compelling interpretation. But
> > I'm wondering whether it is enough to specify the dynamic semantics
> > unambiguously.
> >
> > Two examples:
> >
> > 1.
> >
> >   let _ = undefined in ()
> >
> > Intuitively, since we are talking about /strictness/, this should
> > evaluate to bottom. However, it seems that your rule also admits () as
> > an answer; it is equivalent to () under lazy evaluation *and* it does
> > not create any thunks.
> >
> > 2.
> >
> >   f g = g undefined
> >
> > When compiled lazily, this code doesn't construct any thunks:
> >
> >   f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;
> >
> > So, under your rule, this is an admissible code for -XStrict, too. But
> > we can hardly call it strict.
> >
> > On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
> > > | As I said, I prefer this semantics mainly because it's easier to
> > > | explain: all variables (and underscores) bound in a strict module
> refer
> > > | to WHNF values. Do you have a similarly simple explanation for the
> > > | semantics you're suggesting?
> > >
> > > Here's one, which is roughly what the current implementation does
> (modulo bugs):
> > >
> > > * Code compiled under -XStrict constructs no thunks.
> > >
> > > So consider
> > >
> > >     module M1 where data T = C Int Int
> > >     module M2 where f n = C (n+1) (n-1)
> > >     module M3 where g x = let C y z = f x in ...
> > >
> > > Look at M3.  Usually we'd get a thunk for (f 4), but not with
> -XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.
> > >
> > > If you compile M2 with -XStrict, function f won't build thunks for
> (n+1), (n-1) but will evaluate them instead.
> > >
> > > If you compile M1 with StrictData, then C is made strict, so again M2
> will build no thunks even if M2 was compiled without -XStrict.
> > >
> > > I quite like this design.  It's not clear to me that anything useful
> is gained by forcing y and z in M3 before evaluating the body "...".
> > >
> > >
> > > So Roman's design makes sense, but so does the implemented design
> (modulo any bugs).  The trouble is that the implemented design is not well
> described.
> > >
> > > Simon
> > >
> > > | -----Original Message-----
> > > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> Roman
> > > | Cheplyaka
> > > | Sent: 11 December 2015 12:57
> > > | To: Johan Tibell <johan.tibell at gmail.com>
> > > | Cc: ghc-devs at haskell.org
> > > | Subject: Re: -XStrict: Why some binders are not made strict?
> > > |
> > > | On 12/11/2015 02:21 PM, Johan Tibell wrote:
> > > | > If we force strictness all the way down it's not really
> call-by-value
> > > | > either, because the caller doesn't know what to evaluate (I think).
> > > |
> > > | Not sure what you mean here.
> > > |
> > > | > In addition, making pattern matching strict in this way makes it
> hard to
> > > | > mix and match strict and lazy data types (e.g. Maybe), because
> using a
> > > | > lazy data type from another module will make it appear strict in
> your
> > > | > code (hurting modularity).
> > > |
> > > | I don't think this is a case about modularity. A lazy Maybe value
> > > | defined in a lazy module remains lazy; and you can pass it to lazy
> > > | functions without forcing it. Only when you pattern match on it *in
> the
> > > | strict module*, the evaluation happens.
> > > |
> > > | As I said, I prefer this semantics mainly because it's easier to
> > > | explain: all variables (and underscores) bound in a strict module
> refer
> > > | to WHNF values. Do you have a similarly simple explanation for the
> > > | semantics you're suggesting?
> > > |
> > > | Roman
> > >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > Email had 1 attachment:
> > + signature.asc
> >   1k (application/pgp-signature)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/55ba2eda/attachment-0001.html>

From ben at well-typed.com  Mon Dec 14 19:17:26 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 14 Dec 2015 20:17:26 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <566EFFA7.8040805@gmail.com>
References: <8737v5i1zw.fsf@smart-cactus.org> <566EFFA7.8040805@gmail.com>
Message-ID: <87mvtchmbd.fsf@smart-cactus.org>

David Luposchainsky <dluposchainsky at googlemail.com> writes:

> On 14.12.2015 14:38, Ben Gamari wrote:
>> If you have work still outstanding then you should talk to either me or
>> Austin ASAP if you have not done so already.
>
> The addition of the -W warning syntax [1] is on its way [2]. Unfortunatly, the
> - -Werror=... feature and improved warning messages [3] are out of scope for this
> release.
>
I've added this to the GHC 8.0 status page [1]. Thanks David!

Cheers,

- Ben

[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/1fd3b96c/attachment.sig>

From ben at well-typed.com  Mon Dec 14 19:32:59 2015
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 14 Dec 2015 20:32:59 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <CADdQpRAWp4Wb3ugPYwWr0gyurz2FDc+qfK0ZV2Z9gBp2L8teaw@mail.gmail.com>
References: <CADdQpRAWp4Wb3ugPYwWr0gyurz2FDc+qfK0ZV2Z9gBp2L8teaw@mail.gmail.com>
Message-ID: <87k2oghllg.fsf@smart-cactus.org>

Ryan Scott <ryan.gl.scott at gmail.com> writes:

> One thing I definitely want to get in before the 8.0 release is:
>
> * A fix for Trac #10716 [1] (adding strictness metadata to GHC
> generics). This feels like a natural counterpart for Trac #10697 [2]
> (reworking strictness information to Template Haskell), which
> currently has a Phab Diff in review [3]. I'd like for these to be
> released at the same time so that I can use Template Haskell to
> backport the machinery in generic-deriving [4]. In addition, I
> realized that my encoding of selector metadata is not very extensible
> at the moment, and this would give me a good excuse to fix it.
>
I've added these to "likely to land" list on the release status page.

> Some things that I probably won't get in time for 8.0:
>
> * Automatic derivation of Bifunctor/Bifoldable/Bitraversable, and of
> Eq1/Eq2/Ord1/Ord2/Read1/Read2/Show1/Show2. These would require
> resolving Trac #10448 [5] and #11135 [6] first, which might need more
> discussion. Not only that, but I still need to write up a proposal for
> how each of these classes would be derived, and there would need to be
> additional discussion on those points... All in all, it doesn't sound
> like something I could do in two weeks :)
>
Indeed this sounds like it might be a bit of a stretch.

> * Making Generic1 kind-polymorphic, Trac #10604 [7]. The first step to
> achieving this was done recently [8], but unfortunately, I wasn't able
> to make the actual datatypes in GHC.Generics kind-polymorphic for
> unknown reasons (I'd still like to talk to Richard Eisenberg about
> this at some point). Not only that, but I'm not sure what the
> implications of making Generic1 poly-kinded would be yet. I'd like to
> talk to Andres L?h about this.
>
Good luck and let me know if I can be of assistance!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151214/eaa5e5a1/attachment.sig>

From jan.stolarek at p.lodz.pl  Mon Dec 14 19:54:44 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 14 Dec 2015 20:54:44 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <87k2oghllg.fsf@smart-cactus.org>
References: <CADdQpRAWp4Wb3ugPYwWr0gyurz2FDc+qfK0ZV2Z9gBp2L8teaw@mail.gmail.com>
 <87k2oghllg.fsf@smart-cactus.org>
Message-ID: <201512142054.44398.jan.stolarek@p.lodz.pl>

I would love to land my fix for #10828, but now that the wildcard refactor and no-kinds have been 
merged it will require a substantial rewrite. I'll try to do that on Wednesday and hopefully 
there will be enough time for a review before feature freeze.

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.

From simonpj at microsoft.com  Mon Dec 14 20:32:10 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Dec 2015 20:32:10 +0000
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <1450115427.3319700.467146145.4987568B@webmail.messagingengine.com>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
 <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
 <566B6281.7060502@ro-che.info>
 <1450115427.3319700.467146145.4987568B@webmail.messagingengine.com>
Message-ID: <e5164c3ed1864835b01e0179eb62af66@DB4PR30MB030.064d.mgd.msft.net>

| Given the upcoming 8.0 feature freeze I think the correct approach for
| 8.0 is to document the current implementation (I'll try to do that this
| week).

Yes, that's right.  Thanks!

Simon


| 
| It would probably be good if interested parties would document their
| input in a ticket.
| 
| Cheers,
| --Adam
| 
| 
| On Sat, 12 Dec 2015, at 12:55 AM, Roman Cheplyaka wrote:
| > Thanks Simon, this is an interesting and compelling interpretation. But
| > I'm wondering whether it is enough to specify the dynamic semantics
| > unambiguously.
| >
| > Two examples:
| >
| > 1.
| >
| >   let _ = undefined in ()
| >
| > Intuitively, since we are talking about /strictness/, this should
| > evaluate to bottom. However, it seems that your rule also admits () as
| > an answer; it is equivalent to () under lazy evaluation *and* it does
| > not create any thunks.
| >
| > 2.
| >
| >   f g = g undefined
| >
| > When compiled lazily, this code doesn't construct any thunks:
| >
| >   f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;
| >
| > So, under your rule, this is an admissible code for -XStrict, too. But
| > we can hardly call it strict.
| >
| > On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
| > > | As I said, I prefer this semantics mainly because it's easier to
| > > | explain: all variables (and underscores) bound in a strict module refer
| > > | to WHNF values. Do you have a similarly simple explanation for the
| > > | semantics you're suggesting?
| > >
| > > Here's one, which is roughly what the current implementation does (modulo
| bugs):
| > >
| > > * Code compiled under -XStrict constructs no thunks.
| > >
| > > So consider
| > >
| > > 	module M1 where data T = C Int Int
| > > 	module M2 where f n = C (n+1) (n-1)
| > > 	module M3 where g x = let C y z = f x in ...
| > >
| > > Look at M3.  Usually we'd get a thunk for (f 4), but not with -XStrict.
| But even with -XStrict in M3, y,z might be bound to thunks.
| > >
| > > If you compile M2 with -XStrict, function f won't build thunks for (n+1),
| (n-1) but will evaluate them instead.
| > >
| > > If you compile M1 with StrictData, then C is made strict, so again M2
| will build no thunks even if M2 was compiled without -XStrict.
| > >
| > > I quite like this design.  It's not clear to me that anything useful is
| gained by forcing y and z in M3 before evaluating the body "...".
| > >
| > >
| > > So Roman's design makes sense, but so does the implemented design (modulo
| any bugs).  The trouble is that the implemented design is not well described.
| > >
| > > Simon
| > >
| > > | -----Original Message-----
| > > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Roman
| > > | Cheplyaka
| > > | Sent: 11 December 2015 12:57
| > > | To: Johan Tibell <johan.tibell at gmail.com>
| > > | Cc: ghc-devs at haskell.org
| > > | Subject: Re: -XStrict: Why some binders are not made strict?
| > > |
| > > | On 12/11/2015 02:21 PM, Johan Tibell wrote:
| > > | > If we force strictness all the way down it's not really call-by-value
| > > | > either, because the caller doesn't know what to evaluate (I think).
| > > |
| > > | Not sure what you mean here.
| > > |
| > > | > In addition, making pattern matching strict in this way makes it hard
| to
| > > | > mix and match strict and lazy data types (e.g. Maybe), because using
| a
| > > | > lazy data type from another module will make it appear strict in your
| > > | > code (hurting modularity).
| > > |
| > > | I don't think this is a case about modularity. A lazy Maybe value
| > > | defined in a lazy module remains lazy; and you can pass it to lazy
| > > | functions without forcing it. Only when you pattern match on it *in the
| > > | strict module*, the evaluation happens.
| > > |
| > > | As I said, I prefer this semantics mainly because it's easier to
| > > | explain: all variables (and underscores) bound in a strict module refer
| > > | to WHNF values. Do you have a similarly simple explanation for the
| > > | semantics you're suggesting?
| > > |
| > > | Roman
| > >
| >
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c81ebe250762640019a7b08
| d304af0dcc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qy2g8Dy4zDVKohNOHLnYT
| ekaVLtckBwTtOvN6y4cUuo%3d
| > Email had 1 attachment:
| > + signature.asc
| >   1k (application/pgp-signature)

From simonpj at microsoft.com  Tue Dec 15 14:43:13 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2015 14:43:13 +0000
Subject: [commit: ghc] master: Make sure PatSyns only get added once to
 tcg_patsyns (41ef8f7)
In-Reply-To: <20151211181157.861833A300@ghc.haskell.org>
References: <20151211181157.861833A300@ghc.haskell.org>
Message-ID: <ea411880cb7245e08f0a670cea974fc1@DB4PR30MB030.064d.mgd.msft.net>

Good catch Matthew!

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 11 December 2015 18:12
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Make sure PatSyns only get added once
|  to tcg_patsyns (41ef8f7)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha
|  skell.org%2ftrac%2fghc%2fchangeset%2f41ef8f70819e9b99aacc6d81019e5a33a
|  63dfeab%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265
|  a98dcc44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat
|  a=aH%2bCJDOGW%2f2iqa%2fVNndOfAq2bJfBRBGiCADHYBzt5Uc%3d
|  
|  >---------------------------------------------------------------
|  
|  commit 41ef8f70819e9b99aacc6d81019e5a33a63dfeab
|  Author: Matthew Pickering <matthewtpickering at gmail.com>
|  Date:   Fri Dec 11 18:10:45 2015 +0000
|  
|      Make sure PatSyns only get added once to tcg_patsyns
|  
|      Summary: Before, `PatSyn`s were getting added twice to
|  `tcg_patsyns` so
|      when inspecting afterwards there were duplicates in the list.
|      This makes sure that only they only get added once.
|  
|      Reviewers: austin, bgamari
|  
|      Reviewed By: bgamari
|  
|      Subscribers: thomie
|  
|      Differential Revision: https://phabricator.haskell.org/D1597
|  
|  
|  >---------------------------------------------------------------
|  
|  41ef8f70819e9b99aacc6d81019e5a33a63dfeab
|   compiler/typecheck/TcBinds.hs       |  8 +++-----
|   compiler/typecheck/TcPatSyn.hs      | 10 +++++-----
|   compiler/typecheck/TcPatSyn.hs-boot |  7 +++----
|   3 files changed, 11 insertions(+), 14 deletions(-)
|  
|  diff --git a/compiler/typecheck/TcBinds.hs
|  b/compiler/typecheck/TcBinds.hs index 673109b..1254b78 100644
|  --- a/compiler/typecheck/TcBinds.hs
|  +++ b/compiler/typecheck/TcBinds.hs
|  @@ -49,7 +49,6 @@ import NameSet
|   import NameEnv
|   import SrcLoc
|   import Bag
|  -import PatSyn
|   import ListSetOps
|   import ErrUtils
|   import Digraph
|  @@ -483,13 +482,12 @@ tc_single :: forall thing.
|             -> LHsBind Name -> TcM thing
|             -> TcM (LHsBinds TcId, thing)  tc_single _top_lvl sig_fn
|  _prag_fn (L _ (PatSynBind psb at PSB{ psb_id = L _ name })) thing_inside
|  -  = do { (pat_syn, aux_binds, tcg_env) <- tc_pat_syn_decl
|  -       ; let tything = AConLike (PatSynCon pat_syn)
|  -       ; thing <- setGblEnv tcg_env  $ tcExtendGlobalEnv [tything]
|  thing_inside
|  +  = do { (aux_binds, tcg_env) <- tc_pat_syn_decl
|  +       ; thing <- setGblEnv tcg_env thing_inside
|          ; return (aux_binds, thing)
|          }
|     where
|  -    tc_pat_syn_decl :: TcM (PatSyn, LHsBinds TcId, TcGblEnv)
|  +    tc_pat_syn_decl :: TcM (LHsBinds TcId, TcGblEnv)
|       tc_pat_syn_decl = case sig_fn name of
|           Nothing                 -> tcInferPatSynDecl psb
|           Just (TcPatSynSig tpsi) -> tcCheckPatSynDecl psb tpsi diff --
|  git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs
|  index 30dcbf7..69eeef0 100644
|  --- a/compiler/typecheck/TcPatSyn.hs
|  +++ b/compiler/typecheck/TcPatSyn.hs
|  @@ -61,7 +61,7 @@ import Control.Monad (forM)  -}
|  
|   tcInferPatSynDecl :: PatSynBind Name Name
|  -                  -> TcM (PatSyn, LHsBinds Id, TcGblEnv)
|  +                  -> TcM (LHsBinds Id, TcGblEnv)
|   tcInferPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args =
|  details,
|                          psb_def = lpat, psb_dir = dir }
|     = setSrcSpan loc $
|  @@ -96,7 +96,7 @@ tcInferPatSynDecl PSB{ psb_id = lname@(L loc name),
|  psb_args = details,
|  
|   tcCheckPatSynDecl :: PatSynBind Name Name
|                     -> TcPatSynInfo
|  -                  -> TcM (PatSyn, LHsBinds Id, TcGblEnv)
|  +                  -> TcM (LHsBinds Id, TcGblEnv)
|   tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args =
|  details,
|                          psb_def = lpat, psb_dir = dir }
|                     TPSI{ patsig_tau = tau, @@ -163,7 +163,7 @@
|  tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args =
|  details,
|                             (univ_tvs, req_theta, req_ev_binds,
|  req_dicts)
|                             (ex_tvs, ex_tys, prov_theta, prov_ev_binds,
|  prov_dicts)
|                             wrapped_args
|  -                          pat_ty rec_fields  }
|  +                          pat_ty rec_fields }
|     where
|       (arg_tys, pat_ty) = tcSplitFunTys tau
|  
|  @@ -199,7 +199,7 @@ tc_patsyn_finish :: Located Name  -- ^ PatSyn Name
|                    -> TcType              -- ^ Pattern type
|                    -> [Name]              -- ^ Selector names
|                    -- ^ Whether fields, empty if not record PatSyn
|  -                 -> TcM (PatSyn, LHsBinds Id, TcGblEnv)
|  +                 -> TcM (LHsBinds Id, TcGblEnv)
|   tc_patsyn_finish lname dir is_infix lpat'
|                    (univ_tvs, req_theta, req_ev_binds, req_dicts)
|                    (ex_tvs, subst, prov_theta, prov_ev_binds,
|  prov_dicts) @@ -262,7 +262,7 @@ tc_patsyn_finish lname dir is_infix
|  lpat'
|               tcRecSelBinds
|                 (ValBindsOut (zip (repeat NonRecursive) selector_binds)
|  sigs)
|  
|  -       ; return (patSyn, matcher_bind, tcg_env) }
|  +       ; return (matcher_bind, tcg_env) }
|  
|     where
|       zonk_wrapped_arg :: (Var, HsWrapper) -> TcM (Var, HsWrapper) diff
|  --git a/compiler/typecheck/TcPatSyn.hs-boot
|  b/compiler/typecheck/TcPatSyn.hs-boot
|  index 61f7958..11c1bc1 100644
|  --- a/compiler/typecheck/TcPatSyn.hs-boot
|  +++ b/compiler/typecheck/TcPatSyn.hs-boot
|  @@ -4,16 +4,15 @@ import Name      ( Name )
|   import Id        ( Id )
|   import HsSyn     ( PatSynBind, LHsBinds )
|   import TcRnTypes ( TcM, TcPatSynInfo )
|  -import PatSyn    ( PatSyn )
|  -import TcRnMonad ( TcGblEnv )
|  +import TcRnMonad ( TcGblEnv)
|   import Outputable ( Outputable )
|  
|   tcInferPatSynDecl :: PatSynBind Name Name
|  -                  -> TcM (PatSyn, LHsBinds Id, TcGblEnv)
|  +                  -> TcM (LHsBinds Id, TcGblEnv)
|  
|   tcCheckPatSynDecl :: PatSynBind Name Name
|                     -> TcPatSynInfo
|  -                  -> TcM (PatSyn, LHsBinds Id, TcGblEnv)
|  +                  -> TcM (LHsBinds Id, TcGblEnv)
|  
|   tcPatSynBuilderBind :: PatSynBind Name Name
|                       -> TcM (LHsBinds Id)
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265a98dcc
|  44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B6Hb
|  JaANWHnlqhBaZ5AOMvHAQ0Mzs4t8cvtkQLIo4t4%3d

From simonpj at microsoft.com  Tue Dec 15 15:00:11 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2015 15:00:11 +0000
Subject: -XStrict: Why some binders are not made strict?
In-Reply-To: <566B6281.7060502@ro-che.info>
References: <CAMQQO3k-XfRO=ZxhT7-dpYzBeGuOaLZvXF5GNZM9cfmr1ef3_A@mail.gmail.com>
 <46838e6a300e49809e14eaf98fdee743@DB4PR30MB030.064d.mgd.msft.net>
 <CAK-tuPYN9x8a9QXo-H-6SzFo_KCXH-R1u0gSNdrxenk3+QirVw@mail.gmail.com>
 <566A7324.2040706@ro-che.info>
 <CAK-tuPbUTi_-U+GdrcvSz6jqYktgqJhobeE9urRVyi69EFV6nw@mail.gmail.com>
 <566AC826.9040301@ro-che.info>
 <7cc72cc786bf4794a27530b141310676@DB4PR30MB030.064d.mgd.msft.net>
 <566B6281.7060502@ro-che.info>
Message-ID: <dfc0e8c9d0e64a0f96b9bd6cc21948ed@DB4PR30MB030.064d.mgd.msft.net>

|  Thanks Simon, this is an interesting and compelling interpretation.
|  But I'm wondering whether it is enough to specify the dynamic
|  semantics unambiguously.

You make good points.  Also, consider

	f (g x)

where f is define in some other (lazy) module.  Is that done call-by value?  That is, is (g x) evaluated before the call?  According to the current spec, no. So a thunk is built!

But if we write

	let y = g x in f y

then, lo, the (g x) is computed eagerly.

So the present semantics seems to be more 
	functions always evaluate their arguments to
      WHNF (but not to NF)!

I do think this could do with a tighter spec.  Johan, Adam, this is your baby.

Simon


|  -----Original Message-----
|  From: Roman Cheplyaka [mailto:roma at ro-che.info]
|  Sent: 11 December 2015 23:56
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Johan Tibell
|  <johan.tibell at gmail.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: -XStrict: Why some binders are not made strict?
|  
|  Thanks Simon, this is an interesting and compelling interpretation.
|  But I'm wondering whether it is enough to specify the dynamic
|  semantics unambiguously.
|  
|  Two examples:
|  
|  1.
|  
|    let _ = undefined in ()
|  
|  Intuitively, since we are talking about /strictness/, this should
|  evaluate to bottom. However, it seems that your rule also admits () as
|  an answer; it is equivalent to () under lazy evaluation *and* it does
|  not create any thunks.
|  
|  2.
|  
|    f g = g undefined
|  
|  When compiled lazily, this code doesn't construct any thunks:
|  
|    f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;
|  
|  So, under your rule, this is an admissible code for -XStrict, too. But
|  we can hardly call it strict.
|  
|  On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
|  > | As I said, I prefer this semantics mainly because it's easier to
|  > | explain: all variables (and underscores) bound in a strict module
|  > | refer to WHNF values. Do you have a similarly simple explanation
|  for
|  > | the semantics you're suggesting?
|  >
|  > Here's one, which is roughly what the current implementation does
|  (modulo bugs):
|  >
|  > * Code compiled under -XStrict constructs no thunks.
|  >
|  > So consider
|  >
|  > 	module M1 where data T = C Int Int
|  > 	module M2 where f n = C (n+1) (n-1)
|  > 	module M3 where g x = let C y z = f x in ...
|  >
|  > Look at M3.  Usually we'd get a thunk for (f 4), but not with -
|  XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.
|  >
|  > If you compile M2 with -XStrict, function f won't build thunks for
|  (n+1), (n-1) but will evaluate them instead.
|  >
|  > If you compile M1 with StrictData, then C is made strict, so again
|  M2 will build no thunks even if M2 was compiled without -XStrict.
|  >
|  > I quite like this design.  It's not clear to me that anything useful
|  is gained by forcing y and z in M3 before evaluating the body "...".
|  >
|  >
|  > So Roman's design makes sense, but so does the implemented design
|  (modulo any bugs).  The trouble is that the implemented design is not
|  well described.
|  >
|  > Simon
|  >
|  > | -----Original Message-----
|  > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > | Roman Cheplyaka
|  > | Sent: 11 December 2015 12:57
|  > | To: Johan Tibell <johan.tibell at gmail.com>
|  > | Cc: ghc-devs at haskell.org
|  > | Subject: Re: -XStrict: Why some binders are not made strict?
|  > |
|  > | On 12/11/2015 02:21 PM, Johan Tibell wrote:
|  > | > If we force strictness all the way down it's not really
|  > | > call-by-value either, because the caller doesn't know what to
|  evaluate (I think).
|  > |
|  > | Not sure what you mean here.
|  > |
|  > | > In addition, making pattern matching strict in this way makes it
|  > | > hard to mix and match strict and lazy data types (e.g. Maybe),
|  > | > because using a lazy data type from another module will make it
|  > | > appear strict in your code (hurting modularity).
|  > |
|  > | I don't think this is a case about modularity. A lazy Maybe value
|  > | defined in a lazy module remains lazy; and you can pass it to lazy
|  > | functions without forcing it. Only when you pattern match on it
|  *in
|  > | the strict module*, the evaluation happens.
|  > |
|  > | As I said, I prefer this semantics mainly because it's easier to
|  > | explain: all variables (and underscores) bound in a strict module
|  > | refer to WHNF values. Do you have a similarly simple explanation
|  for
|  > | the semantics you're suggesting?
|  > |
|  > | Roman
|  >
|  


From simonpj at microsoft.com  Tue Dec 15 15:21:10 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2015 15:21:10 +0000
Subject: Warning suppression pragmas
In-Reply-To: <D78AFF60-78A3-4EB4-B29D-7B1C4C7DE84B@cis.upenn.edu>
References: <CAEvjXHSLBCtwx8UHe9vO62MYotU01Exm7bZNNh-VgrqBKytmpw@mail.gmail.com>
 <87si3j3ex8.fsf@smart-cactus.org>
 <CAEvjXHT_vjsuJtfxj4xdcroCVAV9VuUfubQpjbtAL7EkWoWOrQ@mail.gmail.com>
 <D78AFF60-78A3-4EB4-B29D-7B1C4C7DE84B@cis.upenn.edu>
Message-ID: <16c0bb67302342789736a851e81c2832@DB4PR30MB030.064d.mgd.msft.net>

All good questions!   I have nothing to add to that list.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 14 December 2015 14:44
To: ????? ?????????? <edzhavoronkov at gmail.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Warning suppression pragmas

This proposal is a good start, but it needs more fleshing out.

- What scopes are allowed to suppress over? For example, is it possible to suppress warnings for scopes other than a function (for example, within a case expression)? What about type declarations? Local declarations? In a type signature?

- Is there a way to control what warnings are suppressed? Presumably, a user would like to suppress only certain warnings in certain places.

- Your proposal contains motivation and examples. These are necessary parts of a proposal. But we also need a full specification of the feature, describing precisely the syntax (where, exactly, `SUPPRESS` is allowed) and semantics.

I hope this feedback is helpful!
Richard

On Dec 14, 2015, at 8:52 AM, ????? ?????????? <edzhavoronkov at gmail.com<mailto:edzhavoronkov at gmail.com>> wrote:


Hi devs!

I edited wiki page [1] with my proposal about more than week ago. The main idea is that we mark functins with pragma and filter all warnings that it will throw. Although it is the question of bad design, i think users, who have to support old libraries will find this helpful.

I don't know about suppressing specific kinds of warnings. I think, that it would be more precise to filter them in one place instead of many.

Can someone review it? Sorry for bothering, if any

[1] - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas

---
? ?????????,
?????????? ?????

Best regards,
Edgar A. Zhavoronkov

2015-12-03 15:16 GMT+03:00 Ben Gamari <ben at smart-cactus.org<mailto:ben at smart-cactus.org>>:
????? ?????????? <edzhavoronkov at gmail.com<mailto:edzhavoronkov at gmail.com>> writes:

> Hello devs!
>
> I am trying to implement some kind of local warnings suppresion and i need
> some help.
>
> I want to use a pragma to mark functions so compiler won't throw warnings
> from them. I defined my pragma in lexer, parser and added type signature in
> HsBinds.hs. And i am stuck. I don't know what to do. What should i consider
> doing further?
>
I think it would be helpful to focus on further elaborating the
specification before we move into the implementation. There are still a
number of open questions about the design that the wiki page doesn't yet
address.

For instance, you should explicitly specify,

 * What are the identifiers that appear after the `SUPPRESS` token?

 * What exactly does the pragma apply to? For instance, if I have a case
   like,

       hello :: Int -> Int
       {-# SUPPRESS some-warning #-}
       helloAgain :: Type -> AnotherType
       hello = (+1)
       helloAgain = error "42"

   or even just
       hello = (+1)
       {-# SUPPRESS another-warning #-}
       helloAgain = error "oops"

   What do you expect to happen? The behavior of the pragma in both of
   these cases should be unambiguously stated in the specification.

 * An concrete use-case motivating the change (preferably with examples
   showing how the proposed syntax would address the motivation)

I know this sounds repetitive, but the act of writing down a proposal
will help you immensely when you do move on to implementing your ideas.

Thanks for your persistence.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151215/e5a142b1/attachment.html>

From simonpj at microsoft.com  Tue Dec 15 16:02:28 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2015 16:02:28 +0000
Subject: Unused type variables with non-linear patterns
In-Reply-To: <CDE401FD-5125-4F2F-AEF3-256762E48B1E@cis.upenn.edu>
References: <201512101548.59480.jan.stolarek@p.lodz.pl>
 <CAEDDsWfGFvVN7WeKOH=DYhY7g9yt1frwcR0MxHiUryCB2xSWtQ@mail.gmail.com>
 <CDE401FD-5125-4F2F-AEF3-256762E48B1E@cis.upenn.edu>
Message-ID: <810df9b80fec4f3db7fc5b7caaa2b2ba@DB4PR30MB030.064d.mgd.msft.net>

I agree too.

Is there a ticket?   Does it emit a warning right now?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 11 December 2015 16:02
To: Michael Sloan <mgsloan at gmail.com>
Cc: ghc-devs at haskell.org
Subject: Re: Unused type variables with non-linear patterns

I agree with Michael. This should not emit a warning.

While you're in this area, make sure that

> type instance F _ _ = Int

indeed matches `F Char Bool`. It's easy to imagine both underscores being treated as the same variable, which is not what the user intends.

Thanks,
Richard

On Dec 10, 2015, at 4:32 PM, Michael Sloan <mgsloan at gmail.com<mailto:mgsloan at gmail.com>> wrote:


I definitely think this should be considered a usage.  Ideally, you should always be able to resolve warnings, but there'd be no straightforward way to do so if LHS-only usages cause warnings.  Also, It's quite useful to use type variables only on the LHS.  Usage example: https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Type.Equality.html#EqStar<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fhackage.haskell.org%2fpackage%2fbase-4.8.1.0%2fdocs%2fsrc%2fData.Type.Equality.html%23EqStar&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c65bff682e66a434f1f1708d302447d3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gkgghrbPZ7shUtk4z2WesVVJaQD8wlKhlbXWmFHpjEs%3d>

-Michael

On Thu, Dec 10, 2015 at 6:48 AM, Jan Stolarek <jan.stolarek at p.lodz.pl<mailto:jan.stolarek at p.lodz.pl>> wrote:
An intersting thing came up when implementing warnings for unused type variables in type family
patterns (#10982 / D1576):

type family X a b where
  X a a = Int

Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used
because of non-linear pattern. We can fix this by prefixing both appearances of `a` with an
underscore - this silences the warning and maintains semantics. Nevertheless, if a variable is
unused it should be perfectly valid to replace it with an underscore - that is not the case in
this example. Thoughts?

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 at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c65bff682e66a434f1f1708d302447d3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HZKgQKaUHcWjhAQNgfwXyK55SzqAgqhVevgpQRbyz5c%3d>

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151215/19c933f5/attachment-0001.html>

From jan.stolarek at p.lodz.pl  Tue Dec 15 18:11:12 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 15 Dec 2015 19:11:12 +0100
Subject: Unused type variables with non-linear patterns
In-Reply-To: <810df9b80fec4f3db7fc5b7caaa2b2ba@DB4PR30MB030.064d.mgd.msft.net>
References: <201512101548.59480.jan.stolarek@p.lodz.pl>
 <CDE401FD-5125-4F2F-AEF3-256762E48B1E@cis.upenn.edu>
 <810df9b80fec4f3db7fc5b7caaa2b2ba@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <201512151911.12209.jan.stolarek@p.lodz.pl>

> Is there a ticket?
#10982

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.

From omeragacan at gmail.com  Tue Dec 15 23:05:54 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 15 Dec 2015 18:05:54 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
Message-ID: <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>

Hi Richard,

Now that we have levity arguments I'm wondering if we should go ahead and
implement this. The code is already there - unboxed tuples have levity
arguments and then type arguments depend on the levity arguments, so this
works:

    ?> :k (# Int, Int# #)
    (# Int, Int# #) :: #

But this doesn't because boxed tuples are not implemented that way:

    ?> :k ( Int, Int# )

    <interactive>:1:8: error:
        ? Expecting a lifted type, but ?Int#? is unlifted
        ? In the type ?(Int, Int#)?

The implementation looked fairly simple so I just tried to lift this
restriction (I basically merged the code that generates TyCons and DataCons for
unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
started to panic. Should I investigate this further or are there any problems
with this that we need to solve first?

If there's a problem with this I think we should at least add a NOTE in
TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are used
in unboxed tuples, but there's no comments or notes about why we don't do the
same for boxed tuples.

Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
arguments do that work now and we no longer need OpenKind?

Thanks

2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
> I think this is a consequence of the rule that we never abstract over types of kind #. But I believe this should work with my branch:
>
>> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
>
> The user would have to request that the synonym be used over both * and #, but the synonym should work. The need to request the special treatment might be lifted, but we'd have to think hard about where we want the generality by default and where we want simpler behavior by default.
>
> Richard
>
> On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>
>> In this program:
>>
>>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
>>
>>    module Main where
>>
>>    import GHC.Prim
>>    import GHC.Types
>>
>>    type Tuple a b = (# a, b #)
>>
>>    main = do
>>      let -- x :: Tuple Int# Float#
>>          x :: (# Int#, Float# #)
>>          x = (# 1#, 0.0# #)
>>
>>      return ()
>>
>> If I use the first type declaration for 'x' I'm getting this error message:
>>
>>    Expecting a lifted type, but ?Int#? is unlifted
>>
>> Indeed, if I look at the kinds of arguments of 'Tuple':
>>
>>    ?:7> :k Tuple
>>    Tuple :: * -> * -> #
>>
>> It's star. I was wondering why is this not 'OpenKind'(or whatever the
>> super-kind of star and hash). Is there a problem with this? Is this a bug?
>> Or is this simply because type synonyms are implemented before OpenKinds?
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From simonpj at microsoft.com  Tue Dec 15 23:08:35 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 15 Dec 2015 23:08:35 +0000
Subject: Kinds of type synonym arguments
In-Reply-To: <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
Message-ID: <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>

What is "this" that you propose to implement?  Is there a wiki page that describes the design?

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan
| Agacan
| Sent: 15 December 2015 23:06
| To: Richard Eisenberg <eir at cis.upenn.edu>
| Cc: ghc-devs <ghc-devs at haskell.org>
| Subject: Re: Kinds of type synonym arguments
| 
| Hi Richard,
| 
| Now that we have levity arguments I'm wondering if we should go ahead and
| implement this. The code is already there - unboxed tuples have levity
| arguments and then type arguments depend on the levity arguments, so this
| works:
| 
|     ?> :k (# Int, Int# #)
|     (# Int, Int# #) :: #
| 
| But this doesn't because boxed tuples are not implemented that way:
| 
|     ?> :k ( Int, Int# )
| 
|     <interactive>:1:8: error:
|         ? Expecting a lifted type, but ?Int#? is unlifted
|         ? In the type ?(Int, Int#)?
| 
| The implementation looked fairly simple so I just tried to lift this
| restriction (I basically merged the code that generates TyCons and DataCons
| for
| unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
| started to panic. Should I investigate this further or are there any problems
| with this that we need to solve first?
| 
| If there's a problem with this I think we should at least add a NOTE in
| TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are
| used
| in unboxed tuples, but there's no comments or notes about why we don't do the
| same for boxed tuples.
| 
| Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
| arguments do that work now and we no longer need OpenKind?
| 
| Thanks
| 
| 2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
| > I think this is a consequence of the rule that we never abstract over types
| of kind #. But I believe this should work with my branch:
| >
| >> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
| >
| > The user would have to request that the synonym be used over both * and #,
| but the synonym should work. The need to request the special treatment might
| be lifted, but we'd have to think hard about where we want the generality by
| default and where we want simpler behavior by default.
| >
| > Richard
| >
| > On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
| >
| >> In this program:
| >>
| >>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
| >>
| >>    module Main where
| >>
| >>    import GHC.Prim
| >>    import GHC.Types
| >>
| >>    type Tuple a b = (# a, b #)
| >>
| >>    main = do
| >>      let -- x :: Tuple Int# Float#
| >>          x :: (# Int#, Float# #)
| >>          x = (# 1#, 0.0# #)
| >>
| >>      return ()
| >>
| >> If I use the first type declaration for 'x' I'm getting this error
| message:
| >>
| >>    Expecting a lifted type, but ?Int#? is unlifted
| >>
| >> Indeed, if I look at the kinds of arguments of 'Tuple':
| >>
| >>    ?:7> :k Tuple
| >>    Tuple :: * -> * -> #
| >>
| >> It's star. I was wondering why is this not 'OpenKind'(or whatever the
| >> super-kind of star and hash). Is there a problem with this? Is this a bug?
| >> Or is this simply because type synonyms are implemented before OpenKinds?
| >> _______________________________________________
| >> ghc-devs mailing list
| >> ghc-devs at haskell.org
| >>
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c308
| d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sYBDmz3zltvhkRvFsuo1h
| OiBLqO6Qsu7N0zpzUK7iPY%3d
| >>
| >
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c
| 308d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=A4khlPGkSRO%2f4S%2
| bv%2fUxEiJj9DewPXVbsuX7GAzHB0FQ%3d

From omeragacan at gmail.com  Tue Dec 15 23:25:56 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 15 Dec 2015 18:25:56 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>

Oh sorry, I just mean that currently boxed tuples don't accept unboxed types:

    ?> :k ( Int#, Int )

    <interactive>:1:3: error:
        ? Expecting a lifted type, but ?Int#? is unlifted
        ? In the type ?(Int#, Int)?

But unboxed variant of exactly the same thing is accepted:

    ?> :k (# Int#, Int #)
    (# Int#, Int #) :: #

I was hoping make these two the same by adding levity arguments and making type
arguments depend on levity arguments, just like how unboxed tuple types are
implemented (as described in Note [Unboxed tuple levity vars]).

The changes in tuple DataCon and TyCon generation is fairly simple (in fact I
just implemented that part) but the rest of the compiler started panicking. So
my question is, is there a reason for not doing this, because otherwise I'd
like to fix panics etc. and make this change.

2015-12-15 18:08 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
> What is "this" that you propose to implement?  Is there a wiki page that describes the design?
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan
> | Agacan
> | Sent: 15 December 2015 23:06
> | To: Richard Eisenberg <eir at cis.upenn.edu>
> | Cc: ghc-devs <ghc-devs at haskell.org>
> | Subject: Re: Kinds of type synonym arguments
> |
> | Hi Richard,
> |
> | Now that we have levity arguments I'm wondering if we should go ahead and
> | implement this. The code is already there - unboxed tuples have levity
> | arguments and then type arguments depend on the levity arguments, so this
> | works:
> |
> |     ?> :k (# Int, Int# #)
> |     (# Int, Int# #) :: #
> |
> | But this doesn't because boxed tuples are not implemented that way:
> |
> |     ?> :k ( Int, Int# )
> |
> |     <interactive>:1:8: error:
> |         ? Expecting a lifted type, but ?Int#? is unlifted
> |         ? In the type ?(Int, Int#)?
> |
> | The implementation looked fairly simple so I just tried to lift this
> | restriction (I basically merged the code that generates TyCons and DataCons
> | for
> | unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
> | started to panic. Should I investigate this further or are there any problems
> | with this that we need to solve first?
> |
> | If there's a problem with this I think we should at least add a NOTE in
> | TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are
> | used
> | in unboxed tuples, but there's no comments or notes about why we don't do the
> | same for boxed tuples.
> |
> | Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
> | arguments do that work now and we no longer need OpenKind?
> |
> | Thanks
> |
> | 2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
> | > I think this is a consequence of the rule that we never abstract over types
> | of kind #. But I believe this should work with my branch:
> | >
> | >> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
> | >
> | > The user would have to request that the synonym be used over both * and #,
> | but the synonym should work. The need to request the special treatment might
> | be lifted, but we'd have to think hard about where we want the generality by
> | default and where we want simpler behavior by default.
> | >
> | > Richard
> | >
> | > On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
> | >
> | >> In this program:
> | >>
> | >>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
> | >>
> | >>    module Main where
> | >>
> | >>    import GHC.Prim
> | >>    import GHC.Types
> | >>
> | >>    type Tuple a b = (# a, b #)
> | >>
> | >>    main = do
> | >>      let -- x :: Tuple Int# Float#
> | >>          x :: (# Int#, Float# #)
> | >>          x = (# 1#, 0.0# #)
> | >>
> | >>      return ()
> | >>
> | >> If I use the first type declaration for 'x' I'm getting this error
> | message:
> | >>
> | >>    Expecting a lifted type, but ?Int#? is unlifted
> | >>
> | >> Indeed, if I look at the kinds of arguments of 'Tuple':
> | >>
> | >>    ?:7> :k Tuple
> | >>    Tuple :: * -> * -> #
> | >>
> | >> It's star. I was wondering why is this not 'OpenKind'(or whatever the
> | >> super-kind of star and hash). Is there a problem with this? Is this a bug?
> | >> Or is this simply because type synonyms are implemented before OpenKinds?
> | >> _______________________________________________
> | >> ghc-devs mailing list
> | >> ghc-devs at haskell.org
> | >>
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c308
> | d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sYBDmz3zltvhkRvFsuo1h
> | OiBLqO6Qsu7N0zpzUK7iPY%3d
> | >>
> | >
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c
> | 308d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=A4khlPGkSRO%2f4S%2
> | bv%2fUxEiJj9DewPXVbsuX7GAzHB0FQ%3d

From dan.doel at gmail.com  Wed Dec 16 03:04:41 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Tue, 15 Dec 2015 22:04:41 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
Message-ID: <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>

This is not a simple change at all, though.

The reason that (,) cannot accept arguments of kind # is not just that
there was no levity abstraction. You simply cannot abstract over # in
the same way as you can *, because the types in # are not represented
uniformly. Creating a tuple with an argument of kind # would require
generating code for (at the least) each different size of thing that
can go in #; but there are infinitely many of those, because of
unboxed tuples, so  you probably have to do on-demand code generation
when particular types are used.

And of course, the evaluation conventions change between # and *, so
you have to deal with that if tuples are supposed to accept types of
both kinds. See the stuff at:

    https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes

for instance. Note that that that page is only considering being able
to abstract over the portion of # that is represented uniformly by a
pointer, though. Things like Int#, Double# and (# Int#, Double #) are
completely out of its scope.

This isn't just the typing on (,) being overly restrictive. It would
be a pretty fundamental change that would, I assume, be non-trivial to
implement. I think it would be non-trivial to come up with a good
design, too, really.

-- Dan


On Tue, Dec 15, 2015 at 6:25 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
> Oh sorry, I just mean that currently boxed tuples don't accept unboxed types:
>
>     ?> :k ( Int#, Int )
>
>     <interactive>:1:3: error:
>         ? Expecting a lifted type, but ?Int#? is unlifted
>         ? In the type ?(Int#, Int)?
>
> But unboxed variant of exactly the same thing is accepted:
>
>     ?> :k (# Int#, Int #)
>     (# Int#, Int #) :: #
>
> I was hoping make these two the same by adding levity arguments and making type
> arguments depend on levity arguments, just like how unboxed tuple types are
> implemented (as described in Note [Unboxed tuple levity vars]).
>
> The changes in tuple DataCon and TyCon generation is fairly simple (in fact I
> just implemented that part) but the rest of the compiler started panicking. So
> my question is, is there a reason for not doing this, because otherwise I'd
> like to fix panics etc. and make this change.
>
> 2015-12-15 18:08 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
>> What is "this" that you propose to implement?  Is there a wiki page that describes the design?
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan
>> | Agacan
>> | Sent: 15 December 2015 23:06
>> | To: Richard Eisenberg <eir at cis.upenn.edu>
>> | Cc: ghc-devs <ghc-devs at haskell.org>
>> | Subject: Re: Kinds of type synonym arguments
>> |
>> | Hi Richard,
>> |
>> | Now that we have levity arguments I'm wondering if we should go ahead and
>> | implement this. The code is already there - unboxed tuples have levity
>> | arguments and then type arguments depend on the levity arguments, so this
>> | works:
>> |
>> |     ?> :k (# Int, Int# #)
>> |     (# Int, Int# #) :: #
>> |
>> | But this doesn't because boxed tuples are not implemented that way:
>> |
>> |     ?> :k ( Int, Int# )
>> |
>> |     <interactive>:1:8: error:
>> |         ? Expecting a lifted type, but ?Int#? is unlifted
>> |         ? In the type ?(Int, Int#)?
>> |
>> | The implementation looked fairly simple so I just tried to lift this
>> | restriction (I basically merged the code that generates TyCons and DataCons
>> | for
>> | unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
>> | started to panic. Should I investigate this further or are there any problems
>> | with this that we need to solve first?
>> |
>> | If there's a problem with this I think we should at least add a NOTE in
>> | TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are
>> | used
>> | in unboxed tuples, but there's no comments or notes about why we don't do the
>> | same for boxed tuples.
>> |
>> | Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
>> | arguments do that work now and we no longer need OpenKind?
>> |
>> | Thanks
>> |
>> | 2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
>> | > I think this is a consequence of the rule that we never abstract over types
>> | of kind #. But I believe this should work with my branch:
>> | >
>> | >> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
>> | >
>> | > The user would have to request that the synonym be used over both * and #,
>> | but the synonym should work. The need to request the special treatment might
>> | be lifted, but we'd have to think hard about where we want the generality by
>> | default and where we want simpler behavior by default.
>> | >
>> | > Richard
>> | >
>> | > On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>> | >
>> | >> In this program:
>> | >>
>> | >>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
>> | >>
>> | >>    module Main where
>> | >>
>> | >>    import GHC.Prim
>> | >>    import GHC.Types
>> | >>
>> | >>    type Tuple a b = (# a, b #)
>> | >>
>> | >>    main = do
>> | >>      let -- x :: Tuple Int# Float#
>> | >>          x :: (# Int#, Float# #)
>> | >>          x = (# 1#, 0.0# #)
>> | >>
>> | >>      return ()
>> | >>
>> | >> If I use the first type declaration for 'x' I'm getting this error
>> | message:
>> | >>
>> | >>    Expecting a lifted type, but ?Int#? is unlifted
>> | >>
>> | >> Indeed, if I look at the kinds of arguments of 'Tuple':
>> | >>
>> | >>    ?:7> :k Tuple
>> | >>    Tuple :: * -> * -> #
>> | >>
>> | >> It's star. I was wondering why is this not 'OpenKind'(or whatever the
>> | >> super-kind of star and hash). Is there a problem with this? Is this a bug?
>> | >> Or is this simply because type synonyms are implemented before OpenKinds?
>> | >> _______________________________________________
>> | >> ghc-devs mailing list
>> | >> ghc-devs at haskell.org
>> | >>
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c308
>> | d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sYBDmz3zltvhkRvFsuo1h
>> | OiBLqO6Qsu7N0zpzUK7iPY%3d
>> | >>
>> | >
>> | _______________________________________________
>> | ghc-devs mailing list
>> | ghc-devs at haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c
>> | 308d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=A4khlPGkSRO%2f4S%2
>> | bv%2fUxEiJj9DewPXVbsuX7GAzHB0FQ%3d
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From eir at cis.upenn.edu  Wed Dec 16 04:44:35 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 15 Dec 2015 23:44:35 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
Message-ID: <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>

Yes. I completely agree with Dan.

I wasn't suggesting that boxed tuples would be able to work with unboxed arguments. I was just suggesting that it should be possible to declare a levity-polymorphic type synonym for unboxed tuples, if that's what you need.

Richard

On Dec 15, 2015, at 10:04 PM, Dan Doel <dan.doel at gmail.com> wrote:

> This is not a simple change at all, though.
> 
> The reason that (,) cannot accept arguments of kind # is not just that
> there was no levity abstraction. You simply cannot abstract over # in
> the same way as you can *, because the types in # are not represented
> uniformly. Creating a tuple with an argument of kind # would require
> generating code for (at the least) each different size of thing that
> can go in #; but there are infinitely many of those, because of
> unboxed tuples, so  you probably have to do on-demand code generation
> when particular types are used.
> 
> And of course, the evaluation conventions change between # and *, so
> you have to deal with that if tuples are supposed to accept types of
> both kinds. See the stuff at:
> 
>    https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
> 
> for instance. Note that that that page is only considering being able
> to abstract over the portion of # that is represented uniformly by a
> pointer, though. Things like Int#, Double# and (# Int#, Double #) are
> completely out of its scope.
> 
> This isn't just the typing on (,) being overly restrictive. It would
> be a pretty fundamental change that would, I assume, be non-trivial to
> implement. I think it would be non-trivial to come up with a good
> design, too, really.
> 
> -- Dan
> 
> 
> On Tue, Dec 15, 2015 at 6:25 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>> Oh sorry, I just mean that currently boxed tuples don't accept unboxed types:
>> 
>>    ?> :k ( Int#, Int )
>> 
>>    <interactive>:1:3: error:
>>        ? Expecting a lifted type, but ?Int#? is unlifted
>>        ? In the type ?(Int#, Int)?
>> 
>> But unboxed variant of exactly the same thing is accepted:
>> 
>>    ?> :k (# Int#, Int #)
>>    (# Int#, Int #) :: #
>> 
>> I was hoping make these two the same by adding levity arguments and making type
>> arguments depend on levity arguments, just like how unboxed tuple types are
>> implemented (as described in Note [Unboxed tuple levity vars]).
>> 
>> The changes in tuple DataCon and TyCon generation is fairly simple (in fact I
>> just implemented that part) but the rest of the compiler started panicking. So
>> my question is, is there a reason for not doing this, because otherwise I'd
>> like to fix panics etc. and make this change.
>> 
>> 2015-12-15 18:08 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
>>> What is "this" that you propose to implement?  Is there a wiki page that describes the design?
>>> 
>>> Simon
>>> 
>>> | -----Original Message-----
>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan
>>> | Agacan
>>> | Sent: 15 December 2015 23:06
>>> | To: Richard Eisenberg <eir at cis.upenn.edu>
>>> | Cc: ghc-devs <ghc-devs at haskell.org>
>>> | Subject: Re: Kinds of type synonym arguments
>>> |
>>> | Hi Richard,
>>> |
>>> | Now that we have levity arguments I'm wondering if we should go ahead and
>>> | implement this. The code is already there - unboxed tuples have levity
>>> | arguments and then type arguments depend on the levity arguments, so this
>>> | works:
>>> |
>>> |     ?> :k (# Int, Int# #)
>>> |     (# Int, Int# #) :: #
>>> |
>>> | But this doesn't because boxed tuples are not implemented that way:
>>> |
>>> |     ?> :k ( Int, Int# )
>>> |
>>> |     <interactive>:1:8: error:
>>> |         ? Expecting a lifted type, but ?Int#? is unlifted
>>> |         ? In the type ?(Int, Int#)?
>>> |
>>> | The implementation looked fairly simple so I just tried to lift this
>>> | restriction (I basically merged the code that generates TyCons and DataCons
>>> | for
>>> | unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
>>> | started to panic. Should I investigate this further or are there any problems
>>> | with this that we need to solve first?
>>> |
>>> | If there's a problem with this I think we should at least add a NOTE in
>>> | TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are
>>> | used
>>> | in unboxed tuples, but there's no comments or notes about why we don't do the
>>> | same for boxed tuples.
>>> |
>>> | Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
>>> | arguments do that work now and we no longer need OpenKind?
>>> |
>>> | Thanks
>>> |
>>> | 2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
>>> | > I think this is a consequence of the rule that we never abstract over types
>>> | of kind #. But I believe this should work with my branch:
>>> | >
>>> | >> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
>>> | >
>>> | > The user would have to request that the synonym be used over both * and #,
>>> | but the synonym should work. The need to request the special treatment might
>>> | be lifted, but we'd have to think hard about where we want the generality by
>>> | default and where we want simpler behavior by default.
>>> | >
>>> | > Richard
>>> | >
>>> | > On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>>> | >
>>> | >> In this program:
>>> | >>
>>> | >>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
>>> | >>
>>> | >>    module Main where
>>> | >>
>>> | >>    import GHC.Prim
>>> | >>    import GHC.Types
>>> | >>
>>> | >>    type Tuple a b = (# a, b #)
>>> | >>
>>> | >>    main = do
>>> | >>      let -- x :: Tuple Int# Float#
>>> | >>          x :: (# Int#, Float# #)
>>> | >>          x = (# 1#, 0.0# #)
>>> | >>
>>> | >>      return ()
>>> | >>
>>> | >> If I use the first type declaration for 'x' I'm getting this error
>>> | message:
>>> | >>
>>> | >>    Expecting a lifted type, but ?Int#? is unlifted
>>> | >>
>>> | >> Indeed, if I look at the kinds of arguments of 'Tuple':
>>> | >>
>>> | >>    ?:7> :k Tuple
>>> | >>    Tuple :: * -> * -> #
>>> | >>
>>> | >> It's star. I was wondering why is this not 'OpenKind'(or whatever the
>>> | >> super-kind of star and hash). Is there a problem with this? Is this a bug?
>>> | >> Or is this simply because type synonyms are implemented before OpenKinds?
>>> | >> _______________________________________________
>>> | >> ghc-devs mailing list
>>> | >> ghc-devs at haskell.org
>>> | >>
>>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c308
>>> | d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sYBDmz3zltvhkRvFsuo1h
>>> | OiBLqO6Qsu7N0zpzUK7iPY%3d
>>> | >>
>>> | >
>>> | _______________________________________________
>>> | ghc-devs mailing list
>>> | ghc-devs at haskell.org
>>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c
>>> | 308d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=A4khlPGkSRO%2f4S%2
>>> | bv%2fUxEiJj9DewPXVbsuX7GAzHB0FQ%3d
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From omeragacan at gmail.com  Wed Dec 16 19:06:25 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 16 Dec 2015 14:06:25 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
Message-ID: <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>

I understand the problem, but I was actually talking about something else. We
already have some other restrictions for polymorphism over boxed and unboxed
types. For example:

    data T a b = T a b

This has kind * -> * -> *. Similarly, kinds of 'a' and 'b' in this function are
*:

    f :: (a, b) -> a
    f (x, _) = x

I'm not trying to make this function polymorphic over both hash and start
types. I'm just trying to make something like this possible:

    f :: (Int#, b) -> b
    f (_, b) = b

Here the polymorphic part is boxed, * type. This should not be that hard, I
think. Unless on-demand code generation part as mentioned by Dan is too much
work.

In any case, this is not that big deal. When I read the code I thought this
should be a trivial change but apparently it's not.

2015-12-15 23:44 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
> Yes. I completely agree with Dan.
>
> I wasn't suggesting that boxed tuples would be able to work with unboxed arguments. I was just suggesting that it should be possible to declare a levity-polymorphic type synonym for unboxed tuples, if that's what you need.
>
> Richard
>
> On Dec 15, 2015, at 10:04 PM, Dan Doel <dan.doel at gmail.com> wrote:
>
>> This is not a simple change at all, though.
>>
>> The reason that (,) cannot accept arguments of kind # is not just that
>> there was no levity abstraction. You simply cannot abstract over # in
>> the same way as you can *, because the types in # are not represented
>> uniformly. Creating a tuple with an argument of kind # would require
>> generating code for (at the least) each different size of thing that
>> can go in #; but there are infinitely many of those, because of
>> unboxed tuples, so  you probably have to do on-demand code generation
>> when particular types are used.
>>
>> And of course, the evaluation conventions change between # and *, so
>> you have to deal with that if tuples are supposed to accept types of
>> both kinds. See the stuff at:
>>
>>    https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
>>
>> for instance. Note that that that page is only considering being able
>> to abstract over the portion of # that is represented uniformly by a
>> pointer, though. Things like Int#, Double# and (# Int#, Double #) are
>> completely out of its scope.
>>
>> This isn't just the typing on (,) being overly restrictive. It would
>> be a pretty fundamental change that would, I assume, be non-trivial to
>> implement. I think it would be non-trivial to come up with a good
>> design, too, really.
>>
>> -- Dan
>>
>>
>> On Tue, Dec 15, 2015 at 6:25 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>>> Oh sorry, I just mean that currently boxed tuples don't accept unboxed types:
>>>
>>>    ?> :k ( Int#, Int )
>>>
>>>    <interactive>:1:3: error:
>>>        ? Expecting a lifted type, but ?Int#? is unlifted
>>>        ? In the type ?(Int#, Int)?
>>>
>>> But unboxed variant of exactly the same thing is accepted:
>>>
>>>    ?> :k (# Int#, Int #)
>>>    (# Int#, Int #) :: #
>>>
>>> I was hoping make these two the same by adding levity arguments and making type
>>> arguments depend on levity arguments, just like how unboxed tuple types are
>>> implemented (as described in Note [Unboxed tuple levity vars]).
>>>
>>> The changes in tuple DataCon and TyCon generation is fairly simple (in fact I
>>> just implemented that part) but the rest of the compiler started panicking. So
>>> my question is, is there a reason for not doing this, because otherwise I'd
>>> like to fix panics etc. and make this change.
>>>
>>> 2015-12-15 18:08 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
>>>> What is "this" that you propose to implement?  Is there a wiki page that describes the design?
>>>>
>>>> Simon
>>>>
>>>> | -----Original Message-----
>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer Sinan
>>>> | Agacan
>>>> | Sent: 15 December 2015 23:06
>>>> | To: Richard Eisenberg <eir at cis.upenn.edu>
>>>> | Cc: ghc-devs <ghc-devs at haskell.org>
>>>> | Subject: Re: Kinds of type synonym arguments
>>>> |
>>>> | Hi Richard,
>>>> |
>>>> | Now that we have levity arguments I'm wondering if we should go ahead and
>>>> | implement this. The code is already there - unboxed tuples have levity
>>>> | arguments and then type arguments depend on the levity arguments, so this
>>>> | works:
>>>> |
>>>> |     ?> :k (# Int, Int# #)
>>>> |     (# Int, Int# #) :: #
>>>> |
>>>> | But this doesn't because boxed tuples are not implemented that way:
>>>> |
>>>> |     ?> :k ( Int, Int# )
>>>> |
>>>> |     <interactive>:1:8: error:
>>>> |         ? Expecting a lifted type, but ?Int#? is unlifted
>>>> |         ? In the type ?(Int, Int#)?
>>>> |
>>>> | The implementation looked fairly simple so I just tried to lift this
>>>> | restriction (I basically merged the code that generates TyCons and DataCons
>>>> | for
>>>> | unboxed and boxed tuples in WiredInTys), but some other parts of the compiler
>>>> | started to panic. Should I investigate this further or are there any problems
>>>> | with this that we need to solve first?
>>>> |
>>>> | If there's a problem with this I think we should at least add a NOTE in
>>>> | TysWiredIn. Note [Unboxed tuple levity vars] explains how levity vars are
>>>> | used
>>>> | in unboxed tuples, but there's no comments or notes about why we don't do the
>>>> | same for boxed tuples.
>>>> |
>>>> | Also, I was wondering if OpenKind is deprecated now. Can I assume that levity
>>>> | arguments do that work now and we no longer need OpenKind?
>>>> |
>>>> | Thanks
>>>> |
>>>> | 2015-12-06 21:45 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
>>>> | > I think this is a consequence of the rule that we never abstract over types
>>>> | of kind #. But I believe this should work with my branch:
>>>> | >
>>>> | >> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
>>>> | >
>>>> | > The user would have to request that the synonym be used over both * and #,
>>>> | but the synonym should work. The need to request the special treatment might
>>>> | be lifted, but we'd have to think hard about where we want the generality by
>>>> | default and where we want simpler behavior by default.
>>>> | >
>>>> | > Richard
>>>> | >
>>>> | > On Dec 6, 2015, at 1:55 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>>>> | >
>>>> | >> In this program:
>>>> | >>
>>>> | >>    {-# LANGUAGE MagicHash, UnboxedTuples #-}
>>>> | >>
>>>> | >>    module Main where
>>>> | >>
>>>> | >>    import GHC.Prim
>>>> | >>    import GHC.Types
>>>> | >>
>>>> | >>    type Tuple a b = (# a, b #)
>>>> | >>
>>>> | >>    main = do
>>>> | >>      let -- x :: Tuple Int# Float#
>>>> | >>          x :: (# Int#, Float# #)
>>>> | >>          x = (# 1#, 0.0# #)
>>>> | >>
>>>> | >>      return ()
>>>> | >>
>>>> | >> If I use the first type declaration for 'x' I'm getting this error
>>>> | message:
>>>> | >>
>>>> | >>    Expecting a lifted type, but ?Int#? is unlifted
>>>> | >>
>>>> | >> Indeed, if I look at the kinds of arguments of 'Tuple':
>>>> | >>
>>>> | >>    ?:7> :k Tuple
>>>> | >>    Tuple :: * -> * -> #
>>>> | >>
>>>> | >> It's star. I was wondering why is this not 'OpenKind'(or whatever the
>>>> | >> super-kind of star and hash). Is there a problem with this? Is this a bug?
>>>> | >> Or is this simply because type synonyms are implemented before OpenKinds?
>>>> | >> _______________________________________________
>>>> | >> ghc-devs mailing list
>>>> | >> ghc-devs at haskell.org
>>>> | >>
>>>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>>>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c308
>>>> | d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sYBDmz3zltvhkRvFsuo1h
>>>> | OiBLqO6Qsu7N0zpzUK7iPY%3d
>>>> | >>
>>>> | >
>>>> | _______________________________________________
>>>> | ghc-devs mailing list
>>>> | ghc-devs at haskell.org
>>>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
>>>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>>> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce7184dc9345c4f9123c
>>>> | 308d305a4631f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=A4khlPGkSRO%2f4S%2
>>>> | bv%2fUxEiJj9DewPXVbsuX7GAzHB0FQ%3d
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From jan.stolarek at p.lodz.pl  Wed Dec 16 19:21:26 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 16 Dec 2015 20:21:26 +0100
Subject: Open data kinds
Message-ID: <201512162021.27013.jan.stolarek@p.lodz.pl>

Devs,

I plan to work on implementing open data kinds (#11080). The idea is that users will be allowed to 
declare open kinds and then populate them with member types. Perhaps I will also implement closed 
data kinds. This is already possible using DataKinds, but the idea is to declare a data kind 
without corresponding data type - see #6024.

Now, consider this declaration (syntax subject to bikeshedding):

  kind K = T

In what namespace should T go: type namespace or data constructor namespace? If we put it in type 
namespace then it is possible for the user to declare a data constructor T that is completely 
unrelated to type T belonging to kind K. This might be confusing. If we put T in the data 
namespace then we miss the point of #6024.

Thoughts?

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.

From eir at cis.upenn.edu  Wed Dec 16 22:22:51 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 16 Dec 2015 17:22:51 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
 <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
Message-ID: <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>


On Dec 16, 2015, at 2:06 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
> 
> In any case, this is not that big deal. When I read the code I thought this
> should be a trivial change but apparently it's not.

No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed things. And changing that is far from trivial. It's not the polymorphism that's the problem -- it's the unboxed thing in a boxed tuple.

Richard

From eir at cis.upenn.edu  Thu Dec 17 03:34:41 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 16 Dec 2015 22:34:41 -0500
Subject: Harbormaster acting up?
Message-ID: <0AF4B25C-67B0-4D86-9A4F-DE196BC5C3BD@cis.upenn.edu>

Hi devs,

Is Harbormaster acting up? I saw today two out-of-memory failures, including this one (https://phabricator.haskell.org/harbormaster/build/9150/), which happens when building the stage-1 compiler. That means that an off-the-shelf GHC is the one that's running out of memory.

Separately, a comments-only patch didn't validate (https://phabricator.haskell.org/harbormaster/build/9148/).

Any hints?

Thanks!
Richard

From eir at cis.upenn.edu  Thu Dec 17 03:55:07 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 16 Dec 2015 22:55:07 -0500
Subject: Open data kinds
In-Reply-To: <201512162021.27013.jan.stolarek@p.lodz.pl>
References: <201512162021.27013.jan.stolarek@p.lodz.pl>
Message-ID: <22BB132B-D635-42A8-87B5-8AF24608EED8@cis.upenn.edu>

Janek and I discussed this issue this morning, and I would like to state my opinion and state my case:

 * In `kind K = T`, `T` should live in the data-level namespace.

Of course, if `T` is used in a term-level expression, an error should be issued, because T logically lives only in types.

To explain why I feel this way, it's helpful to reflect on the 4 namespaces Haskell currently has. I will refer to these by number.

1. Term-level data constructors and pattern synonyms
2. Types, classes, and type constructors
3. Term-level variables and globals
4. Type variables

The debate at hand only involves 1 and 2. We are adding a new feature to the language. Should it go in namespace 1 or namespace 2? To help decide, it would be nice to have a general principle of what goes in 1 and what goes in 2. Here is one possible principle:

A. Namespace 1 contains runtime things; namespace 2 contains compile-time things.

Principle A has served us well for some time. But it's failing us now. With DataKinds, we can use namespace-1 things at compile-time. And some of us have been scheming for a way to use namespace-2 things at runtime. So Principle A doesn't seem quite right. Instead, I propose

B. Namespace 1 contains data constructors (and, closely related, pattern synonyms); namespace 2 contains datatypes (and, closely related, classes).

Up until DataKinds, Principles A and B have coincided. But now they have diverged, and only Principle B serves to describe what's going on.

(Aside: When you say True in a type, and it's in scope, that's because GHC looks in namespace 2 first; failing that, it looks in namespace 1. DataKinds never copies namespace-1 things into namespace 2.)

If we thus adopt Principle B, then we indeed want `T` from the example to live in namespace 1. It is a data constructor. One might argue that this is a misnomer, because T lives only at compile time. T indeed does live only at compile time, but it still is a data constructor -- it constructs compile-time data. (Just like using 'True in a type doesn't make 'True any less of a data constructor.)

A noted drawback of Principle B is that it means that compile-time only definitions "pollute" namespace 1. That's true. But it need be only local, as you're free to make namespace-2 type synonyms that refer to namespace-1 data constructors. And it's quite straightforward to ensure that `T` is never present at runtime -- it's just a straightforward check in the typechecker.

Thus, according to general Principle B, `T` should be in namespace 1.

What do you think?

Richard

On Dec 16, 2015, at 2:21 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> Devs,
> 
> I plan to work on implementing open data kinds (#11080). The idea is that users will be allowed to 
> declare open kinds and then populate them with member types. Perhaps I will also implement closed 
> data kinds. This is already possible using DataKinds, but the idea is to declare a data kind 
> without corresponding data type - see #6024.
> 
> Now, consider this declaration (syntax subject to bikeshedding):
> 
>  kind K = T
> 
> In what namespace should T go: type namespace or data constructor namespace? If we put it in type 
> namespace then it is possible for the user to declare a data constructor T that is completely 
> unrelated to type T belonging to kind K. This might be confusing. If we put T in the data 
> namespace then we miss the point of #6024.
> 
> Thoughts?
> 
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From ben at well-typed.com  Thu Dec 17 10:02:33 2015
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 17 Dec 2015 11:02:33 +0100
Subject: Harbormaster acting up?
In-Reply-To: <0AF4B25C-67B0-4D86-9A4F-DE196BC5C3BD@cis.upenn.edu>
References: <0AF4B25C-67B0-4D86-9A4F-DE196BC5C3BD@cis.upenn.edu>
Message-ID: <8737v175qe.fsf@smart-cactus.org>

Richard Eisenberg <eir at cis.upenn.edu> writes:

> Hi devs,
>
> Is Harbormaster acting up? I saw today two out-of-memory failures,
> including this one
> (https://phabricator.haskell.org/harbormaster/build/9150/), which
> happens when building the stage-1 compiler. That means that an
> off-the-shelf GHC is the one that's running out of memory.
>
> Separately, a comments-only patch didn't validate
> (https://phabricator.haskell.org/harbormaster/build/9148/).
>
Yes, Harbormaster has been stuggling a great deal recently due to the
high volume of commits and differentials that we have been experiencing
leading up to the feature freeze.

Of course, in principle this shouldn't result in validations failing.
Sadly, Harbormaster leaves a great deal to be desired when it comes to
resource management as there is no way to limit the number of concurrent
builds which which it launches. Consequently even our quite substantial
build machine eventually starts thrashing under high patch volume.

I have some ideas on how to rework our build process to work around this
insanity but I'm very much out of bandwidth at the moment. It certainly
won't happen before next week.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/1822475a/attachment.sig>

From m at tweag.io  Thu Dec 17 10:22:35 2015
From: m at tweag.io (Boespflug, Mathieu)
Date: Thu, 17 Dec 2015 11:22:35 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <8737v5i1zw.fsf@smart-cactus.org>
References: <8737v5i1zw.fsf@smart-cactus.org>
Message-ID: <CAJ0eudrir105ZS-cMRoubbm0_t83Z5YZ+2oJuHpD=4TmXbZTqQ@mail.gmail.com>

Hi Ben,

does GHC HEAD include the cleanup to the Typeable story detailed here,
https://ghc.haskell.org/trac/ghc/wiki/Typeable? My understanding was that
this blocked on kind equalities, which was merged just recently. See this
quote from that page:

> Step 3 (allowing TypeRep to be fully decomposed in a type safe way)
absolutely requires kind equalities.

Making static pointers safe in GHC 8.0 is dependent on a solution to this
particular issue.

--
Mathieu Boespflug
Founder at http://tweag.io.

On 14 December 2015 at 14:38, Ben Gamari <ben at well-typed.com> wrote:

> Hello GHCers,
>
> Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in
> `master`. Being one of the defining features of the 8.0 release, we bent
> the feature freeze schedule (initially slated for sometime last week) a
> bit to accomodate this piece of work.
>
> Now that Richard's work is in, we will set the official freeze date for
> Monday December 21st so that there is time to review and merge some
> queued work which we've been queuing for after the no-kinds merge. If
> you have work still outstanding then you should talk to either me or
> Austin ASAP if you have not done so already. We will be discussing the
> release schedule for 8.0 during the GHC today.
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/e0356f57/attachment-0001.html>

From simonpj at microsoft.com  Thu Dec 17 10:59:54 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Dec 2015 10:59:54 +0000
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <CAJ0eudrir105ZS-cMRoubbm0_t83Z5YZ+2oJuHpD=4TmXbZTqQ@mail.gmail.com>
References: <8737v5i1zw.fsf@smart-cactus.org>
 <CAJ0eudrir105ZS-cMRoubbm0_t83Z5YZ+2oJuHpD=4TmXbZTqQ@mail.gmail.com>
Message-ID: <9a0c9aa6c21b4faf8a134d2dd4daaa71@DB4PR30MB030.064d.mgd.msft.net>

Mathieu

I?m afraid not.   The underlying technology is there, since this week.  But we need to think carefully about the transition (since it?s a big library change), and I simply have not had time to do that.  Moreover not everything about the new library design is settled.

So we decided to get 8.0 out and then work with the community on exactly what the new API should be.  I?m actually delighted that you are still engaged with this (haven?t heard much from you for a while), and I?d like to start on it in the new year.

Would you be prepared to be an active participant?  Or even be the lead player?  I?ve written a paper that I?ll put up shortly that goes through the idea of type-indexed type representations in some detail.

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Boespflug, Mathieu
Sent: 17 December 2015 10:23
To: Ben Gamari <ben at well-typed.com>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: GHC 8.0 feature freeze imminent

Hi Ben,

does GHC HEAD include the cleanup to the Typeable story detailed here, https://ghc.haskell.org/trac/ghc/wiki/Typeable? My understanding was that this blocked on kind equalities, which was merged just recently. See this quote from that page:

> Step 3 (allowing TypeRep to be fully decomposed in a type safe way) absolutely requires kind equalities.

Making static pointers safe in GHC 8.0 is dependent on a solution to this particular issue.

--
Mathieu Boespflug
Founder at http://tweag.io<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftweag.io&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c47c4601236bb42c613da08d306cbfceb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jwGpXBMlioRlwNF9SFMAySihr8UjY%2bFtcBzVb4NZtDA%3d>.

On 14 December 2015 at 14:38, Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:
Hello GHCers,

Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in
`master`. Being one of the defining features of the 8.0 release, we bent
the feature freeze schedule (initially slated for sometime last week) a
bit to accomodate this piece of work.

Now that Richard's work is in, we will set the official freeze date for
Monday December 21st so that there is time to review and merge some
queued work which we've been queuing for after the no-kinds merge. If
you have work still outstanding then you should talk to either me or
Austin ASAP if you have not done so already. We will be discussing the
release schedule for 8.0 during the GHC today.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c47c4601236bb42c613da08d306cbfceb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OspWIA6BEowkcxcdnrIJTDFZ85q2cNABaFxsufhxgIQ%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/4ec619f3/attachment.html>

From ben at well-typed.com  Thu Dec 17 11:47:35 2015
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 17 Dec 2015 12:47:35 +0100
Subject: GHC 8.0 feature freeze imminent
In-Reply-To: <CAJ0eudrir105ZS-cMRoubbm0_t83Z5YZ+2oJuHpD=4TmXbZTqQ@mail.gmail.com>
References: <8737v5i1zw.fsf@smart-cactus.org>
 <CAJ0eudrir105ZS-cMRoubbm0_t83Z5YZ+2oJuHpD=4TmXbZTqQ@mail.gmail.com>
Message-ID: <87vb7x5maw.fsf@smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi Ben,
>
> does GHC HEAD include the cleanup to the Typeable story detailed here,
> https://ghc.haskell.org/trac/ghc/wiki/Typeable? My understanding was that
> this blocked on kind equalities, which was merged just recently. See this
> quote from that page:
>
Sadly no. As far as I can recall we didn't have anyone with the
bandwidth to work through the interface details and implementation.

Sorry for the bad news! Perhaps you'd be interested in picking this up
for 8.2?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/77a4eff4/attachment.sig>

From simonpj at microsoft.com  Thu Dec 17 12:52:48 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Dec 2015 12:52:48 +0000
Subject: question about coercions between primitive types in STG level
In-Reply-To: <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
 <5665D692.30506@gmail.com>
 <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>
Message-ID: <b37d61af867b435b96ec5bb3d03dc6ec@DB4PR30MB030.064d.mgd.msft.net>

Omer

Honestly I'm out of my depth here, and so time-poor that I don't think I can realistically help much.  I hope others can be more useful!

Simon

|  -----Original Message-----
|  From: ?mer Sinan A?acan [mailto:omeragacan at gmail.com]
|  Sent: 10 December 2015 02:46
|  To: Simon Marlow <marlowsd at gmail.com>; Simon Peyton Jones
|  <simonpj at microsoft.com>; ghc-devs <ghc-devs at haskell.org>; rwbarton at gmail.com
|  Subject: Re: question about coercions between primitive types in STG level
|  
|  Thanks for all the answers,
|  
|  Simon, do you remember anything about the ticket about converting between
|  floating point types and integers? I spend quite a bit of time in Trac
|  searching for this but couldn't find it.
|  
|  
|  Before implementing a new primop, MachOp, and code generation functions for
|  that I tried this: Since type signature of this new primop will be same as
|  float2Int# I thought maybe I should first make current implementation
|  working, and then I can just change the primop to coerceFloat2Int# and it
|  would work.
|  
|  However I'm still this same problem(illegal assembly). What I changed is I
|  looked at the GHC-generated, working STG code that uses float2Int#, and
|  tried to generate a very similar code myself. The change I had to make for
|  this was to use a case expression instead of let expression to bind result
|  of this primop.
|  
|  Here's an example. This STG is working fine:
|  
|      sat_s1Ic :: GHC.Types.Float ->
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Types.IO&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=BnXCV6rCnP5ibif0LwHYctTd6BVA85horA1D
|  1Uketrk%3d () =
|          \r srt:SRT:[0B :-> System.IO.print,
|                      rUB :-> GHC.Show.$fShowInt] [ds_s1I7]
|              case
|                  ds_s1I7 :: GHC.Types.Float :: Alg GHC.Types.Float
|              of
|              (wild_s1I8 :: GHC.Types.Float)
|              { GHC.Types.F# (f_s1I9 :: GHC.Prim.Float#) ->
|                    case
|                        float2Int# [(f_s1I9 :: GHC.Prim.Float#)] :: Prim
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#
|                    of
|                    (sat_s1Ia ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#)
|                    { __DEFAULT ->
|                          let {
|                            sat_s1Ib ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Types.Int&data=01%7c0
|  1%7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=SP%2fVPreBotFEHkZyK2Y1YSX30dEjkei6h
|  PARLyK11Yw%3d =
|                                NO_CCS GHC.Types.I#! [(sat_s1Ia ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#)];
|                          } in
|                            System.IO.print
|                              :: forall a_aUq. GHC.Show.Show a_aUq => a_aUq ->
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Types.IO&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=BnXCV6rCnP5ibif0LwHYctTd6BVA85horA1D
|  1Uketrk%3d ()
|                                (GHC.Show.$fShowInt :: GHC.Show.Show
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Types.Int&data=01%7c0
|  1%7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=SP%2fVPreBotFEHkZyK2Y1YSX30dEjkei6h
|  PARLyK11Yw%3d)
|                                (sat_s1Ib ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Types.Int&data=01%7c0
|  1%7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72
|  f988bf86f141af91ab2d7cd011db47%7c1&sdata=SP%2fVPreBotFEHkZyK2Y1YSX30dEjkei6h
|  PARLyK11Yw%3d);
|                    };
|              };
|  
|  (Sorry for extra noisy output, I changed Outputable instances to print some
|  extra info)
|  
|  This code is generated by GHC for a program that uses the primop directly
|  and it's working. This is the code generated by my pass:
|  
|      Main.main2 :: [GHC.Types.Char] =
|          \u srt:SRT:[r4 :-> Main.showEither2] []
|              case
|                  case
|                      float2Int# [1.2#] :: Prim
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#
|                  of
|                  (co_g21m ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#)
|                  { __DEFAULT -> (#,#) [2## (co_g21m ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#)];
|                  } :: UbxTup 2
|              of
|              (sat_s21b :: (#
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#,
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d# #))
|              { (#,#) (sat_g21R ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#) (sat_g21S ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#) ->
|                    Main.showEither2
|                      :: (#
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#,
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d# #) -> [GHC.Types.Char]
|                        (sat_g21R ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#) (sat_g21S ::
|  https://na01.safelinks.protection.outlook.com/?url=GHC.Prim.Int&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7c72f
|  988bf86f141af91ab2d7cd011db47%7c1&sdata=GMVWFJOAJ4IZj2t9WZ2hX3h7xm7U7Dbn0OfU
|  gjON958%3d#);
|              };
|  
|  Types look correct, and I'm using a case expression to bind the result of
|  the primop. But generated assembly for this is still invalid! I'm wondering
|  if there are some invariants that I'm invalidating here, even although -
|  dstg-lint is passing. Does anyone know what I might be doing wrong here?
|  
|  One thing that I'm not being very careful is the information about live
|  variables, but I don't see how it might be related with this illegal
|  instruction error.
|  
|  Thanks again..
|  
|  2015-12-07 13:57 GMT-05:00 Simon Marlow <marlowsd at gmail.com>:
|  > Simon's right, you need an explicit conversion, and unfortunately
|  > those conversions don't currently exist.  You would have to add them
|  > to the MachOp type, and implement them in each of the native code
|  generators.
|  >
|  > The good news is that if you did this, we could implement cheap
|  > conversions between the IEEE floating point types and their
|  > representations as unboxed integers, which is currently done by poking
|  > the values to memory and then peeking them back at the desired type.
|  > There's a ticket for this around somewhere....
|  >
|  > Cheers
|  > Simon
|  >
|  >
|  > On 07/12/2015 12:23, Simon Peyton Jones wrote:
|  >>
|  >> If memory serves, there are primops for converting between unboxed
|  >> values of different widths.
|  >>
|  >> Certainly converting between a float and a non-float will require an
|  >> instruction on some architectures, since they use different register
|  sets.
|  >>
|  >> Re (2) I have no idea.  You'll need to get more information...
|  >> pprTrace or something.
|  >>
|  >> Simon
|  >>
|  >> |  -----Original Message-----
|  >> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  >> | ?mer  Sinan Agacan
|  >> |  Sent: 06 December 2015 18:25
|  >> |  To: ghc-devs <ghc-devs at haskell.org>
|  >> |  Subject: question about coercions between primitive types in STG
|  >> | level
|  >> |
|  >> |  Hi all,
|  >> |
|  >> |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some
|  >> | unsafe  coercions at the STG level. It works fine for lifted types,
|  >> | but for  unlifted ones I'm having some problems. What I'm trying to
|  >> | do is given  a number of primitive types I'm finding the one with
|  >> | biggest size, and  then generating a constructor that takes this
|  >> | biggest primitive type  as argument.
|  >> |
|  >> |  The problem is that this is not working very well - GHC is
|  >> | generating  illegal instructions that try to load a F32 value to a
|  >> | register  allocated for I64, using movss instruction.
|  >> |
|  >> |  CoreLint is catching this error and printing this:
|  >> |
|  >> |      Cmm lint error:
|  >> |        in basic block c1hF
|  >> |          in assignment:
|  >> |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
|  >> |            Reg ty: I64
|  >> |            Rhs ty: F32
|  >> |
|  >> |  So I have two questions about this:
|  >> |
|  >> |  1. Is there a way to safely do this? What are my options here?
|  >> | What  I'm trying
|  >> |     to do is to use a single data constructor field for different
|  >> | primitive
|  >> |     types.  The field is guaranteed to be as big as necessary.
|  >> |
|  >> |  2. In the Cmm code shown above, the type annotation is showing
|  >> | `W32`  but in the
|  >> |     error message it says `F32`. I'm confused about this, is this
|  >> | error  message
|  >> |     given because the sizes don't match? (64bits vs 32bits) Why the
|  >> | type
|  >> |     annotation says W32 while the value has type F32?
|  >> |
|  >> |  Thanks..
|  >> |  _______________________________________________
|  >> |  ghc-devs mailing list
|  >> |  ghc-devs at haskell.org
|  >> |
|  >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai
|  >> | l.h
|  >> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  >> |
|  >> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa625
|  >> | 4e5
|  >> |
|  >> | 2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3f
|  >> | Qs4  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d
|  >> _______________________________________________
|  >> ghc-devs mailing list
|  >> ghc-devs at haskell.org
|  >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.
|  >> haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7c
|  >> simonpj%40064d.mgd.microsoft.com%7c900655295d074c8b867b08d3010c2165%7
|  >> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DYbGX1f9UBqSTEN9qDWBiqM9H
|  >> ucMEitgBCnh4ZZjneg%3d
|  >>
|  >

From marlowsd at gmail.com  Thu Dec 17 17:15:34 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 17 Dec 2015 17:15:34 +0000
Subject: question about coercions between primitive types in STG level
In-Reply-To: <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
 <5665D692.30506@gmail.com>
 <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>
Message-ID: <5672EDB6.70901@gmail.com>

On 10/12/2015 02:45, ?mer Sinan A?acan wrote:
> Thanks for all the answers,
>
> Simon, do you remember anything about the ticket about converting between
> floating point types and integers? I spend quite a bit of time in Trac
> searching for this but couldn't find it.

Sorry, I searched too but I couldn't find it.  I did find an 
implementation of the conversion in GHC (ByteCodeAsm.mkLitD).

> Before implementing a new primop, MachOp, and code generation functions for
> that I tried this: Since type signature of this new primop will be same as
> float2Int# I thought maybe I should first make current implementation working,
> and then I can just change the primop to coerceFloat2Int# and it would work.
>
> However I'm still this same problem(illegal assembly). What I changed is I
> looked at the GHC-generated, working STG code that uses float2Int#, and tried
> to generate a very similar code myself. The change I had to make for this was
> to use a case expression instead of let expression to bind result of this
> primop.
>
> Here's an example. This STG is working fine:
>
>      sat_s1Ic :: GHC.Types.Float -> GHC.Types.IO () =
>          \r srt:SRT:[0B :-> System.IO.print,
>                      rUB :-> GHC.Show.$fShowInt] [ds_s1I7]
>              case
>                  ds_s1I7 :: GHC.Types.Float :: Alg GHC.Types.Float
>              of
>              (wild_s1I8 :: GHC.Types.Float)
>              { GHC.Types.F# (f_s1I9 :: GHC.Prim.Float#) ->
>                    case
>                        float2Int# [(f_s1I9 :: GHC.Prim.Float#)] :: Prim
> GHC.Prim.Int#
>                    of
>                    (sat_s1Ia :: GHC.Prim.Int#)
>                    { __DEFAULT ->
>                          let {
>                            sat_s1Ib :: GHC.Types.Int =
>                                NO_CCS GHC.Types.I#! [(sat_s1Ia ::
> GHC.Prim.Int#)];
>                          } in
>                            System.IO.print
>                              :: forall a_aUq. GHC.Show.Show a_aUq =>
> a_aUq -> GHC.Types.IO ()
>                                (GHC.Show.$fShowInt :: GHC.Show.Show
> GHC.Types.Int)
>                                (sat_s1Ib :: GHC.Types.Int);
>                    };
>              };
>
> (Sorry for extra noisy output, I changed Outputable instances to print some
> extra info)
>
> This code is generated by GHC for a program that uses the primop directly and
> it's working. This is the code generated by my pass:
>
>      Main.main2 :: [GHC.Types.Char] =
>          \u srt:SRT:[r4 :-> Main.showEither2] []
>              case
>                  case
>                      float2Int# [1.2#] :: Prim GHC.Prim.Int#
>                  of
>                  (co_g21m :: GHC.Prim.Int#)
>                  { __DEFAULT -> (#,#) [2## (co_g21m :: GHC.Prim.Int#)];
>                  } :: UbxTup 2
>              of
>              (sat_s21b :: (# GHC.Prim.Int#, GHC.Prim.Int# #))
>              { (#,#) (sat_g21R :: GHC.Prim.Int#) (sat_g21S :: GHC.Prim.Int#) ->
>                    Main.showEither2
>                      :: (# GHC.Prim.Int#, GHC.Prim.Int# #) -> [GHC.Types.Char]
>                        (sat_g21R :: GHC.Prim.Int#) (sat_g21S :: GHC.Prim.Int#);
>              };
>
> Types look correct, and I'm using a case expression to bind the result of the
> primop. But generated assembly for this is still invalid! I'm wondering if
> there are some invariants that I'm invalidating here, even although -dstg-lint
> is passing. Does anyone know what I might be doing wrong here?
>
> One thing that I'm not being very careful is the information about live
> variables, but I don't see how it might be related with this illegal
> instruction error.

I'm not sure what you did to get to this point, but let me elaborate on 
what I think is needed:

- Add primops for the conversions
- Add appropriate MachOps for the conversions (F32 -> I32, F64 -> I64)
- Make sure the primops get compiled into the appropriate MachOps (see 
StgCmmPrim)
- Implement those MachOps in the native code generator (X86/CodeGen.hs). 
  For this part you'll need to figure out what the appropriate 
x86/x86_64 instructions to generate are; it may be that you need to go 
via memory, which would be unfortunate.

Cheers,
Simon

> Thanks again..
>
> 2015-12-07 13:57 GMT-05:00 Simon Marlow <marlowsd at gmail.com>:
>> Simon's right, you need an explicit conversion, and unfortunately those
>> conversions don't currently exist.  You would have to add them to the MachOp
>> type, and implement them in each of the native code generators.
>>
>> The good news is that if you did this, we could implement cheap conversions
>> between the IEEE floating point types and their representations as unboxed
>> integers, which is currently done by poking the values to memory and then
>> peeking them back at the desired type. There's a ticket for this around
>> somewhere....
>>
>> Cheers
>> Simon
>>
>>
>> On 07/12/2015 12:23, Simon Peyton Jones wrote:
>>>
>>> If memory serves, there are primops for converting between unboxed values
>>> of different widths.
>>>
>>> Certainly converting between a float and a non-float will require an
>>> instruction on some architectures, since they use different register sets.
>>>
>>> Re (2) I have no idea.  You'll need to get more information... pprTrace or
>>> something.
>>>
>>> Simon
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
>>> |  Sinan Agacan
>>> |  Sent: 06 December 2015 18:25
>>> |  To: ghc-devs <ghc-devs at haskell.org>
>>> |  Subject: question about coercions between primitive types in STG level
>>> |
>>> |  Hi all,
>>> |
>>> |  In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe
>>> |  coercions at the STG level. It works fine for lifted types, but for
>>> |  unlifted ones I'm having some problems. What I'm trying to do is given
>>> |  a number of primitive types I'm finding the one with biggest size, and
>>> |  then generating a constructor that takes this biggest primitive type
>>> |  as argument.
>>> |
>>> |  The problem is that this is not working very well - GHC is generating
>>> |  illegal instructions that try to load a F32 value to a register
>>> |  allocated for I64, using movss instruction.
>>> |
>>> |  CoreLint is catching this error and printing this:
>>> |
>>> |      Cmm lint error:
>>> |        in basic block c1hF
>>> |          in assignment:
>>> |            _g16W::I64 = 4.5 :: W32;   // CmmAssign
>>> |            Reg ty: I64
>>> |            Rhs ty: F32
>>> |
>>> |  So I have two questions about this:
>>> |
>>> |  1. Is there a way to safely do this? What are my options here? What
>>> |  I'm trying
>>> |     to do is to use a single data constructor field for different
>>> |  primitive
>>> |     types.  The field is guaranteed to be as big as necessary.
>>> |
>>> |  2. In the Cmm code shown above, the type annotation is showing `W32`
>>> |  but in the
>>> |     error message it says `F32`. I'm confused about this, is this error
>>> |  message
>>> |     given because the sizes don't match? (64bits vs 32bits) Why the
>>> |  type
>>> |     annotation says W32 while the value has type F32?
>>> |
>>> |  Thanks..
>>> |  _______________________________________________
>>> |  ghc-devs mailing list
>>> |  ghc-devs at haskell.org
>>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
>>> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ced6a1fbfa6254e5
>>> |  2a7d808d2fe6a9a63%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7j3fQs4
>>> |  ox67SZbA4jv4uPVVdvp5X5yUUuMaqp4sh%2fpg%3d
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>

From simonpj at microsoft.com  Thu Dec 17 17:49:31 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Dec 2015 17:49:31 +0000
Subject: ghc-split??
Message-ID: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>

I?m getting this with a clean HEAD on Linux.  Any ideas?
Simon

ghc-stage1: could not execute: /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/ea6fc35f/attachment.html>

From ben at well-typed.com  Thu Dec 17 17:52:43 2015
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 17 Dec 2015 18:52:43 +0100
Subject: question about coercions between primitive types in STG level
In-Reply-To: <5672EDB6.70901@gmail.com>
References: <CAMQQO3nRvcu65DiC6VptKPB5DKdnzd+PNp1SOyyx4Us2WjUw7Q@mail.gmail.com>
 <c561075644d74f6c86f705c42c364f8a@DB4PR30MB030.064d.mgd.msft.net>
 <5665D692.30506@gmail.com>
 <CAMQQO3=x+xRFf11e-MYVH-2VW18-yMWNthfBcD4J2DvF2VJedg@mail.gmail.com>
 <5672EDB6.70901@gmail.com>
Message-ID: <871talj72s.fsf@smart-cactus.org>

Simon Marlow <marlowsd at gmail.com> writes:

> I'm not sure what you did to get to this point, but let me elaborate on 
> what I think is needed:
>
> - Add primops for the conversions
> - Add appropriate MachOps for the conversions (F32 -> I32, F64 -> I64)
> - Make sure the primops get compiled into the appropriate MachOps (see 
> StgCmmPrim)
> - Implement those MachOps in the native code generator (X86/CodeGen.hs). 
> 
>   For this part you'll need to figure out what the appropriate 
> x86/x86_64 instructions to generate are; it may be that you need to go 
> via memory, which would be unfortunate.
>
?mer,

LLVM can be a useful tool for working out proper instruction generation.
You may find this LLVM snippet helpful (along with some simplified
output),

$ cat hi.ll
define i32 @float_to_int(float %x) {
        %x1 = fadd float 1.0, %x;
        %y = bitcast float %x1 to i32;
        ret i32 %y;
}

define i64 @double_to_int(double %x) {
        %x1 = fadd double 0.1, %x;
        %y = bitcast double %x1 to i64;
        ret i64 %y;
}
$ llc hi.ll --march=x86 && cat hi.s
float_to_int:                           # @float_to_int
	fld1
	fadds	8(%esp)
	fstps	(%esp)
	movl	(%esp), %eax
	popl	%edx
	retl

double_to_int:                          # @double_to_int
	fldl	16(%esp)
	faddl	.LCPI1_0
	fstpl	(%esp)
	movl	(%esp), %eax
	movl	4(%esp), %edx
	addl	$12, %esp
	retl

$ llc hi.ll --march=x86_64 && cat hi.s
float_to_int:                           # @float_to_int
	addss	.LCPI0_0(%rip), %xmm0
	movd	%xmm0, %eax

double_to_int:                          # @double_to_int
	addsd	.LCPI1_0(%rip), %xmm0
	movd	%xmm0, %rax
	retq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/e61afd7d/attachment.sig>

From ben at smart-cactus.org  Thu Dec 17 18:00:41 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 17 Dec 2015 19:00:41 +0100
Subject: ghc-split??
In-Reply-To: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>
References: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87y4cths52.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> I?m getting this with a clean HEAD on Linux.  Any ideas?
> Simon
>
> ghc-stage1: could not execute: /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split

Interesting: this binary is inplace/lib/ghc-split in my local tree. Does
this exist?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/75d55853/attachment.sig>

From eir at cis.upenn.edu  Thu Dec 17 18:16:28 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 17 Dec 2015 13:16:28 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_6JKpGYkNUGxMo-FJu5vbXTE0uyi8LqO2g=iADfDXFnFA@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
 <CAEwUq_6JKpGYkNUGxMo-FJu5vbXTE0uyi8LqO2g=iADfDXFnFA@mail.gmail.com>
Message-ID: <F2265856-C384-45F2-9CAA-FA8CB58AACD8@cis.upenn.edu>


On Dec 17, 2015, at 8:15 AM, George Karachalias <george.karachalias at gmail.com> wrote:

> What do you think? I have already implemented a first patch with two options: If the number of
> guards is small run the check and say nothing. If not, check for 2 possible flags:
> -fwarn-pattern-guards           ==> Give it your best
> -fwarn-ignore-pattern-guards ==> Do not run the check on the cases with many guards without a warning
> None of the two enabled?     ==> Give a warning of the form:
> 
> T783.hs:4:1: warning:
>     Pattern match checking failed for an equation for foo
>     due to the big number of guards
>       (Use -fwarn-ignore-pattern-guards if you want to hide this message
>        or -fwarn-pattern-guards if you want the checker to run no matter what)
I don't have much comment on your implementation techniques, as I don't know this end of the operation well enough to have an opinion.

For the point above: what if both flags are enabled?

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/51b1c8f0/attachment.html>

From eir at cis.upenn.edu  Thu Dec 17 18:37:03 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 17 Dec 2015 13:37:03 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_6_cJs75wbT3DrzWea9z+rjFU-KsaWy2M_dnbPMS+MkGg@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
 <CAEwUq_6JKpGYkNUGxMo-FJu5vbXTE0uyi8LqO2g=iADfDXFnFA@mail.gmail.com>
 <F2265856-C384-45F2-9CAA-FA8CB58AACD8@cis.upenn.edu>
 <CAEwUq_6_cJs75wbT3DrzWea9z+rjFU-KsaWy2M_dnbPMS+MkGg@mail.gmail.com>
Message-ID: <54D7C535-037C-4D1C-8C61-F9C03004A401@cis.upenn.edu>


On Dec 17, 2015, at 1:31 PM, George Karachalias <george.karachalias at gmail.com> wrote:
> 
> My single last concern is what I wrote earlier: "Flags 2 and 3 are a bit tricky: Actual bailing
> will uglify the code and make it much more complicated so I would prefer in practice to just
> check up front with a good metric whether the possibility to be non-performant is high and in
> these cases just not call the checker at all."
> 
> If we agree on this one, I am gonna wrap it up in the next 2 days. :-)

I'm quite happy with this. My thought is that if it's a bit wrong, that's OK -- we'll refine the settings over time.

Others?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/5e2d4672/attachment-0001.html>

From thomasmiedema at gmail.com  Thu Dec 17 18:57:02 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Thu, 17 Dec 2015 19:57:02 +0100
Subject: ghc-split??
In-Reply-To: <87y4cths52.fsf@smart-cactus.org>
References: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>
 <87y4cths52.fsf@smart-cactus.org>
Message-ID: <CAD3WKghhFKsZZmoYaV6N5w8m4_xCKUMxnkTUp-7maO_TwYddzQ@mail.gmail.com>

This was broken by the "Remote GHCi" patch. I'm currently validating a fix.
In the meantime you can set `SplitObjs=NO` in mk/build.mk.

On Thu, Dec 17, 2015 at 7:00 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Peyton Jones <simonpj at microsoft.com> writes:
>
> > I?m getting this with a clean HEAD on Linux.  Any ideas?
> > Simon
> >
> > ghc-stage1: could not execute:
> /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split
>
> Interesting: this binary is inplace/lib/ghc-split in my local tree. Does
> this exist?
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/4cbe21f7/attachment.html>

From thomasmiedema at gmail.com  Thu Dec 17 20:48:47 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Thu, 17 Dec 2015 21:48:47 +0100
Subject: ghc-split??
In-Reply-To: <CAD3WKghhFKsZZmoYaV6N5w8m4_xCKUMxnkTUp-7maO_TwYddzQ@mail.gmail.com>
References: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>
 <87y4cths52.fsf@smart-cactus.org>
 <CAD3WKghhFKsZZmoYaV6N5w8m4_xCKUMxnkTUp-7maO_TwYddzQ@mail.gmail.com>
Message-ID: <CAD3WKggVe=p_Ph7p7P1fbL=0NmXm4s3wU7ccYCXCN_S2LgMHng@mail.gmail.com>

Fixed in
http://git.haskell.org/ghc.git/commit/c1bd3d444f8c52c688fdbea695ee0ae7f402945d

On Thu, Dec 17, 2015 at 7:57 PM, Thomas Miedema <thomasmiedema at gmail.com>
wrote:

> This was broken by the "Remote GHCi" patch. I'm currently validating a
> fix. In the meantime you can set `SplitObjs=NO` in mk/build.mk.
>
> On Thu, Dec 17, 2015 at 7:00 PM, Ben Gamari <ben at smart-cactus.org> wrote:
>
>> Simon Peyton Jones <simonpj at microsoft.com> writes:
>>
>> > I?m getting this with a clean HEAD on Linux.  Any ideas?
>> > Simon
>> >
>> > ghc-stage1: could not execute:
>> /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split
>>
>> Interesting: this binary is inplace/lib/ghc-split in my local tree. Does
>> this exist?
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151217/c33d2ebf/attachment.html>

From simonpj at microsoft.com  Fri Dec 18 08:52:27 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 Dec 2015 08:52:27 +0000
Subject: ghc-split??
In-Reply-To: <CAD3WKggVe=p_Ph7p7P1fbL=0NmXm4s3wU7ccYCXCN_S2LgMHng@mail.gmail.com>
References: <5212bf77697248a58d82f334fab85dee@DB4PR30MB030.064d.mgd.msft.net>
 <87y4cths52.fsf@smart-cactus.org>
 <CAD3WKghhFKsZZmoYaV6N5w8m4_xCKUMxnkTUp-7maO_TwYddzQ@mail.gmail.com>
 <CAD3WKggVe=p_Ph7p7P1fbL=0NmXm4s3wU7ccYCXCN_S2LgMHng@mail.gmail.com>
Message-ID: <4f7cb92d0143452db6169adac61c704e@DB4PR30MB030.064d.mgd.msft.net>

Thank you. Thomas, you are such a star? you do fix lots of corner bugs and loose ends that no one else is looking at.  You do us all a service, and I?m very grateful.

Simon

From: Thomas Miedema [mailto:thomasmiedema at gmail.com]
Sent: 17 December 2015 20:49
To: Ben Gamari <ben at smart-cactus.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-devs at haskell.org>
Subject: Re: ghc-split??

Fixed in http://git.haskell.org/ghc.git/commit/c1bd3d444f8c52c688fdbea695ee0ae7f402945d<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgit.haskell.org%2fghc.git%2fcommit%2fc1bd3d444f8c52c688fdbea695ee0ae7f402945d&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c461e0f0a2e0b4a36540908d30723769a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LeE%2fduditmrXLtuhrxueS75NEH%2fzHo30FtnFoqjz0oo%3d>

On Thu, Dec 17, 2015 at 7:57 PM, Thomas Miedema <thomasmiedema at gmail.com<mailto:thomasmiedema at gmail.com>> wrote:
This was broken by the "Remote GHCi" patch. I'm currently validating a fix. In the meantime you can set `SplitObjs=NO` in mk/build.mk<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbuild.mk&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c461e0f0a2e0b4a36540908d30723769a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ch3s94J%2bURWbId%2fi7NFcE5SArHZCDzp4qHHrWtIpS7U%3d>.

On Thu, Dec 17, 2015 at 7:00 PM, Ben Gamari <ben at smart-cactus.org<mailto:ben at smart-cactus.org>> wrote:
Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> writes:

> I?m getting this with a clean HEAD on Linux.  Any ideas?
> Simon
>
> ghc-stage1: could not execute: /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split

Interesting: this binary is inplace/lib/ghc-split in my local tree. Does
this exist?

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c461e0f0a2e0b4a36540908d30723769a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f9wxTmBATlqe1zGLoWcBS51oWQqJpr9ghRxa%2bsUhZ3I%3d>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151218/536b3193/attachment-0001.html>

From simonpj at microsoft.com  Fri Dec 18 17:40:46 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 Dec 2015 17:40:46 +0000
Subject: [commit: ghc] master: SrcLoc: Eliminate constructors of
 RealSrcSpan (987426c)
In-Reply-To: <20151218173324.E6A293A300@ghc.haskell.org>
References: <20151218173324.E6A293A300@ghc.haskell.org>
Message-ID: <0d1c47a644b44b95a9974d8bf8ced9a4@DB4PR30MB030.064d.mgd.msft.net>

Does this change yield any benefits?  Eg. if we can now unbox SrcLoc does something go faster?

S

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
|  git at git.haskell.org
|  Sent: 18 December 2015 17:33
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: SrcLoc: Eliminate constructors of RealSrcSpan
|  (987426c)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell.
|  org%2ftrac%2fghc%2fchangeset%2f987426c04fdea33d9e02c2a195d6885248b77574%2fgh
|  c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c02a06bd4542a4d06ef8008d3
|  07d17760%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SsUgj9Ei9cT5%2fuiDnBAD
|  G9cc268AQ4cx8s2t2hY94t4%3d
|  
|  >---------------------------------------------------------------
|  
|  commit 987426c04fdea33d9e02c2a195d6885248b77574
|  Author: Ben Gamari <bgamari.foss at gmail.com>
|  Date:   Fri Dec 18 17:21:22 2015 +0100
|  
|      SrcLoc: Eliminate constructors of RealSrcSpan
|  
|      This type is occurs very often but previously had multiple, meaning it
|      could not be unboxed. Even worse, these constructors didn't offer any
|      compelling safety benefits. Thankfully, the type is abstract, so
|      changing the representation to be a single-constructor type was quite
|      straightforward.
|  
|      Reviewers: austin
|  
|      Subscribers: alanz, thomie, hvr
|  
|      Differential Revision: https://phabricator.haskell.org/D1657
|  
|  
|  >---------------------------------------------------------------
|  
|  987426c04fdea33d9e02c2a195d6885248b77574
|   compiler/basicTypes/SrcLoc.hs | 95 ++++++++++++++++++----------------------
|  ---
|   1 file changed, 40 insertions(+), 55 deletions(-)
|  
|  diff --git a/compiler/basicTypes/SrcLoc.hs b/compiler/basicTypes/SrcLoc.hs
|  index e171e70..524da78 100644
|  --- a/compiler/basicTypes/SrcLoc.hs
|  +++ b/compiler/basicTypes/SrcLoc.hs
|  @@ -240,7 +240,7 @@ instance Data SrcSpan where  -}
|  
|   {- |
|  -A SrcSpan delimits a portion of a text file.  It could be represented
|  +A 'RealSrcSpan' delimits a portion of a text file.  It could be
|  +represented
|   by a pair of (line,column) coordinates, but in fact we optimise  slightly
|  by using more compact representations for single-line and  zero-length
|  spans, both of which are quite common.
|  @@ -250,28 +250,17 @@ span.  That is, a span of (1,1)-(1,2) is one character
|  long, and a  span of (1,1)-(1,1) is zero characters long.
|   -}
|   data RealSrcSpan
|  -  = SrcSpanOneLine              -- a common case: a single line
|  -        { srcSpanFile     :: !FastString,
|  -          srcSpanLine     :: {-# UNPACK #-} !Int,
|  -          srcSpanSCol     :: {-# UNPACK #-} !Int,
|  -          srcSpanECol     :: {-# UNPACK #-} !Int
|  -        }
|  -
|  -  | SrcSpanMultiLine
|  +  = RealSrcSpan'
|           { srcSpanFile     :: !FastString,
|             srcSpanSLine    :: {-# UNPACK #-} !Int,
|             srcSpanSCol     :: {-# UNPACK #-} !Int,
|             srcSpanELine    :: {-# UNPACK #-} !Int,
|             srcSpanECol     :: {-# UNPACK #-} !Int
|           }
|  -
|  -  | SrcSpanPoint
|  -        { srcSpanFile     :: !FastString,
|  -          srcSpanLine     :: {-# UNPACK #-} !Int,
|  -          srcSpanCol      :: {-# UNPACK #-} !Int
|  -        }
|     deriving (Eq, Typeable)
|  
|  +-- | A 'SrcSpan' identifies either a specific portion of a text file
|  +-- or a human-readable description of a location.
|   data SrcSpan =
|       RealSrcSpan !RealSrcSpan
|     | UnhelpfulSpan !FastString   -- Just a general indication
|  @@ -296,15 +285,11 @@ srcLocSpan (UnhelpfulLoc str) = UnhelpfulSpan str
|  srcLocSpan (RealSrcLoc l) = RealSrcSpan (realSrcLocSpan l)
|  
|   realSrcLocSpan :: RealSrcLoc -> RealSrcSpan -realSrcLocSpan (SrcLoc file
|  line col) = SrcSpanPoint file line col
|  +realSrcLocSpan (SrcLoc file line col) = RealSrcSpan' file line col line
|  +col
|  
|   -- | Create a 'SrcSpan' between two points in a file  mkRealSrcSpan ::
|  RealSrcLoc -> RealSrcLoc -> RealSrcSpan -mkRealSrcSpan loc1 loc2
|  -  | line1 == line2 = if col1 == col2
|  -                        then SrcSpanPoint file line1 col1
|  -                        else SrcSpanOneLine file line1 col1 col2
|  -  | otherwise      = SrcSpanMultiLine file line1 col1 line2 col2
|  +mkRealSrcSpan loc1 loc2 = RealSrcSpan' file line1 col1 line2 col2
|     where
|           line1 = srcLocLine loc1
|           line2 = srcLocLine loc2
|  @@ -312,6 +297,16 @@ mkRealSrcSpan loc1 loc2
|           col2 = srcLocCol loc2
|           file = srcLocFile loc1
|  
|  +-- | 'True' if the span is known to straddle only one line.
|  +isOneLineRealSpan :: RealSrcSpan -> Bool isOneLineRealSpan
|  +(RealSrcSpan' _ line1 _ line2 _)
|  +  = line1 == line2
|  +
|  +-- | 'True' if the span is a single point isPointRealSpan ::
|  +RealSrcSpan -> Bool isPointRealSpan (RealSrcSpan' _ line1 col1 line2
|  +col2)
|  +  = line1 == line2 && col1 == col2
|  +
|   -- | Create a 'SrcSpan' between two points in a file  mkSrcSpan :: SrcLoc -
|  > SrcLoc -> SrcSpan  mkSrcSpan (UnhelpfulLoc str) _ = UnhelpfulSpan str @@ -
|  331,11 +326,7 @@ combineSrcSpans (RealSrcSpan span1) (RealSrcSpan span2)
|   -- within both spans. Assumes the "file" part is the same in both inputs
|  combineRealSrcSpans :: RealSrcSpan -> RealSrcSpan -> RealSrcSpan
|  combineRealSrcSpans span1 span2
|  - = if line_start == line_end
|  -   then if col_start == col_end
|  -        then SrcSpanPoint     file line_start col_start
|  -        else SrcSpanOneLine   file line_start col_start col_end
|  -   else      SrcSpanMultiLine file line_start col_start line_end col_end
|  +  = RealSrcSpan' file line_start col_start line_end col_end
|     where
|       (line_start, col_start) = min (srcSpanStartLine span1, srcSpanStartCol
|  span1)
|                                     (srcSpanStartLine span2, srcSpanStartCol
|  span2) @@ -392,21 +383,10 @@ srcSpanEndLine :: RealSrcSpan -> Int
|  srcSpanStartCol :: RealSrcSpan -> Int  srcSpanEndCol :: RealSrcSpan -> Int
|  
|  -srcSpanStartLine SrcSpanOneLine{ srcSpanLine=l } = l -srcSpanStartLine
|  SrcSpanMultiLine{ srcSpanSLine=l } = l -srcSpanStartLine SrcSpanPoint{
|  srcSpanLine=l } = l
|  -
|  -srcSpanEndLine SrcSpanOneLine{ srcSpanLine=l } = l -srcSpanEndLine
|  SrcSpanMultiLine{ srcSpanELine=l } = l -srcSpanEndLine SrcSpanPoint{
|  srcSpanLine=l } = l
|  -
|  -srcSpanStartCol SrcSpanOneLine{ srcSpanSCol=l } = l -srcSpanStartCol
|  SrcSpanMultiLine{ srcSpanSCol=l } = l -srcSpanStartCol SrcSpanPoint{
|  srcSpanCol=l } = l
|  -
|  -srcSpanEndCol SrcSpanOneLine{ srcSpanECol=c } = c -srcSpanEndCol
|  SrcSpanMultiLine{ srcSpanECol=c } = c -srcSpanEndCol SrcSpanPoint{
|  srcSpanCol=c } = c
|  +srcSpanStartLine RealSrcSpan'{ srcSpanSLine=l } = l srcSpanEndLine
|  +RealSrcSpan'{ srcSpanELine=l } = l srcSpanStartCol RealSrcSpan'{
|  +srcSpanSCol=l } = l srcSpanEndCol RealSrcSpan'{ srcSpanECol=c } = c
|  
|   {-
|   ************************************************************************
|  @@ -462,14 +442,17 @@ instance Show RealSrcLoc where
|  
|   -- Show is used by Lexer.x, because we derive Show for Token  instance Show
|  RealSrcSpan where
|  -  show (SrcSpanOneLine file l sc ec)
|  +  show span@(RealSrcSpan' file sl sc el ec)
|  +    | isPointRealSpan span
|  +    = "SrcSpanPoint " ++ show file ++ " " ++ intercalate " " (map show
|  + [sl,sc])
|  +
|  +    | isOneLineRealSpan span
|       = "SrcSpanOneLine " ++ show file ++ " "
|  -                        ++ intercalate " " (map show [l,sc,ec])
|  -  show (SrcSpanMultiLine file sl sc el ec)
|  +                        ++ intercalate " " (map show [sl,sc,ec])
|  +
|  +    | otherwise
|       = "SrcSpanMultiLine " ++ show file ++ " "
|                             ++ intercalate " " (map show [sl,sc,el,ec])
|  -  show (SrcSpanPoint file l c)
|  -    = "SrcSpanPoint " ++ show file ++ " " ++ intercalate " " (map show
|  [l,c])
|  
|  
|   instance Outputable RealSrcSpan where
|  @@ -500,15 +483,22 @@ pprUserSpan _         (UnhelpfulSpan s) = ftext s
|   pprUserSpan show_path (RealSrcSpan s)   = pprUserRealSpan show_path s
|  
|   pprUserRealSpan :: Bool -> RealSrcSpan -> SDoc -pprUserRealSpan show_path
|  (SrcSpanOneLine src_path line start_col end_col)
|  +pprUserRealSpan show_path span@(RealSrcSpan' src_path line col _ _)
|  +  | isPointRealSpan span
|     = hcat [ ppWhen show_path (pprFastFilePath src_path <> colon)
|            , int line <> colon
|  -         , int start_col
|  -         , ppUnless (end_col - start_col <= 1) (char '-' <> int (end_col -
|  1)) ]
|  +         , int col ]
|  +
|  +pprUserRealSpan show_path span@(RealSrcSpan' src_path line scol _ ecol)
|  +  | isOneLineRealSpan span
|  +  = hcat [ ppWhen show_path (pprFastFilePath src_path <> colon)
|  +         , int line <> colon
|  +         , int scol
|  +         , ppUnless (ecol - scol <= 1) (char '-' <> int (ecol - 1)) ]
|               -- For single-character or point spans, we just
|               -- output the starting column number
|  
|  -pprUserRealSpan show_path (SrcSpanMultiLine src_path sline scol eline ecol)
|  +pprUserRealSpan show_path (RealSrcSpan' src_path sline scol eline ecol)
|     = hcat [ ppWhen show_path (pprFastFilePath src_path <> colon)
|            , parens (int sline <> comma <> int scol)
|            , char '-'
|  @@ -516,11 +506,6 @@ pprUserRealSpan show_path (SrcSpanMultiLine src_path
|  sline scol eline ecol)
|    where
|      ecol' = if ecol == 0 then ecol else ecol - 1
|  
|  -pprUserRealSpan show_path (SrcSpanPoint src_path line col)
|  -  = hcat [ ppWhen show_path (pprFastFilePath src_path <> colon)
|  -         , int line <> colon
|  -         , int col ]
|  -
|   {-
|   ************************************************************************
|   *                                                                      *
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell
|  .org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c02a06bd4542a4d06ef
|  8008d307d17760%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=L7r%2buyrlMk0mSh
|  hWTNgi7%2bfhTgu2Osarn6rI6z706cw%3d

From thomasmiedema at gmail.com  Fri Dec 18 18:08:01 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Fri, 18 Dec 2015 19:08:01 +0100
Subject: arc land changes author
In-Reply-To: <1414567269.1346.1.camel@joachim-breitner.de>
References: <1414567269.1346.1.camel@joachim-breitner.de>
Message-ID: <CAD3WKgjPETaS9pHxf1QdqnL2hQHtgAGuirzp415zG_EapfvF7A@mail.gmail.com>

Austin: can you report this bug with the Phabricator people please.

For committers: don't use 'arc land' to land patches from others!

If this has happened to you in the past, could you please let me know. I am
soon updating the contributors list on
https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, and would like it to be
complete. These are the patches that I'm aware of that were misattributed
this year:

D600: Brian McKenna -> Erik de Castro Lopo
D971: Bernard Desmyter -> Thomas Miedema
D974: Zejun Wu -> Simon Marlow
#11209: John Paul Adrian Glaubitz -> Sergei Trofimovich

Thanks

On Wed, Oct 29, 2014 at 8:21 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> I was just about to apply a DR by David. First I ran
> $ arc patch D390
> which put me on a feature branch. Then I reworded the commit with
> $ git commit --amend
> and then I tried to land it with
> $ arc land
> Luckily I also passed --hold...
>
> It even asked me if I want to land the commit although I am not the
> author:
>
>     This branch has revision 'D390: Reorder GHC.List; fix performance
>     regressions' but you are not the author. Land this revision by dfeuer?
>     [y/N] y
>
> But it still put me in the author field:
>
>         $ git show HEAD
>         commit a387c359b99667ce55016de3816b5d9873a155db
>         Author: Joachim Breitner <mail at joachim-breitner.de>
>         Date:   Wed Oct 29 08:17:05 2014 +0100
>
>             Reorder GHC.List; fix performance regressions
>
>             Summary:
>             Rearrange some oddly placed code.
>
> (and undid my commit message changes....)
>
> Did I do something wrong?
>
> Anyways, it said something along the lines of
>         Cleaning up feature branch...
>         (Use `git checkout -b 'arcpatch-D390'
>         'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it
>         back.)
> so with
>         $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029
> I was able to get the edited commit message with the right author back.
>
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> 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://mail.haskell.org/pipermail/ghc-devs/attachments/20151218/3535ad76/attachment.html>

From ryan.gl.scott at gmail.com  Fri Dec 18 18:37:13 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 18 Dec 2015 10:37:13 -0800
Subject: Kind classes and associated closed type families
Message-ID: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>

Thanks to Richard's hard work, I can now define kind classes!

    class Extractable k where
      type Extract (n :: Nat) (x :: k) :: y

(For context, Extract is something roughly resembling the X type
family in the paper Generic Programming for Indexed Datatypes. [1])

This is really, really cool. Except that when I tried using this
class, I quickly ran into issues:

    instance Extractable (a, b) where
      type Extract 0 '(l, _) = l
      type Extract 1 '(_, r) = r
      type Extract _ _       = TypeError ('Text "out of bounds")

This yields the error:

    Extractable.hs:16:8: error:
        Conflicting family instance declarations:
          forall a b (r :: b) (_ :: a).
            Extract 1 '(_, r) = r -- Defined at Extractable.hs:16:8
          forall a b (_ :: Nat) (_1 :: (a, b)) y.
            Extract _ _1 = (TypeError ...) -- Defined at Extractable.hs:17:8

It hit me as to why: GHC is interpreting each Extract type instance as
being separate from each other, not as a part of a single, closed type
family over kind (a, b). And as it turns out, GHC does not allow
closed associated type families. [2]

That leads me to wonder: is there a particular reason why GHC couldn't
allow closed associated type families? Because of this restriction, I
have to define the Extractable (a, b) instance like this:

    instance Extractable (a, b) where
      type Extract n p = ExtractPair n p

    type family ExtractPair (n :: Nat) (x :: (a, b)) :: y where
      ExtractPair 0 '(a, _) = a
      ExtractPair 1 '(_, b) = b
      ExtractPair _ _       = TypeError ('Text "out of bounds")

But that requires -XUndecidableInstances, and makes it much more
difficult to examine type family reductions with GHCi's :kind!
command.

Ryan S.
-----
[1] http://dreixel.net/research/pdf/gpid.pdf
[2] https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#synonym-families

From eir at cis.upenn.edu  Fri Dec 18 18:56:06 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 18 Dec 2015 13:56:06 -0500
Subject: Kind classes and associated closed type families
In-Reply-To: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
References: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
Message-ID: <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>


On Dec 18, 2015, at 1:37 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> It hit me as to why: GHC is interpreting each Extract type instance as
> being separate from each other, not as a part of a single, closed type
> family over kind (a, b). And as it turns out, GHC does not allow
> closed associated type families. [2]

Yes, that's exactly right.

> 
> That leads me to wonder: is there a particular reason why GHC couldn't
> allow closed associated type families?

No. At the time, we thought that associated closed type families are easy enough to build (as you do here) and just one more wrinkle that GHC didn't need. No theoretical trouble at all. Just some routine engineering, I imagine.

> Because of this restriction, I
> have to define the Extractable (a, b) instance like this:
> 
>    instance Extractable (a, b) where
>      type Extract n p = ExtractPair n p
> 
>    type family ExtractPair (n :: Nat) (x :: (a, b)) :: y where
>      ExtractPair 0 '(a, _) = a
>      ExtractPair 1 '(_, b) = b
>      ExtractPair _ _       = TypeError ('Text "out of bounds")
> 
> But that requires -XUndecidableInstances, and makes it much more
> difficult to examine type family reductions with GHCi's :kind!
> command.

Why does this interfere with :kind! ? It shouldn't. (Yes, the -XUndecidableInstances is regrettable. We really need a better type-level termination checker. Care to write one? :)  )

Richard

> 
> Ryan S.
> -----
> [1] http://dreixel.net/research/pdf/gpid.pdf
> [2] https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#synonym-families
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ryan.gl.scott at gmail.com  Fri Dec 18 19:03:16 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 18 Dec 2015 11:03:16 -0800
Subject: Kind classes and associated closed type families
In-Reply-To: <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>
References: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
 <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>
Message-ID: <CADdQpRDC5Fvfb=D2Pqu8wfuAaLjzkxySSUffqPoifXk+4A1gOQ@mail.gmail.com>

> Why does this interfere with :kind! ? It shouldn't.

Well, it seems to interfere in my usage of it, at least:

> :kind! Extract 0 '(Int, Char)
Extract 0 '(Int, Char) :: y
= ExtractPair 0 '(Int, Char)

I presumed this was because :kind! didn't do any type family reduction
whenever something was undecidable in general (to ensure :kind! always
terminates, I suppose).

Ryan S.

On Fri, Dec 18, 2015 at 10:56 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> On Dec 18, 2015, at 1:37 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>
>> It hit me as to why: GHC is interpreting each Extract type instance as
>> being separate from each other, not as a part of a single, closed type
>> family over kind (a, b). And as it turns out, GHC does not allow
>> closed associated type families. [2]
>
> Yes, that's exactly right.
>
>>
>> That leads me to wonder: is there a particular reason why GHC couldn't
>> allow closed associated type families?
>
> No. At the time, we thought that associated closed type families are easy enough to build (as you do here) and just one more wrinkle that GHC didn't need. No theoretical trouble at all. Just some routine engineering, I imagine.
>
>> Because of this restriction, I
>> have to define the Extractable (a, b) instance like this:
>>
>>    instance Extractable (a, b) where
>>      type Extract n p = ExtractPair n p
>>
>>    type family ExtractPair (n :: Nat) (x :: (a, b)) :: y where
>>      ExtractPair 0 '(a, _) = a
>>      ExtractPair 1 '(_, b) = b
>>      ExtractPair _ _       = TypeError ('Text "out of bounds")
>>
>> But that requires -XUndecidableInstances, and makes it much more
>> difficult to examine type family reductions with GHCi's :kind!
>> command.
>
> Why does this interfere with :kind! ? It shouldn't. (Yes, the -XUndecidableInstances is regrettable. We really need a better type-level termination checker. Care to write one? :)  )
>
> Richard
>
>>
>> Ryan S.
>> -----
>> [1] http://dreixel.net/research/pdf/gpid.pdf
>> [2] https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#synonym-families
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From mail at joachim-breitner.de  Sat Dec 19 09:48:34 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 19 Dec 2015 10:48:34 +0100
Subject: arc land changes author
In-Reply-To: <CAD3WKgjPETaS9pHxf1QdqnL2hQHtgAGuirzp415zG_EapfvF7A@mail.gmail.com>
References: <1414567269.1346.1.camel@joachim-breitner.de>
 <CAD3WKgjPETaS9pHxf1QdqnL2hQHtgAGuirzp415zG_EapfvF7A@mail.gmail.com>
Message-ID: <1450518514.12360.5.camel@joachim-breitner.de>

Hi,

Am Freitag, den 18.12.2015, 19:08 +0100 schrieb Thomas Miedema:
> D600: Brian McKenna -> Erik de Castro Lopo
> D971: Bernard Desmyter -> Thomas Miedema
> D974: Zejun Wu -> Simon Marlow
> #11209:?John Paul Adrian Glaubitz ->?Sergei Trofimovich

add

D322 David Feuer ? Joachim Breitner

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151219/eece8b19/attachment.sig>

From ben at well-typed.com  Sat Dec 19 11:51:13 2015
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 19 Dec 2015 12:51:13 +0100
Subject: [commit: ghc] master: SrcLoc: Eliminate constructors of
 RealSrcSpan (987426c)
In-Reply-To: <0d1c47a644b44b95a9974d8bf8ced9a4@DB4PR30MB030.064d.mgd.msft.net>
References: <20151218173324.E6A293A300@ghc.haskell.org>
 <0d1c47a644b44b95a9974d8bf8ced9a4@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <874mfeirm6.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Does this change yield any benefits?  Eg. if we can now unbox SrcLoc does something go faster?
>
Compiler allocations in the testsuite decrease between 0 and 1% [1].

Moreover, it still seemed like a reasonable clean-up given it is a
net reduction in code length with no loss of clarity.

Cheers,

- Ben


[1] https://perf.haskell.org/ghc/#table-6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151219/fd7f25fd/attachment.sig>

From alan.zimm at gmail.com  Sat Dec 19 13:14:51 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 19 Dec 2015 15:14:51 +0200
Subject: ExprWithTySigOut
Message-ID: <CANma=H-NjHqeMj9PpG4+1KAcDCzPHr8V9jodV8GKzcL1KT53QQ@mail.gmail.com>

At the moment HsExpr includes the following two constructors

  | ExprWithTySig
                (LHsExpr id)
                (LHsSigWcType id)

  | ExprWithTySigOut              -- Post typechecking
                (LHsExpr id)
                (LHsSigWcType Name)  -- Retain the signature,
                                     -- as HsSigType Name, for
                                     -- round-tripping purposes

I do not understand why we need the second one, which hard-codes Name
instead of id.

There are a couple of places where there is an XXXOut variant with
hard coded Name parameter, and these complicate creating any kind of
custom class intended to work on a parameterised AST as it ripples out
and forces Name instances of it everywhere.

Perhaps we should introduce HsExprLR id id to cope with renaming?

Alan

From thomasmiedema at gmail.com  Sat Dec 19 18:52:23 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sat, 19 Dec 2015 19:52:23 +0100
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
Message-ID: <CAD3WKgg6Dox5y--HYPz6svUa49o88UWo5Wo_ePMp92xfWGqaTw@mail.gmail.com>

On Mon, Dec 14, 2015 at 3:03 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> 1. -fwarn-pattern-guards=none
> 2. -fwarn-pattern-guards=try
> 3. -fwarn-pattern-guards=try-quiet
> 4. -fwarn-pattern-guards=do   -- there is no "try"
>

The implementation
<https://phabricator.haskell.org/rGHC7e216050ce0366a1d2c2a971db457a5d49f60e8a>
now
uses:
1. -guard-reasoning=simple
2. -guard-reasoning=try
3. -guard-reasoning=try-quiet
4. -guard-reasoning=do

Since `try-quiet` suppresses a warning, it seems more consistent with the
rest of the warning machinery to have a separate warning flag for it
(`-Wornate-guards`,
using the new syntax from #11218), enabled by default. When the fine-grained
`-Werror=...` facility is implemented (#11219), this would allow you to for
example say `-Werror -Wno-error=ornate-guards`, meaning: turn all warnings
into errors, except for `-Wornate-guards` (but don't silence those
completely!).

So then it would like this (with `-f` prefix preferable):
1. -fguard-reasoning=simple
2. -fguard-reasoning=try
3. -fguard-reasoning=do

And orthogonal to that: -Wornate-guards / -Wno-ornate-guards (name to be
decided), which only have an effect when `-fguard-reasoning=try` (the
default).

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151219/a3963fa7/attachment.html>

From thomasmiedema at gmail.com  Sat Dec 19 19:36:19 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sat, 19 Dec 2015 20:36:19 +0100
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAD3WKgg6Dox5y--HYPz6svUa49o88UWo5Wo_ePMp92xfWGqaTw@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
 <CAD3WKgg6Dox5y--HYPz6svUa49o88UWo5Wo_ePMp92xfWGqaTw@mail.gmail.com>
Message-ID: <CAD3WKghVqJK9NeySCT_e+dqJiJoYCq7HjP2T=OFzQ+6zEG48hg@mail.gmail.com>

Hi George,

here is an even simpler design!

When `-ffull-guard-reasoning` is on, use the new pattern match checker.

When `-ffull-guard-reasoning` is off (the default), try to use the new
pattern match checker, but if the number of guards is more than 20,
1. fall back to the old (simple) pattern match checker, and
2. issue a `too-many-guards` warning

The warning can be turned off with `-Wno-too-many-guards`.

What do you think?

Thomas


On Sat, Dec 19, 2015 at 7:52 PM, Thomas Miedema <thomasmiedema at gmail.com>
wrote:

> On Mon, Dec 14, 2015 at 3:03 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> 1. -fwarn-pattern-guards=none
>> 2. -fwarn-pattern-guards=try
>> 3. -fwarn-pattern-guards=try-quiet
>> 4. -fwarn-pattern-guards=do   -- there is no "try"
>>
>
> The implementation
> <https://phabricator.haskell.org/rGHC7e216050ce0366a1d2c2a971db457a5d49f60e8a> now
> uses:
> 1. -guard-reasoning=simple
> 2. -guard-reasoning=try
> 3. -guard-reasoning=try-quiet
> 4. -guard-reasoning=do
>
> Since `try-quiet` suppresses a warning, it seems more consistent with the
> rest of the warning machinery to have a separate warning flag for it (`-Wornate-guards`,
> using the new syntax from #11218), enabled by default. When the fine-grained
> `-Werror=...` facility is implemented (#11219), this would allow you to for
> example say `-Werror -Wno-error=ornate-guards`, meaning: turn all warnings
> into errors, except for `-Wornate-guards` (but don't silence those
> completely!).
>
> So then it would like this (with `-f` prefix preferable):
> 1. -fguard-reasoning=simple
> 2. -fguard-reasoning=try
> 3. -fguard-reasoning=do
>
> And orthogonal to that: -Wornate-guards / -Wno-ornate-guards (name to be
> decided), which only have an effect when `-fguard-reasoning=try` (the
> default).
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151219/b33102c1/attachment.html>

From eir at cis.upenn.edu  Sun Dec 20 04:36:56 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 19 Dec 2015 23:36:56 -0500
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_5JgA5pqA6wWoAH_eMC4V=1YdOsQ_EdcgrPoes=aXjsfw@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
 <CAD3WKgg6Dox5y--HYPz6svUa49o88UWo5Wo_ePMp92xfWGqaTw@mail.gmail.com>
 <CAD3WKghVqJK9NeySCT_e+dqJiJoYCq7HjP2T=OFzQ+6zEG48hg@mail.gmail.com>
 <CAEwUq_5JgA5pqA6wWoAH_eMC4V=1YdOsQ_EdcgrPoes=aXjsfw@mail.gmail.com>
Message-ID: <75D0E317-DA6C-4A0B-9A64-6A734E4A60BA@cis.upenn.edu>

I hereby abstain from debating the color on this particular bikeshed. My taste in bikeshed colors has proven to be unreliable.

Richard

On Dec 19, 2015, at 5:32 PM, George Karachalias <george.karachalias at gmail.com> wrote:

> Hi Thomas,
> 
> On Sat, Dec 19, 2015 at 8:36 PM, Thomas Miedema <thomasmiedema at gmail.com> wrote:
> Hi George,
> 
> here is an even simpler design!
> 
> When `-ffull-guard-reasoning` is on, use the new pattern match checker.
> 
> When `-ffull-guard-reasoning` is off (the default), try to use the new pattern match checker, but if the number of guards is more than 20,
> 1. fall back to the old (simple) pattern match checker, and
> 2. issue a `too-many-guards` warning 
> 
> The warning can be turned off with `-Wno-too-many-guards`.
> 
> What do you think?
> 
> Sounds nice and easy to change :)
> I have a small question though: do we need the opposites too (I mean
> `-fno-full-guard-reasoning` and ` -Wtoo-many-guards`)? I cannot think of
> a scenario where we do or am I missing something?
> 
> Others? If I get the green light, this is a matter of minutes to change :)
> 
> George
> 
> -- 
> things you own end up owning you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151219/0795fbcf/attachment.html>

From thomasmiedema at gmail.com  Sun Dec 20 12:23:17 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 20 Dec 2015 13:23:17 +0100
Subject: Performance of pattern checker on OptCoercions
In-Reply-To: <CAEwUq_5JgA5pqA6wWoAH_eMC4V=1YdOsQ_EdcgrPoes=aXjsfw@mail.gmail.com>
References: <87lh91i75u.fsf@smart-cactus.org>
 <CAEwUq_7Fx90cHcg8hx_Yhbo+xmoT_+3KpDoyZfjL5FLh5SoPTg@mail.gmail.com>
 <34b1f1c8e01b404db8e508f54a4563f1@DB4PR30MB030.064d.mgd.msft.net>
 <CAEwUq_4FeoC5hUdW=ZiLyyVWhLzUYoOPAO2LSSp3EwJAPFu3Zw@mail.gmail.com>
 <6A3D5867-D5EA-44E5-B79D-DFF05806F1FE@cis.upenn.edu>
 <CAEwUq_6oL+G+wTEqv7XPiZ123fONqOQpQO1dL9Qazhw01smBJg@mail.gmail.com>
 <0750B34B-B65E-4B3A-8458-5B12A8300835@cis.upenn.edu>
 <CAD3WKgg6Dox5y--HYPz6svUa49o88UWo5Wo_ePMp92xfWGqaTw@mail.gmail.com>
 <CAD3WKghVqJK9NeySCT_e+dqJiJoYCq7HjP2T=OFzQ+6zEG48hg@mail.gmail.com>
 <CAEwUq_5JgA5pqA6wWoAH_eMC4V=1YdOsQ_EdcgrPoes=aXjsfw@mail.gmail.com>
Message-ID: <CAD3WKgjJ_jGik8rywozQWT-3asypghNs3ep2LefvboUCz03pVQ@mail.gmail.com>

> I have a small question though: do we need the opposites too (I mean
> `-fno-full-guard-reasoning` and ` -Wtoo-many-guards`)? I cannot think of
> a scenario where we do or am I missing something?
>

A scenario where `-fno-full-guard-reasoning` could be useful: you add
`-ffull-guard-reasoning` to ghc-options in your .cabal file, but switch it
off in an OPTIONS_GHC pragma in a specific file.

But `-f` and `-W` flags always come in pairs, so that is easy. You would
add `-Wtoo-many-guards` to `standardWarnings` in compiler/main/DynFlags.hs.

Others? If I get the green light, this is a matter of minutes to change :)
>

If it is not too much trouble, please submit your patch to Phabricator.
Then others can review, and harbormaster can validate it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151220/c6806920/attachment.html>

From alan.zimm at gmail.com  Sun Dec 20 18:55:23 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 20 Dec 2015 20:55:23 +0200
Subject: Change from 7.10.3 to current master
Message-ID: <CANma=H9Hk5miH6y3F=jNCNB1-Rq15FcLh8awcQfhioAsg_1Y5Q@mail.gmail.com>

I am in the process of updating ghc-exactprint for current GHC master.

One of the tests has the following in it

-----------------------------
{-# LANGUAGE TypeOperators #-}

type family (r1 :++: r2); infixr 5 :++:
type instance r :++: Nil = r
type instance r1 :++: r2 :> a = (r1 :++: r2) :> a
------------------------------

Current GHC master rejects this with

/tmp/Foo.hs:5:15: error:
    Malformed head of type or class declaration: r1 :++: r2 :> a

Is this expected, or a bug?

Alan

From omeragacan at gmail.com  Sun Dec 20 19:14:48 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 20 Dec 2015 14:14:48 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
 <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
 <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>
Message-ID: <CAMQQO3nkTCa=xzOa0HyXi8xwD_p70P+J-Qqzk5t-s_kqoX-PMQ@mail.gmail.com>

I have another related question: What about allowing primitive types
in newtypes?

    ?:4> newtype Blah1 = Blah1 Int
    ?:5> newtype Blah2 = Blah2 Int#

    <interactive>:5:23: error:
        ? Expecting a lifted type, but ?Int#? is unlifted
        ? In the type ?Int#?
          In the definition of data constructor ?Blah2?
          In the newtype declaration for ?Blah2?

Ideally second definition should be OK, and kind of Blah2 should be #. Is this
too hard to do?

2015-12-16 17:22 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
>
> On Dec 16, 2015, at 2:06 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>>
>> In any case, this is not that big deal. When I read the code I thought this
>> should be a trivial change but apparently it's not.
>
> No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed things. And changing that is far from trivial. It's not the polymorphism that's the problem -- it's the unboxed thing in a boxed tuple.
>
> Richard

From gautier.difolco at gmail.com  Sun Dec 20 23:36:09 2015
From: gautier.difolco at gmail.com (Gautier DI FOLCO)
Date: Mon, 21 Dec 2015 00:36:09 +0100
Subject: Haddock for GHC 8.0
Message-ID: <CAH_3vcQ4Rqvgpj2BMg4cT351R8Q9W2FoHcG=sUZ_NFejxxiVXQ@mail.gmail.com>

------------------------------

> tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release.
>
>
> Hello everyone,
>
> As you likely know, the GHC 8.0 release cycle is quickly drawing to a
> close. One of the tasks that remains outstanding is porting the patches
> on Haddock's `ghc-head` branch to `master`. This task is bound to
> require a bit more work than usual this time around as both GHC and
> Haddock have evolved significantly (which is a good thing!). Sadly,
> Austin and I are quite busy at the moment and would be hard-pressed to
> undertake such a task ourselves. Consequently, we need a volunteer to
> pick up this work.
>
> At the moment the GHC release schedule is largely determined by progress
> on the no-kinds branch but we expect to have a release candidate out
> within the next two weeks. If we aren't able to find someone to bring
> haddock up-to-date by mid-January I'm afraid we'll have to release GHC
> 8.0 with the current state of the `ghc-head` branch. Considering the
> significant effort that went into this summer's GSoC projects, this
> would be a shame.
>
> If you think you might be able to contribute to this effort, please say
> so in this thread.
>
> Thanks for all of your effort,
>
> - Ben
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 472 bytes
> Desc: not available
> URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/52bff35b/attachment.sig>
>
>
Hello,

Sorry for the delay and for all the netiquette violations (I wasn't
registered to this list).
If this task is not taken in charge by someone, I can try to do it by the
end of the year.
Is it still the case?

I hope I can help,
Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/6751505a/attachment.html>

From matthewtpickering at gmail.com  Mon Dec 21 00:04:41 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 21 Dec 2015 00:04:41 +0000
Subject: Haddock for GHC 8.0
In-Reply-To: <CAH_3vcQ4Rqvgpj2BMg4cT351R8Q9W2FoHcG=sUZ_NFejxxiVXQ@mail.gmail.com>
References: <CAH_3vcQ4Rqvgpj2BMg4cT351R8Q9W2FoHcG=sUZ_NFejxxiVXQ@mail.gmail.com>
Message-ID: <CALuQ0m-8Op1D4dkw0K0eM27t0Oo+kPvLH-SgEFevp3pSyJZRzQ@mail.gmail.com>

Hi Gautier,

Indeed the task has been done.

Here is the current rebased branch -
https://github.com/haskell/haddock/tree/ghc-head

Matt

On Sun, Dec 20, 2015 at 11:36 PM, Gautier DI FOLCO
<gautier.difolco at gmail.com> wrote:
> ________________________________
>>
>> tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release.
>>
>>
>> Hello everyone,
>>
>> As you likely know, the GHC 8.0 release cycle is quickly drawing to a
>> close. One of the tasks that remains outstanding is porting the patches
>> on Haddock's `ghc-head` branch to `master`. This task is bound to
>> require a bit more work than usual this time around as both GHC and
>> Haddock have evolved significantly (which is a good thing!). Sadly,
>> Austin and I are quite busy at the moment and would be hard-pressed to
>> undertake such a task ourselves. Consequently, we need a volunteer to
>> pick up this work.
>>
>> At the moment the GHC release schedule is largely determined by progress
>> on the no-kinds branch but we expect to have a release candidate out
>> within the next two weeks. If we aren't able to find someone to bring
>> haddock up-to-date by mid-January I'm afraid we'll have to release GHC
>> 8.0 with the current state of the `ghc-head` branch. Considering the
>> significant effort that went into this summer's GSoC projects, this
>> would be a shame.
>>
>> If you think you might be able to contribute to this effort, please say
>> so in this thread.
>>
>> Thanks for all of your effort,
>>
>> - Ben
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 472 bytes
>> Desc: not available
>> URL:
>> <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/52bff35b/attachment.sig>
>
>
> Hello,
>
> Sorry for the delay and for all the netiquette violations (I wasn't
> registered to this list).
> If this task is not taken in charge by someone, I can try to do it by the
> end of the year.
> Is it still the case?
>
> I hope I can help,
> Regards.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From gautier.difolco at gmail.com  Mon Dec 21 06:47:41 2015
From: gautier.difolco at gmail.com (Gautier DI FOLCO)
Date: Mon, 21 Dec 2015 07:47:41 +0100
Subject: Haddock for GHC 8.0
In-Reply-To: <CALuQ0m-8Op1D4dkw0K0eM27t0Oo+kPvLH-SgEFevp3pSyJZRzQ@mail.gmail.com>
References: <CAH_3vcQ4Rqvgpj2BMg4cT351R8Q9W2FoHcG=sUZ_NFejxxiVXQ@mail.gmail.com>
 <CALuQ0m-8Op1D4dkw0K0eM27t0Oo+kPvLH-SgEFevp3pSyJZRzQ@mail.gmail.com>
Message-ID: <CAH_3vcSvNr0Yy6aqyU7QYfv2ERsYKatVudqMxvYX77X_13z4tA@mail.gmail.com>

Hello,

Thanks for the quick answer, sorry for the inconvenience, I hope I'll be
quicker next time.

Regards.

2015-12-21 1:04 GMT+01:00 Matthew Pickering <matthewtpickering at gmail.com>:

> Hi Gautier,
>
> Indeed the task has been done.
>
> Here is the current rebased branch -
> https://github.com/haskell/haddock/tree/ghc-head
>
> Matt
>
> On Sun, Dec 20, 2015 at 11:36 PM, Gautier DI FOLCO
> <gautier.difolco at gmail.com> wrote:
> > ________________________________
> >>
> >> tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release.
> >>
> >>
> >> Hello everyone,
> >>
> >> As you likely know, the GHC 8.0 release cycle is quickly drawing to a
> >> close. One of the tasks that remains outstanding is porting the patches
> >> on Haddock's `ghc-head` branch to `master`. This task is bound to
> >> require a bit more work than usual this time around as both GHC and
> >> Haddock have evolved significantly (which is a good thing!). Sadly,
> >> Austin and I are quite busy at the moment and would be hard-pressed to
> >> undertake such a task ourselves. Consequently, we need a volunteer to
> >> pick up this work.
> >>
> >> At the moment the GHC release schedule is largely determined by progress
> >> on the no-kinds branch but we expect to have a release candidate out
> >> within the next two weeks. If we aren't able to find someone to bring
> >> haddock up-to-date by mid-January I'm afraid we'll have to release GHC
> >> 8.0 with the current state of the `ghc-head` branch. Considering the
> >> significant effort that went into this summer's GSoC projects, this
> >> would be a shame.
> >>
> >> If you think you might be able to contribute to this effort, please say
> >> so in this thread.
> >>
> >> Thanks for all of your effort,
> >>
> >> - Ben
> >> -------------- next part --------------
> >> A non-text attachment was scrubbed...
> >> Name: signature.asc
> >> Type: application/pgp-signature
> >> Size: 472 bytes
> >> Desc: not available
> >> URL:
> >> <
> http://mail.haskell.org/pipermail/ghc-devs/attachments/20151207/52bff35b/attachment.sig
> >
> >
> >
> > Hello,
> >
> > Sorry for the delay and for all the netiquette violations (I wasn't
> > registered to this list).
> > If this task is not taken in charge by someone, I can try to do it by the
> > end of the year.
> > Is it still the case?
> >
> > I hope I can help,
> > Regards.
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/e5effe7d/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec 21 08:42:41 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Dec 2015 08:42:41 +0000
Subject: [commit: ghc] master: SrcLoc: Eliminate constructors of
 RealSrcSpan (987426c)
In-Reply-To: <874mfeirm6.fsf@smart-cactus.org>
References: <20151218173324.E6A293A300@ghc.haskell.org>
 <0d1c47a644b44b95a9974d8bf8ced9a4@DB4PR30MB030.064d.mgd.msft.net>
 <874mfeirm6.fsf@smart-cactus.org>
Message-ID: <4f8419670ccc40f481bda5b9f10fc751@DB4PR30MB030.064d.mgd.msft.net>

1% is huge!  Good to do.

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at well-typed.com]
|  Sent: 19 December 2015 11:51
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
|  Subject: RE: [commit: ghc] master: SrcLoc: Eliminate constructors of
|  RealSrcSpan (987426c)
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > Does this change yield any benefits?  Eg. if we can now unbox SrcLoc
|  does something go faster?
|  >
|  Compiler allocations in the testsuite decrease between 0 and 1% [1].
|  
|  Moreover, it still seemed like a reasonable clean-up given it is a net
|  reduction in code length with no loss of clarity.
|  
|  Cheers,
|  
|  - Ben
|  
|  
|  [1] https://perf.haskell.org/ghc/#table-6

From simonpj at microsoft.com  Mon Dec 21 08:46:58 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Dec 2015 08:46:58 +0000
Subject: ExprWithTySigOut
In-Reply-To: <CANma=H-NjHqeMj9PpG4+1KAcDCzPHr8V9jodV8GKzcL1KT53QQ@mail.gmail.com>
References: <CANma=H-NjHqeMj9PpG4+1KAcDCzPHr8V9jodV8GKzcL1KT53QQ@mail.gmail.com>
Message-ID: <681a13059ba64c1799b78eb621d06a86@DB4PR30MB030.064d.mgd.msft.net>

Yes this is annoying.

The thing is that with the first constructor only we'd get
	(LHsSigWcType Id)
after type checking, but we don't have such a thing. `HsTypes` are typechecked to `Types`.  

Perhaps we could have
	(LHsSigWcType (StopAtRenamer d))

where
	type family StopAtRenamer a where
		StopAtRenamer Id = Name
		StopAtRenamer x = x

If this pattern happened a lot it might be worth it.  But I think this is the only occurrence.

Better ideas welcome.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan
|  & Kim Zimmerman
|  Sent: 19 December 2015 13:15
|  To: ghc-devs at haskell.org
|  Subject: ExprWithTySigOut
|  
|  At the moment HsExpr includes the following two constructors
|  
|    | ExprWithTySig
|                  (LHsExpr id)
|                  (LHsSigWcType id)
|  
|    | ExprWithTySigOut              -- Post typechecking
|                  (LHsExpr id)
|                  (LHsSigWcType Name)  -- Retain the signature,
|                                       -- as HsSigType Name, for
|                                       -- round-tripping purposes
|  
|  I do not understand why we need the second one, which hard-codes Name
|  instead of id.
|  
|  There are a couple of places where there is an XXXOut variant with
|  hard coded Name parameter, and these complicate creating any kind of
|  custom class intended to work on a parameterised AST as it ripples out
|  and forces Name instances of it everywhere.
|  
|  Perhaps we should introduce HsExprLR id id to cope with renaming?
|  
|  Alan
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b
|  3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX
|  bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d

From ekmett at gmail.com  Mon Dec 21 09:10:27 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 21 Dec 2015 04:10:27 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <CAMQQO3nkTCa=xzOa0HyXi8xwD_p70P+J-Qqzk5t-s_kqoX-PMQ@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
 <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
 <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>
 <CAMQQO3nkTCa=xzOa0HyXi8xwD_p70P+J-Qqzk5t-s_kqoX-PMQ@mail.gmail.com>
Message-ID: <CAJumaK8OPYad_jdEmqOp4XTFck=Spr5Szc1pS-K8c9ZtqaAOhw@mail.gmail.com>

I brought up the subject of allowing newtypes in kind # (or even in any
kind that ends in * or # after a chain of ->'s to get more powerful
Coercible instances) at ICFP this year and Simon seemed to think it'd be a
pretty straightforward modification to the typechecker.

I confess, he's likely waiting for me to actually sit down and give the
idea a nice writeup. ;)

This would be good for many things, especially when it comes to improving
the type safety of various custom c-- tricks.

-Edward

On Sun, Dec 20, 2015 at 2:14 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> I have another related question: What about allowing primitive types
> in newtypes?
>
>     ?:4> newtype Blah1 = Blah1 Int
>     ?:5> newtype Blah2 = Blah2 Int#
>
>     <interactive>:5:23: error:
>         ? Expecting a lifted type, but ?Int#? is unlifted
>         ? In the type ?Int#?
>           In the definition of data constructor ?Blah2?
>           In the newtype declaration for ?Blah2?
>
> Ideally second definition should be OK, and kind of Blah2 should be #. Is
> this
> too hard to do?
>
> 2015-12-16 17:22 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu>:
> >
> > On Dec 16, 2015, at 2:06 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
> >>
> >> In any case, this is not that big deal. When I read the code I thought
> this
> >> should be a trivial change but apparently it's not.
> >
> > No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed
> thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed
> things. And changing that is far from trivial. It's not the polymorphism
> that's the problem -- it's the unboxed thing in a boxed tuple.
> >
> > Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/32cebcd4/attachment-0001.html>

From hvriedel at gmail.com  Mon Dec 21 10:10:00 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 21 Dec 2015 11:10:00 +0100
Subject: ExprWithTySigOut
In-Reply-To: <681a13059ba64c1799b78eb621d06a86@DB4PR30MB030.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Mon, 21 Dec 2015 08:46:58 +0000")
References: <CANma=H-NjHqeMj9PpG4+1KAcDCzPHr8V9jodV8GKzcL1KT53QQ@mail.gmail.com>
 <681a13059ba64c1799b78eb621d06a86@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87wps8gljb.fsf@gmail.com>

Hi,

Btw, I also used that annoying pattern in

  https://phabricator.haskell.org/D1185

to represent type-signature sections before/after typechecking:
  
?  -- | Type-signature operator sections
?
?  | TySigSection    (LHsType id)
?		    (PostRn id [Name])	-- wildcards
?
?  | TySigSectionOut (LHsType Name)
?		    (PostTc id Type)
?		    (PostTc id Coercion)

I'd be interested in better ideas as well...

On 2015-12-21 at 09:46:58 +0100, Simon Peyton Jones wrote:
> Yes this is annoying.
>
> The thing is that with the first constructor only we'd get
> 	(LHsSigWcType Id)
> after type checking, but we don't have such a thing. `HsTypes` are typechecked to `Types`.  
>
> Perhaps we could have
> 	(LHsSigWcType (StopAtRenamer d))
>
> where
> 	type family StopAtRenamer a where
> 		StopAtRenamer Id = Name
> 		StopAtRenamer x = x
>
> If this pattern happened a lot it might be worth it.  But I think this is the only occurrence.
>
> Better ideas welcome.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan
> |  & Kim Zimmerman
> |  Sent: 19 December 2015 13:15
> |  To: ghc-devs at haskell.org
> |  Subject: ExprWithTySigOut
> |  
> |  At the moment HsExpr includes the following two constructors
> |  
> |    | ExprWithTySig
> |                  (LHsExpr id)
> |                  (LHsSigWcType id)
> |  
> |    | ExprWithTySigOut              -- Post typechecking
> |                  (LHsExpr id)
> |                  (LHsSigWcType Name)  -- Retain the signature,
> |                                       -- as HsSigType Name, for
> |                                       -- round-tripping purposes
> |  
> |  I do not understand why we need the second one, which hard-codes Name
> |  instead of id.
> |  
> |  There are a couple of places where there is an XXXOut variant with
> |  hard coded Name parameter, and these complicate creating any kind of
> |  custom class intended to work on a parameterised AST as it ripples out
> |  and forces Name instances of it everywhere.
> |  
> |  Perhaps we should introduce HsExprLR id id to cope with renaming?
> |  
> |  Alan
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c70b008fd4c5b43b
> |  3915e08d308766f7d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MB%2fBX
> |  bBIUeYFlOOH5PGXV27wJpZRNKcHJV%2fTQmfI%2f%2bE%3d
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
"Elegance is not optional" -- Richard O'Keefe

From simonpj at microsoft.com  Mon Dec 21 10:13:34 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Dec 2015 10:13:34 +0000
Subject: Kinds of type synonym arguments
In-Reply-To: <CAJumaK8OPYad_jdEmqOp4XTFck=Spr5Szc1pS-K8c9ZtqaAOhw@mail.gmail.com>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
 <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
 <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>
 <CAMQQO3nkTCa=xzOa0HyXi8xwD_p70P+J-Qqzk5t-s_kqoX-PMQ@mail.gmail.com>
 <CAJumaK8OPYad_jdEmqOp4XTFck=Spr5Szc1pS-K8c9ZtqaAOhw@mail.gmail.com>
Message-ID: <2716f1366f054471a4f975a7c98f6ea6@AM3PR30MB019.064d.mgd.msft.net>

newtype T = MkT Int#

Provided T :: # (i.e. unlifted), I don?t think this would be too hard.  That is, you can give a new name (via newtype) to an unlifted type like Int#, Float#, Double# etc.

Worth a wiki page and a ticket.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 21 December 2015 09:10
To: ?mer Sinan A?acan <omeragacan at gmail.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Kinds of type synonym arguments

I brought up the subject of allowing newtypes in kind # (or even in any kind that ends in * or # after a chain of ->'s to get more powerful Coercible instances) at ICFP this year and Simon seemed to think it'd be a pretty straightforward modification to the typechecker.

I confess, he's likely waiting for me to actually sit down and give the idea a nice writeup. ;)

This would be good for many things, especially when it comes to improving the type safety of various custom c-- tricks.

-Edward

On Sun, Dec 20, 2015 at 2:14 PM, ?mer Sinan A?acan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>> wrote:
I have another related question: What about allowing primitive types
in newtypes?

    ?:4> newtype Blah1 = Blah1 Int
    ?:5> newtype Blah2 = Blah2 Int#

    <interactive>:5:23: error:
        ? Expecting a lifted type, but ?Int#? is unlifted
        ? In the type ?Int#?
          In the definition of data constructor ?Blah2?
          In the newtype declaration for ?Blah2?

Ideally second definition should be OK, and kind of Blah2 should be #. Is this
too hard to do?

2015-12-16 17:22 GMT-05:00 Richard Eisenberg <eir at cis.upenn.edu<mailto:eir at cis.upenn.edu>>:
>
> On Dec 16, 2015, at 2:06 PM, ?mer Sinan A?acan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>> wrote:
>>
>> In any case, this is not that big deal. When I read the code I thought this
>> should be a trivial change but apparently it's not.
>
> No, it's not. Your example (`f :: (Int#, b) -> b`) still has an unboxed thing in a boxed tuple. Boxed tuples simply can't (currently) hold unboxed things. And changing that is far from trivial. It's not the polymorphism that's the problem -- it's the unboxed thing in a boxed tuple.
>
> Richard
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ba7cbf98af84227d01808d309e6931f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nmxCKI9q3o%2b1pw%2f8phLXRWHv3QZ1xUpyAbN5CmyUwxQ%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/b0b085c5/attachment-0001.html>

From simonpj at microsoft.com  Mon Dec 21 11:03:10 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 21 Dec 2015 11:03:10 +0000
Subject: Change from 7.10.3 to current master
In-Reply-To: <CANma=H9Hk5miH6y3F=jNCNB1-Rq15FcLh8awcQfhioAsg_1Y5Q@mail.gmail.com>
References: <CANma=H9Hk5miH6y3F=jNCNB1-Rq15FcLh8awcQfhioAsg_1Y5Q@mail.gmail.com>
Message-ID: <620eda64a8f441b68e0c29e92ec0f6db@AM3PR30MB019.064d.mgd.msft.net>

|  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a

What do you expect this to mean?  I suppose you could hope that GHC will unravel the fixity of :++: and :>, to determine whether you are giving an instance for :++: or for :>?

That sounds reasonable, but it's not trivial.

Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and it looks like this:


data TyFamEqn name pats
  = TyFamEqn
       { tfe_tycon :: Located name
       , tfe_pats  :: pats
       , tfe_rhs   :: LHsType name }


So we've already decided (in the parser) what the type-function name is.  But we can't do that in this case, because the parser doesn't understand fixity.

To deal with this we'd need to change to

data TyFamEqn name pats
  = TyFamEqn
       { tfe_lhs  :: LHSType name
       , tfe_rhs   :: LHsType name }

so that the LHS was just a type.  Now the renamer can re-jiggle its fixities in the usual way, and only in the type checker will we need to decide exactly which type it's an instance of.  Easy!

This might be a good change to make! It's a bit like in ClsInstDecl, you'll see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed into which class it is.


So: my instinct is that the above would be Fine Thing.  Make a ticket?  Add these comments to give context?  Excecute?

Thanks

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan
|  & Kim Zimmerman
|  Sent: 20 December 2015 18:55
|  To: ghc-devs at haskell.org
|  Subject: Change from 7.10.3 to current master
|  
|  I am in the process of updating ghc-exactprint for current GHC master.
|  
|  One of the tests has the following in it
|  
|  -----------------------------
|  {-# LANGUAGE TypeOperators #-}
|  
|  type family (r1 :++: r2); infixr 5 :++:
|  type instance r :++: Nil = r
|  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a
|  ------------------------------
|  
|  Current GHC master rejects this with
|  
|  /tmp/Foo.hs:5:15: error:
|      Malformed head of type or class declaration: r1 :++: r2 :> a
|  
|  Is this expected, or a bug?
|  
|  Alan
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c17b33d7be13045d
|  d141308d3096f2bc5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LGroqdv
|  nYFSxydfZFQydhi2N6lltWwi%2b4tt%2bM3LH0P0%3d

From rwbarton at gmail.com  Mon Dec 21 11:31:38 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Mon, 21 Dec 2015 06:31:38 -0500
Subject: Kinds of type synonym arguments
In-Reply-To: <2716f1366f054471a4f975a7c98f6ea6@AM3PR30MB019.064d.mgd.msft.net>
References: <CAMQQO3mTW3C8VCkqqGedq42JLW4rKZ3CY00MXTBPtKr56EHVfw@mail.gmail.com>
 <EFAF823C-D461-49F8-9D0B-28ED2CC29126@cis.upenn.edu>
 <CAMQQO3mSw1ntNvRDxCQAh6iyOC3jWEPihaF0LuuzMWarPyMX+w@mail.gmail.com>
 <5be27a4482984c57823f12b465945e9b@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3mrHL5fxJ542uN_JNHUr0pSPxeRJGAaKCqQoXp25+K70A@mail.gmail.com>
 <CAHEA9tPBOpHrdxzKmFCGoFqNEymGT=3LS23CYDOkEvKpAoN8PQ@mail.gmail.com>
 <1F5CA808-2341-4070-ABAF-CA66EC527F62@cis.upenn.edu>
 <CAMQQO3=63nJL2MzmrxTvaSHP8TsbTEYEbOraSzys2_NirVT_oA@mail.gmail.com>
 <388D9560-2F69-4292-ACA0-68EDB4C0D67B@cis.upenn.edu>
 <CAMQQO3nkTCa=xzOa0HyXi8xwD_p70P+J-Qqzk5t-s_kqoX-PMQ@mail.gmail.com>
 <CAJumaK8OPYad_jdEmqOp4XTFck=Spr5Szc1pS-K8c9ZtqaAOhw@mail.gmail.com>
 <2716f1366f054471a4f975a7c98f6ea6@AM3PR30MB019.064d.mgd.msft.net>
Message-ID: <CADmwj47qB5dK38jjLFuCm=OJm5iUZDXXtjk_ggZ_Y=HKGeiuHw@mail.gmail.com>

On Mon, Dec 21, 2015 at 5:13 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> newtype T = MkT Int#
>
>
>
> Provided T :: # (i.e. unlifted), I don?t think this would be too hard.
> That is, you can give a new name (via newtype) to an unlifted type like
> Int#, Float#, Double# etc.
>
>
>
> Worth a wiki page and a ticket.
>

There is already a ticket at least,
https://ghc.haskell.org/trac/ghc/ticket/1311.

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151221/9b73cf7d/attachment.html>

From eir at cis.upenn.edu  Fri Dec 18 20:57:02 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 18 Dec 2015 15:57:02 -0500
Subject: Kind classes and associated closed type families
In-Reply-To: <CADdQpRDC5Fvfb=D2Pqu8wfuAaLjzkxySSUffqPoifXk+4A1gOQ@mail.gmail.com>
References: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
 <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>
 <CADdQpRDC5Fvfb=D2Pqu8wfuAaLjzkxySSUffqPoifXk+4A1gOQ@mail.gmail.com>
Message-ID: <EDC77E94-6095-43AE-8DB0-2D7C8C3546AD@cis.upenn.edu>

On Dec 18, 2015, at 2:03 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I presumed this was because :kind! didn't do any type family reduction
> whenever something was undecidable in general (to ensure :kind! always
> terminates, I suppose).

No. :kind! isn't that smart.

Out of curiosity, what happens if you try again? As in, run :kind! ... twice, exactly the same both times. I seem to recall a ticket saying that worked. Regardless, this is just a plain old bug. Please post a report.

Thanks!
Richard

From ryan.gl.scott at gmail.com  Tue Dec 22 01:43:13 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 21 Dec 2015 19:43:13 -0600
Subject: Kind classes and associated closed type families
In-Reply-To: <EDC77E94-6095-43AE-8DB0-2D7C8C3546AD@cis.upenn.edu>
References: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
 <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>
 <CADdQpRDC5Fvfb=D2Pqu8wfuAaLjzkxySSUffqPoifXk+4A1gOQ@mail.gmail.com>
 <EDC77E94-6095-43AE-8DB0-2D7C8C3546AD@cis.upenn.edu>
Message-ID: <CADdQpRCZ7Xqv3pVdoN1qvm1-7qg-G+D9-gD_npiEqad+7NcUSQ@mail.gmail.com>

Running :kind! twice in a row does nothing, and your hunch was
correct: it does appear to be a bug. Specifically, it's a bug that
affects type families with polymorphic return kinds (like Extract,
which has kind y). I've opened Trac #11275 [1] for this issue.

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/11275

From ryan.gl.scott at gmail.com  Tue Dec 22 02:15:41 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 21 Dec 2015 20:15:41 -0600
Subject: Kind classes and associated closed type families
In-Reply-To: <CADdQpRCZ7Xqv3pVdoN1qvm1-7qg-G+D9-gD_npiEqad+7NcUSQ@mail.gmail.com>
References: <CADdQpRCj0_nFshCaNyQfT2BtY5ob5Ngd88RBybFk_BHGytZEOA@mail.gmail.com>
 <053DFF41-E0F2-4B84-951E-D297A778648B@cis.upenn.edu>
 <CADdQpRDC5Fvfb=D2Pqu8wfuAaLjzkxySSUffqPoifXk+4A1gOQ@mail.gmail.com>
 <EDC77E94-6095-43AE-8DB0-2D7C8C3546AD@cis.upenn.edu>
 <CADdQpRCZ7Xqv3pVdoN1qvm1-7qg-G+D9-gD_npiEqad+7NcUSQ@mail.gmail.com>
Message-ID: <CADdQpRC7G+WVgpZ-PXjMtFtTrhCyYiHv+5KaOn88JhOXNRBttQ@mail.gmail.com>

...actually, nevermind, it's not a bug after all. It was just me being
boneheaded. Since Extract has a polymorphic return kind, there's no
way for GHCi to know what the kind of Extract 0 '(Int, Char) will be
unless there's a kind ascription. If you be more explicit, then GHCi
knows what to do:

    > :kind! (Extract 0 '(Int, Char) :: *)
    (Extract 0 '(Int, Char) :: *) :: *
    = Int
    > :kind! (Extract 0 '(Int, Char) :: * -> *)
    (Extract 0 '(Int, Char) :: * -> *) :: * -> *
    = (TypeError ...)

Thanks to Reid Barton for pointing this out to me.

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/10116

From simonpj at microsoft.com  Wed Dec 23 20:53:24 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 23 Dec 2015 20:53:24 +0000
Subject: [commit: ghc] wip/T10832-generalised-injectivity: Generalized
 injective type families (332bc0d)
In-Reply-To: <20151223143602.74E243A300@ghc.haskell.org>
References: <20151223143602.74E243A300@ghc.haskell.org>
Message-ID: <95691b5d9e304a17829b3c168c132c91@DB4PR30MB030.064d.mgd.msft.net>

Jan

Just to say that I'm working on your D10832 ticket.  I've rebased your patch on HEAD, and pushed it to wip/T10832-generalised-injectivity

I plan some actual work on it tomorrow

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 23 December 2015 14:36
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] wip/T10832-generalised-injectivity: Generalized
| injective type families (332bc0d)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : wip/T10832-generalised-injectivity
| Link       :
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell.o
| rg%2ftrac%2fghc%2fchangeset%2f332bc0d3af0a208ad310ce28cf798d4682423329%2fghc&
| data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2004c57729e44f345ad008d30ba
| 6867c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YoNY2%2fx%2bBqO0FO5DUOLBRp
| uqLlOm5kT%2bIwTXrLZ6Kgs%3d
| 
| >---------------------------------------------------------------
| 
| commit 332bc0d3af0a208ad310ce28cf798d4682423329
| Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
| Date:   Wed Dec 23 10:18:44 2015 +0000
| 
|     Generalized injective type families
| 
|     (As modified onto HEAD, 23 Dec 15)
| 
|     Summary:
|     Generalization of injective type families to match the expressiveness of
|     functional dependencies, as briefly outlined in Section 7 of "Injective
| type
|     families for Haskell" Haskell Symposium 2015 paper.  See also injectivity
| of
|     type C described on the wiki page
|     https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies
| 
|     Test Plan: ./validate
| 
|     Reviewers: simonpj, austin, goldfire, bgamari
| 
|     Subscribers: thomie, mpickering
| 
|     Projects: #ghc
| 
|     Differential Revision: https://phabricator.haskell.org/D1287
| 
|     GHC Trac Issues: #10832
| 
| 
| >---------------------------------------------------------------
| 
| 332bc0d3af0a208ad310ce28cf798d4682423329
|  compiler/deSugar/DsMeta.hs                         | 18 +++++--
|  compiler/hsSyn/Convert.hs                          | 15 ++++--
|  compiler/hsSyn/HsDecls.hs                          | 21 ++++++--
|  compiler/iface/IfaceSyn.hs                         | 18 ++++---
|  compiler/parser/Parser.y                           | 31 +++++++----
|  compiler/prelude/THNames.hs                        | 61 ++++++++++++--------
| --
|  compiler/rename/RnSource.hs                        | 35 +++++++++----
|  compiler/typecheck/FamInst.hs                      | 57 ++++++++++++--------
|  compiler/typecheck/TcInteract.hs                   | 47 +++++++++++------
|  compiler/typecheck/TcSplice.hs                     | 11 ++--
|  compiler/typecheck/TcTyClsDecls.hs                 | 29 +++++++---
|  compiler/typecheck/TcValidity.hs                   | 15 +++---
|  compiler/types/FamInstEnv.hs                       | 27 +++++-----
|  compiler/types/TyCon.hs                            | 11 ++--
|  compiler/types/Unify.hs                            | 15 +++---
|  libraries/ghci/GHCi/TH/Binary.hs                   |  2 +-
|  libraries/template-haskell/Language/Haskell/TH.hs  |  4 +-
|  .../template-haskell/Language/Haskell/TH/Lib.hs    | 10 ++--
|  .../template-haskell/Language/Haskell/TH/Ppr.hs    | 10 ++--
|  .../template-haskell/Language/Haskell/TH/Syntax.hs |  5 +-
|  20 files changed, 285 insertions(+), 157 deletions(-)
| 
| Diff suppressed because of size. To see it, use:
| 
|     git diff-tree --root --patch-with-stat --no-color --find-copies-harder --
| ignore-space-at-eol --cc 332bc0d3af0a208ad310ce28cf798d4682423329
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2004c57729e44f345ad
| 008d30ba6867c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MrrhJNaC991MpNKtwr
| Tb5cg7H41RAdGxX2c7GWosm5c%3d

From simonpj at microsoft.com  Wed Dec 23 22:48:45 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 23 Dec 2015 22:48:45 +0000
Subject: alignment failure
Message-ID: <cc5cb1e4160146d4885702a18d86114e@DB4PR30MB030.064d.mgd.msft.net>

Ryan
Your commit d9c13cb8f5be89a030783d758fcf7c077351c6a9 breaks the build of ?haskeline? on Windows. See below.
I think the fix is to remove the #let from libraries/haskeline/./System/Console/Haskeline/Backend/Win32.hsc.
Could you make that, or whatever the right fix is, happen?  Thanks
Simon


"inplace/bin/hsc2hs.exe" '--cc=C:/code/HEAD/inplace/mingw/bin/gcc.exe' '--ld=C:/code/HEAD/inplace/mingw/bin/gcc.exe'   --cflag=-Wall --cflag=-Werror --cflag=-fno-stack-protector   --cflag=-Dx86_64_HOST_ARCH=1 --cflag=-Dmingw32_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 '--cflag=-fno-stack-protector' '--cflag=-Wall' '--cflag=-Werror' '--cflag=-Ilibraries/haskeline/dist-install/build/autogen' '--cflag=-Ilibraries/haskeline/includes' '--cflag=-DUSE_GHC_ENCODINGS' '--cflag=-DMINGW' '--cflag=-IC:\code\HEAD\libraries\directory\include' '--cflag=-IC:\code\HEAD\libraries\time\lib/include' '--cflag=-IC:\code\HEAD\libraries\containers\include' '--cflag=-IC:\code\HEAD\libraries\Win32\include' '--cflag=-IC:\code\HEAD\libraries\bytestring\include' '--cflag=-IC:\code\HEAD\libraries\base\include' '--cflag=-IC:\code\HEAD\libraries\integer-gmp\include' '--cflag=-IC:/code/HEAD/rts/dist/build' '--cflag=-IC:/code/HEAD/includes' '--cflag=-IC:/code/HEAD/includes/dist-derivedconstants/header' '--cflag=-Wno-error=inline' '--lflag=-LC:\code\HEAD\libraries\transformers\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\directory\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\time\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\filepath\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\containers\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\Win32\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\bytestring\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\deepseq\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\array\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\base\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\integer-gmp\dist-install\build' '--lflag=-LC:\code\HEAD\libraries\ghc-prim\dist-install\build' '--lflag=-LC:/code/HEAD/rts/dist/build' '--lflag=-luser32' '--lflag=-lgdi32' '--lflag=-lwinmm' '--lflag=-ladvapi32' '--lflag=-lshell32' '--lflag=-lshfolder' '--lflag=-lwsock32' '--lflag=-luser32' '--lflag=-lshell32' '--lflag=-lm' '--lflag=-lwsock32' '--lflag=-lgdi32' '--lflag=-lwinmm' '--lflag=-lmingwex' --cflag=-Ilibraries/haskeline/dist-install/build/autogen --cflag=-include --cflag=libraries/haskeline/dist-install/build/autogen/cabal_macros.h   libraries/haskeline/./System/Console/Haskeline/Backend/Win32.hsc -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs

Win32.hsc:170:0: error: "hsc_alignment" redefined [-Werror]

In file included from libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32_hsc_make.c:1:0:

C:\code\HEAD\inplace/lib/template-hsc.h:88:0: note: this is the location of the previous definition

#define hsc_alignment(t...) \

^

cc1.exe: all warnings being treated as errors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151223/d096ef0a/attachment-0001.html>

From ryan.gl.scott at gmail.com  Thu Dec 24 01:18:11 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 23 Dec 2015 19:18:11 -0600
Subject: alignment failure
In-Reply-To: <cc5cb1e4160146d4885702a18d86114e@DB4PR30MB030.064d.mgd.msft.net>
References: <cc5cb1e4160146d4885702a18d86114e@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CADdQpRDqfMerVZH+m4m6BCfRkuZEMcrnTmpTgH35EMSrZm4sgQ@mail.gmail.com>

Ack, sorry about that. The maintainer of haskeline just made the
relevant changes needed to fix the issue?I just need someone with push
access to update the haskeline submodule.

Ryan S.

On Wed, Dec 23, 2015 at 4:48 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Ryan
>
> Your commit d9c13cb8f5be89a030783d758fcf7c077351c6a9 breaks the build of
> ?haskeline? on Windows. See below.
>
> I think the fix is to remove the #let from
> libraries/haskeline/./System/Console/Haskeline/Backend/Win32.hsc.
>
> Could you make that, or whatever the right fix is, happen?  Thanks
>
> Simon
>
>
>
> "inplace/bin/hsc2hs.exe" '--cc=C:/code/HEAD/inplace/mingw/bin/gcc.exe'
> '--ld=C:/code/HEAD/inplace/mingw/bin/gcc.exe'   --cflag=-Wall
> --cflag=-Werror --cflag=-fno-stack-protector   --cflag=-Dx86_64_HOST_ARCH=1
> --cflag=-Dmingw32_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711
> '--cflag=-fno-stack-protector' '--cflag=-Wall' '--cflag=-Werror'
> '--cflag=-Ilibraries/haskeline/dist-install/build/autogen'
> '--cflag=-Ilibraries/haskeline/includes' '--cflag=-DUSE_GHC_ENCODINGS'
> '--cflag=-DMINGW' '--cflag=-IC:\code\HEAD\libraries\directory\include'
> '--cflag=-IC:\code\HEAD\libraries\time\lib/include'
> '--cflag=-IC:\code\HEAD\libraries\containers\include'
> '--cflag=-IC:\code\HEAD\libraries\Win32\include'
> '--cflag=-IC:\code\HEAD\libraries\bytestring\include'
> '--cflag=-IC:\code\HEAD\libraries\base\include'
> '--cflag=-IC:\code\HEAD\libraries\integer-gmp\include'
> '--cflag=-IC:/code/HEAD/rts/dist/build' '--cflag=-IC:/code/HEAD/includes'
> '--cflag=-IC:/code/HEAD/includes/dist-derivedconstants/header'
> '--cflag=-Wno-error=inline'
> '--lflag=-LC:\code\HEAD\libraries\transformers\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\directory\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\time\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\filepath\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\containers\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\Win32\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\bytestring\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\deepseq\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\array\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\base\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\integer-gmp\dist-install\build'
> '--lflag=-LC:\code\HEAD\libraries\ghc-prim\dist-install\build'
> '--lflag=-LC:/code/HEAD/rts/dist/build' '--lflag=-luser32' '--lflag=-lgdi32'
> '--lflag=-lwinmm' '--lflag=-ladvapi32' '--lflag=-lshell32'
> '--lflag=-lshfolder' '--lflag=-lwsock32' '--lflag=-luser32'
> '--lflag=-lshell32' '--lflag=-lm' '--lflag=-lwsock32' '--lflag=-lgdi32'
> '--lflag=-lwinmm' '--lflag=-lmingwex'
> --cflag=-Ilibraries/haskeline/dist-install/build/autogen --cflag=-include
> --cflag=libraries/haskeline/dist-install/build/autogen/cabal_macros.h
> libraries/haskeline/./System/Console/Haskeline/Backend/Win32.hsc -o
> libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs
>
> Win32.hsc:170:0: error: "hsc_alignment" redefined [-Werror]
>
> In file included from
> libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32_hsc_make.c:1:0:
>
> C:\code\HEAD\inplace/lib/template-hsc.h:88:0: note: this is the location of
> the previous definition
>
> #define hsc_alignment(t...) \
>
> ^
>
> cc1.exe: all warnings being treated as errors

From simonpj at microsoft.com  Thu Dec 24 15:11:31 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Dec 2015 15:11:31 +0000
Subject: wip/T10832-generalised-injectivity
Message-ID: <c6a75016f93546cf94924ec51822d30f@DB4PR30MB030.064d.mgd.msft.net>

Jan, Richard
I?ve spent much of today working on the generalised-injectivity branch
wip/T10832-generalised-injectivity
I?ve done a lot of refactoring: you could to worse than start with Note [Injectivity information] in TyCon, and the data types that follow.
Not finished, but making progress
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151224/4fcc36e1/attachment.html>

From ben at smart-cactus.org  Sun Dec 27 10:57:00 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 27 Dec 2015 11:57:00 +0100
Subject: CmmSwitchTest on 32-bit platforms?
Message-ID: <878u4g9n2b.fsf@smart-cactus.org>

Hi Joachim!

One of the issues I've recently noticed is that the
codeGen/should_run/CmmSwitchTest testcase fails on 32-bit architectures
[1] due to its use of 64-bit literals. Judging from the commit history
of this file I suspect you are the original author of this test. What
should we do about this?

It seems like one option would be to make the sub-parts of this test
which require 64-bit literals conditional on the word size.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/ticket/11297
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151227/e0d46afd/attachment.sig>

From matthewtpickering at gmail.com  Mon Dec 28 00:33:15 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 28 Dec 2015 00:33:15 +0000
Subject: Improving trac notifications
Message-ID: <CALuQ0m-c4-DQdm4qTyWukmCsgk78R_nHHV311tq6oy+Ki6ZTGQ@mail.gmail.com>

I subscribe to the ghc-tickets[1] mailing list which provides updates
to all trac tickets. This is very useful, however when a ticket
description is updated the whole description is included in the email
which makes it hard to see what actually changed. The web interface
shows a nice diff[2] of the changes, I think it would be good if
emails could also include a diff rather than the current quite useless
output.

After a bit of investigation, it appears that the easiest way to
achieve this is apply a simple patch to our copy of trac. The current
format is hard coded on line 558 in this module, it seems easy to
modify this section to instead provide a diff.

http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pysrc.html

There is also already a module which has the diff operations
implemented which could be used.

http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-module.html

Another option would be to use something like the `AnnouncerPlugin`[3]
but that seems like much more work and would still require someone to
write a custom formatter.

Any thoughts?

Matt

[1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets

[2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6

[3]: https://trac-hacks.org/wiki/AnnouncerPlugin

From ben at smart-cactus.org  Mon Dec 28 10:42:41 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 28 Dec 2015 11:42:41 +0100
Subject: Improving trac notifications
In-Reply-To: <CALuQ0m-c4-DQdm4qTyWukmCsgk78R_nHHV311tq6oy+Ki6ZTGQ@mail.gmail.com>
References: <CALuQ0m-c4-DQdm4qTyWukmCsgk78R_nHHV311tq6oy+Ki6ZTGQ@mail.gmail.com>
Message-ID: <87twn297mm.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> I subscribe to the ghc-tickets[1] mailing list which provides updates
> to all trac tickets. This is very useful, however when a ticket
> description is updated the whole description is included in the email
> which makes it hard to see what actually changed. The web interface
> shows a nice diff[2] of the changes, I think it would be good if
> emails could also include a diff rather than the current quite useless
> output.
>
I think this would be a great improvement. I, for one, am quite guilty
of incrementally editing ticket descriptions and the current email
notifications are nearly useless in this case.

> After a bit of investigation, it appears that the easiest way to
> achieve this is apply a simple patch to our copy of trac. The current
> format is hard coded on line 558 in this module, it seems easy to
> modify this section to instead provide a diff.
>
Herbert, perhaps we could do something along these lines?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151228/77abf4a2/attachment.sig>

From alan.zimm at gmail.com  Mon Dec 28 19:01:05 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 28 Dec 2015 21:01:05 +0200
Subject: Change from 7.10.3 to current master
In-Reply-To: <620eda64a8f441b68e0c29e92ec0f6db@AM3PR30MB019.064d.mgd.msft.net>
References: <CANma=H9Hk5miH6y3F=jNCNB1-Rq15FcLh8awcQfhioAsg_1Y5Q@mail.gmail.com>
 <620eda64a8f441b68e0c29e92ec0f6db@AM3PR30MB019.064d.mgd.msft.net>
Message-ID: <CANma=H9TeGGbk9L6W=4gnjJ=iryaaBimS9tHuOqZTNOKf14Q5w@mail.gmail.com>

This is now https://ghc.haskell.org/trac/ghc/ticket/11307

On Mon, Dec 21, 2015 at 1:03 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> |  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a
>
> What do you expect this to mean?  I suppose you could hope that GHC will unravel the fixity of :++: and :>, to determine whether you are giving an instance for :++: or for :>?
>
> That sounds reasonable, but it's not trivial.
>
> Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and it looks like this:
>
>
> data TyFamEqn name pats
>   = TyFamEqn
>        { tfe_tycon :: Located name
>        , tfe_pats  :: pats
>        , tfe_rhs   :: LHsType name }
>
>
> So we've already decided (in the parser) what the type-function name is.  But we can't do that in this case, because the parser doesn't understand fixity.
>
> To deal with this we'd need to change to
>
> data TyFamEqn name pats
>   = TyFamEqn
>        { tfe_lhs  :: LHSType name
>        , tfe_rhs   :: LHsType name }
>
> so that the LHS was just a type.  Now the renamer can re-jiggle its fixities in the usual way, and only in the type checker will we need to decide exactly which type it's an instance of.  Easy!
>
> This might be a good change to make! It's a bit like in ClsInstDecl, you'll see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed into which class it is.
>
>
> So: my instinct is that the above would be Fine Thing.  Make a ticket?  Add these comments to give context?  Excecute?
>
> Thanks
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan
> |  & Kim Zimmerman
> |  Sent: 20 December 2015 18:55
> |  To: ghc-devs at haskell.org
> |  Subject: Change from 7.10.3 to current master
> |
> |  I am in the process of updating ghc-exactprint for current GHC master.
> |
> |  One of the tests has the following in it
> |
> |  -----------------------------
> |  {-# LANGUAGE TypeOperators #-}
> |
> |  type family (r1 :++: r2); infixr 5 :++:
> |  type instance r :++: Nil = r
> |  type instance r1 :++: r2 :> a = (r1 :++: r2) :> a
> |  ------------------------------
> |
> |  Current GHC master rejects this with
> |
> |  /tmp/Foo.hs:5:15: error:
> |      Malformed head of type or class declaration: r1 :++: r2 :> a
> |
> |  Is this expected, or a bug?
> |
> |  Alan
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c17b33d7be13045d
> |  d141308d3096f2bc5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LGroqdv
> |  nYFSxydfZFQydhi2N6lltWwi%2b4tt%2bM3LH0P0%3d

From ggreif at gmail.com  Mon Dec 28 21:31:45 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 28 Dec 2015 22:31:45 +0100
Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD
In-Reply-To: <063.a9d359e8fe82f731bb88defbd855eb68@haskell.org>
References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org>
 <063.a9d359e8fe82f731bb88defbd855eb68@haskell.org>
Message-ID: <CAK-hX0nD+8H_TAH7103vhz85QxVS_iDUziRR4t5qr83a-Xybow@mail.gmail.com>

Sounds very much like it :-) Will try the workaround tomorrow.

Em segunda-feira, 28 de dezembro de 2015, GHC <ghc-devs at haskell.org>
escreveu:

> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD
> -------------------------------------+-------------------------------------
>         Reporter:  heisenbug         |                Owner:
>             Type:  bug               |               Status:  new
>         Priority:  high              |            Milestone:  8.0.1
>        Component:  Compiler          |              Version:  7.11
>       Resolution:                    |             Keywords:
> Operating System:  Unknown/Multiple  |         Architecture:
>  Type of failure:  Building GHC      |  Unknown/Multiple
>   failed                             |            Test Case:
>       Blocked By:                    |             Blocking:
>  Related Tickets:                    |  Differential Rev(s):
>        Wiki Page:                    |
> -------------------------------------+-------------------------------------
>
> Comment (by hvr):
>
>  Replying to [comment:4 heisenbug]:
>  > It would be interesting to see if it is just me or if somebody can
>  reproduce the problem.
>
>  Re `genprimopcode` see #11302 and #11303
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11239#comment:6>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151228/aea28c2e/attachment.html>

From takenobu.hs at gmail.com  Tue Dec 29 09:54:08 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 29 Dec 2015 18:54:08 +0900
Subject: Unlifted data types
In-Reply-To: <1441353701-sup-9422@sabre>
References: <1441353701-sup-9422@sabre>
Message-ID: <CAPB_Nvybde2aSAgZzZddGgGPtewqwt=MXYqyP+txEAp-XqS0jg@mail.gmail.com>

Hi devs,

Apologies if I'm missing context.

Is it more better that "Unlifted" kind is other name, such as
"BoxedUnlifted", "Bul", "%",... ?


I'm studying Unlifted data types [1].
It's good proposals to optimize code by users.

But I worry that newcomers may be confusing about its kind name.
In my understanding [2], "unlifted" types may include "unboxed, unlifted"
type.
But "unlifted" kind does not include "unboxed, unlifted" types.


[1]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
[2]:
http://takenobu-hs.github.io/downloads/haskell_lazy_evaluation.pdf#page=190
 (sorry, large)

I wish you a happy new year.
Regards,
Takenobu


2015-09-04 17:03 GMT+09:00 Edward Z. Yang <ezyang at mit.edu>:

> Hello friends,
>
> After many discussions and beers at ICFP, I've written up my current
> best understanding of the unlifted data types proposal:
>
>     https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes
>
> Many thanks to Richard, Iavor, Ryan, Simon, Duncan, George, Paul,
> Edward Kmett, and any others who I may have forgotten for crystallizing
> this proposal.
>
> Cheers,
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151229/2d5bdf67/attachment.html>

From takenobu.hs at gmail.com  Tue Dec 29 09:55:20 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 29 Dec 2015 18:55:20 +0900
Subject: May I update Kind page on wiki?
Message-ID: <CAPB_NvyUraKNMYi0fOdOkBLJNdUtrezmeEGStGfEJCRozvkxgQ@mail.gmail.com>

Dear devs,

Apologies if I'm missing list.

May I update Kind page on wiki[1] ?


In my understanding[2], kind '#' means "unlifted" kind rather than
"unboxed" kind.
If it's right, may I update the wiki[1] for newcomers ?

I'd like to change the wiki page[1] as following:

- GHC introduces another inhabited kind, #, for unboxed types.
+ GHC introduces another inhabited kind, #, for unlifted types.


[1]: https://wiki.haskell.org/Kind
[2]:
https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/types/TyCoRep.hs#L284

I wish you a happy new year.
Regards,
Takenobu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151229/9d6c5f3a/attachment.html>

From eir at cis.upenn.edu  Wed Dec 30 14:51:23 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 30 Dec 2015 09:51:23 -0500
Subject: May I update Kind page on wiki?
In-Reply-To: <CAPB_NvyUraKNMYi0fOdOkBLJNdUtrezmeEGStGfEJCRozvkxgQ@mail.gmail.com>
References: <CAPB_NvyUraKNMYi0fOdOkBLJNdUtrezmeEGStGfEJCRozvkxgQ@mail.gmail.com>
Message-ID: <D94C3948-78B7-4CE7-B751-31065AFB60AF@cis.upenn.edu>

Yes, please. Thanks for picking up on this!

Richard

On Dec 29, 2015, at 4:55 AM, Takenobu Tani <takenobu.hs at gmail.com> wrote:

> Dear devs,
> 
> Apologies if I'm missing list.
> 
> May I update Kind page on wiki[1] ?
> 
> 
> In my understanding[2], kind '#' means "unlifted" kind rather than "unboxed" kind.
> If it's right, may I update the wiki[1] for newcomers ?
> 
> I'd like to change the wiki page[1] as following:
> 
> - GHC introduces another inhabited kind, #, for unboxed types.
> + GHC introduces another inhabited kind, #, for unlifted types.
> 
> 
> [1]: https://wiki.haskell.org/Kind
> [2]: https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/types/TyCoRep.hs#L284
> 
> I wish you a happy new year.
> Regards,
> Takenobu
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151230/ab984417/attachment.html>

From takenobu.hs at gmail.com  Thu Dec 31 05:59:56 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Thu, 31 Dec 2015 14:59:56 +0900
Subject: May I update Kind page on wiki?
In-Reply-To: <D94C3948-78B7-4CE7-B751-31065AFB60AF@cis.upenn.edu>
References: <CAPB_NvyUraKNMYi0fOdOkBLJNdUtrezmeEGStGfEJCRozvkxgQ@mail.gmail.com>
 <D94C3948-78B7-4CE7-B751-31065AFB60AF@cis.upenn.edu>
Message-ID: <CAPB_NvzvcJzJktKR4gZR47H+3EVFd6wfSY3CtU0QvtNSZLHT6g@mail.gmail.com>

Hi Richard,

Thank you for the advice.
I'll get a wiki account and update this.

I wish you a happy new year =)
Regards,
Takenobu



2015-12-30 23:51 GMT+09:00 Richard Eisenberg <eir at cis.upenn.edu>:

> Yes, please. Thanks for picking up on this!
>
> Richard
>
> On Dec 29, 2015, at 4:55 AM, Takenobu Tani <takenobu.hs at gmail.com> wrote:
>
> Dear devs,
>
> Apologies if I'm missing list.
>
> May I update Kind page on wiki[1] ?
>
>
> In my understanding[2], kind '#' means "unlifted" kind rather than
> "unboxed" kind.
> If it's right, may I update the wiki[1] for newcomers ?
>
> I'd like to change the wiki page[1] as following:
>
> - GHC introduces another inhabited kind, #, for unboxed types.
> + GHC introduces another inhabited kind, #, for unlifted types.
>
>
> [1]: https://wiki.haskell.org/Kind
> [2]:
> https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/types/TyCoRep.hs#L284
>
> I wish you a happy new year.
> Regards,
> Takenobu
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/13c8b005/attachment.html>

From alain.odea at gmail.com  Thu Dec 31 07:09:49 2015
From: alain.odea at gmail.com (Alain O'Dea)
Date: Thu, 31 Dec 2015 07:09:49 +0000
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
Message-ID: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>

On SmartOS GHC flag warnings show up like this:
/tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning:
    -fffi is deprecated: use -XForeignFunctionInterface or pragma {-#
LANGUAGE ForeignFunctionInterface #-} instead

It appears that this line in DriverPipeline leads to the correct filename
in warnings on Ubuntu, but not on SmartOS:
src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn
https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/compiler/main/DriverPipeline.hs#L865

How does the intermediate hscpp filename get restored to a correct filename
if warnings are generated during a re-read of the pragmas after having
preprocessed the file?

Full investigation notes are here (rambling and unedited):
https://gist.github.com/AlainODea/98141991849093285c52
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/6430f799/attachment.html>

From karel.gardas at centrum.cz  Thu Dec 31 08:28:03 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 31 Dec 2015 09:28:03 +0100
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
Message-ID: <5684E713.4050503@centrum.cz>


Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just 
verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different 
non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,

Thanks,
Karel

On 12/31/15 08:09 AM, Alain O'Dea wrote:
> On SmartOS GHC flag warnings show up like this:
> /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning:
>      -fffi is deprecated: use -XForeignFunctionInterface or pragma {-#
> LANGUAGE ForeignFunctionInterface #-} instead
>
> It appears that this line in DriverPipeline leads to the correct
> filename in warnings on Ubuntu, but not on SmartOS:
> src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn
> https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/compiler/main/DriverPipeline.hs#L865
>
> How does the intermediate hscpp filename get restored to a correct
> filename if warnings are generated during a re-read of the pragmas after
> having preprocessed the file?
>
> Full investigation notes are here (rambling and unedited):
> https://gist.github.com/AlainODea/98141991849093285c52
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


From karel.gardas at centrum.cz  Thu Dec 31 09:00:53 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 31 Dec 2015 10:00:53 +0100
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <5684E713.4050503@centrum.cz>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz>
Message-ID: <5684EEC5.6040507@centrum.cz>


Also related: https://haskell-phabricator.global.ssl.fastly.net/D151

as Solaris is not the only problematic platform with CPP, HVR has 
started excellent 'RFC: "Native -XCPP" Proposal' thread in the past 
together with the wiki page: 
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

Hope this helps,
Karel


On 12/31/15 09:28 AM, Karel Gardas wrote:
>
> Hi Alain,
>
> I guess you are hit by well known issue in GCC's CPP on Solaris. Just
> verify here:
>
> https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
>
> solution in this case is simple: use configure option to set different
> non buggy CPP as a CPP for GHC.
>
> Please let me know if this is the culprit,
>
> Thanks,
> Karel
>
> On 12/31/15 08:09 AM, Alain O'Dea wrote:
>> On SmartOS GHC flag warnings show up like this:
>> /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning:
>>      -fffi is deprecated: use -XForeignFunctionInterface or pragma {-#
>> LANGUAGE ForeignFunctionInterface #-} instead
>>
>> It appears that this line in DriverPipeline leads to the correct
>> filename in warnings on Ubuntu, but not on SmartOS:
>> src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn
>> https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/compiler/main/DriverPipeline.hs#L865
>>
>>
>> How does the intermediate hscpp filename get restored to a correct
>> filename if warnings are generated during a re-read of the pragmas after
>> having preprocessed the file?
>>
>> Full investigation notes are here (rambling and unedited):
>> https://gist.github.com/AlainODea/98141991849093285c52
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


From ben at smart-cactus.org  Thu Dec 31 12:30:05 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 31 Dec 2015 13:30:05 +0100
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <5684E713.4050503@centrum.cz>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz>
Message-ID: <87a8oq94xe.fsf@smart-cactus.org>

Karel Gardas <karel.gardas at centrum.cz> writes:

> Hi Alain,
>
> I guess you are hit by well known issue in GCC's CPP on Solaris. Just 
> verify here:
>
> https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
>
> solution in this case is simple: use configure option to set different 
> non buggy CPP as a CPP for GHC.
>
> Please let me know if this is the culprit,
>
Perhaps we should add an autoconf check to preempt this issue and point
affected users in the direction of a solution?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/c9dcbb65/attachment.sig>

From alain.odea at gmail.com  Thu Dec 31 13:49:13 2015
From: alain.odea at gmail.com (Alain O'Dea)
Date: Thu, 31 Dec 2015 13:49:13 +0000
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <87a8oq94xe.fsf@smart-cactus.org>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
Message-ID: <CAM6cUzDaeJh85dhSNO_UCXWx02_jEWLzpvO4oHvbH0xJNMdhHw@mail.gmail.com>

Thank you Karel. I'll try that tomorrow and report back my results.

On Thu, Dec 31, 2015 at 09:00 Ben Gamari <ben at smart-cactus.org> wrote:

> Karel Gardas <karel.gardas at centrum.cz> writes:
>
> > Hi Alain,
> >
> > I guess you are hit by well known issue in GCC's CPP on Solaris. Just
> > verify here:
> >
> > https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
> >
> > solution in this case is simple: use configure option to set different
> > non buggy CPP as a CPP for GHC.
> >
> > Please let me know if this is the culprit,
> >
> Perhaps we should add an autoconf check to preempt this issue and point
> affected users in the direction of a solution?
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/96230cf5/attachment.html>

From karel.gardas at centrum.cz  Thu Dec 31 15:21:28 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 31 Dec 2015 16:21:28 +0100
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <87a8oq94xe.fsf@smart-cactus.org>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
Message-ID: <568547F8.1040209@centrum.cz>

On 12/31/15 01:30 PM, Ben Gamari wrote:
> Karel Gardas <karel.gardas at centrum.cz> writes:
>
>> Hi Alain,
>>
>> I guess you are hit by well known issue in GCC's CPP on Solaris. Just
>> verify here:
>>
>> https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
>>
>> solution in this case is simple: use configure option to set different
>> non buggy CPP as a CPP for GHC.
>>
>> Please let me know if this is the culprit,
>>
> Perhaps we should add an autoconf check to preempt this issue and point
> affected users in the direction of a solution?

Hmm, I tried that with https://phabricator.haskell.org/D151 -- but 
perhaps some nice warning emitted during configure time in case of 
undetected GCC 3.4.3 on Solaris will help here? This will also need to 
be done in bindist configure thought.

Alain, would you do that? I'm asking since you've been hit by this 
recently...

Karel


From alain.odea at gmail.com  Thu Dec 31 18:41:52 2015
From: alain.odea at gmail.com (Alain O'Dea)
Date: Thu, 31 Dec 2015 18:41:52 +0000
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <568547F8.1040209@centrum.cz>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
 <568547F8.1040209@centrum.cz>
Message-ID: <CAM6cUzAXDH_8KDLWKZ4Z=ZFnnMzjWtAd670aTf8Araam_M0Z4Q@mail.gmail.com>

Yes. I can do that.

On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x
through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to verify
that as part of checking this.

I think requiring cpphs on Illumos and Solaris might be a reasonable
compromise. I like the idea of warning about this and suggesting
--with-hs-cpp /path/to/cpphs.
On Thu, Dec 31, 2015 at 11:51 Karel Gardas <karel.gardas at centrum.cz> wrote:

> On 12/31/15 01:30 PM, Ben Gamari wrote:
> > Karel Gardas <karel.gardas at centrum.cz> writes:
> >
> >> Hi Alain,
> >>
> >> I guess you are hit by well known issue in GCC's CPP on Solaris. Just
> >> verify here:
> >>
> >> https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
> >>
> >> solution in this case is simple: use configure option to set different
> >> non buggy CPP as a CPP for GHC.
> >>
> >> Please let me know if this is the culprit,
> >>
> > Perhaps we should add an autoconf check to preempt this issue and point
> > affected users in the direction of a solution?
>
> Hmm, I tried that with https://phabricator.haskell.org/D151 -- but
> perhaps some nice warning emitted during configure time in case of
> undetected GCC 3.4.3 on Solaris will help here? This will also need to
> be done in bindist configure thought.
>
> Alain, would you do that? I'm asking since you've been hit by this
> recently...
>
> Karel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/fdfe205f/attachment.html>

From karel.gardas at centrum.cz  Thu Dec 31 20:21:39 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 31 Dec 2015 21:21:39 +0100
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <CAM6cUzAXDH_8KDLWKZ4Z=ZFnnMzjWtAd670aTf8Araam_M0Z4Q@mail.gmail.com>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
 <568547F8.1040209@centrum.cz>
 <CAM6cUzAXDH_8KDLWKZ4Z=ZFnnMzjWtAd670aTf8Araam_M0Z4Q@mail.gmail.com>
Message-ID: <56858E53.8010105@centrum.cz>

On 12/31/15 07:41 PM, Alain O'Dea wrote:
> Yes. I can do that.
>
> On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x
> through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to
> verify that as part of checking this.

This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior, 
while all 4.x provides broken CPP. That means as a workaround when GCC 
3.4.3 is installed I set it as GHC's CPP automatically on Solaris. When 
it is not available, then GHC behaves like you've seen when using CPP...

Hopefully this is more clear now,

Karel


From alain.odea at gmail.com  Thu Dec 31 20:49:39 2015
From: alain.odea at gmail.com (Alain O'Dea)
Date: Thu, 31 Dec 2015 20:49:39 +0000
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <56858E53.8010105@centrum.cz>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
 <568547F8.1040209@centrum.cz>
 <CAM6cUzAXDH_8KDLWKZ4Z=ZFnnMzjWtAd670aTf8Araam_M0Z4Q@mail.gmail.com>
 <56858E53.8010105@centrum.cz>
Message-ID: <CAM6cUzA7Pvr18aZ18-FKq60FfMt9bTczGfpKK29S2Yg+nx38gw@mail.gmail.com>

Thanks for the clarification. I understand now.
On Thu, Dec 31, 2015 at 16:52 Karel Gardas <karel.gardas at centrum.cz> wrote:

> On 12/31/15 07:41 PM, Alain O'Dea wrote:
> > Yes. I can do that.
> >
> > On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x
> > through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to
> > verify that as part of checking this.
>
> This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior,
> while all 4.x provides broken CPP. That means as a workaround when GCC
> 3.4.3 is installed I set it as GHC's CPP automatically on Solaris. When
> it is not available, then GHC behaves like you've seen when using CPP...
>
> Hopefully this is more clear now,
>
> Karel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/6666fb99/attachment.html>

From simonpj at microsoft.com  Thu Dec 31 22:31:03 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 31 Dec 2015 22:31:03 +0000
Subject: Haskeline on Windows
Message-ID: <106482f96f15463880e97ab31923affb@DB4PR30MB030.064d.mgd.msft.net>

To get ?haskeline? to compile on Windows I have to apply the patch below.    Otherwise this alignment thing is defined twice and the build fails

Could someone fix it properly?  Thanks!

Simon


modified   System/Console/Haskeline/Backend/Win32.hsc

@@ -167,7 +167,7 @@ getKeyEvent p = do

data Coord = Coord {coordX, coordY :: Int}

                 deriving Show



-#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)

+-- #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)

instance Storable Coord where

     sizeOf _ = (#size COORD)

     alignment _ = (#alignment COORD)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/b21dde6d/attachment-0001.html>

From ryan.gl.scott at gmail.com  Thu Dec 31 22:39:00 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 31 Dec 2015 16:39:00 -0600
Subject: Haskeline on Windows
Message-ID: <CADdQpRCoOm+-wxThqyO1GndQAybLJDYLn4F2heDJdDQh=X8Apg@mail.gmail.com>

This is already fixed in the haskeline GitHub repo [1], but I never
got around to updating the downstream haskeline repo on
git.haskell.org [2] since I don't have push access. Can someone update
it for me?

Ryan S.
-----
[1] https://github.com/judah/haskeline/commit/576e7cbc4cde1195fb97c8540caad38de8d7e681
[2] http://git.haskell.org/packages/haskeline.git

From lonetiger at gmail.com  Thu Dec 31 22:45:00 2015
From: lonetiger at gmail.com (Tamar Christina)
Date: Thu, 31 Dec 2015 14:45:00 -0800
Subject: Haskeline on Windows
Message-ID: <-2095242510434908623@unknownmsgid>

GHC 8.0 wasn't branched at the time and I forgot to push the mk entry
to ignore the warning. But I believe now that GHC has been branched we
can just update the submodule.

The pull request that fixed this issue had a lot of other unrelated
changes and was rather big so it wasn't updated before.

Regards,
TamarFrom: Ryan Scott
Sent: ?31/?12/?2015 23:39
To: ghc-devs at haskell.org
Subject: Re: Haskeline on Windows
This is already fixed in the haskeline GitHub repo [1], but I never
got around to updating the downstream haskeline repo on
git.haskell.org [2] since I don't have push access. Can someone update
it for me?

Ryan S.
-----
[1] https://github.com/judah/haskeline/commit/576e7cbc4cde1195fb97c8540caad38de8d7e681
[2] http://git.haskell.org/packages/haskeline.git
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From alain.odea at gmail.com  Thu Dec 31 23:17:02 2015
From: alain.odea at gmail.com (Alain O'Dea)
Date: Thu, 31 Dec 2015 23:17:02 +0000
Subject: Flag warnings show intermediate hscpp filenames on SmartOS
In-Reply-To: <CAM6cUzA7Pvr18aZ18-FKq60FfMt9bTczGfpKK29S2Yg+nx38gw@mail.gmail.com>
References: <CAM6cUzD_4ZNmz8F14+xvgHy+C1ySbfObguQGYbjYWiNydj0+yg@mail.gmail.com>
 <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org>
 <568547F8.1040209@centrum.cz>
 <CAM6cUzAXDH_8KDLWKZ4Z=ZFnnMzjWtAd670aTf8Araam_M0Z4Q@mail.gmail.com>
 <56858E53.8010105@centrum.cz>
 <CAM6cUzA7Pvr18aZ18-FKq60FfMt9bTczGfpKK29S2Yg+nx38gw@mail.gmail.com>
Message-ID: <CAM6cUzAROUKtLfLXH1ZU41HaeSXZ=i3RRJLJMeuBMcGnSkwv+A@mail.gmail.com>

cpphs isn't a direct option.  It won't install on SmartOS with Cabal.  GCC
4.7 is the earliest GCC supported so I'll have to try something else for
SmartOS.

It looks like the GCC Specs are the problem.

On Ubuntu the Spec for cpp is:

*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}

On SmartOS the Spec for cpp is:

*cpp:
%{,assembler-with-cpp:-P} %(cpp_subtarget)

I think this is how the -P gets injected.  I think this is correctable.  I
had a similar issue with -std=c99 which is the default for C compiling on
Ubuntu but not on SmartOS leading to issues with compiling source that
isn't old school C (like persistent-sqlite).

Anyways I must retire from this and entertain my guests.  Happy New Year
folks.


On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea <alain.odea at gmail.com> wrote:

> Thanks for the clarification. I understand now.
> On Thu, Dec 31, 2015 at 16:52 Karel Gardas <karel.gardas at centrum.cz>
> wrote:
>
>> On 12/31/15 07:41 PM, Alain O'Dea wrote:
>> > Yes. I can do that.
>> >
>> > On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x
>> > through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to
>> > verify that as part of checking this.
>>
>> This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior,
>> while all 4.x provides broken CPP. That means as a workaround when GCC
>> 3.4.3 is installed I set it as GHC's CPP automatically on Solaris. When
>> it is not available, then GHC behaves like you've seen when using CPP...
>>
>> Hopefully this is more clear now,
>>
>> Karel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151231/96054199/attachment.html>