From austin at well-typed.com  Wed Oct  1 16:02:41 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 1 Oct 2014 11:02:41 -0500
Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590
In-Reply-To: <CAHNEpiw_b7vV-HbXohM1diF6i7kkL1NpqGb_tqqn_X8-=2PeLQ@mail.gmail.com>
References: <CAEs96n2QGx=Nx+bjKR9QQMs4x041AXzBRiqhLEgMxec67DHqbQ@mail.gmail.com>
 <5F743CA1-227C-4F5C-B38E-1DD860659168@me.com>
 <CAKFCL4UAdF4Rgsyqs_u-R1soqaEO3+NU+VgO+dcZYMLXGe8F+w@mail.gmail.com>
 <CAHNEpiw_b7vV-HbXohM1diF6i7kkL1NpqGb_tqqn_X8-=2PeLQ@mail.gmail.com>
Message-ID: <CAEs96n0RfatTGVrh9SpjkKpYLYhL7d0MZfVKoVCVu6=ALFPiQA@mail.gmail.com>

Hi Ryan,

Yes, that or one of the various superclass instance proposals would
probably solve this without too much grief, since we could simply
export Applicative, then automatically get an instance for it
afterwords at no cost.

This was very very briefly discussed yesterday, but I left it out of
the 'Possibilities' list here because it is simply contingent on too
much work, and too much discussion, in too short a span of time. There
have probably been a dozen proposals for this kind of functionality,
and I don't think any of them ever even got to the implementation
stage.

Unless someone has a hidden, ready-to-go patch with these features and
it'll be committed very very soon (which I unfortunately doubt), I
just don't think it's realistic to consider these approaches as
solutions right now.

On Tue, Sep 30, 2014 at 6:04 PM, Ryan Trinkle <ryan.trinkle at gmail.com> wrote:
> Would something like John Meacham's class alias proposal
> (http://repetae.net/recent/out/classalias.html) help alleviate this problem?
>
> On Tue, Sep 30, 2014 at 5:02 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>>
>> On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace <malcolm.wallace at me.com>
>> wrote:
>>>
>>> How about doing the honest thing, and withdrawing both packages in
>>> ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never
>>> really popular anyway.
>>
>>
>> There are apparently educators using both, although they're not used much
>> if at all in production.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From austin at well-typed.com  Wed Oct  1 16:10:41 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 1 Oct 2014 11:10:41 -0500
Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590
In-Reply-To: <5F743CA1-227C-4F5C-B38E-1DD860659168@me.com>
References: <CAEs96n2QGx=Nx+bjKR9QQMs4x041AXzBRiqhLEgMxec67DHqbQ@mail.gmail.com>
 <5F743CA1-227C-4F5C-B38E-1DD860659168@me.com>
Message-ID: <CAEs96n3=OjUCe0gWgcJeP4eZ0jYHzSM3bHFUyOL9k=4ZcaoMkQ@mail.gmail.com>

Hi Malcolm,

Withdrawing the packages from GHC's distribution is certainly a
possibility. We did briefly raise that point when we talked yesterday
too, but it wasn't discussed much.

Perhaps some others feel the same, but I imagine more people would be
OK with #2 above as opposed to eliminating it, since we already
lightly break some things anyway. Hopefully we'll really find out
soon.

On Tue, Sep 30, 2014 at 4:00 PM, Malcolm Wallace <malcolm.wallace at me.com> wrote:
> How about doing the honest thing, and withdrawing both packages in ghc-7.10?  Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway.
>
>  Regards,
>     Malcolm
>
> On 30 Sep 2014, at 21:21, Austin Seipp <austin at well-typed.com> wrote:
>
> Hello developers, users, friends,
>
> I'd like you all to weigh in on something - a GHC bug report, that has
> happened as a result of making Applicative a superclass of Monad:
>
> https://ghc.haskell.org/trac/ghc/ticket/9590
>
> The very condensed version is this: because haskell2010/haskell98
> packages try to be fairly strictly conforming, they do not have
> modules like Control.Applicative.
>
> Unfortunately, due to the way these packages are structured, many
> things are simply re-exported from base, like `Monad`. But
> `Applicative` is not, and cannot be imported if you use -XHaskell2010
> and the haskell2010 package.
>
> The net result here is that haskell98/haskell2010 are hopelessly
> broken in the current state: it's impossible to define an instance of
> `Monad`, because you cannot define an instance of `Applicative`,
> because you can't import it in the first place!
>
> This leaves us in quite a pickle.
>
> So I ask: Friends, what do you think we should do? I am particularly
> interested in users/developers of current Haskell2010 packages - not
> just code that may *be* standard Haskell - code that implies a
> dependency on it.
>
> There was a short discussion between me and Simon Marlow about this in
> the morning, and again on IRC this morning between me, Duncan, Edward
> K, and Herbert.
>
> Basically, I only see one of two options:
>
> - We could make GHC support both: a version of `Monad` without
> `Applicative`, and one with it. This creates some complication in the
> desugarer, where GHC takes care of `do` syntax (and thus needs to be
> aware of `Monad`'s definition and location). But it is, perhaps, quite
> doable.
>
> - We change both packages to export `Applicative` and follow the API
> changes in `base` accordingly.
>
> Note that #1 above is contingent on three things:
>
> 1) There is interest in this actually happening, and these separate
> APIs being supported. If there is not significant interest in
> maintaining this, it's unclear if we should go for it.
>
> 2) It's not overly monstrously complex (I don't think it necessarily
> will be, but it might be.)
>
> 3) You can't like `haskell2010` packages and `base` packages together
> in the general case, but, AFAIK, this wasn't the case before either.
>
> I'd really appreciate your thoughts. This must be sorted out for 7.10
> somehow; the current situation is hopelessly busted.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From iavor.diatchki at gmail.com  Mon Oct  6 18:42:06 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 6 Oct 2014 11:42:06 -0700
Subject: Type checker plugins
In-Reply-To: <54132257.4070803@well-typed.com>
References: <54132257.4070803@well-typed.com>
Message-ID: <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>

Hi Adam,

I am back from vacation, and I think I should have some time to try to
implement something along these lines.

Cheers,
-Iavor

On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry <adam at well-typed.com> wrote:

> Hi folks,
>
> Those of you at HIW last week might have been subjected to my lightning
> talk on plugins for the GHC type checker, which should allow us to
> properly implement nifty features like units of measure or type-level
> numbers without recompiling GHC. I've written up a wiki page summarising
> the idea:
>
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>
> Feedback is very welcome, particularly if (a) you have an interesting
> use for this feature or (b) you think this is a terrible idea!
>
> Thanks,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141006/77834935/attachment.html>

From carter.schonwald at gmail.com  Mon Oct  6 18:53:35 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 6 Oct 2014 14:53:35 -0400
Subject: Type checker plugins
In-Reply-To: <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
Message-ID: <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>

yay :)

On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hi Adam,
>
> I am back from vacation, and I think I should have some time to try to
> implement something along these lines.
>
> Cheers,
> -Iavor
>
> On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry <adam at well-typed.com> wrote:
>
>> Hi folks,
>>
>> Those of you at HIW last week might have been subjected to my lightning
>> talk on plugins for the GHC type checker, which should allow us to
>> properly implement nifty features like units of measure or type-level
>> numbers without recompiling GHC. I've written up a wiki page summarising
>> the idea:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>>
>> Feedback is very welcome, particularly if (a) you have an interesting
>> use for this feature or (b) you think this is a terrible idea!
>>
>> Thanks,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141006/67d1e31f/attachment.html>

From magicloud.magiclouds at gmail.com  Mon Oct 13 01:03:40 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Mon, 13 Oct 2014 09:03:40 +0800
Subject: Dependencies missing when building ghc.
Message-ID: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>

Hi,

  I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then
I wanted to build ghc from git to upgrade to 7.8.3.

  I did following commands. I tried 'make clean', or reget the source. No
luck yet.

$ git clone --recursive git://git.haskell.org/ghc.git
$ ./sync-all -r git://git.haskell.org remote set-url origin
$ git checkout ghc-7.8.3-release
$ ./sync-all get
$ rm -r libraries/time # as prompted by sync-all
$ ./sync-all get
$ ./boot
$ ./configure
$ make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
"inplace/bin/ghc-cabal" check libraries/haskell98
"inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install ""
--with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1"
--with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg"
 --disable-library-for-ghci --enable-library-vanilla
--enable-library-profiling --enable-shared --configure-option=CFLAGS="
-fno-stack-protector   " --configure-option=LDFLAGS="   "
--configure-option=CPPFLAGS="   " --gcc-options=" -fno-stack-protector
  " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld"
--configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar"
--with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex"
--with-happy="/usr/bin/happy"
Configuring haskell98-2.0.0.4...
ghc-cabal: At least the following dependencies are missing:
base ==4.8.*
make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1
make: *** [all] Error 2
-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141013/cd901d6d/attachment.html>

From shumovichy at gmail.com  Mon Oct 13 07:16:11 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Mon, 13 Oct 2014 10:16:11 +0300
Subject: Dependencies missing when building ghc.
In-Reply-To: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
References: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
Message-ID: <CAPcZ8KMeLENJQ+Ez_a9eJJMjCy=W23nW8_Ag5XGd_3eG9zScbA@mail.gmail.com>

Hello,

It is recommended to checkout 7.8 in special way, see
https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#checkout-old-branch

That is because repo structure was changed after 7.8

Thanks,
Yuras
13 ??? 2014 ?. 4:03 ???????????? "Magicloud Magiclouds" <
magicloud.magiclouds at gmail.com> ???????:

> Hi,
>
>   I am with my new Ubuntu Trusty box. I have installed ghc by apt-get.
> Then I wanted to build ghc from git to upgrade to 7.8.3.
>
>   I did following commands. I tried 'make clean', or reget the source. No
> luck yet.
>
> $ git clone --recursive git://git.haskell.org/ghc.git
> $ ./sync-all -r git://git.haskell.org remote set-url origin
> $ git checkout ghc-7.8.3-release
> $ ./sync-all get
> $ rm -r libraries/time # as prompted by sync-all
> $ ./sync-all get
> $ ./boot
> $ ./configure
> $ make
> ===--- building phase 0
> make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
> make[1]: Nothing to be done for `phase_0_builds'.
> ===--- building phase 1
> make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
> "inplace/bin/ghc-cabal" check libraries/haskell98
> "inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install ""
> --with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1"
> --with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg"
>  --disable-library-for-ghci --enable-library-vanilla
> --enable-library-profiling --enable-shared --configure-option=CFLAGS="
> -fno-stack-protector   " --configure-option=LDFLAGS="   "
> --configure-option=CPPFLAGS="   " --gcc-options=" -fno-stack-protector
>   " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld"
> --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar"
> --with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex"
> --with-happy="/usr/bin/happy"
> Configuring haskell98-2.0.0.4...
> ghc-cabal: At least the following dependencies are missing:
> base ==4.8.*
> make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1
> make: *** [all] Error 2
> --
> ???????
> ???????
>
> And for G+, please use magiclouds#gmail.com.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141013/3521c3aa/attachment.html>

From daniel.trstenjak at gmail.com  Mon Oct 13 08:14:44 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 13 Oct 2014 10:14:44 +0200
Subject: Dependencies missing when building ghc.
In-Reply-To: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
References: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
Message-ID: <20141013081444.GA3771@machine>


> I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I
> wanted to build ghc from git to upgrade to 7.8.3.

If you only want to install a newer ghc version on ubuntu or even
multiple ghc versions at once, then I can only recommend the excellent
PPA of Herbert Valerio Riedel:

   https://launchpad.net/~hvr/+archive/ubuntu/ghc


Greetings,
Daniel

From austin at well-typed.com  Mon Oct 13 16:37:25 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 13 Oct 2014 11:37:25 -0500
Subject: GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
Message-ID: <CAEs96n3s+_033=ynumAyEqxXYyA6H83iP-PqPGebt3aUiuMc3w@mail.gmail.com>

Hi *,

After some discussion with Simon & Mikolaj today, I'd like to direct
you all at this:

https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4

This status page is the basic overview of what we plan on doing for
7.8.4. There are two basic components to this page:

 - Show stopping bugs.
 - Everything else, which is "nice to have".

Show stoppers are listed at the top of the page, in the first
paragraph. Right now, this includes:

 - #9439 - LLVM mangling too vigorously.
 - #8819 - Arithmetic failures for unregistered systems
 - #8690 - SpecConstr blow-up

And that's all. But what's all the other stuff? That's "everything else".

Aside from these tickets listed here - and any future amendments to it
- all other tickets will only be considered nice-to-have. What does
that mean?

 - It's low risk to include.
 - It clearly fixes the problem
 - It doesn't take Austin significant amounts of time to merge.

For example, "Tickets marked merge with no milestone" are all
nice-to-have. Similarly, all the *closed tickets* on this page may be
re-opened and merged again[1], since most didn't make it to 7.8.4.

Ditto with the remaining categories.

OK, so that's the gist. Now I ask of you the following:

 - If you have a show-stopping bug with GHC 7.8.3, **you really,
_positively_ need to file a bug, and get in contact with me ASAP**.
Otherwise you'll be waiting for 7.10 most likely.
 - Again: if you have a show stopper, contact me. Very soon.
 - If there are bugs you *think* are showstoppers, but we didn't
categorize them properly, let me know.

Anything we accept as a show-stopper will delay the release of 7.8.4.
Anything else can (and possibly will) be left behind. Luckily, almost
all of the show stoppers have patches. Only #8819 does not, but I have
asked Sergei to look into it for me if he has time today.

Finally, I would please ask that users/developers do not include their
own personal pet tickets under "show stoppers" without consulting me
first, at least. :) If it's just nice to have, you can still pester
me, of course, and I'll try to make it happen.

I would like to have 7.8.4 out and done with by mid November, before
we freeze the new STABLE branch for 7.10.1. That's not a hard
deadline; just a timeframe I'd like to hit.

Let me know if you have any questions or comments; thanks!

[1] A lot of the closed tickets on this page had an improper milestone
set, which is why they show up. You can mostly ignore them, I
apologize.

-- 
Regards,

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

From iavor.diatchki at gmail.com  Mon Oct 13 20:34:16 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 13 Oct 2014 13:34:16 -0700
Subject: Type checker plugins
In-Reply-To: <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
Message-ID: <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>

Hello,

We now have an implementation of type-checker with plugin support.   If you
are interested in trying it out:

  - Checkout and build the `wip/tc-plugins` branch of GHC

  - As an example, I've extracted my work on using an SMT solver at the
type level as a separate plugin:

      https://github.com/yav/type-nat-solver

   - To see how to invoke a module that uses a plugin, have a look in
`examples/A.hs`.
     (Currently, the plugin assumes that you have `cvc4` installed and
available in the path).

    - Besides this, we don't have much documentation yet.  For hackers: we
tried to use `tcPlugin` on
    `TcPlugin` in the names of all things plugin related, so you could grep
for this.  The basic API
     types and functions are defined in `TcRnTypes` and `TcRnMonad`.

Happy hacking,
-Iavor











On Mon, Oct 6, 2014 at 11:53 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> yay :)
>
> On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> Hi Adam,
>>
>> I am back from vacation, and I think I should have some time to try to
>> implement something along these lines.
>>
>> Cheers,
>> -Iavor
>>
>> On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> Hi folks,
>>>
>>> Those of you at HIW last week might have been subjected to my lightning
>>> talk on plugins for the GHC type checker, which should allow us to
>>> properly implement nifty features like units of measure or type-level
>>> numbers without recompiling GHC. I've written up a wiki page summarising
>>> the idea:
>>>
>>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>>>
>>> Feedback is very welcome, particularly if (a) you have an interesting
>>> use for this feature or (b) you think this is a terrible idea!
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141013/802edc77/attachment.html>

From austin at well-typed.com  Mon Oct 13 20:47:51 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 13 Oct 2014 15:47:51 -0500
Subject: Type checker plugins
In-Reply-To: <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
Message-ID: <CAEs96n1jRtsTxx2VX62h2Kf1Eg+t_dZf6FcbSa+AbvcXDtN2kw@mail.gmail.com>

Iavor,

Wow, this is one of the coolest new features I've seen in a while, I
have to say. I hope we can see it in GHC sometime soon. :)

On Mon, Oct 13, 2014 at 3:34 PM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> Hello,
>
> We now have an implementation of type-checker with plugin support.   If you
> are interested in trying it out:
>
>   - Checkout and build the `wip/tc-plugins` branch of GHC
>
>   - As an example, I've extracted my work on using an SMT solver at the type
> level as a separate plugin:
>
>       https://github.com/yav/type-nat-solver
>
>    - To see how to invoke a module that uses a plugin, have a look in
> `examples/A.hs`.
>      (Currently, the plugin assumes that you have `cvc4` installed and
> available in the path).
>
>     - Besides this, we don't have much documentation yet.  For hackers: we
> tried to use `tcPlugin` on
>     `TcPlugin` in the names of all things plugin related, so you could grep
> for this.  The basic API
>      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
>
> Happy hacking,
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 6, 2014 at 11:53 AM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> yay :)
>>
>> On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>>
>>> Hi Adam,
>>>
>>> I am back from vacation, and I think I should have some time to try to
>>> implement something along these lines.
>>>
>>> Cheers,
>>> -Iavor
>>>
>>> On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> Those of you at HIW last week might have been subjected to my lightning
>>>> talk on plugins for the GHC type checker, which should allow us to
>>>> properly implement nifty features like units of measure or type-level
>>>> numbers without recompiling GHC. I've written up a wiki page summarising
>>>> the idea:
>>>>
>>>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>>>>
>>>> Feedback is very welcome, particularly if (a) you have an interesting
>>>> use for this feature or (b) you think this is a terrible idea!
>>>>
>>>> Thanks,
>>>>
>>>> Adam
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, http://www.well-typed.com/
>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From magicloud.magiclouds at gmail.com  Tue Oct 14 02:07:38 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Tue, 14 Oct 2014 10:07:38 +0800
Subject: Dependencies missing when building ghc.
In-Reply-To: <CAPcZ8KMeLENJQ+Ez_a9eJJMjCy=W23nW8_Ag5XGd_3eG9zScbA@mail.gmail.com>
References: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
 <CAPcZ8KMeLENJQ+Ez_a9eJJMjCy=W23nW8_Ag5XGd_3eG9zScbA@mail.gmail.com>
Message-ID: <CABErt4fS+CMnpTpNSeZ4L7G2HewAn-VR0R9Ucn_kHAsGZYmpeA@mail.gmail.com>

Works like a charm. Thank you.

On Mon, Oct 13, 2014 at 3:16 PM, Yuras Shumovich <shumovichy at gmail.com>
wrote:

> Hello,
>
> It is recommended to checkout 7.8 in special way, see
> https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#checkout-old-branch
>
> That is because repo structure was changed after 7.8
>
> Thanks,
> Yuras
> 13 ??? 2014 ?. 4:03 ???????????? "Magicloud Magiclouds" <
> magicloud.magiclouds at gmail.com> ???????:
>
>> Hi,
>>
>>   I am with my new Ubuntu Trusty box. I have installed ghc by apt-get.
>> Then I wanted to build ghc from git to upgrade to 7.8.3.
>>
>>   I did following commands. I tried 'make clean', or reget the source. No
>> luck yet.
>>
>> $ git clone --recursive git://git.haskell.org/ghc.git
>> $ ./sync-all -r git://git.haskell.org remote set-url origin
>> $ git checkout ghc-7.8.3-release
>> $ ./sync-all get
>> $ rm -r libraries/time # as prompted by sync-all
>> $ ./sync-all get
>> $ ./boot
>> $ ./configure
>> $ make
>> ===--- building phase 0
>> make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
>> make[1]: Nothing to be done for `phase_0_builds'.
>> ===--- building phase 1
>> make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
>> "inplace/bin/ghc-cabal" check libraries/haskell98
>> "inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install ""
>> --with-ghc="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1"
>> --with-ghc-pkg="/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg"
>>  --disable-library-for-ghci --enable-library-vanilla
>> --enable-library-profiling --enable-shared --configure-option=CFLAGS="
>> -fno-stack-protector   " --configure-option=LDFLAGS="   "
>> --configure-option=CPPFLAGS="   " --gcc-options=" -fno-stack-protector
>>   " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld"
>> --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar"
>> --with-ranlib="/usr/bin/ranlib" --with-alex="/usr/bin/alex"
>> --with-happy="/usr/bin/happy"
>> Configuring haskell98-2.0.0.4...
>> ghc-cabal: At least the following dependencies are missing:
>> base ==4.8.*
>> make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1
>> make: *** [all] Error 2
>> --
>> ???????
>> ???????
>>
>> And for G+, please use magiclouds#gmail.com.
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>


-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141014/a739bfd8/attachment.html>

From magicloud.magiclouds at gmail.com  Tue Oct 14 02:07:51 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Tue, 14 Oct 2014 10:07:51 +0800
Subject: [Haskell-cafe] Dependencies missing when building ghc.
In-Reply-To: <20141013081444.GA3771@machine>
References: <CABErt4cz5_pRCfbx39LLzR8G-ouU_S-87nnYGn3Fxjc85S5Ltg@mail.gmail.com>
 <20141013081444.GA3771@machine>
Message-ID: <CABErt4dDw=zGHh3SWjfKxXEGve-RY7EbvyOrYP4Qnq9Jm_acSg@mail.gmail.com>

That is something I did not know. Thank you.

On Mon, Oct 13, 2014 at 4:14 PM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

>
> > I am with my new Ubuntu Trusty box. I have installed ghc by apt-get.
> Then I
> > wanted to build ghc from git to upgrade to 7.8.3.
>
> If you only want to install a newer ghc version on ubuntu or even
> multiple ghc versions at once, then I can only recommend the excellent
> PPA of Herbert Valerio Riedel:
>
>    https://launchpad.net/~hvr/+archive/ubuntu/ghc
>
>
> Greetings,
> Daniel
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141014/3e42d2ab/attachment-0001.html>

From bulat.ziganshin at gmail.com  Tue Oct 14 17:08:59 2014
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Tue, 14 Oct 2014 21:08:59 +0400
Subject: optimizing StgPtr allocate (Capability *cap, W_ n)
Message-ID: <659910670.20141014210859@gmail.com>

Hello Glasgow-haskell-users,

i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680

if i correctly understand, it's speed-critical routine?

i think that it may be improved in this way:

StgPtr allocate (Capability *cap, W_ n)
{
    bdescr *bd;
    StgPtr p;

    TICK_ALLOC_HEAP_NOCTR(WDS(n));
    CCS_ALLOC(cap->r.rCCCS,n);

/// here starts new improved code:

    bd = cap->r.rCurrentAlloc;
    if (bd == NULL || bd->free + n > bd->end) {
        if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) {
            ....
        }
        if (bd->free + n <= bd->start + BLOCK_SIZE_W)
            bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD)
            goto usual_alloc;
        }
        ....
    }

/// and here it stops

usual_alloc:
    p = bd->free;
    bd->free += n;

    IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
    return p;
}


i  think  it's  obvious - we consolidate two if's on the crirical path
into the single one plus avoid one ADD by keeping highly-useful bd->end pointer

further   improvements   may   include   removing  bd==NULL  check  by
initializing bd->free=bd->end=NULL   and   moving   entire   "if" body
into   separate   slow_allocate()  procedure  marked  "noinline"  with
allocate() probably marked as forceinline:

StgPtr allocate (Capability *cap, W_ n)
{
    bdescr *bd;
    StgPtr p;

    TICK_ALLOC_HEAP_NOCTR(WDS(n));
    CCS_ALLOC(cap->r.rCCCS,n);

    bd = cap->r.rCurrentAlloc;
    if (bd->free + n > bd->end)
        return slow_allocate(cap,n);

    p = bd->free;
    bd->free += n;

    IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
    return p;
}

this  change  will  greatly simplify optimizer's work. according to my
experience   current  C++  compilers  are  weak  on  optimizing  large
functions with complex execution paths and such transformations really
improve the generated code


-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin at gmail.com


From doaitse at swierstra.net  Tue Oct 14 20:26:46 2014
From: doaitse at swierstra.net (S. Doaitse Swierstra)
Date: Tue, 14 Oct 2014 22:26:46 +0200
Subject: status of rebindable syntax for  arrows
Message-ID: <434BFFC2-19A4-429D-B7E3-6286F6B81D35@swierstra.net>



The GHC manual already for quite a number of version states:

	? Arrow notation (see Section 7.17, ?Arrow notation ?) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. 
         But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! 

When using this feature we get the error:

"Var/Type length mismatch: 
   [s{tv aVL} [tv]]
   []
ghc: panic! (the 'impossible' happened)
 (GHC version 7.8.3 for x86_64-apple-darwin):
	tcTyVarDetails s{tv aVL} [tv]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug"

So our question is whether we should really report this as a bug, and/or what we can do about this. 

Thanks for your help,

Doaitse






From bulat.ziganshin at gmail.com  Tue Oct 14 23:39:27 2014
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Wed, 15 Oct 2014 03:39:27 +0400
Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590
In-Reply-To: <CAKFCL4UAdF4Rgsyqs_u-R1soqaEO3+NU+VgO+dcZYMLXGe8F+w@mail.gmail.com>
References: <CAEs96n2QGx=Nx+bjKR9QQMs4x041AXzBRiqhLEgMxec67DHqbQ@mail.gmail.com>
 <5F743CA1-227C-4F5C-B38E-1DD860659168@me.com>
 <CAKFCL4UAdF4Rgsyqs_u-R1soqaEO3+NU+VgO+dcZYMLXGe8F+w@mail.gmail.com>
Message-ID: <8327120.20141015033927@gmail.com>

An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141015/ccdf9c1b/attachment.html>

From R.Paterson at city.ac.uk  Wed Oct 15 05:55:46 2014
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Wed, 15 Oct 2014 06:55:46 +0100
Subject: status of rebindable syntax for  arrows
In-Reply-To: <434BFFC2-19A4-429D-B7E3-6286F6B81D35@swierstra.net>
References: <434BFFC2-19A4-429D-B7E3-6286F6B81D35@swierstra.net>
Message-ID: <20141015055546.GA2006@city.ac.uk>

On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
> The GHC manual already for quite a number of version states:
> 
> 	? Arrow notation (see Section 7.17, ?Arrow notation ?) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. 
>          But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! 
> 
> When using this feature we get the error:
> 
> "Var/Type length mismatch: 
>    [s{tv aVL} [tv]]
>    []
> ghc: panic! (the 'impossible' happened)
>  (GHC version 7.8.3 for x86_64-apple-darwin):
> 	tcTyVarDetails s{tv aVL} [tv]
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug"
> 
> So our question is whether we should really report this as a bug, and/or what we can do about this. 

It already has a bug entry: #7828.  What would help is to know the kind
of use you have in mind, to see whether it fits with the proposed solution.

From simonpj at microsoft.com  Wed Oct 15 08:33:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 15 Oct 2014 08:33:55 +0000
Subject: status of rebindable syntax for  arrows
In-Reply-To: <20141015055546.GA2006@city.ac.uk>
References: <434BFFC2-19A4-429D-B7E3-6286F6B81D35@swierstra.net>
 <20141015055546.GA2006@city.ac.uk>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F337006@DB3PRD3001MB020.064d.mgd.msft.net>

|  It already has a bug entry: #7828.  What would help is to know the
|  kind of use you have in mind, to see whether it fits with the proposed
|  solution.

Indeed.  Moreover #7828 is stalled; it needs some arrow-savvy person to focus cycles on it.  If rebindable syntax for arrows is considered important.

Meanwhile I think you should not rely on rebindable syntax for arrows. The user manual is misleading on this point.

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Ross Paterson
|  Sent: 15 October 2014 06:56
|  To: glasgow-haskell-users
|  Subject: Re: status of rebindable syntax for arrows
|  
|  On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
|  > The GHC manual already for quite a number of version states:
|  >
|  > 	? Arrow notation (see Section 7.17, ?Arrow notation ?) uses
|  whatever arr, (>>>), first, app, (|||) and loop functions are in
|  scope.
|  >          But unlike the other constructs, the types of these
|  functions must match the Prelude types very closely. Details are in
|  flux; if you want to use this, ask!
|  >
|  > When using this feature we get the error:
|  >
|  > "Var/Type length mismatch:
|  >    [s{tv aVL} [tv]]
|  >    []
|  > ghc: panic! (the 'impossible' happened)  (GHC version 7.8.3 for
|  > x86_64-apple-darwin):
|  > 	tcTyVarDetails s{tv aVL} [tv]
|  >
|  > Please report this as a GHC bug:
|  http://www.haskell.org/ghc/reportabug"
|  >
|  > So our question is whether we should really report this as a bug,
|  and/or what we can do about this.
|  
|  It already has a bug entry: #7828.  What would help is to know the
|  kind of use you have in mind, to see whether it fits with the proposed
|  solution.
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From ezyang at mit.edu  Thu Oct 16 07:04:22 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 16 Oct 2014 00:04:22 -0700
Subject: optimizing StgPtr allocate (Capability *cap, W_ n)
In-Reply-To: <659910670.20141014210859@gmail.com>
References: <659910670.20141014210859@gmail.com>
Message-ID: <1413443015-sup-8462@sabre>

Hi Bulat,

This seems quite reasonable to me. Have you eyeballed the assembly
GCC produces to see that the hotpath is improved? If you can submit
a patch that would be great!

Cheers,
Edward

Excerpts from Bulat Ziganshin's message of 2014-10-14 10:08:59 -0700:
> Hello Glasgow-haskell-users,
> 
> i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680
> 
> if i correctly understand, it's speed-critical routine?
> 
> i think that it may be improved in this way:
> 
> StgPtr allocate (Capability *cap, W_ n)
> {
>     bdescr *bd;
>     StgPtr p;
> 
>     TICK_ALLOC_HEAP_NOCTR(WDS(n));
>     CCS_ALLOC(cap->r.rCCCS,n);
> 
> /// here starts new improved code:
> 
>     bd = cap->r.rCurrentAlloc;
>     if (bd == NULL || bd->free + n > bd->end) {
>         if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) {
>             ....
>         }
>         if (bd->free + n <= bd->start + BLOCK_SIZE_W)
>             bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD)
>             goto usual_alloc;
>         }
>         ....
>     }
> 
> /// and here it stops
> 
> usual_alloc:
>     p = bd->free;
>     bd->free += n;
> 
>     IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
>     return p;
> }
> 
> 
> i  think  it's  obvious - we consolidate two if's on the crirical path
> into the single one plus avoid one ADD by keeping highly-useful bd->end pointer
> 
> further   improvements   may   include   removing  bd==NULL  check  by
> initializing bd->free=bd->end=NULL   and   moving   entire   "if" body
> into   separate   slow_allocate()  procedure  marked  "noinline"  with
> allocate() probably marked as forceinline:
> 
> StgPtr allocate (Capability *cap, W_ n)
> {
>     bdescr *bd;
>     StgPtr p;
> 
>     TICK_ALLOC_HEAP_NOCTR(WDS(n));
>     CCS_ALLOC(cap->r.rCCCS,n);
> 
>     bd = cap->r.rCurrentAlloc;
>     if (bd->free + n > bd->end)
>         return slow_allocate(cap,n);
> 
>     p = bd->free;
>     bd->free += n;
> 
>     IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
>     return p;
> }
> 
> this  change  will  greatly simplify optimizer's work. according to my
> experience   current  C++  compilers  are  weak  on  optimizing  large
> functions with complex execution paths and such transformations really
> improve the generated code
> 

From adam at well-typed.com  Thu Oct 16 10:58:48 2014
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 16 Oct 2014 11:58:48 +0100
Subject: Type checker plugins
In-Reply-To: <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
References: <54132257.4070803@well-typed.com>	<CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>	<CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
Message-ID: <543FA4E8.7090609@well-typed.com>

Hi Iavor,


On 13/10/14 21:34, Iavor Diatchki wrote:
> Hello,
> 
> We now have an implementation of type-checker with plugin support.   If
> you are interested in trying it out:
> 
>   - Checkout and build the `wip/tc-plugins` branch of GHC


Thanks, this is great! I'd been working on a similar implementation, but
yours is much better integrated. I am trying to adapt my units of
measure plugin to work with this interface, and work out what else I
need in TcPluginM.

One problem I've run into is transforming the flattened CFunEqCans into
unflattened form (so the flatten-skolems don't get in the way of
AG-unification). Do you know if there is an easy way to do this, or do I
need to rebuild the tree manually in the plugin?

Also, I notice that you are providing only equality constraints to the
plugin. Is there any reason we can't make other types of constraint
available as well? For example, one might want to introduce a typeclass
with a special solution strategy (cf. Coercible, or the Has class in
OverloadedRecordFields).


Cheers,

Adam


>   - As an example, I've extracted my work on using an SMT solver at the
> type level as a separate plugin:
>   
>       https://github.com/yav/type-nat-solver
> 
>    - To see how to invoke a module that uses a plugin, have a look in
> `examples/A.hs`.
>      (Currently, the plugin assumes that you have `cvc4` installed and
> available in the path).
> 
>     - Besides this, we don't have much documentation yet.  For hackers:
> we tried to use `tcPlugin` on
>     `TcPlugin` in the names of all things plugin related, so you could
> grep for this.  The basic API
>      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
> 
> Happy hacking,
> -Iavor


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From simonpj at microsoft.com  Thu Oct 16 14:08:05 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Oct 2014 14:08:05 +0000
Subject: Type checker plugins
In-Reply-To: <543FA4E8.7090609@well-typed.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>

This will become easier, I think. look on wip/new-flatten-skoelms-Aug14.  I'm now unflattening after solving the flat constraints. 

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Adam Gundry
|  Sent: 16 October 2014 11:59
|  To: Iavor Diatchki
|  Cc: glasgow-haskell-users at haskell.org
|  Subject: Re: Type checker plugins
|  
|  Hi Iavor,
|  
|  
|  On 13/10/14 21:34, Iavor Diatchki wrote:
|  > Hello,
|  >
|  > We now have an implementation of type-checker with plugin support.
|  If
|  > you are interested in trying it out:
|  >
|  >   - Checkout and build the `wip/tc-plugins` branch of GHC
|  
|  
|  Thanks, this is great! I'd been working on a similar implementation,
|  but yours is much better integrated. I am trying to adapt my units of
|  measure plugin to work with this interface, and work out what else I
|  need in TcPluginM.
|  
|  One problem I've run into is transforming the flattened CFunEqCans
|  into unflattened form (so the flatten-skolems don't get in the way of
|  AG-unification). Do you know if there is an easy way to do this, or do
|  I need to rebuild the tree manually in the plugin?
|  
|  Also, I notice that you are providing only equality constraints to the
|  plugin. Is there any reason we can't make other types of constraint
|  available as well? For example, one might want to introduce a
|  typeclass with a special solution strategy (cf. Coercible, or the Has
|  class in OverloadedRecordFields).
|  
|  
|  Cheers,
|  
|  Adam
|  
|  
|  >   - As an example, I've extracted my work on using an SMT solver at
|  > the type level as a separate plugin:
|  >
|  >       https://github.com/yav/type-nat-solver
|  >
|  >    - To see how to invoke a module that uses a plugin, have a look
|  in
|  > `examples/A.hs`.
|  >      (Currently, the plugin assumes that you have `cvc4` installed
|  and
|  > available in the path).
|  >
|  >     - Besides this, we don't have much documentation yet.  For
|  hackers:
|  > we tried to use `tcPlugin` on
|  >     `TcPlugin` in the names of all things plugin related, so you
|  could
|  > grep for this.  The basic API
|  >      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
|  >
|  > Happy hacking,
|  > -Iavor
|  
|  
|  --
|  Adam Gundry, Haskell Consultant
|  Well-Typed LLP, http://www.well-typed.com/
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From adam at well-typed.com  Thu Oct 16 20:49:52 2014
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 16 Oct 2014 21:49:52 +0100
Subject: Type checker plugins
In-Reply-To: <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
Message-ID: <54402F70.3000104@well-typed.com>

Thanks Simon, your branch does make it a lot more feasible to unflatten,
so I'll just go ahead and implement that in my plugin for now.

Eric, that's fair enough, and I don't have any concrete use cases for
non-equality constraints at the moment. I'm just keen to minimize the
restrictions placed on plugins, because it is much easier to recompile a
plugin than make changes in GHC itself!

On that note, I still wonder if it would be better to define TcPluginM
as a wrapper around TcS rather than TcM. While in principle TcM should
suffice, in practice GHC sometimes uses TcS for things that a plugin
might want (I've run into TcSMonad.matchFam, which could easily be
implemented in TcM instead). Is there any downside to defining a nice
API in TcPluginM but providing an escape hatch to TcS, not just TcM?

Thanks,

Adam


On 16/10/14 16:21, Eric Seidel wrote:
> Our branch is actually based on yours Simon, are there any changes in the past week that we should pull in for people who want to experiment?
> 
> Adam, we talked about passing other constraints to the plugins, but didn't have a concrete use-case at the time, so we just kept it as simple as possible. I don't see a reason to hide constraints if, as you say, there are plugins that may want to solve them. 
> 
> Eric
> 
> Sent from my iPhone
> 
>> On Oct 16, 2014, at 07:08, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>
>> This will become easier, I think. look on wip/new-flatten-skoelms-Aug14.  I'm now unflattening after solving the flat constraints. 
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
>> |  bounces at haskell.org] On Behalf Of Adam Gundry
>> |  Sent: 16 October 2014 11:59
>> |  To: Iavor Diatchki
>> |  Cc: glasgow-haskell-users at haskell.org
>> |  Subject: Re: Type checker plugins
>> |  
>> |  Hi Iavor,
>> |  
>> |  
>> |  On 13/10/14 21:34, Iavor Diatchki wrote:
>> |  > Hello,
>> |  >
>> |  > We now have an implementation of type-checker with plugin support.
>> |  If
>> |  > you are interested in trying it out:
>> |  >
>> |  >   - Checkout and build the `wip/tc-plugins` branch of GHC
>> |  
>> |  
>> |  Thanks, this is great! I'd been working on a similar implementation,
>> |  but yours is much better integrated. I am trying to adapt my units of
>> |  measure plugin to work with this interface, and work out what else I
>> |  need in TcPluginM.
>> |  
>> |  One problem I've run into is transforming the flattened CFunEqCans
>> |  into unflattened form (so the flatten-skolems don't get in the way of
>> |  AG-unification). Do you know if there is an easy way to do this, or do
>> |  I need to rebuild the tree manually in the plugin?
>> |  
>> |  Also, I notice that you are providing only equality constraints to the
>> |  plugin. Is there any reason we can't make other types of constraint
>> |  available as well? For example, one might want to introduce a
>> |  typeclass with a special solution strategy (cf. Coercible, or the Has
>> |  class in OverloadedRecordFields).
>> |  
>> |  
>> |  Cheers,
>> |  
>> |  Adam
>> |  
>> |  
>> |  >   - As an example, I've extracted my work on using an SMT solver at
>> |  > the type level as a separate plugin:
>> |  >
>> |  >       https://github.com/yav/type-nat-solver
>> |  >
>> |  >    - To see how to invoke a module that uses a plugin, have a look
>> |  in
>> |  > `examples/A.hs`.
>> |  >      (Currently, the plugin assumes that you have `cvc4` installed
>> |  and
>> |  > available in the path).
>> |  >
>> |  >     - Besides this, we don't have much documentation yet.  For
>> |  hackers:
>> |  > we tried to use `tcPlugin` on
>> |  >     `TcPlugin` in the names of all things plugin related, so you
>> |  could
>> |  > grep for this.  The basic API
>> |  >      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
>> |  >
>> |  > Happy hacking,
>> |  > -Iavor

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From goodingm at gmail.com  Thu Oct 16 22:19:37 2014
From: goodingm at gmail.com (Malcolm Gooding)
Date: Thu, 16 Oct 2014 15:19:37 -0700
Subject: Hiding import behaviour
Message-ID: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>

With the prelude changes that people have been discussing recently
I've been wondering is there any reason why importing an identifier
explicitly and unqualified doesn't automatically hide any implicit
imports of the same identifier? Specifically I'm wondering about cases
where you've imported an identifier explicitly from only one module,
like this:

module Foo (x, ...) where { ... }
module Bar (x, ...) where { ... }

import Bar
import Foo (x)

Even if you needed a pragma to enable it I can't think of any sensible
reason why that shouldn't be equivalent to:

import Bar hiding (x)
import Foo (x)

I don't know much of GHC's internals, but it seems like a pretty
minimal change. Typing rules remain the same; explicit imports just
shadow implicits. So importing multiple identifiers both implicitly or
both explicitly would remain ambiguous.

From david.feuer at gmail.com  Thu Oct 16 22:29:06 2014
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 16 Oct 2014 18:29:06 -0400
Subject: Hiding import behaviour
In-Reply-To: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
Message-ID: <CAMgWh9tn6Rh8Wigqpc4EwV7qUCB55BaQw4amZBeKtiA0v5nTxQ@mail.gmail.com>

I think this is a great idea. I also think it should apply to the name
shadowing warning?identifiers imported implicitly should never trigger that.

On Thu, Oct 16, 2014 at 6:19 PM, Malcolm Gooding <goodingm at gmail.com> wrote:

> With the prelude changes that people have been discussing recently
> I've been wondering is there any reason why importing an identifier
> explicitly and unqualified doesn't automatically hide any implicit
> imports of the same identifier? Specifically I'm wondering about cases
> where you've imported an identifier explicitly from only one module,
> like this:
>
> module Foo (x, ...) where { ... }
> module Bar (x, ...) where { ... }
>
> import Bar
> import Foo (x)
>
> Even if you needed a pragma to enable it I can't think of any sensible
> reason why that shouldn't be equivalent to:
>
> import Bar hiding (x)
> import Foo (x)
>
> I don't know much of GHC's internals, but it seems like a pretty
> minimal change. Typing rules remain the same; explicit imports just
> shadow implicits. So importing multiple identifiers both implicitly or
> both explicitly would remain ambiguous.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141016/cba09f15/attachment.html>

From austin at well-typed.com  Thu Oct 16 22:40:48 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 16 Oct 2014 17:40:48 -0500
Subject: Hiding import behaviour
In-Reply-To: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
Message-ID: <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>

My first thought is: Wouldn't this make it impossible to reorder or
sort imports lexicographically (or otherwise), without fully parsing,
renaming and typechecking the code?

For example, I often use ghc-mod plus stylish-haskell to order and
format my imports. If there is no syntactic indication that one import
should be hidden (and another preferred) as there is now, then
reordering the imports of a working program willy-nilly could result
in a program that no longer typechecks (or worse, one that does, but
is now wrong).

Maybe there are some cases today where something like this could
happen, but this seems awfully, awfully implicit and hard-to-follow as
a language feature.

In general I think a program that has imports like this that may clash
can be automated to make it easier to manage - but ultimately such
imports tend to represent a complex relationship between a module and
its dependencies - I'd prefer it if these were as clear as possible.

On Thu, Oct 16, 2014 at 5:19 PM, Malcolm Gooding <goodingm at gmail.com> wrote:
> With the prelude changes that people have been discussing recently
> I've been wondering is there any reason why importing an identifier
> explicitly and unqualified doesn't automatically hide any implicit
> imports of the same identifier? Specifically I'm wondering about cases
> where you've imported an identifier explicitly from only one module,
> like this:
>
> module Foo (x, ...) where { ... }
> module Bar (x, ...) where { ... }
>
> import Bar
> import Foo (x)
>
> Even if you needed a pragma to enable it I can't think of any sensible
> reason why that shouldn't be equivalent to:
>
> import Bar hiding (x)
> import Foo (x)
>
> I don't know much of GHC's internals, but it seems like a pretty
> minimal change. Typing rules remain the same; explicit imports just
> shadow implicits. So importing multiple identifiers both implicitly or
> both explicitly would remain ambiguous.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From simonpj at microsoft.com  Thu Oct 16 22:47:47 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Oct 2014 22:47:47 +0000
Subject: Type checker plugins
In-Reply-To: <54402F70.3000104@well-typed.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F35EB99@DB3PRD3001MB020.064d.mgd.msft.net>

| Thanks Simon, your branch does make it a lot more feasible to unflatten,
| so I'll just go ahead and implement that in my plugin for now.

Actually it would be worth pausing.  If you get the latest Unflattening is now done by getInertUnsolved, which itself is called by solveFlatWanteds, immediately after calling solveFlats.  And solveFlats (which used to be called solveInteract) is where Iavor has the plugin interface.

In short, if you'd like to see unflattened constraints, rather than flattened ones, that would be easy.

Unflattening yourself is inadvisable.  The unflattening code in getInertUnsolved is quite remarkably tricky and it took me some time get it right.  (I have to write a long Note before committing it to head.)

All this is in the just-committed wip/new-flatten-skolems-Aug14 branch

Simon

| -----Original Message-----
| From: Adam Gundry [mailto:adam at well-typed.com]
| Sent: 16 October 2014 21:50
| To: Eric Seidel; Simon Peyton Jones
| Cc: Iavor Diatchki; glasgow-haskell-users at haskell.org
| Subject: Re: Type checker plugins
| 
| Thanks Simon, your branch does make it a lot more feasible to unflatten,
| so I'll just go ahead and implement that in my plugin for now.
| 
| Eric, that's fair enough, and I don't have any concrete use cases for
| non-equality constraints at the moment. I'm just keen to minimize the
| restrictions placed on plugins, because it is much easier to recompile a
| plugin than make changes in GHC itself!
| 
| On that note, I still wonder if it would be better to define TcPluginM
| as a wrapper around TcS rather than TcM. While in principle TcM should
| suffice, in practice GHC sometimes uses TcS for things that a plugin
| might want (I've run into TcSMonad.matchFam, which could easily be
| implemented in TcM instead). Is there any downside to defining a nice
| API in TcPluginM but providing an escape hatch to TcS, not just TcM?
| 
| Thanks,
| 
| Adam
| 
| 
| On 16/10/14 16:21, Eric Seidel wrote:
| > Our branch is actually based on yours Simon, are there any changes in
| the past week that we should pull in for people who want to experiment?
| >
| > Adam, we talked about passing other constraints to the plugins, but
| didn't have a concrete use-case at the time, so we just kept it as simple
| as possible. I don't see a reason to hide constraints if, as you say,
| there are plugins that may want to solve them.
| >
| > Eric
| >
| > Sent from my iPhone
| >
| >> On Oct 16, 2014, at 07:08, Simon Peyton Jones <simonpj at microsoft.com>
| wrote:
| >>
| >> This will become easier, I think. look on wip/new-flatten-skoelms-
| Aug14.  I'm now unflattening after solving the flat constraints.
| >>
| >> Simon
| >>
| >> |  -----Original Message-----
| >> |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| >> |  bounces at haskell.org] On Behalf Of Adam Gundry
| >> |  Sent: 16 October 2014 11:59
| >> |  To: Iavor Diatchki
| >> |  Cc: glasgow-haskell-users at haskell.org
| >> |  Subject: Re: Type checker plugins
| >> |
| >> |  Hi Iavor,
| >> |
| >> |
| >> |  On 13/10/14 21:34, Iavor Diatchki wrote:
| >> |  > Hello,
| >> |  >
| >> |  > We now have an implementation of type-checker with plugin
| support.
| >> |  If
| >> |  > you are interested in trying it out:
| >> |  >
| >> |  >   - Checkout and build the `wip/tc-plugins` branch of GHC
| >> |
| >> |
| >> |  Thanks, this is great! I'd been working on a similar
| implementation,
| >> |  but yours is much better integrated. I am trying to adapt my units
| of
| >> |  measure plugin to work with this interface, and work out what else
| I
| >> |  need in TcPluginM.
| >> |
| >> |  One problem I've run into is transforming the flattened CFunEqCans
| >> |  into unflattened form (so the flatten-skolems don't get in the way
| of
| >> |  AG-unification). Do you know if there is an easy way to do this, or
| do
| >> |  I need to rebuild the tree manually in the plugin?
| >> |
| >> |  Also, I notice that you are providing only equality constraints to
| the
| >> |  plugin. Is there any reason we can't make other types of constraint
| >> |  available as well? For example, one might want to introduce a
| >> |  typeclass with a special solution strategy (cf. Coercible, or the
| Has
| >> |  class in OverloadedRecordFields).
| >> |
| >> |
| >> |  Cheers,
| >> |
| >> |  Adam
| >> |
| >> |
| >> |  >   - As an example, I've extracted my work on using an SMT solver
| at
| >> |  > the type level as a separate plugin:
| >> |  >
| >> |  >       https://github.com/yav/type-nat-solver
| >> |  >
| >> |  >    - To see how to invoke a module that uses a plugin, have a
| look
| >> |  in
| >> |  > `examples/A.hs`.
| >> |  >      (Currently, the plugin assumes that you have `cvc4`
| installed
| >> |  and
| >> |  > available in the path).
| >> |  >
| >> |  >     - Besides this, we don't have much documentation yet.  For
| >> |  hackers:
| >> |  > we tried to use `tcPlugin` on
| >> |  >     `TcPlugin` in the names of all things plugin related, so you
| >> |  could
| >> |  > grep for this.  The basic API
| >> |  >      types and functions are defined in `TcRnTypes` and
| `TcRnMonad`.
| >> |  >
| >> |  > Happy hacking,
| >> |  > -Iavor
| 
| --
| Adam Gundry, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/

From b.hilken at ntlworld.com  Thu Oct 16 22:59:44 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Thu, 16 Oct 2014 23:59:44 +0100
Subject: Type checker plugins
In-Reply-To: <54402F70.3000104@well-typed.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
Message-ID: <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>

I can think of a use for a non-equality constraint: an alphabetical ordering on Symbol. This would allow experimental implementations of extensible records (without shadowing) which keep the labels sorted.

An order constraint on Nat might be useful, too.

Barney.


From carter.schonwald at gmail.com  Thu Oct 16 23:06:56 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 16 Oct 2014 19:06:56 -0400
Subject: Type checker plugins
In-Reply-To: <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
 <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
Message-ID: <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>

the alphabetical ordering on Symbol is already exposed via TypeLits... this
would be some machinery to help maintain that ordering with less user
intervention?

On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> I can think of a use for a non-equality constraint: an alphabetical
> ordering on Symbol. This would allow experimental implementations of
> extensible records (without shadowing) which keep the labels sorted.
>
> An order constraint on Nat might be useful, too.
>
> Barney.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141016/e6d64cea/attachment.html>

From goodingm at gmail.com  Thu Oct 16 23:10:38 2014
From: goodingm at gmail.com (htebalaka)
Date: Thu, 16 Oct 2014 16:10:38 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
Message-ID: <1413501038977-5758161.post@n5.nabble.com>

Well I suppose tooling might need to be aware of the feature depending on
what it does, but I don't see why the code actually typechecking would need
to be dependent on ordering. When I say shadowing I don't mean explicitly
having any explicit import create a new scope, since in that case it would
be sensitive to re-ordering, which I agree would be bad. My thought would be
first you would need to parse all the imports to see which identifiers they
import, then do another pass to change the imports to hide any identifiers
that should be shadowed.

So in the example I gave you would need to be aware that Foo exports x,
because otherwise there would be no way to know that x needs to be hidden
from Bar. I assume GHC already would have access to that information though.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758161.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From b.hilken at ntlworld.com  Thu Oct 16 23:14:09 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Fri, 17 Oct 2014 00:14:09 +0100
Subject: Type checker plugins
In-Reply-To: <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
 <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
 <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>
Message-ID: <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>

Ok, I hadn't realised that. Looking in the user's guide, I see <= and <=? for Nat, but I couldn't find anything about Symbol. I must try them out!


> From: Carter Schonwald <carter.schonwald at gmail.com>
> 
> the alphabetical ordering on Symbol is already exposed via TypeLits... this would be some machinery to help maintain that ordering with less user intervention?
> 
> On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken <b.hilken at ntlworld.com> wrote:
> I can think of a use for a non-equality constraint: an alphabetical ordering on Symbol. This would allow experimental implementations of extensible records (without shadowing) which keep the labels sorted.
> 
> An order constraint on Nat might be useful, too.
> 
> Barney.
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

From david.feuer at gmail.com  Thu Oct 16 23:22:16 2014
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 16 Oct 2014 19:22:16 -0400
Subject: Hiding import behaviour
In-Reply-To: <1413501038977-5758161.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <1413501038977-5758161.post@n5.nabble.com>
Message-ID: <CAMgWh9ufbYANcqYirU4hRghN0ssEAVOpwXLvFZ=JUWFbBWG1Tw@mail.gmail.com>

It should be good enough (for what you're talking about) to hide them all.
Turn

import A (foo)
import B (bar)
import C hiding (baz)
import D

into

import A (foo)
import B (bar)
import C hiding (foo,bar,baz)
import D hiding (foo,bar)

There's no reason to worry about hiding nonexistent identifiers, I don't
think.

On Thu, Oct 16, 2014 at 7:10 PM, htebalaka <goodingm at gmail.com> wrote:

> Well I suppose tooling might need to be aware of the feature depending on
> what it does, but I don't see why the code actually typechecking would need
> to be dependent on ordering. When I say shadowing I don't mean explicitly
> having any explicit import create a new scope, since in that case it would
> be sensitive to re-ordering, which I agree would be bad. My thought would
> be
> first you would need to parse all the imports to see which identifiers they
> import, then do another pass to change the imports to hide any identifiers
> that should be shadowed.
>
> So in the example I gave you would need to be aware that Foo exports x,
> because otherwise there would be no way to know that x needs to be hidden
> from Bar. I assume GHC already would have access to that information
> though.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758161.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141016/eec999e1/attachment.html>

From goodingm at gmail.com  Thu Oct 16 23:45:17 2014
From: goodingm at gmail.com (htebalaka)
Date: Thu, 16 Oct 2014 16:45:17 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAMgWh9ufbYANcqYirU4hRghN0ssEAVOpwXLvFZ=JUWFbBWG1Tw@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <1413501038977-5758161.post@n5.nabble.com>
 <CAMgWh9ufbYANcqYirU4hRghN0ssEAVOpwXLvFZ=JUWFbBWG1Tw@mail.gmail.com>
Message-ID: <1413503117893-5758166.post@n5.nabble.com>

Yeah, I just realized that would work too. You would still need to do two
passes over the imports, so foo and bar are hidden from anything imported
above A. Though while we're reasoning syntactically, you would also need to
hide them from the Prelude if it was being implicitly imported.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758166.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From carter.schonwald at gmail.com  Fri Oct 17 01:24:31 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 16 Oct 2014 21:24:31 -0400
Subject: Type checker plugins
In-Reply-To: <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
 <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
 <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>
 <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>
Message-ID: <CAHYVw0zvm0H3uDMqDMFC0iw6GEZkkW2V3vXs6=Ox753Eai44vA@mail.gmail.com>

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html

type family CmpSymbol m n :: Ordering
<http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Ord.html#t:Ordering>

On Thu, Oct 16, 2014 at 7:14 PM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> Ok, I hadn't realised that. Looking in the user's guide, I see <= and <=?
> for Nat, but I couldn't find anything about Symbol. I must try them out!
>
>
> > From: Carter Schonwald <carter.schonwald at gmail.com>
> >
> > the alphabetical ordering on Symbol is already exposed via TypeLits...
> this would be some machinery to help maintain that ordering with less user
> intervention?
> >
> > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken <b.hilken at ntlworld.com>
> wrote:
> > I can think of a use for a non-equality constraint: an alphabetical
> ordering on Symbol. This would allow experimental implementations of
> extensible records (without shadowing) which keep the labels sorted.
> >
> > An order constraint on Nat might be useful, too.
> >
> > Barney.
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141016/6c2eccd5/attachment-0001.html>

From carter.schonwald at gmail.com  Fri Oct 17 01:39:57 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 16 Oct 2014 21:39:57 -0400
Subject: Type checker plugins
In-Reply-To: <CAHYVw0zvm0H3uDMqDMFC0iw6GEZkkW2V3vXs6=Ox753Eai44vA@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
 <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
 <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>
 <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>
 <CAHYVw0zvm0H3uDMqDMFC0iw6GEZkkW2V3vXs6=Ox753Eai44vA@mail.gmail.com>
Message-ID: <CAHYVw0w8E+G22eiEGtrwmh9LFSZq8WZ8JJnMSmPoQ_BBC8uf_g@mail.gmail.com>

mind you, i'm not sure what the ordering is specified to be :)

On Thu, Oct 16, 2014 at 9:24 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html
>
> type family CmpSymbol m n :: Ordering
> <http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Ord.html#t:Ordering>
>
> On Thu, Oct 16, 2014 at 7:14 PM, Barney Hilken <b.hilken at ntlworld.com>
> wrote:
>
>> Ok, I hadn't realised that. Looking in the user's guide, I see <= and <=?
>> for Nat, but I couldn't find anything about Symbol. I must try them out!
>>
>>
>> > From: Carter Schonwald <carter.schonwald at gmail.com>
>> >
>> > the alphabetical ordering on Symbol is already exposed via TypeLits...
>> this would be some machinery to help maintain that ordering with less user
>> intervention?
>> >
>> > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken <b.hilken at ntlworld.com>
>> wrote:
>> > I can think of a use for a non-equality constraint: an alphabetical
>> ordering on Symbol. This would allow experimental implementations of
>> extensible records (without shadowing) which keep the labels sorted.
>> >
>> > An order constraint on Nat might be useful, too.
>> >
>> > Barney.
>> >
>> > _______________________________________________
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users at haskell.org
>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141016/07318746/attachment.html>

From johnw at newartisans.com  Fri Oct 17 03:01:15 2014
From: johnw at newartisans.com (John Wiegley)
Date: Thu, 16 Oct 2014 22:01:15 -0500
Subject: Windows build broken in Linker.c
In-Reply-To: <54405C16.8000901@gmail.com> (Simon Marlow's message of "Thu, 16
 Oct 2014 17:00:22 -0700")
References: <618BE556AADD624C9C918AA5D5911BEF3F35E9E8@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAEs96n1zypR5g3jHyba4cJYP2Kn=fHUzkv=0DY71WiH2KnzheA@mail.gmail.com>
 <54405C16.8000901@gmail.com>
Message-ID: <m2mw8v762s.fsf@newartisans.com>

>>>>> Simon Marlow <marlowsd at gmail.com> writes:

> I was working on a fix yesterday but ran out of time. Frankly this code is a
> nightmare, every time I touch it it breaks on some platform - this time I
> validated on 64 bit Windows but not 32. Aargh indeed.

Before I start breaking this code up into pieces, do we have tests that solely
target the linking sub-components, and how would I run them?  Perhaps I can
setup a fleet of virtual machines to try it out in every combination where we
expect the code to compile.

John

From alexander at plaimi.net  Fri Oct 17 07:32:15 2014
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 17 Oct 2014 09:32:15 +0200
Subject: Hiding import behaviour
In-Reply-To: <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
Message-ID: <5440C5FF.3020101@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/10/14 00:40, Austin Seipp wrote:
> Maybe there are some cases today where something like this could 
> happen, but this seems awfully, awfully implicit and hard-to-follow
> as a language feature.
> 
> In general I think a program that has imports like this that may
> clash can be automated to make it easier to manage - but ultimately
> such imports tend to represent a complex relationship between a
> module and its dependencies - I'd prefer it if these were as clear
> as possible.
Very strong +1 from me. It seems awfully implicit and obscure for very
little benefit, and it may mean quite a bit of work for tool developers.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRAxf8ACgkQRtClrXBQc7WGewD/Vt/7OdyPgzORiE4uHtU/p22a
TLGGnQuceSlrMJiWFhMA/0GuZ1leom0ILvrqW/oJYugnwGgX1atqmneJoZ72qNEM
=+oUV
-----END PGP SIGNATURE-----

From simonpj at microsoft.com  Fri Oct 17 08:01:06 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Oct 2014 08:01:06 +0000
Subject: Type checker plugins
In-Reply-To: <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <618BE556AADD624C9C918AA5D5911BEF3F35D691@DB3PRD3001MB020.064d.mgd.msft.net>
 <8F1ECD7B-2C4D-4822-930D-CBAE9F7CD998@seidel.io>
 <54402F70.3000104@well-typed.com>
 <706D53E5-C629-4B15-9FDB-649C3813D8B6@ntlworld.com>
 <CAHYVw0yOiZ75TXvErBA08P9JdRXHMyhKhbHkpE2JCu_NxsO8wA@mail.gmail.com>
 <6A992EF0-DE59-4A6B-9D8B-50121F4A0C84@ntlworld.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F35EF79@DB3PRD3001MB020.064d.mgd.msft.net>

And can someone update the user manual please?

|  -----Original Message-----
|  From: Barney Hilken [mailto:b.hilken at ntlworld.com]
|  Sent: 17 October 2014 00:14
|  To: Carter Schonwald
|  Cc: Adam Gundry; Eric Seidel; glasgow-haskell-users at haskell.org; Simon
|  Peyton Jones
|  Subject: Re: Type checker plugins
|  
|  Ok, I hadn't realised that. Looking in the user's guide, I see <= and
|  <=? for Nat, but I couldn't find anything about Symbol. I must try
|  them out!
|  
|  
|  > From: Carter Schonwald <carter.schonwald at gmail.com>
|  >
|  > the alphabetical ordering on Symbol is already exposed via
|  TypeLits... this would be some machinery to help maintain that
|  ordering with less user intervention?
|  >
|  > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken
|  <b.hilken at ntlworld.com> wrote:
|  > I can think of a use for a non-equality constraint: an alphabetical
|  ordering on Symbol. This would allow experimental implementations of
|  extensible records (without shadowing) which keep the labels sorted.
|  >
|  > An order constraint on Nat might be useful, too.
|  >
|  > Barney.
|  >
|  > _______________________________________________
|  > Glasgow-haskell-users mailing list
|  > Glasgow-haskell-users at haskell.org
|  > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|  >

From austin at well-typed.com  Fri Oct 17 14:54:40 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 17 Oct 2014 09:54:40 -0500
Subject: Windows build broken in Linker.c
In-Reply-To: <m2mw8v762s.fsf@newartisans.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F35E9E8@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAEs96n1zypR5g3jHyba4cJYP2Kn=fHUzkv=0DY71WiH2KnzheA@mail.gmail.com>
 <54405C16.8000901@gmail.com> <m2mw8v762s.fsf@newartisans.com>
Message-ID: <CAEs96n0viM0nD_AKA1CB1pbvUojoc+wEBf0_vErBGZ5=24LPxA@mail.gmail.com>

There's one or two of them, yes. If you look under
./testsuite/tests/rts, and grep for files named `linker_*`, you'll
find the primary load test we use. This test should also test whether
or not unloading objects works too. So, feel free to add more;
shouldn't be too difficult.

On Thu, Oct 16, 2014 at 10:01 PM, John Wiegley <johnw at newartisans.com> wrote:
>>>>>> Simon Marlow <marlowsd at gmail.com> writes:
>
>> I was working on a fix yesterday but ran out of time. Frankly this code is a
>> nightmare, every time I touch it it breaks on some platform - this time I
>> validated on 64 bit Windows but not 32. Aargh indeed.
>
> Before I start breaking this code up into pieces, do we have tests that solely
> target the linking sub-components, and how would I run them?  Perhaps I can
> setup a fleet of virtual machines to try it out in every combination where we
> expect the code to compile.
>
> John
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From iavor.diatchki at gmail.com  Fri Oct 17 22:36:14 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 17 Oct 2014 15:36:14 -0700
Subject: Type checker plugins
In-Reply-To: <543FA4E8.7090609@well-typed.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
Message-ID: <CAGK9nuqtKKWnELS2TmhydK2oLkRVmRz10-VuP+om5=Q0jj8_SQ@mail.gmail.com>

Hello,

On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry <adam at well-typed.com> wrote:

>
>
> One problem I've run into is transforming the flattened CFunEqCans into
> unflattened form (so the flatten-skolems don't get in the way of
> AG-unification). Do you know if there is an easy way to do this, or do I
> need to rebuild the tree manually in the plugin?
>

One thing that occurred to me about this:  when constraints are "flattened",
it is easy for a plugin to pick-out only the one that it cares about.  If
things were fully
unflattened, this would not be the case... For example, if I have a
constraint:

(2 + F a) ~ F a + F a

In the flattened form, this will become:
(F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)

So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~
f3),
and ignore (F a ~ f1), as it knows nothing about arbitrary type functions.

So, if we want to do un-flattening, I think we should do it only on those
constraints
that are of interest to the plugin.



>
> Also, I notice that you are providing only equality constraints to the
> plugin. Is there any reason we can't make other types of constraint
> available as well? For example, one might want to introduce a typeclass
> with a special solution strategy (cf. Coercible, or the Has class in
> OverloadedRecordFields).
>
>
Yeah, we should probably pass-in all constraints, inlcluding derived ones.
The reason it is not like that is pretty much historical now.
So I'll have a go at making this change.

-Iavor





>
>
> >   - As an example, I've extracted my work on using an SMT solver at the
> > type level as a separate plugin:
> >
> >       https://github.com/yav/type-nat-solver
> >
> >    - To see how to invoke a module that uses a plugin, have a look in
> > `examples/A.hs`.
> >      (Currently, the plugin assumes that you have `cvc4` installed and
> > available in the path).
> >
> >     - Besides this, we don't have much documentation yet.  For hackers:
> > we tried to use `tcPlugin` on
> >     `TcPlugin` in the names of all things plugin related, so you could
> > grep for this.  The basic API
> >      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
> >
> > Happy hacking,
> > -Iavor
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141017/582f0738/attachment.html>

From carter.schonwald at gmail.com  Sat Oct 18 17:43:59 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 18 Oct 2014 13:43:59 -0400
Subject: GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
In-Reply-To: <CAEs96n3s+_033=ynumAyEqxXYyA6H83iP-PqPGebt3aUiuMc3w@mail.gmail.com>
References: <CAEs96n3s+_033=ynumAyEqxXYyA6H83iP-PqPGebt3aUiuMc3w@mail.gmail.com>
Message-ID: <CAHYVw0y47=Xzz6n1J=SUu-pQus8hQsR295a+3kJ3QGf8n3akdA@mail.gmail.com>

would https://ghc.haskell.org/trac/ghc/ticket/9284 be good candidate for
7.8.4 ?
It looks like its the only forkProcess related bug fix that wasnt merged
into 7.8.3, and impacts OS X

On Mon, Oct 13, 2014 at 12:37 PM, Austin Seipp <austin at well-typed.com>
wrote:

> Hi *,
>
> After some discussion with Simon & Mikolaj today, I'd like to direct
> you all at this:
>
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4
>
> This status page is the basic overview of what we plan on doing for
> 7.8.4. There are two basic components to this page:
>
>  - Show stopping bugs.
>  - Everything else, which is "nice to have".
>
> Show stoppers are listed at the top of the page, in the first
> paragraph. Right now, this includes:
>
>  - #9439 - LLVM mangling too vigorously.
>  - #8819 - Arithmetic failures for unregistered systems
>  - #8690 - SpecConstr blow-up
>
> And that's all. But what's all the other stuff? That's "everything else".
>
> Aside from these tickets listed here - and any future amendments to it
> - all other tickets will only be considered nice-to-have. What does
> that mean?
>
>  - It's low risk to include.
>  - It clearly fixes the problem
>  - It doesn't take Austin significant amounts of time to merge.
>
> For example, "Tickets marked merge with no milestone" are all
> nice-to-have. Similarly, all the *closed tickets* on this page may be
> re-opened and merged again[1], since most didn't make it to 7.8.4.
>
> Ditto with the remaining categories.
>
> OK, so that's the gist. Now I ask of you the following:
>
>  - If you have a show-stopping bug with GHC 7.8.3, **you really,
> _positively_ need to file a bug, and get in contact with me ASAP**.
> Otherwise you'll be waiting for 7.10 most likely.
>  - Again: if you have a show stopper, contact me. Very soon.
>  - If there are bugs you *think* are showstoppers, but we didn't
> categorize them properly, let me know.
>
> Anything we accept as a show-stopper will delay the release of 7.8.4.
> Anything else can (and possibly will) be left behind. Luckily, almost
> all of the show stoppers have patches. Only #8819 does not, but I have
> asked Sergei to look into it for me if he has time today.
>
> Finally, I would please ask that users/developers do not include their
> own personal pet tickets under "show stoppers" without consulting me
> first, at least. :) If it's just nice to have, you can still pester
> me, of course, and I'll try to make it happen.
>
> I would like to have 7.8.4 out and done with by mid November, before
> we freeze the new STABLE branch for 7.10.1. That's not a hard
> deadline; just a timeframe I'd like to hit.
>
> Let me know if you have any questions or comments; thanks!
>
> [1] A lot of the closed tickets on this page had an improper milestone
> set, which is why they show up. You can mostly ignore them, I
> apologize.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141018/cacfd5fc/attachment.html>

From goodingm at gmail.com  Sat Oct 18 18:02:28 2014
From: goodingm at gmail.com (htebalaka)
Date: Sat, 18 Oct 2014 11:02:28 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <5440C5FF.3020101@plaimi.net>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
Message-ID: <1413655348523-5758246.post@n5.nabble.com>

On 10/17/14 12:32, Alexander Berntsen wrote:
> On 17/10/14 00:40, Austin Seipp wrote: 
> > Maybe there are some cases today where something like this could 
> > happen, but this seems awfully, awfully implicit and hard-to-follow 
> > as a language feature. 
> > 
> > In general I think a program that has imports like this that may 
> > clash can be automated to make it easier to manage - but ultimately 
> > such imports tend to represent a complex relationship between a 
> > module and its dependencies - I'd prefer it if these were as clear 
> > as possible. 
> Very strong +1 from me. It seems awfully implicit and obscure for very 
> little benefit, and it may mean quite a bit of work for tool developers.

I guess my central point is I don't see how anyone can benefit from the
current behaviour. For instance, a simple real world example:

import Prelude
import Data.Text.Lazy.IO (putStrLn)

Regardless of the ordering of the imports, is there any way for me to use
putStrLn in any context without hiding it from the Prelude (and any other
modules that I might be unintentionally importing it from)? Any unqualified
use will be ambiguous, unless you hide it from every other module that might
export a function with the same name. I would think the fact that it
shouldn't be implicitly imported from other modules would directly follow
from the fact you imported it explicitly (otherwise, why did you import
it?). I'm having trouble coming up with a single example where the current
behaviour is useful.

I can't speak to tooling, though I suppose if this doesn't get implemented
I'll write my own. Just to be very clear, supposing you have some Import
datatype which stores a list of any identifiers that are being explicitly
imported unqualified (or conversely, a list of any identifiers that are
being hidden), then the behaviour I'm suggesting is a pragma to enable
something like this:

hide :: [Import] -> [Import]
hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
    collectOnly :: [Import] -> [Identifier]
    collectOnly = concat . mapMaybe getExplicitImports
    appendHiddenImports :: [Identifier] -> Import -> Import
    getExplicitImports :: Import -> Maybe [Identifier]

where appendHiddenImports would only change import statements that import an
unspecified number of unqualified identifiers, like "import X hiding (x, y)"
or "import Y".



--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From david.feuer at gmail.com  Sat Oct 18 18:11:31 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 18 Oct 2014 14:11:31 -0400
Subject: Hiding import behaviour
In-Reply-To: <1413655348523-5758246.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
Message-ID: <CAMgWh9t6Z3c=QRR11sUcegpj_Eke3FSy4L-r3Ou5SyDNtjDzyw@mail.gmail.com>

You mention only unqualified imports, but if we do this, it should also
apply to qualified ones:

import qualified Data.List as L
import qualified MyModule as L (isInfixOf)
On Oct 18, 2014 2:02 PM, "htebalaka" <goodingm at gmail.com> wrote:

> On 10/17/14 12:32, Alexander Berntsen wrote:
> > On 17/10/14 00:40, Austin Seipp wrote:
> > > Maybe there are some cases today where something like this could
> > > happen, but this seems awfully, awfully implicit and hard-to-follow
> > > as a language feature.
> > >
> > > In general I think a program that has imports like this that may
> > > clash can be automated to make it easier to manage - but ultimately
> > > such imports tend to represent a complex relationship between a
> > > module and its dependencies - I'd prefer it if these were as clear
> > > as possible.
> > Very strong +1 from me. It seems awfully implicit and obscure for very
> > little benefit, and it may mean quite a bit of work for tool developers.
>
> I guess my central point is I don't see how anyone can benefit from the
> current behaviour. For instance, a simple real world example:
>
> import Prelude
> import Data.Text.Lazy.IO (putStrLn)
>
> Regardless of the ordering of the imports, is there any way for me to use
> putStrLn in any context without hiding it from the Prelude (and any other
> modules that I might be unintentionally importing it from)? Any unqualified
> use will be ambiguous, unless you hide it from every other module that
> might
> export a function with the same name. I would think the fact that it
> shouldn't be implicitly imported from other modules would directly follow
> from the fact you imported it explicitly (otherwise, why did you import
> it?). I'm having trouble coming up with a single example where the current
> behaviour is useful.
>
> I can't speak to tooling, though I suppose if this doesn't get implemented
> I'll write my own. Just to be very clear, supposing you have some Import
> datatype which stores a list of any identifiers that are being explicitly
> imported unqualified (or conversely, a list of any identifiers that are
> being hidden), then the behaviour I'm suggesting is a pragma to enable
> something like this:
>
> hide :: [Import] -> [Import]
> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>     collectOnly :: [Import] -> [Identifier]
>     collectOnly = concat . mapMaybe getExplicitImports
>     appendHiddenImports :: [Identifier] -> Import -> Import
>     getExplicitImports :: Import -> Maybe [Identifier]
>
> where appendHiddenImports would only change import statements that import
> an
> unspecified number of unqualified identifiers, like "import X hiding (x,
> y)"
> or "import Y".
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141018/a8870a95/attachment.html>

From austin at well-typed.com  Sat Oct 18 18:33:16 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 18 Oct 2014 13:33:16 -0500
Subject: Hiding import behaviour
In-Reply-To: <1413655348523-5758246.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
Message-ID: <CAEs96n1=XL2jGoyJSZ2=p49oz0+rUZumZHfRcWmnZcv9EbDZPw@mail.gmail.com>

On Sat, Oct 18, 2014 at 1:02 PM, htebalaka <goodingm at gmail.com> wrote:
> On 10/17/14 12:32, Alexander Berntsen wrote:
>> On 17/10/14 00:40, Austin Seipp wrote:
>> > Maybe there are some cases today where something like this could
>> > happen, but this seems awfully, awfully implicit and hard-to-follow
>> > as a language feature.
>> >
>> > In general I think a program that has imports like this that may
>> > clash can be automated to make it easier to manage - but ultimately
>> > such imports tend to represent a complex relationship between a
>> > module and its dependencies - I'd prefer it if these were as clear
>> > as possible.
>> Very strong +1 from me. It seems awfully implicit and obscure for very
>> little benefit, and it may mean quite a bit of work for tool developers.
>
> I guess my central point is I don't see how anyone can benefit from the
> current behaviour. For instance, a simple real world example:
>
> import Prelude
> import Data.Text.Lazy.IO (putStrLn)
>
> Regardless of the ordering of the imports, is there any way for me to use
> putStrLn in any context without hiding it from the Prelude (and any other
> modules that I might be unintentionally importing it from)?

I suppose my point isn't that the current behavior is more useful, but
the *proposed behavior seems more confusing for humans*. I would
rather have GHC inform me of an ambiguous import as opposed to
silently accepting or rejecting my program based on the import list,
and whether it shadows something prior to it. I don't even always know
what identifiers may get imported in the first place, due to
transitive module reexports. It just seems like pretty confusing
behavior - shadowing of identifiers is rarely a 'feature' for humans,
IMO.

In the example you have, what happens if I change the import list of
Data.Text by removing it, for example, or what happens if I *remove*
the Prelude import, and stick it after the Text import? Rather than
getting an out of scope identifier error, or something ambiguous, I'd
get a confusing type error based on Prelude's use of putStrLn in the
context of needing Texts', because the shadowing would fail to apply
since it didn't occur before the Text import. Shadowing of previously
imported identifiers only works one-way, so to speak, where with
'hiding', order no longer matters in the import list.

Of course you might say, "Well, of course Prelude exports putStrLn, so
you wouldn't move the import, and it wouldn't be a problem". The
problem is I don't know what exports an arbitrary module has; it
doesn't seem to scale mentally for humans at all. In this case, I know
Prelude exports that, but in the general case of:

import Frob
import Knob (xyz)

Today, this means I only import 'xyz' from Knob, and there are no
other ambiguous names. But under your proposal, I have zero clue if
'xyz' is actually shadowing a prior import. So unless I check *all*
the transitive exports of 'Frob', I have no clue if it's actually safe
to move the import of 'Knob' higher up - an identifier may not be
shadowed if I do that. OTOH, I know *for a fact* when I see this:

import Frob hiding (xyz)
import Knob (xyz)

which 'xyz' I'm referring to later, without ambiguity. Also, what
happens if I do this:

import Knob (xyz)
import Frob

legitimately, without shadowing, and 'Frob' later ends up exporting
its own 'xyz'? Do I just get an ambiguous identifier error, like I
would today? Again, shadowing in this sense only works 'one-way': top
to bottom, and it fails any other case they might be rearranged.

This all just seems like a relatively large amount of hoops to jump
through, just to avoid writing 'hiding' in a on a few things, so to
me, the cure looks worse than the disease. But I may just be missing
something completely.

> Any unqualified use will be ambiguous, unless you hide it from every other module that might
> export a function with the same name. I would think the fact that it
> shouldn't be implicitly imported from other modules would directly follow
> from the fact you imported it explicitly (otherwise, why did you import
> it?). I'm having trouble coming up with a single example where the current
> behaviour is useful.
>
> I can't speak to tooling, though I suppose if this doesn't get implemented
> I'll write my own. Just to be very clear, supposing you have some Import
> datatype which stores a list of any identifiers that are being explicitly
> imported unqualified (or conversely, a list of any identifiers that are
> being hidden), then the behaviour I'm suggesting is a pragma to enable
> something like this:
>
> hide :: [Import] -> [Import]
> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>     collectOnly :: [Import] -> [Identifier]
>     collectOnly = concat . mapMaybe getExplicitImports
>     appendHiddenImports :: [Identifier] -> Import -> Import
>     getExplicitImports :: Import -> Maybe [Identifier]
>
> where appendHiddenImports would only change import statements that import an
> unspecified number of unqualified identifiers, like "import X hiding (x, y)"
> or "import Y".
>
>
>
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

-- 
Regards,

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

From austin at well-typed.com  Sat Oct 18 18:42:17 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 18 Oct 2014 13:42:17 -0500
Subject: Hiding import behaviour
In-Reply-To: <CAEs96n1=XL2jGoyJSZ2=p49oz0+rUZumZHfRcWmnZcv9EbDZPw@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <CAEs96n1=XL2jGoyJSZ2=p49oz0+rUZumZHfRcWmnZcv9EbDZPw@mail.gmail.com>
Message-ID: <CAEs96n0j+-dDN3AmvktKA+rMu0y7rUKKNyqZ3kQgyJ=VW+3d2A@mail.gmail.com>

And also, the ultimate confusing case: if two modules exported
identifiers with the same name *and* type. At least under the current
scheme, you'd be required to clearly disambiguate them in all cases.
Under the proposed scheme, there's no telling what behavior your
program might have, based solely on the shadowing rules/ordering of
the imports of your module and nothing else.

I don't think this would be a common occurrence. But it seems deeply
upsetting that in such a case, rather than the compiler complaining
loudly about ambiguity in a very obvious case (a compiler which
catches many *other* very obvious static code errors), it would
instead silently accept accept your program under a very implicit
"DWIM-ish" import rule.

On Sat, Oct 18, 2014 at 1:33 PM, Austin Seipp <austin at well-typed.com> wrote:
> On Sat, Oct 18, 2014 at 1:02 PM, htebalaka <goodingm at gmail.com> wrote:
>> On 10/17/14 12:32, Alexander Berntsen wrote:
>>> On 17/10/14 00:40, Austin Seipp wrote:
>>> > Maybe there are some cases today where something like this could
>>> > happen, but this seems awfully, awfully implicit and hard-to-follow
>>> > as a language feature.
>>> >
>>> > In general I think a program that has imports like this that may
>>> > clash can be automated to make it easier to manage - but ultimately
>>> > such imports tend to represent a complex relationship between a
>>> > module and its dependencies - I'd prefer it if these were as clear
>>> > as possible.
>>> Very strong +1 from me. It seems awfully implicit and obscure for very
>>> little benefit, and it may mean quite a bit of work for tool developers.
>>
>> I guess my central point is I don't see how anyone can benefit from the
>> current behaviour. For instance, a simple real world example:
>>
>> import Prelude
>> import Data.Text.Lazy.IO (putStrLn)
>>
>> Regardless of the ordering of the imports, is there any way for me to use
>> putStrLn in any context without hiding it from the Prelude (and any other
>> modules that I might be unintentionally importing it from)?
>
> I suppose my point isn't that the current behavior is more useful, but
> the *proposed behavior seems more confusing for humans*. I would
> rather have GHC inform me of an ambiguous import as opposed to
> silently accepting or rejecting my program based on the import list,
> and whether it shadows something prior to it. I don't even always know
> what identifiers may get imported in the first place, due to
> transitive module reexports. It just seems like pretty confusing
> behavior - shadowing of identifiers is rarely a 'feature' for humans,
> IMO.
>
> In the example you have, what happens if I change the import list of
> Data.Text by removing it, for example, or what happens if I *remove*
> the Prelude import, and stick it after the Text import? Rather than
> getting an out of scope identifier error, or something ambiguous, I'd
> get a confusing type error based on Prelude's use of putStrLn in the
> context of needing Texts', because the shadowing would fail to apply
> since it didn't occur before the Text import. Shadowing of previously
> imported identifiers only works one-way, so to speak, where with
> 'hiding', order no longer matters in the import list.
>
> Of course you might say, "Well, of course Prelude exports putStrLn, so
> you wouldn't move the import, and it wouldn't be a problem". The
> problem is I don't know what exports an arbitrary module has; it
> doesn't seem to scale mentally for humans at all. In this case, I know
> Prelude exports that, but in the general case of:
>
> import Frob
> import Knob (xyz)
>
> Today, this means I only import 'xyz' from Knob, and there are no
> other ambiguous names. But under your proposal, I have zero clue if
> 'xyz' is actually shadowing a prior import. So unless I check *all*
> the transitive exports of 'Frob', I have no clue if it's actually safe
> to move the import of 'Knob' higher up - an identifier may not be
> shadowed if I do that. OTOH, I know *for a fact* when I see this:
>
> import Frob hiding (xyz)
> import Knob (xyz)
>
> which 'xyz' I'm referring to later, without ambiguity. Also, what
> happens if I do this:
>
> import Knob (xyz)
> import Frob
>
> legitimately, without shadowing, and 'Frob' later ends up exporting
> its own 'xyz'? Do I just get an ambiguous identifier error, like I
> would today? Again, shadowing in this sense only works 'one-way': top
> to bottom, and it fails any other case they might be rearranged.
>
> This all just seems like a relatively large amount of hoops to jump
> through, just to avoid writing 'hiding' in a on a few things, so to
> me, the cure looks worse than the disease. But I may just be missing
> something completely.
>
>> Any unqualified use will be ambiguous, unless you hide it from every other module that might
>> export a function with the same name. I would think the fact that it
>> shouldn't be implicitly imported from other modules would directly follow
>> from the fact you imported it explicitly (otherwise, why did you import
>> it?). I'm having trouble coming up with a single example where the current
>> behaviour is useful.
>>
>> I can't speak to tooling, though I suppose if this doesn't get implemented
>> I'll write my own. Just to be very clear, supposing you have some Import
>> datatype which stores a list of any identifiers that are being explicitly
>> imported unqualified (or conversely, a list of any identifiers that are
>> being hidden), then the behaviour I'm suggesting is a pragma to enable
>> something like this:
>>
>> hide :: [Import] -> [Import]
>> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>>     collectOnly :: [Import] -> [Identifier]
>>     collectOnly = concat . mapMaybe getExplicitImports
>>     appendHiddenImports :: [Identifier] -> Import -> Import
>>     getExplicitImports :: Import -> Maybe [Identifier]
>>
>> where appendHiddenImports would only change import statements that import an
>> unspecified number of unqualified identifiers, like "import X hiding (x, y)"
>> or "import Y".
>>
>>
>>
>> --
>> View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

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

From goodingm at gmail.com  Sat Oct 18 18:43:58 2014
From: goodingm at gmail.com (htebalaka)
Date: Sat, 18 Oct 2014 11:43:58 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAMgWh9t6Z3c=QRR11sUcegpj_Eke3FSy4L-r3Ou5SyDNtjDzyw@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <CAMgWh9t6Z3c=QRR11sUcegpj_Eke3FSy4L-r3Ou5SyDNtjDzyw@mail.gmail.com>
Message-ID: <1413657838234-5758251.post@n5.nabble.com>

I don't normally import things qualified like that, so it hadn't occurred to
me, but that makes sense. I do want to be clear that this shouldn't be
sensitive to ordering, and it can occur before type checking. You just need
to know what modules are importing which identifiers explicitly, and what
modules are importing an unspecified set of identifiers. It should be
possible to do while parsing even, as soon as you've reached a point where
you know every import statement has been reached.

The behaviour would thus remain the same if someone was to explicitly import
the same identifier from two or more modules, since hiding the implicit
imports wouldn't remove the ambiguity in that case. I'm pretty sure the code
I provided is sufficient; you would just need a separate pass for qualified
and unqualified imports.


David Feuer wrote
> You mention only unqualified imports, but if we do this, it should also
> apply to qualified ones:
> 
> import qualified Data.List as L
> import qualified MyModule as L (isInfixOf)
> On Oct 18, 2014 2:02 PM, "htebalaka" &lt;

> goodingm@

> &gt; wrote:
> 
>> On 10/17/14 12:32, Alexander Berntsen wrote:
>> > On 17/10/14 00:40, Austin Seipp wrote:
>> > > Maybe there are some cases today where something like this could
>> > > happen, but this seems awfully, awfully implicit and hard-to-follow
>> > > as a language feature.
>> > >
>> > > In general I think a program that has imports like this that may
>> > > clash can be automated to make it easier to manage - but ultimately
>> > > such imports tend to represent a complex relationship between a
>> > > module and its dependencies - I'd prefer it if these were as clear
>> > > as possible.
>> > Very strong +1 from me. It seems awfully implicit and obscure for very
>> > little benefit, and it may mean quite a bit of work for tool
>> developers.
>>
>> I guess my central point is I don't see how anyone can benefit from the
>> current behaviour. For instance, a simple real world example:
>>
>> import Prelude
>> import Data.Text.Lazy.IO (putStrLn)
>>
>> Regardless of the ordering of the imports, is there any way for me to use
>> putStrLn in any context without hiding it from the Prelude (and any other
>> modules that I might be unintentionally importing it from)? Any
>> unqualified
>> use will be ambiguous, unless you hide it from every other module that
>> might
>> export a function with the same name. I would think the fact that it
>> shouldn't be implicitly imported from other modules would directly follow
>> from the fact you imported it explicitly (otherwise, why did you import
>> it?). I'm having trouble coming up with a single example where the
>> current
>> behaviour is useful.
>>
>> I can't speak to tooling, though I suppose if this doesn't get
>> implemented
>> I'll write my own. Just to be very clear, supposing you have some Import
>> datatype which stores a list of any identifiers that are being explicitly
>> imported unqualified (or conversely, a list of any identifiers that are
>> being hidden), then the behaviour I'm suggesting is a pragma to enable
>> something like this:
>>
>> hide :: [Import] -> [Import]
>> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>>     collectOnly :: [Import] -> [Identifier]
>>     collectOnly = concat . mapMaybe getExplicitImports
>>     appendHiddenImports :: [Identifier] -> Import -> Import
>>     getExplicitImports :: Import -> Maybe [Identifier]
>>
>> where appendHiddenImports would only change import statements that import
>> an
>> unspecified number of unqualified identifiers, like "import X hiding (x,
>> y)"
>> or "import Y".
>>
>>
>>
>> --
>> View this message in context:
>> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
>> Nabble.com.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> 

> Glasgow-haskell-users@

>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> 
> _______________________________________________
> Glasgow-haskell-users mailing list

> Glasgow-haskell-users@

> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758251.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From goodingm at gmail.com  Sat Oct 18 19:02:42 2014
From: goodingm at gmail.com (htebalaka)
Date: Sat, 18 Oct 2014 12:02:42 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAEs96n0j+-dDN3AmvktKA+rMu0y7rUKKNyqZ3kQgyJ=VW+3d2A@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <CAEs96n1=XL2jGoyJSZ2=p49oz0+rUZumZHfRcWmnZcv9EbDZPw@mail.gmail.com>
 <CAEs96n0j+-dDN3AmvktKA+rMu0y7rUKKNyqZ3kQgyJ=VW+3d2A@mail.gmail.com>
Message-ID: <1413658962742-5758254.post@n5.nabble.com>

Shadowing may have been a poor name on my part, since that does imply a scope
that is sensitive to order. It's more like import precedence. The explicit
import takes precedence over ones that are being implicitly imported. So in
the Frob/Knob examples the behaviour would be identical in all cases,
regardless of transitive imports. An explicit import of xyz from Knob hides
xyz from the implicit imports regardless of where they appear in the import
list.

I suppose in the case where the types of the implicitly imported thing match
that of the explicitly imported one, AND you later remove the explicit
import, that would be potentially dangerous, since you might not realize
that the lower precedence function is now being used, and wouldn't be able
to use the compiler to track down those uses without first manually hiding
the function from the module thats being implicitly imported (which the
current behaviour would have required you to do already). I still think a
pragma would be useful, though clearly it wouldn't be acceptable as the
default; you don't really need to be careful when adding imports, but you do
need to be more careful when removing.


Austin Seipp-5 wrote
> And also, the ultimate confusing case: if two modules exported
> identifiers with the same name *and* type. At least under the current
> scheme, you'd be required to clearly disambiguate them in all cases.
> Under the proposed scheme, there's no telling what behavior your
> program might have, based solely on the shadowing rules/ordering of
> the imports of your module and nothing else.
> 
> I don't think this would be a common occurrence. But it seems deeply
> upsetting that in such a case, rather than the compiler complaining
> loudly about ambiguity in a very obvious case (a compiler which
> catches many *other* very obvious static code errors), it would
> instead silently accept accept your program under a very implicit
> "DWIM-ish" import rule.
> 
> On Sat, Oct 18, 2014 at 1:33 PM, Austin Seipp &lt;

> austin@

> &gt; wrote:
>> On Sat, Oct 18, 2014 at 1:02 PM, htebalaka &lt;

> goodingm@

> &gt; wrote:
>>> On 10/17/14 12:32, Alexander Berntsen wrote:
>>>> On 17/10/14 00:40, Austin Seipp wrote:
>>>> > Maybe there are some cases today where something like this could
>>>> > happen, but this seems awfully, awfully implicit and hard-to-follow
>>>> > as a language feature.
>>>> >
>>>> > In general I think a program that has imports like this that may
>>>> > clash can be automated to make it easier to manage - but ultimately
>>>> > such imports tend to represent a complex relationship between a
>>>> > module and its dependencies - I'd prefer it if these were as clear
>>>> > as possible.
>>>> Very strong +1 from me. It seems awfully implicit and obscure for very
>>>> little benefit, and it may mean quite a bit of work for tool
>>>> developers.
>>>
>>> I guess my central point is I don't see how anyone can benefit from the
>>> current behaviour. For instance, a simple real world example:
>>>
>>> import Prelude
>>> import Data.Text.Lazy.IO (putStrLn)
>>>
>>> Regardless of the ordering of the imports, is there any way for me to
>>> use
>>> putStrLn in any context without hiding it from the Prelude (and any
>>> other
>>> modules that I might be unintentionally importing it from)?
>>
>> I suppose my point isn't that the current behavior is more useful, but
>> the *proposed behavior seems more confusing for humans*. I would
>> rather have GHC inform me of an ambiguous import as opposed to
>> silently accepting or rejecting my program based on the import list,
>> and whether it shadows something prior to it. I don't even always know
>> what identifiers may get imported in the first place, due to
>> transitive module reexports. It just seems like pretty confusing
>> behavior - shadowing of identifiers is rarely a 'feature' for humans,
>> IMO.
>>
>> In the example you have, what happens if I change the import list of
>> Data.Text by removing it, for example, or what happens if I *remove*
>> the Prelude import, and stick it after the Text import? Rather than
>> getting an out of scope identifier error, or something ambiguous, I'd
>> get a confusing type error based on Prelude's use of putStrLn in the
>> context of needing Texts', because the shadowing would fail to apply
>> since it didn't occur before the Text import. Shadowing of previously
>> imported identifiers only works one-way, so to speak, where with
>> 'hiding', order no longer matters in the import list.
>>
>> Of course you might say, "Well, of course Prelude exports putStrLn, so
>> you wouldn't move the import, and it wouldn't be a problem". The
>> problem is I don't know what exports an arbitrary module has; it
>> doesn't seem to scale mentally for humans at all. In this case, I know
>> Prelude exports that, but in the general case of:
>>
>> import Frob
>> import Knob (xyz)
>>
>> Today, this means I only import 'xyz' from Knob, and there are no
>> other ambiguous names. But under your proposal, I have zero clue if
>> 'xyz' is actually shadowing a prior import. So unless I check *all*
>> the transitive exports of 'Frob', I have no clue if it's actually safe
>> to move the import of 'Knob' higher up - an identifier may not be
>> shadowed if I do that. OTOH, I know *for a fact* when I see this:
>>
>> import Frob hiding (xyz)
>> import Knob (xyz)
>>
>> which 'xyz' I'm referring to later, without ambiguity. Also, what
>> happens if I do this:
>>
>> import Knob (xyz)
>> import Frob
>>
>> legitimately, without shadowing, and 'Frob' later ends up exporting
>> its own 'xyz'? Do I just get an ambiguous identifier error, like I
>> would today? Again, shadowing in this sense only works 'one-way': top
>> to bottom, and it fails any other case they might be rearranged.
>>
>> This all just seems like a relatively large amount of hoops to jump
>> through, just to avoid writing 'hiding' in a on a few things, so to
>> me, the cure looks worse than the disease. But I may just be missing
>> something completely.
>>
>>> Any unqualified use will be ambiguous, unless you hide it from every
>>> other module that might
>>> export a function with the same name. I would think the fact that it
>>> shouldn't be implicitly imported from other modules would directly
>>> follow
>>> from the fact you imported it explicitly (otherwise, why did you import
>>> it?). I'm having trouble coming up with a single example where the
>>> current
>>> behaviour is useful.
>>>
>>> I can't speak to tooling, though I suppose if this doesn't get
>>> implemented
>>> I'll write my own. Just to be very clear, supposing you have some Import
>>> datatype which stores a list of any identifiers that are being
>>> explicitly
>>> imported unqualified (or conversely, a list of any identifiers that are
>>> being hidden), then the behaviour I'm suggesting is a pragma to enable
>>> something like this:
>>>
>>> hide :: [Import] -> [Import]
>>> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>>>     collectOnly :: [Import] -> [Identifier]
>>>     collectOnly = concat . mapMaybe getExplicitImports
>>>     appendHiddenImports :: [Identifier] -> Import -> Import
>>>     getExplicitImports :: Import -> Maybe [Identifier]
>>>
>>> where appendHiddenImports would only change import statements that
>>> import an
>>> unspecified number of unqualified identifiers, like "import X hiding (x,
>>> y)"
>>> or "import Y".
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
>>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
>>> Nabble.com.
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> 

> Glasgow-haskell-users@

>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list

> Glasgow-haskell-users@

> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758254.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From goodingm at gmail.com  Sat Oct 18 19:22:49 2014
From: goodingm at gmail.com (htebalaka)
Date: Sat, 18 Oct 2014 12:22:49 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <1413658962742-5758254.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <CAEs96n1=XL2jGoyJSZ2=p49oz0+rUZumZHfRcWmnZcv9EbDZPw@mail.gmail.com>
 <CAEs96n0j+-dDN3AmvktKA+rMu0y7rUKKNyqZ3kQgyJ=VW+3d2A@mail.gmail.com>
 <1413658962742-5758254.post@n5.nabble.com>
Message-ID: <1413660169918-5758257.post@n5.nabble.com>

I hate to reply three times in a row, but I guess even when adding in that
case it's a little iffy. Currently you could add an explicit import, use the
compiler to track down which cases are ambiguous, and then once you're
confident they're taken care of hide the identifier from the module that was
implicitly importing it. With the pragma on I still think it would be
unambiguous that you want to prefer the one you've imported explicitly, but
you couldn't use the compiler to check out each ambiguous occurrence before
you hide it from the Prelude (or whatever module was importing it); they
would instead get immediately changed to the explicit identifier.

I hadn't considered those, but I still think it would be kind of useful as a
pragma. I get kind of annoyed when modules essentially steal identifiers
that you never use; the hiding clauses become very mechanical when you want
to use most of what a module exports, but not everything. I've described it
as best I can at any rate, so if there's still not enough interest I'll try
to make something of my own to just parse a source file and auto-add the
hiding clauses.


htebalaka wrote
> Shadowing may have been a poor name on my part, since that does imply a
> scope that is sensitive to order. It's more like import precedence. The
> explicit import takes precedence over ones that are being implicitly
> imported. So in the Frob/Knob examples the behaviour would be identical in
> all cases, regardless of transitive imports. An explicit import of xyz
> from Knob hides xyz from the implicit imports regardless of where they
> appear in the import list.
> 
> I suppose in the case where the types of the implicitly imported thing
> match that of the explicitly imported one, AND you later remove the
> explicit import, that would be potentially dangerous, since you might not
> realize that the lower precedence function is now being used, and wouldn't
> be able to use the compiler to track down those uses without first
> manually hiding the function from the module thats being implicitly
> imported (which the current behaviour would have required you to do
> already). I still think a pragma would be useful, though clearly it
> wouldn't be acceptable as the default; you don't really need to be careful
> when adding imports, but you do need to be more careful when removing.
> Austin Seipp-5 wrote
>> And also, the ultimate confusing case: if two modules exported
>> identifiers with the same name *and* type. At least under the current
>> scheme, you'd be required to clearly disambiguate them in all cases.
>> Under the proposed scheme, there's no telling what behavior your
>> program might have, based solely on the shadowing rules/ordering of
>> the imports of your module and nothing else.
>> 
>> I don't think this would be a common occurrence. But it seems deeply
>> upsetting that in such a case, rather than the compiler complaining
>> loudly about ambiguity in a very obvious case (a compiler which
>> catches many *other* very obvious static code errors), it would
>> instead silently accept accept your program under a very implicit
>> "DWIM-ish" import rule.
>> 
>> On Sat, Oct 18, 2014 at 1:33 PM, Austin Seipp &lt;

>> austin@

>> &gt; wrote:
>>> On Sat, Oct 18, 2014 at 1:02 PM, htebalaka &lt;

>> goodingm@

>> &gt; wrote:
>>>> On 10/17/14 12:32, Alexander Berntsen wrote:
>>>>> On 17/10/14 00:40, Austin Seipp wrote:
>>>>> > Maybe there are some cases today where something like this could
>>>>> > happen, but this seems awfully, awfully implicit and hard-to-follow
>>>>> > as a language feature.
>>>>> >
>>>>> > In general I think a program that has imports like this that may
>>>>> > clash can be automated to make it easier to manage - but ultimately
>>>>> > such imports tend to represent a complex relationship between a
>>>>> > module and its dependencies - I'd prefer it if these were as clear
>>>>> > as possible.
>>>>> Very strong +1 from me. It seems awfully implicit and obscure for very
>>>>> little benefit, and it may mean quite a bit of work for tool
>>>>> developers.
>>>>
>>>> I guess my central point is I don't see how anyone can benefit from the
>>>> current behaviour. For instance, a simple real world example:
>>>>
>>>> import Prelude
>>>> import Data.Text.Lazy.IO (putStrLn)
>>>>
>>>> Regardless of the ordering of the imports, is there any way for me to
>>>> use
>>>> putStrLn in any context without hiding it from the Prelude (and any
>>>> other
>>>> modules that I might be unintentionally importing it from)?
>>>
>>> I suppose my point isn't that the current behavior is more useful, but
>>> the *proposed behavior seems more confusing for humans*. I would
>>> rather have GHC inform me of an ambiguous import as opposed to
>>> silently accepting or rejecting my program based on the import list,
>>> and whether it shadows something prior to it. I don't even always know
>>> what identifiers may get imported in the first place, due to
>>> transitive module reexports. It just seems like pretty confusing
>>> behavior - shadowing of identifiers is rarely a 'feature' for humans,
>>> IMO.
>>>
>>> In the example you have, what happens if I change the import list of
>>> Data.Text by removing it, for example, or what happens if I *remove*
>>> the Prelude import, and stick it after the Text import? Rather than
>>> getting an out of scope identifier error, or something ambiguous, I'd
>>> get a confusing type error based on Prelude's use of putStrLn in the
>>> context of needing Texts', because the shadowing would fail to apply
>>> since it didn't occur before the Text import. Shadowing of previously
>>> imported identifiers only works one-way, so to speak, where with
>>> 'hiding', order no longer matters in the import list.
>>>
>>> Of course you might say, "Well, of course Prelude exports putStrLn, so
>>> you wouldn't move the import, and it wouldn't be a problem". The
>>> problem is I don't know what exports an arbitrary module has; it
>>> doesn't seem to scale mentally for humans at all. In this case, I know
>>> Prelude exports that, but in the general case of:
>>>
>>> import Frob
>>> import Knob (xyz)
>>>
>>> Today, this means I only import 'xyz' from Knob, and there are no
>>> other ambiguous names. But under your proposal, I have zero clue if
>>> 'xyz' is actually shadowing a prior import. So unless I check *all*
>>> the transitive exports of 'Frob', I have no clue if it's actually safe
>>> to move the import of 'Knob' higher up - an identifier may not be
>>> shadowed if I do that. OTOH, I know *for a fact* when I see this:
>>>
>>> import Frob hiding (xyz)
>>> import Knob (xyz)
>>>
>>> which 'xyz' I'm referring to later, without ambiguity. Also, what
>>> happens if I do this:
>>>
>>> import Knob (xyz)
>>> import Frob
>>>
>>> legitimately, without shadowing, and 'Frob' later ends up exporting
>>> its own 'xyz'? Do I just get an ambiguous identifier error, like I
>>> would today? Again, shadowing in this sense only works 'one-way': top
>>> to bottom, and it fails any other case they might be rearranged.
>>>
>>> This all just seems like a relatively large amount of hoops to jump
>>> through, just to avoid writing 'hiding' in a on a few things, so to
>>> me, the cure looks worse than the disease. But I may just be missing
>>> something completely.
>>>
>>>> Any unqualified use will be ambiguous, unless you hide it from every
>>>> other module that might
>>>> export a function with the same name. I would think the fact that it
>>>> shouldn't be implicitly imported from other modules would directly
>>>> follow
>>>> from the fact you imported it explicitly (otherwise, why did you import
>>>> it?). I'm having trouble coming up with a single example where the
>>>> current
>>>> behaviour is useful.
>>>>
>>>> I can't speak to tooling, though I suppose if this doesn't get
>>>> implemented
>>>> I'll write my own. Just to be very clear, supposing you have some
>>>> Import
>>>> datatype which stores a list of any identifiers that are being
>>>> explicitly
>>>> imported unqualified (or conversely, a list of any identifiers that are
>>>> being hidden), then the behaviour I'm suggesting is a pragma to enable
>>>> something like this:
>>>>
>>>> hide :: [Import] -> [Import]
>>>> hide = flip (fmap fmap appendHiddenImports) <*> collectOnly where
>>>>     collectOnly :: [Import] -> [Identifier]
>>>>     collectOnly = concat . mapMaybe getExplicitImports
>>>>     appendHiddenImports :: [Identifier] -> Import -> Import
>>>>     getExplicitImports :: Import -> Maybe [Identifier]
>>>>
>>>> where appendHiddenImports would only change import statements that
>>>> import an
>>>> unspecified number of unqualified identifiers, like "import X hiding
>>>> (x, y)"
>>>> or "import Y".
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758246.html
>>>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
>>>> Nabble.com.
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> 

>> Glasgow-haskell-users@

>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>> 
>> 
>> 
>> -- 
>> Regards,
>> 
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> Glasgow-haskell-users mailing list

>> Glasgow-haskell-users@

>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758257.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From iavor.diatchki at gmail.com  Sat Oct 18 22:33:50 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 18 Oct 2014 15:33:50 -0700
Subject: Type checker plugins
In-Reply-To: <CAGK9nuqtKKWnELS2TmhydK2oLkRVmRz10-VuP+om5=Q0jj8_SQ@mail.gmail.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <CAGK9nuqtKKWnELS2TmhydK2oLkRVmRz10-VuP+om5=Q0jj8_SQ@mail.gmail.com>
Message-ID: <CAGK9nur5Y7bhvdT=ZunJPXstyDqmSoFsPmrBwgndvUTQ15xzgA@mail.gmail.com>

Hello,

Just a heads up, if anyone is playing around with this:  I just updated the
plugin interface a bit.

Here are the changes:
   - A plugin now gets 3 sets of constraints: given, derived, and wanted
(in that order)
   - Plugins are now also presented with dictionary constraints (i.e., you
may see equalities, function equalities, and dictionaries)
   - A plugin does not need to return all constraints that need to be put
back in the inert set.  This is both simpler and more efficient, I think.
So, now a plugin can return one of these two results:
      - All is good:  plugin returns some solved constraints, and some new
constraints to be processed by the constraint solver. The solved
constraints are removed from the inert set, and their evidence variables
are defined.  The new work is added to the work list.
      - Found contradiction: plugin returns a list of the conflicting
constraint; these are removed from the inert set, and re-added as
insoluable.

Happy hacking,
-Iavor






On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry <adam at well-typed.com> wrote:
>
>>
>>
>> One problem I've run into is transforming the flattened CFunEqCans into
>> unflattened form (so the flatten-skolems don't get in the way of
>> AG-unification). Do you know if there is an easy way to do this, or do I
>> need to rebuild the tree manually in the plugin?
>>
>
> One thing that occurred to me about this:  when constraints are
> "flattened",
> it is easy for a plugin to pick-out only the one that it cares about.  If
> things were fully
> unflattened, this would not be the case... For example, if I have a
> constraint:
>
> (2 + F a) ~ F a + F a
>
> In the flattened form, this will become:
> (F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)
>
> So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~
> f3),
> and ignore (F a ~ f1), as it knows nothing about arbitrary type functions.
>
> So, if we want to do un-flattening, I think we should do it only on those
> constraints
> that are of interest to the plugin.
>
>
>
>>
>> Also, I notice that you are providing only equality constraints to the
>> plugin. Is there any reason we can't make other types of constraint
>> available as well? For example, one might want to introduce a typeclass
>> with a special solution strategy (cf. Coercible, or the Has class in
>> OverloadedRecordFields).
>>
>>
> Yeah, we should probably pass-in all constraints, inlcluding derived ones.
> The reason it is not like that is pretty much historical now.
> So I'll have a go at making this change.
>
> -Iavor
>
>
>
>
>
>>
>>
>> >   - As an example, I've extracted my work on using an SMT solver at the
>> > type level as a separate plugin:
>> >
>> >       https://github.com/yav/type-nat-solver
>> >
>> >    - To see how to invoke a module that uses a plugin, have a look in
>> > `examples/A.hs`.
>> >      (Currently, the plugin assumes that you have `cvc4` installed and
>> > available in the path).
>> >
>> >     - Besides this, we don't have much documentation yet.  For hackers:
>> > we tried to use `tcPlugin` on
>> >     `TcPlugin` in the names of all things plugin related, so you could
>> > grep for this.  The basic API
>> >      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
>> >
>> > Happy hacking,
>> > -Iavor
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141018/e4b79ce0/attachment.html>

From mail at joachim-breitner.de  Sat Oct 18 22:39:42 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 19 Oct 2014 00:39:42 +0200
Subject: Hiding import behaviour
In-Reply-To: <1413655348523-5758246.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
Message-ID: <1413671982.2318.5.camel@joachim-breitner.de>

Hi,

Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
> I guess my central point is I don't see how anyone can benefit from the
> current behaviour. For instance, a simple real world example:
> 
> import Prelude
> import Data.Text.Lazy.IO (putStrLn)

I find this quite convincing. If I bother to explicitly write out ?take
putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
might have meant some putStrLn from somewhere else.

Of course, order should not matter (I don?t think anyone suggested it
should, I think Austin simply mis-read that).

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://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141019/a3811a57/attachment.sig>

From david.feuer at gmail.com  Sat Oct 18 23:32:53 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 18 Oct 2014 19:32:53 -0400
Subject: Hiding import behaviour
In-Reply-To: <1413671982.2318.5.camel@joachim-breitner.de>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
Message-ID: <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>

I'm generally in favor of the proposal, but I figured I should mention one
situation when I personally might find this confusing. If the module import
list is very long, and includes an unrestricted import of a well-known
module, it might be easy to assume a certain well-known function comes from
there, when in fact it comes from some other module on the other end of the
import list.
On Oct 18, 2014 6:39 PM, "Joachim Breitner" <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
> > I guess my central point is I don't see how anyone can benefit from the
> > current behaviour. For instance, a simple real world example:
> >
> > import Prelude
> > import Data.Text.Lazy.IO (putStrLn)
>
> I find this quite convincing. If I bother to explicitly write out ?take
> putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
> might have meant some putStrLn from somewhere else.
>
> Of course, order should not matter (I don?t think anyone suggested it
> should, I think Austin simply mis-read that).
>
> 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
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141018/5cb1d473/attachment.html>

From hvr at gnu.org  Sun Oct 19 07:56:04 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 19 Oct 2014 09:56:04 +0200
Subject: Hiding import behaviour
In-Reply-To: <1413671982.2318.5.camel@joachim-breitner.de> (Joachim Breitner's
 message of "Sun, 19 Oct 2014 00:39:42 +0200")
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
Message-ID: <874mv08pd7.fsf@gnu.org>

On 2014-10-19 at 00:39:42 +0200, Joachim Breitner wrote:
>> I guess my central point is I don't see how anyone can benefit from the
>> current behaviour. For instance, a simple real world example:
>> 
>> import Prelude
>> import Data.Text.Lazy.IO (putStrLn)
>
> I find this quite convincing. If I bother to explicitly write out ?take
> putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
> might have meant some putStrLn from somewhere else.

I think we've reached the point where this proposal should be turned
into a Wiki page detailing the exact semantics[1], and giving this
extension a catchy name...

If it's trivial enough (in the sense there is little design-space
variation to get it wrong), having it in 7.10 rather than 7.12 may be
still possible (and IMHO desirable to be able to start using it earlier
rather than later on real-world code).


 [1]: Cases to consider include all combinations of variations of
      import-statements; as well as turning most unqualified imports
      from which entities are to be hidden into a pair of qualified and
      unqualified import:

          import Doo (doo)
          import Bar -- provide 'doo' as well

      which I'd think should be transformed into
  
          import Doo (doo)
          import qualified Bar
          import Bar hiding (doo)

      as to allow to still have 'Bar.doo' in scope (unless some other
      import explicitly mentions `... as Bar (doo)`, in which case that
      needs to be hidden from the qualified `Bar` import as well)

Cheers,
  hvr

From hesselink at gmail.com  Sun Oct 19 12:10:55 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Sun, 19 Oct 2014 14:10:55 +0200
Subject: Hiding import behaviour
In-Reply-To: <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
Message-ID: <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>

I feel that this extension, while looking tempting for writing code
from scratch, might hurt maintainability of code. Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import and the new function is type
incorrect), or worse, can cause semantic change (when it hides an
implicit import and the new function is type correct, but has
different behavior). Remember that not all code is written by the same
person, or in a short time frame, so not everybody might fully
understand every module and every import of the code they're editing.

Erik

On Sun, Oct 19, 2014 at 1:32 AM, David Feuer <david.feuer at gmail.com> wrote:
> I'm generally in favor of the proposal, but I figured I should mention one
> situation when I personally might find this confusing. If the module import
> list is very long, and includes an unrestricted import of a well-known
> module, it might be easy to assume a certain well-known function comes from
> there, when in fact it comes from some other module on the other end of the
> import list.
>
> On Oct 18, 2014 6:39 PM, "Joachim Breitner" <mail at joachim-breitner.de>
> wrote:
>>
>> Hi,
>>
>> Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
>> > I guess my central point is I don't see how anyone can benefit from the
>> > current behaviour. For instance, a simple real world example:
>> >
>> > import Prelude
>> > import Data.Text.Lazy.IO (putStrLn)
>>
>> I find this quite convincing. If I bother to explicitly write out ?take
>> putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
>> might have meant some putStrLn from somewhere else.
>>
>> Of course, order should not matter (I don?t think anyone suggested it
>> should, I think Austin simply mis-read that).
>>
>> 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
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From goodingm at gmail.com  Sun Oct 19 19:02:52 2014
From: goodingm at gmail.com (htebalaka)
Date: Sun, 19 Oct 2014 12:02:52 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
Message-ID: <1413745372892-5758327.post@n5.nabble.com>

At least in the case where something being hidden causes an unintended type
error, compiler errors could /potentially/ be aware of the extension, though
defining unintended seems non-trivial. You don't want actual type errors
being replaced with "maybe you didn't realize this other function is being
auto-hidden", and you definitely don't want to have to type check for
different combination of hidden functions. I don't think it's really worth
extending the scope, unless there's some trivial solution I'm missing.

What I want to be able to do is use a not-too-large set of more general (IO
-> MonadIO) or differently monomorphic (String -> Text) functions than what
I'm implicitly importing. In either case I think the change is semantically
safe: any type errors you encounter are actual type errors. This should make
that kind of use a little more lightweight than it is currently. I'll
definitely concede it could be unsuitable behaviour by default for large
projects. My coding is mostly personal-use stuff, so that's where my
experience is.

Is there a good example proposal somewhere for what kind of format I should
follow. I'm somewhat busy at the moment, but I'll write up a more detailed
proposal on the wiki by the end of the week unless someone feels compelled
to beat me to it.


Erik Hesselink wrote
> I feel that this extension, while looking tempting for writing code
> from scratch, might hurt maintainability of code. Adding an explicit
> import can suddenly cause type errors in completely unrelated places
> (when it hides an implicit import and the new function is type
> incorrect), or worse, can cause semantic change (when it hides an
> implicit import and the new function is type correct, but has
> different behavior). Remember that not all code is written by the same
> person, or in a short time frame, so not everybody might fully
> understand every module and every import of the code they're editing.
> 
> Erik
> 
> On Sun, Oct 19, 2014 at 1:32 AM, David Feuer &lt;

> david.feuer@

> &gt; wrote:
>> I'm generally in favor of the proposal, but I figured I should mention
>> one
>> situation when I personally might find this confusing. If the module
>> import
>> list is very long, and includes an unrestricted import of a well-known
>> module, it might be easy to assume a certain well-known function comes
>> from
>> there, when in fact it comes from some other module on the other end of
>> the
>> import list.
>>
>> On Oct 18, 2014 6:39 PM, "Joachim Breitner" &lt;

> mail@

> &gt;
>> wrote:
>>>
>>> Hi,
>>>
>>> Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
>>> > I guess my central point is I don't see how anyone can benefit from
>>> the
>>> > current behaviour. For instance, a simple real world example:
>>> >
>>> > import Prelude
>>> > import Data.Text.Lazy.IO (putStrLn)
>>>
>>> I find this quite convincing. If I bother to explicitly write out ?take
>>> putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
>>> might have meant some putStrLn from somewhere else.
>>>
>>> Of course, order should not matter (I don?t think anyone suggested it
>>> should, I think Austin simply mis-read that).
>>>
>>> Greetings,
>>> Joachim
>>>
>>>
>>> --
>>> Joachim ?nomeata? Breitner
>>>   

> mail@

>  ? http://www.joachim-breitner.de/
>>>   Jabber: 

> nomeata@

>   ? GPG-Key: 0xF0FBF51F
>>>   Debian Developer: 

> nomeata@

>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> 

> Glasgow-haskell-users@

>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> 

> Glasgow-haskell-users@

>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> _______________________________________________
> Glasgow-haskell-users mailing list

> Glasgow-haskell-users@

> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758327.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From goodingm at gmail.com  Mon Oct 20 02:46:35 2014
From: goodingm at gmail.com (htebalaka)
Date: Sun, 19 Oct 2014 19:46:35 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <1413745372892-5758327.post@n5.nabble.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <1413745372892-5758327.post@n5.nabble.com>
Message-ID: <1413773195996-5758346.post@n5.nabble.com>

There is one more case that I hadn't considered that would be kind of
ambiguous. If you import something like "import Control.Comonad
(Comonad(..))" it's unclear if the compiler should automatically treat it as
if you added "hiding (Comonad(..))" to implicit imports, or added "hiding
(Comonad, extend, extract, duplicate)".

The former could hide identifiers from modules that define Comonad
differently, and might still cause using Comonads methods to be ambiguous.
The latter resolves the ambiguity, but could change what is automatically
hidden if the Comonad typeclass is ever changed. In some sense the methods
being imported from Comonad could still be considered implicit, since they
aren't being imported individually by name.

Unless people feel differently, I'd propose neither solution, since users
would be confused if they assumed the wrong way the compiler did, and silent
changes to what is being imported would be bad things. Instead they would
still get an ambiguous occurrence as they do now. It also makes its
behaviour more uniform: only identifiers imported *by name* are auto-hidden.

For a pragma, AutoHidingImports?


htebalaka wrote
> At least in the case where something being hidden causes an unintended
> type error, compiler errors could 
/
> potentially
/
>  be aware of the extension, though defining unintended seems non-trivial.
> You don't want actual type errors being replaced with "maybe you didn't
> realize this other function is being auto-hidden", and you definitely
> don't want to have to type check for different combination of hidden
> functions. I don't think it's really worth extending the scope, unless
> there's some trivial solution I'm missing.
> 
> What I want to be able to do is use a not-too-large set of more general
> (IO -> MonadIO) or differently monomorphic (String -> Text) functions than
> what I'm implicitly importing. In either case I think the change is
> semantically safe: any type errors you encounter are actual type errors.
> This should make that kind of use a little more lightweight than it is
> currently. I'll definitely concede it could be unsuitable behaviour by
> default for large projects. My coding is mostly personal-use stuff, so
> that's where my experience is.
> 
> Is there a good example proposal somewhere for what kind of format I
> should follow. I'm somewhat busy at the moment, but I'll write up a more
> detailed proposal on the wiki by the end of the week unless someone feels
> compelled to beat me to it.
> Erik Hesselink wrote
>> I feel that this extension, while looking tempting for writing code
>> from scratch, might hurt maintainability of code. Adding an explicit
>> import can suddenly cause type errors in completely unrelated places
>> (when it hides an implicit import and the new function is type
>> incorrect), or worse, can cause semantic change (when it hides an
>> implicit import and the new function is type correct, but has
>> different behavior). Remember that not all code is written by the same
>> person, or in a short time frame, so not everybody might fully
>> understand every module and every import of the code they're editing.
>> 
>> Erik
>> 
>> On Sun, Oct 19, 2014 at 1:32 AM, David Feuer &lt;

>> david.feuer@

>> &gt; wrote:
>>> I'm generally in favor of the proposal, but I figured I should mention
>>> one
>>> situation when I personally might find this confusing. If the module
>>> import
>>> list is very long, and includes an unrestricted import of a well-known
>>> module, it might be easy to assume a certain well-known function comes
>>> from
>>> there, when in fact it comes from some other module on the other end of
>>> the
>>> import list.
>>>
>>> On Oct 18, 2014 6:39 PM, "Joachim Breitner" &lt;

>> mail@

>> &gt;
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
>>>> > I guess my central point is I don't see how anyone can benefit from
>>>> the
>>>> > current behaviour. For instance, a simple real world example:
>>>> >
>>>> > import Prelude
>>>> > import Data.Text.Lazy.IO (putStrLn)
>>>>
>>>> I find this quite convincing. If I bother to explicitly write out ?take
>>>> putStrLn from Data.Text.Lazy.IO?, why should the compiler assume that I
>>>> might have meant some putStrLn from somewhere else.
>>>>
>>>> Of course, order should not matter (I don?t think anyone suggested it
>>>> should, I think Austin simply mis-read that).
>>>>
>>>> Greetings,
>>>> Joachim
>>>>
>>>>
>>>> --
>>>> Joachim ?nomeata? Breitner
>>>>   

>> mail@

>>  ? http://www.joachim-breitner.de/
>>>>   Jabber: 

>> nomeata@

>>   ? GPG-Key: 0xF0FBF51F
>>>>   Debian Developer: 

>> nomeata@

>>>>
>>>>
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> 

>> Glasgow-haskell-users@

>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> 

>> Glasgow-haskell-users@

>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list

>> Glasgow-haskell-users@

>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758346.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From voldermort at hotmail.com  Mon Oct 20 12:53:36 2014
From: voldermort at hotmail.com (Jeremy)
Date: Mon, 20 Oct 2014 12:53:36 +0000 (UTC)
Subject: Dynamic only GHC
Message-ID: <loom.20141020T144703-842@post.gmane.org>

I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic
libraries (this is for a system where disc space is scarce). I'm using this
build.mk:

GhcRTSWays = thr
GhcLibWays = dyn
HADDOCK_DOCS = NO
DYNAMIC_BY_DEFAULT = YES
GhcDynamic = YES

Tried with and without GhcDynamic (asked on beginners how it's different to
DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end
of the build, then fails with:

  HC [stage 1] ghc/stage2/build/Main.dyn_o
  HC [stage 1] ghc/stage2/build/tmp/ghc-stage2
/usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3
collect2: error: ld returned 1 exit status
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2

If I build with only static libraries, everything seems to work OK.


From austin at well-typed.com  Mon Oct 20 14:21:48 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 20 Oct 2014 09:21:48 -0500
Subject: Dynamic only GHC
In-Reply-To: <loom.20141020T144703-842@post.gmane.org>
References: <loom.20141020T144703-842@post.gmane.org>
Message-ID: <CAEs96n1F91yLP1-3c_OzuNT9N57BOUSwRO+43rsq-Y6Gv1fwEg@mail.gmail.com>

As far as I'm aware, Dynamic-by-default GHC is actually broken, and I
don't know for how long this has been the case.

For some history: originally when all this was being decided to try
and fix the linker issues in GHC, dynamic by default was considered an
option, but was rejected in favor of DynamicGhcPrograms. Why was it
rejected? Well, dynamic by default particularly hurts 32bit x86, which
suffers from a very pathetic set of registers, and dynamic programs
steal one of these for the GOT (%ebx IIRC).

On the other hand, DynamicGhcPrograms instead means GHC builds
everything statically, *except itself*, which it builds as a
dynamically linked executable. The idea is you dynamically link GHC
itself to fix linker issues, and end-user programs remain static,
which is the expected mode of operation.

In all honesty, we should probably remove any traces of
DYNAMIC_BY_DEFAULT unless someone is actively interested in it, since
it's bitrotten at this point.

On Mon, Oct 20, 2014 at 7:53 AM, Jeremy <voldermort at hotmail.com> wrote:
> I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic
> libraries (this is for a system where disc space is scarce). I'm using this
> build.mk:
>
> GhcRTSWays = thr
> GhcLibWays = dyn
> HADDOCK_DOCS = NO
> DYNAMIC_BY_DEFAULT = YES
> GhcDynamic = YES
>
> Tried with and without GhcDynamic (asked on beginners how it's different to
> DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end
> of the build, then fails with:
>
>   HC [stage 1] ghc/stage2/build/Main.dyn_o
>   HC [stage 1] ghc/stage2/build/tmp/ghc-stage2
> /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3
> collect2: error: ld returned 1 exit status
> make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
> make: *** [all] Error 2
>
> If I build with only static libraries, everything seems to work OK.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From voldermort at hotmail.com  Mon Oct 20 14:32:13 2014
From: voldermort at hotmail.com (Jeremy)
Date: Mon, 20 Oct 2014 14:32:13 +0000 (UTC)
Subject: Dynamic only GHC
References: <loom.20141020T144703-842@post.gmane.org>
 <CAEs96n1F91yLP1-3c_OzuNT9N57BOUSwRO+43rsq-Y6Gv1fwEg@mail.gmail.com>
Message-ID: <loom.20141020T162830-919@post.gmane.org>

Austin Seipp <austin <at> well-typed.com> writes:

> As far as I'm aware, Dynamic-by-default GHC is actually broken, and I
> don't know for how long this has been the case.
> 
> For some history: originally when all this was being decided to try
> and fix the linker issues in GHC, dynamic by default was considered an
> option, but was rejected in favor of DynamicGhcPrograms. Why was it
> rejected? Well, dynamic by default particularly hurts 32bit x86, which
> suffers from a very pathetic set of registers, and dynamic programs
> steal one of these for the GOT (%ebx IIRC).
> 
> On the other hand, DynamicGhcPrograms instead means GHC builds
> everything statically, *except itself*, which it builds as a
> dynamically linked executable. The idea is you dynamically link GHC
> itself to fix linker issues, and end-user programs remain static,
> which is the expected mode of operation.

Thank you for the detailed explanation (although I still don't understand
why DYNAMIC_BY_DEFAULT by default wasn't kept for x64.)

Where does GhcDynamic fit into this?


From austin at well-typed.com  Mon Oct 20 14:39:57 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 20 Oct 2014 09:39:57 -0500
Subject: Dynamic only GHC
In-Reply-To: <loom.20141020T162830-919@post.gmane.org>
References: <loom.20141020T144703-842@post.gmane.org>
 <CAEs96n1F91yLP1-3c_OzuNT9N57BOUSwRO+43rsq-Y6Gv1fwEg@mail.gmail.com>
 <loom.20141020T162830-919@post.gmane.org>
Message-ID: <CAEs96n1b9K+iNKNONOUAZBkcpXtCrcpwJB6oi6tMHKx8WxrgSA@mail.gmail.com>

Sorry, I confused 'DynamicGhcPrograms' merely with 'DynamicGhc'. In
other words: DynamicGhc means exactly what I said before - dynamic
GHC, static everything else.

As for the reason why the switch wasn't made for x86, I was not privvy
to the decision at the time, but I imagine it's one of consistency. To
ship a x64 GHC with these features (where it was acceptable) but not a
32bit one means essentially you force 32bit users into one of two
situations:

 - Your compiled program may not work in GHCi, or at all in some
corner cases, and most of the bugs that were there are effectively
unfixed.
 - Your compiled program suffers a noticeable performance hit, due to
register theft.

Which is rather unfortunate. On the other hand, if you dynamically
link GHC only, only GHC itself pays a hit on the dynamic linking, and
your remaining programs are unaffected.

On Mon, Oct 20, 2014 at 9:32 AM, Jeremy <voldermort at hotmail.com> wrote:
> Austin Seipp <austin <at> well-typed.com> writes:
>
>> As far as I'm aware, Dynamic-by-default GHC is actually broken, and I
>> don't know for how long this has been the case.
>>
>> For some history: originally when all this was being decided to try
>> and fix the linker issues in GHC, dynamic by default was considered an
>> option, but was rejected in favor of DynamicGhcPrograms. Why was it
>> rejected? Well, dynamic by default particularly hurts 32bit x86, which
>> suffers from a very pathetic set of registers, and dynamic programs
>> steal one of these for the GOT (%ebx IIRC).
>>
>> On the other hand, DynamicGhcPrograms instead means GHC builds
>> everything statically, *except itself*, which it builds as a
>> dynamically linked executable. The idea is you dynamically link GHC
>> itself to fix linker issues, and end-user programs remain static,
>> which is the expected mode of operation.
>
> Thank you for the detailed explanation (although I still don't understand
> why DYNAMIC_BY_DEFAULT by default wasn't kept for x64.)
>
> Where does GhcDynamic fit into this?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From voldermort at hotmail.com  Mon Oct 20 14:44:27 2014
From: voldermort at hotmail.com (Jeremy)
Date: Mon, 20 Oct 2014 14:44:27 +0000 (UTC)
Subject: Dynamic only GHC
References: <loom.20141020T144703-842@post.gmane.org>
 <CAEs96n1F91yLP1-3c_OzuNT9N57BOUSwRO+43rsq-Y6Gv1fwEg@mail.gmail.com>
 <loom.20141020T162830-919@post.gmane.org>
 <CAEs96n1b9K+iNKNONOUAZBkcpXtCrcpwJB6oi6tMHKx8WxrgSA@mail.gmail.com>
Message-ID: <loom.20141020T164244-598@post.gmane.org>

So out of GhcDynamic, DYNAMIC_GHC_PROGRAMS, and DYNAMIC_BY_DEFAULT, which is
broken, and what's the difference between GhcDynamic and
DYNAMIC_GHC_PROGRAMS? This is getting somewhat confusing.


From austin at well-typed.com  Mon Oct 20 14:56:30 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 20 Oct 2014 09:56:30 -0500
Subject: Dynamic only GHC
In-Reply-To: <loom.20141020T164244-598@post.gmane.org>
References: <loom.20141020T144703-842@post.gmane.org>
 <CAEs96n1F91yLP1-3c_OzuNT9N57BOUSwRO+43rsq-Y6Gv1fwEg@mail.gmail.com>
 <loom.20141020T162830-919@post.gmane.org>
 <CAEs96n1b9K+iNKNONOUAZBkcpXtCrcpwJB6oi6tMHKx8WxrgSA@mail.gmail.com>
 <loom.20141020T164244-598@post.gmane.org>
Message-ID: <CAEs96n3+Qdh2+KVKv6LVaem=h=JfRaB6RKKBC+=whCaUAbATJg@mail.gmail.com>

(Sorry for resend; also hitting the list this time).

GhcDynamic is really a variable set by the build system which is
propagated and used to control various other 'things that happen'
during the build, in the case GHC is dynamically linked.

On the other hand, DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT are the
actual options you may set in your build configuration to control what
happens. In other words, these two variables actually control what
will occur; GhcDynamic is just a detail of the build system to push
some information around, in the case you choose an option where GHC is
dynamically linked (you can certainly choose NO for both of these
options, which means 'GhcDynamic' will be false).


On Mon, Oct 20, 2014 at 9:44 AM, Jeremy <voldermort at hotmail.com> wrote:
> So out of GhcDynamic, DYNAMIC_GHC_PROGRAMS, and DYNAMIC_BY_DEFAULT, which is
> broken, and what's the difference between GhcDynamic and
> DYNAMIC_GHC_PROGRAMS? This is getting somewhat confusing.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

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

From eir at cis.upenn.edu  Mon Oct 20 18:35:04 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 20 Oct 2014 14:35:04 -0400
Subject: GADTs in implementation of Template Haskell
Message-ID: <16077A03-605D-4BE3-85B6-57DC51C05CB7@cis.upenn.edu>

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT.

Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs  

Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email.

Thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141020/354c2b09/attachment.html>

From mblazevic at stilo.com  Mon Oct 20 21:57:30 2014
From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=)
Date: Mon, 20 Oct 2014 17:57:30 -0400
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
Message-ID: <5445854A.7060409@stilo.com>

On 14-10-19 08:10 AM, Erik Hesselink wrote:
> I feel that this extension, while looking tempting for writing code
> from scratch, might hurt maintainability of code.

	That depends on how you define maintainability.

> Adding an explicit
> import can suddenly cause type errors in completely unrelated places
> (when it hides an implicit import and the new function is type
> incorrect), or worse, can cause semantic change (when it hides an
> implicit import and the new function is type correct, but has
> different behavior). Remember that not all code is written by the same
> person, or in a short time frame, so not everybody might fully
> understand every module and every import of the code they're editing.

	Your example requires somebody actively editing the import list. A code 
change causes a compile error or worse? That is not all that surprising.

	No, what I find much worse is a cabal update causing an error in a 
module that was correct before the update. Consider

 > module Main where
 >
 > import Foo (foo)
 > import Bar
 >
 > main = foo

	Now suppose Bar came from the package bar-1.0, and the new version 
bar-1.0.1 decides to export foo. With the current behaviour, this change 
would break my module. With Malcolm's proposal the old code would 
continue to work.

	Anyway, count me as +1 on the proposal. It would improve the long-term 
stability of Haskell code.


From hesselink at gmail.com  Tue Oct 21 11:14:37 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 21 Oct 2014 13:14:37 +0200
Subject: Hiding import behaviour
In-Reply-To: <5445854A.7060409@stilo.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
Message-ID: <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>

On Mon, Oct 20, 2014 at 11:57 PM, Mario Bla?evi? <mblazevic at stilo.com> wrote:
> On 14-10-19 08:10 AM, Erik Hesselink wrote:
>>
>> Adding an explicit
>> import can suddenly cause type errors in completely unrelated places
>> (when it hides an implicit import and the new function is type
>> incorrect), or worse, can cause semantic change (when it hides an
>> implicit import and the new function is type correct, but has
>> different behavior). Remember that not all code is written by the same
>> person, or in a short time frame, so not everybody might fully
>> understand every module and every import of the code they're editing.
>
>         Your example requires somebody actively editing the import list. A
> code change causes a compile error or worse? That is not all that
> surprising.

But right now, we have a useful property that adding imports and code
to a module does not break or change other code in that module. With
this extension, that changes. I find this kind of local reasoning very
useful, IMHO it's one of the most useful things about Haskell in
general.

>         No, what I find much worse is a cabal update causing an error in a
> module that was correct before the update. Consider
>
>> module Main where
>>
>> import Foo (foo)
>> import Bar
>>
>> main = foo
>
>         Now suppose Bar came from the package bar-1.0, and the new version
> bar-1.0.1 decides to export foo. With the current behaviour, this change
> would break my module. With Malcolm's proposal the old code would continue
> to work.

That's a very good point. Given that and the above, I don't understand
your conclusion:

>         Anyway, count me as +1 on the proposal. It would improve the
> long-term stability of Haskell code.

How is adding more ways to break something "improving the long-term stability"?

Regards,

Erik

From eir at cis.upenn.edu  Tue Oct 21 12:38:08 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 21 Oct 2014 08:38:08 -0400
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
Message-ID: <7B590DA2-1008-4D74-A1A1-B463317FBBEA@cis.upenn.edu>

I'm having a hard time keeping track of what's going on in this discussion. But, I'm generally in favor of making *some* change along the lines discussed here, and also in #9702 (https://ghc.haskell.org/trac/ghc/ticket/9702). Could the proposers of various features perhaps create a wiki page, naming the individual pieces or proposals, and then we can have something closer to a vote among a stable list of candidates?

Thanks!
Richard

On Oct 21, 2014, at 7:14 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> On Mon, Oct 20, 2014 at 11:57 PM, Mario Bla?evi? <mblazevic at stilo.com> wrote:
>> On 14-10-19 08:10 AM, Erik Hesselink wrote:
>>> 
>>> Adding an explicit
>>> import can suddenly cause type errors in completely unrelated places
>>> (when it hides an implicit import and the new function is type
>>> incorrect), or worse, can cause semantic change (when it hides an
>>> implicit import and the new function is type correct, but has
>>> different behavior). Remember that not all code is written by the same
>>> person, or in a short time frame, so not everybody might fully
>>> understand every module and every import of the code they're editing.
>> 
>>        Your example requires somebody actively editing the import list. A
>> code change causes a compile error or worse? That is not all that
>> surprising.
> 
> But right now, we have a useful property that adding imports and code
> to a module does not break or change other code in that module. With
> this extension, that changes. I find this kind of local reasoning very
> useful, IMHO it's one of the most useful things about Haskell in
> general.
> 
>>        No, what I find much worse is a cabal update causing an error in a
>> module that was correct before the update. Consider
>> 
>>> module Main where
>>> 
>>> import Foo (foo)
>>> import Bar
>>> 
>>> main = foo
>> 
>>        Now suppose Bar came from the package bar-1.0, and the new version
>> bar-1.0.1 decides to export foo. With the current behaviour, this change
>> would break my module. With Malcolm's proposal the old code would continue
>> to work.
> 
> That's a very good point. Given that and the above, I don't understand
> your conclusion:
> 
>>        Anyway, count me as +1 on the proposal. It would improve the
>> long-term stability of Haskell code.
> 
> How is adding more ways to break something "improving the long-term stability"?
> 
> Regards,
> 
> Erik
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


From daniel.trstenjak at gmail.com  Tue Oct 21 14:12:18 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Tue, 21 Oct 2014 16:12:18 +0200
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
Message-ID: <20141021141218.GA23245@machine>


Hi Erik,

> But right now, we have a useful property that adding imports and code
> to a module does not break or change other code in that module. With
> this extension, that changes.

So your biggest concern is about silent breakage of code, that suddenly
a different function is used which has the same name and type, but
different semantics.

In all other cases the compiler would throw an error, because the types
wouldn't match.

I have the feeling, that the proposal shouldn't be about implicit/explicit imports,
but about prefering the function with the fitting type.

If there're two functions with the same name and type in scope, then the
compiler most likely should always throw an error.

The only exception might be, if there's a function locally defined in the
module, then this one might be prefered over every imported one with the
same name and type. But perhaps even in this case it might be a good idea to
throw an error.


Greetings,
Daniel

From mblazevic at stilo.com  Tue Oct 21 14:55:15 2014
From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=)
Date: Tue, 21 Oct 2014 10:55:15 -0400
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
Message-ID: <544673D3.7030207@stilo.com>

On 14-10-21 07:14 AM, Erik Hesselink wrote:
> On Mon, Oct 20, 2014 at 11:57 PM, Mario Bla?evi? <mblazevic at stilo.com> wrote:
>> On 14-10-19 08:10 AM, Erik Hesselink wrote:
>>>
>>> Adding an explicit
>>> import can suddenly cause type errors in completely unrelated places
>>> (when it hides an implicit import and the new function is type
>>> incorrect), or worse, can cause semantic change (when it hides an
>>> implicit import and the new function is type correct, but has
>>> different behavior). Remember that not all code is written by the same
>>> person, or in a short time frame, so not everybody might fully
>>> understand every module and every import of the code they're editing.
>>
>>          Your example requires somebody actively editing the import list. A
>> code change causes a compile error or worse? That is not all that
>> surprising.
>
> But right now, we have a useful property that adding imports and code
> to a module does not break or change other code in that module. With
> this extension, that changes. I find this kind of local reasoning very
> useful, IMHO it's one of the most useful things about Haskell in
> general.

	Right now, adding an import can certainly cause a compiler error. It 
can't change the run-time behaviour of a correct module, that is true.

	With the proposal, there would be still be a somewhat weaker guarantee: 
adding an *implicit* import would never change the module's run-time 
behaviour.


>>          No, what I find much worse is a cabal update causing an error in a
>> module that was correct before the update. Consider
>>
>>> module Main where
>>>
>>> import Foo (foo)
>>> import Bar
>>>
>>> main = foo
>>
>>          Now suppose Bar came from the package bar-1.0, and the new version
>> bar-1.0.1 decides to export foo. With the current behaviour, this change
>> would break my module. With Malcolm's proposal the old code would continue
>> to work.
>
> That's a very good point. Given that and the above, I don't understand
> your conclusion:
>
>>          Anyway, count me as +1 on the proposal. It would improve the
>> long-term stability of Haskell code.
>
> How is adding more ways to break something "improving the long-term stability"?

	You seem determined to misunderstand every message in this thread. What 
I said was that the change from bar-1.0 to bar-1.0.1 breaks the example 
code *with the current behaviour*. The proposal removes this breakage. 
Anything that keeps the old code compiling and working with new 
libraries improves its long-term stability in my book.

	Note that the bar-1.0.1 upgrade wasn't even a major version change. 
This is correct according to the PVP:

> Otherwise, if only new bindings, types, classes, non-orphan instances
> or modules (but see below) were added to the interface, then A.B may
> remain the same but the new C must be greater than the old C.

but it still breaks the example module.

	Mind you, while the current proposal only increases the chances that 
old Haskell code continues to work with new libraries. If my module had 
defined a function foo itself instead of importing it, the upgrade would 
still break it. An extended version of the proposal might state that 
implicitly imported members get shadowed by local definitions as well, 
but this might be harder to implement. Besides, even this proposal 
wouldn't protect the importer from new instance imports from clashing 
with the local ones. There's no shadowing solution in this case.

	To summarize, the proposal is not providing any hard guarantees, and 
it's weakening an existing guarantee (see above). I'm still in favour, 
because it increases the stability of the legacy Haskell codebase.



From hesselink at gmail.com  Tue Oct 21 15:01:26 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 21 Oct 2014 17:01:26 +0200
Subject: Hiding import behaviour
In-Reply-To: <544673D3.7030207@stilo.com>
References: <CAOXMPx=H9kSiMSWvjiTA2=OkGn0jSxEB2pTWQ-rMZMDsDhFm7Q@mail.gmail.com>
 <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
Message-ID: <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>

On Tue, Oct 21, 2014 at 4:55 PM, Mario Bla?evi? <mblazevic at stilo.com> wrote:
> On 14-10-21 07:14 AM, Erik Hesselink wrote:
>>
>> On Mon, Oct 20, 2014 at 11:57 PM, Mario Bla?evi? <mblazevic at stilo.com>
>> wrote:
>>>          No, what I find much worse is a cabal update causing an error in
>>> a
>>> module that was correct before the update. Consider
>>>
>>>> module Main where
>>>>
>>>> import Foo (foo)
>>>> import Bar
>>>>
>>>> main = foo
>>>
>>>
>>>          Now suppose Bar came from the package bar-1.0, and the new
>>> version
>>> bar-1.0.1 decides to export foo. With the current behaviour, this change
>>> would break my module. With Malcolm's proposal the old code would
>>> continue
>>> to work.
>>
>>
>> That's a very good point. Given that and the above, I don't understand
>> your conclusion:
>>
>>>          Anyway, count me as +1 on the proposal. It would improve the
>>> long-term stability of Haskell code.
>>
>>
>> How is adding more ways to break something "improving the long-term
>> stability"?
>
>
>         You seem determined to misunderstand every message in this thread.
> What I said was that the change from bar-1.0 to bar-1.0.1 breaks the example
> code *with the current behaviour*. The proposal removes this breakage.
> Anything that keeps the old code compiling and working with new libraries
> improves its long-term stability in my book.
>
>         Note that the bar-1.0.1 upgrade wasn't even a major version change.
> This is correct according to the PVP:

You're right, I misread your message. I understand now, and you're
right that this is currently something that can break your package,
although it happens so rarely that people still depend on major
version ranges, even though they sometimes don't use explicit or
qualified imports.

Regards,

Erik

From gershomb at gmail.com  Tue Oct 21 15:46:49 2014
From: gershomb at gmail.com (Gershom B)
Date: Tue, 21 Oct 2014 11:46:49 -0400
Subject: GADTs in implementation of Template Haskell
In-Reply-To: <16077A03-605D-4BE3-85B6-57DC51C05CB7@cis.upenn.edu>
References: <16077A03-605D-4BE3-85B6-57DC51C05CB7@cis.upenn.edu>
Message-ID: <etPan.54467ff8.7fdcc233.2a47@mbp.local>

On October 20, 2014 at 2:35:27 PM, Richard Eisenberg (eir at cis.upenn.edu) wrote:
> Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback  
> on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs  
>  
> Is this a change for the better or worse? Feel free either to comment on the wiki page or  
> to this email.
>  
> Thanks!
> Richard

As I understand it, the big downsides are that we don?t get `gunfold` for Dec and Pragma, and we may not get `Generic` instances for them at all.

At first this felt pretty bad, but then I reviewed how generics and TH tend to get used together, and now I?m not _quite_ as anxious. In my mind the main use case for them is in things like this: http://www.well-typed.com/blog/2014/10/quasi-quoting-dsls/ ? skimming the code involved, and the way `dataToExpQ` and friends tend to work, the key bit is having the generic instances on what we?re inducting on, not what we?re building? By the time we hit concrete TH syntax, it feels a bit late to be doing further generic transformations on it, so I have a suspicion this won?t hit anyone. I certainly don?t think it?ll affect _my_ uses of TH at least :-)

Cheers,
Gershom

From adam at well-typed.com  Tue Oct 21 16:40:07 2014
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 21 Oct 2014 17:40:07 +0100
Subject: Type checker plugins
In-Reply-To: <CAGK9nur5Y7bhvdT=ZunJPXstyDqmSoFsPmrBwgndvUTQ15xzgA@mail.gmail.com>
References: <54132257.4070803@well-typed.com>	<CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>	<CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>	<CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>	<543FA4E8.7090609@well-typed.com>	<CAGK9nuqtKKWnELS2TmhydK2oLkRVmRz10-VuP+om5=Q0jj8_SQ@mail.gmail.com>
 <CAGK9nur5Y7bhvdT=ZunJPXstyDqmSoFsPmrBwgndvUTQ15xzgA@mail.gmail.com>
Message-ID: <54468C67.9090207@well-typed.com>

Thanks Iavor, this is really helpful!

If you have a moment to merge Simon's more recent changes on
wip/new-flatten-skolems-Aug14, I'm keen to try out the new
unflattening... or I can have a go at the merge if it would help?

You may be right that flattened constraints are easier to work with in
some cases, so it would be great if the plugin could choose which it
sees. Unfortunately I'm not sure we can easily unflatten *some*
constraints, given the way unflattening will work in the new
getInertUnsolved. One option might be for tcPluginSolve to be called in
both places, with a boolean parameter.

Cheers,

Adam


On 18/10/14 23:33, Iavor Diatchki wrote:
> Hello,
> 
> Just a heads up, if anyone is playing around with this:  I just updated
> the plugin interface a bit.
> 
> Here are the changes:
>    - A plugin now gets 3 sets of constraints: given, derived, and wanted
> (in that order)
>    - Plugins are now also presented with dictionary constraints (i.e.,
> you may see equalities, function equalities, and dictionaries)
>    - A plugin does not need to return all constraints that need to be
> put back in the inert set.  This is both simpler and more efficient, I
> think.  So, now a plugin can return one of these two results:
>       - All is good:  plugin returns some solved constraints, and some
> new constraints to be processed by the constraint solver. The solved
> constraints are removed from the inert set, and their evidence variables
> are defined.  The new work is added to the work list.
>       - Found contradiction: plugin returns a list of the conflicting
> constraint; these are removed from the inert set, and re-added as
> insoluable.
> 
> Happy hacking,
> -Iavor
> 
> 
> 
> 
> 
> 
> On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki
> <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> 
>     Hello,
> 
>     On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry <adam at well-typed.com
>     <mailto:adam at well-typed.com>> wrote:
> 
> 
> 
>         One problem I've run into is transforming the flattened
>         CFunEqCans into
>         unflattened form (so the flatten-skolems don't get in the way of
>         AG-unification). Do you know if there is an easy way to do this,
>         or do I
>         need to rebuild the tree manually in the plugin?
> 
> 
>     One thing that occurred to me about this:  when constraints are
>     "flattened",
>     it is easy for a plugin to pick-out only the one that it cares
>     about.  If things were fully
>     unflattened, this would not be the case... For example, if I have a
>     constraint:
> 
>     (2 + F a) ~ F a + F a
> 
>     In the flattened form, this will become:
>     (F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)
> 
>     So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3,
>     f2 ~ f3),
>     and ignore (F a ~ f1), as it knows nothing about arbitrary type
>     functions.
> 
>     So, if we want to do un-flattening, I think we should do it only on
>     those constraints
>     that are of interest to the plugin.
> 
>      
> 
> 
>         Also, I notice that you are providing only equality constraints
>         to the
>         plugin. Is there any reason we can't make other types of constraint
>         available as well? For example, one might want to introduce a
>         typeclass
>         with a special solution strategy (cf. Coercible, or the Has class in
>         OverloadedRecordFields).
> 
> 
>     Yeah, we should probably pass-in all constraints, inlcluding derived
>     ones.
>     The reason it is not like that is pretty much historical now.
>     So I'll have a go at making this change.
> 
>     -Iavor
> 
> 
> 
>      
> 
> 
> 
>         >   - As an example, I've extracted my work on using an SMT solver at the
>         > type level as a separate plugin:
>         >
>         >       https://github.com/yav/type-nat-solver
>         >
>         >    - To see how to invoke a module that uses a plugin, have a look in
>         > `examples/A.hs`.
>         >      (Currently, the plugin assumes that you have `cvc4` installed and
>         > available in the path).
>         >
>         >     - Besides this, we don't have much documentation yet.  For hackers:
>         > we tried to use `tcPlugin` on
>         >     `TcPlugin` in the names of all things plugin related, so you could
>         > grep for this.  The basic API
>         >      types and functions are defined in `TcRnTypes` and `TcRnMonad`.
>         >
>         > Happy hacking,
>         > -Iavor

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From goodingm at gmail.com  Tue Oct 21 16:45:05 2014
From: goodingm at gmail.com (htebalaka)
Date: Tue, 21 Oct 2014 09:45:05 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
References: <CAEs96n2Tja8=t2F702yrbfXU+n4-JoooiMtrvPVORwbp0smLmQ@mail.gmail.com>
 <5440C5FF.3020101@plaimi.net> <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
 <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
Message-ID: <1413909905533-5758451.post@n5.nabble.com>

The current situation could be summed up as requiring some code duplication
when explicitly importing (due to the possibility of one or more redundant
hides), while encouraging a sort of measure-twice-cut-once mentality. Not
suggesting changing the default; I'll have a proposal detailing the exact
semantics and possible consequences of using it on the wiki on Thursday, so
that more people can weigh in.


Erik Hesselink wrote
> On Tue, Oct 21, 2014 at 4:55 PM, Mario Bla?evi? &lt;

> mblazevic@

> &gt; wrote:
>> On 14-10-21 07:14 AM, Erik Hesselink wrote:
>>>
>>> On Mon, Oct 20, 2014 at 11:57 PM, Mario Bla?evi? &lt;

> mblazevic@

> &gt;
>>> wrote:
>>>>          No, what I find much worse is a cabal update causing an error
>>>> in
>>>> a
>>>> module that was correct before the update. Consider
>>>>
>>>>> module Main where
>>>>>
>>>>> import Foo (foo)
>>>>> import Bar
>>>>>
>>>>> main = foo
>>>>
>>>>
>>>>          Now suppose Bar came from the package bar-1.0, and the new
>>>> version
>>>> bar-1.0.1 decides to export foo. With the current behaviour, this
>>>> change
>>>> would break my module. With Malcolm's proposal the old code would
>>>> continue
>>>> to work.
>>>
>>>
>>> That's a very good point. Given that and the above, I don't understand
>>> your conclusion:
>>>
>>>>          Anyway, count me as +1 on the proposal. It would improve the
>>>> long-term stability of Haskell code.
>>>
>>>
>>> How is adding more ways to break something "improving the long-term
>>> stability"?
>>
>>
>>         You seem determined to misunderstand every message in this
>> thread.
>> What I said was that the change from bar-1.0 to bar-1.0.1 breaks the
>> example
>> code *with the current behaviour*. The proposal removes this breakage.
>> Anything that keeps the old code compiling and working with new libraries
>> improves its long-term stability in my book.
>>
>>         Note that the bar-1.0.1 upgrade wasn't even a major version
>> change.
>> This is correct according to the PVP:
> 
> You're right, I misread your message. I understand now, and you're
> right that this is currently something that can break your package,
> although it happens so rarely that people still depend on major
> version ranges, even though they sometimes don't use explicit or
> qualified imports.
> 
> Regards,
> 
> Erik
> _______________________________________________
> Glasgow-haskell-users mailing list

> Glasgow-haskell-users@

> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758451.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From goodingm at gmail.com  Tue Oct 21 21:30:37 2014
From: goodingm at gmail.com (htebalaka)
Date: Tue, 21 Oct 2014 14:30:37 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <1413909905533-5758451.post@n5.nabble.com>
References: <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
 <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
 <1413909905533-5758451.post@n5.nabble.com>
Message-ID: <1413927037441-5758463.post@n5.nabble.com>

It's occurred to me that a much simpler description of the proposed change
would be automatically lifting *uses* of the explicitly imported variable to
a qualified use, /if/ there was only one explicit import of the identifier.
For instance, with the following import:

import Data.Text.Lazy.IO (putStrLn)
import Prelude
import qualified Data.List as L
import qualified MyModule as L (isInfixOf)

automatically change any unqualified (and un-shadowed) use of putStrLn to
Data.Text.Lazy.IO.putStrLn, and any use of L.infixOf to MyModule.isInfixOf.

The latter should be easier to implement covering a number of corner cases:

* you can still refer to Prelude.putStrLn or Data.List.isInfixOf by
prepending the path, which the naive auto-hiding transformation would
prevent.
* possibly easier to have the pragma available to use in GHCi, since you
don't need to retroactively hide identifiers from previously imported
modules when a new explicit import is made.
* works better with imports like "import Data.Either (Either(..)); import
MyModule (Left)", which would otherwise require translating the Data.Either
import to something like "import Data.Either (Either(..)) hiding (Left)"
which isn't currently possible or "import Data.Either (Either(Right))" which
can't be done without knowing which modules export which identifiers.

The only remaining corner case is if you shadow the name of a module like:

import Data.Text.Lazy.IO (putStrLn)
import Prelude as Data.Text.Lazy.IO

An unqualified user of putStrLn /should/ refer to the text version, but if
anything translating it to Data.Text.Lazy.IO.putStrLn makes it more
ambiguous. I assume GHC can disambiguate even if the user can't, or if you
didn't want to cover that case the existing ambiguous identifier occurrence
error could still fire. Really just depends where in the pipeline the change
is implemented.

I suppose I'll describe both possible implementations. Functionally they're
the same, but maybe this one is simpler.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758463.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From qdunkan at gmail.com  Wed Oct 22 00:02:56 2014
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 21 Oct 2014 17:02:56 -0700
Subject: ghci balkiness on OS X?
Message-ID: <CACbaDy6JzCTJuZFrsUyLGo87v2FYegrn1YsOXOo+d9LVRXpuPA@mail.gmail.com>

On my OS X, if I load a couple hundred modules into ghci as bytecode,
text entry gets balky and laggy.  So e.g. if I hold down a key, the
letters will stream in but have frequent hiccups.  This seems to
adversely affect haskeline as well, such that, using vi mode,
sometimes ^[ to move to command mode will be lost, or it will
spontaneously go to insert mode, or ^[ followed by 'h' will be just
beep and remain in insert mode.  If I load most of the modules
compiled, this doesn't happen, or at least is not nearly so bad.

It doesn't seem to be due to background work by ghci or anything,
because it doesn't matter how long I wait after loading the modules.
My previous random guess was that increased memory use made the GC
work more, and my pauses were due to major collections.  But when I
try on linux, ghci remains responsive no matter how many modules I
load, so maybe it's an OS X only problem.

Do any other OS X users see this effect?

From merijn at inconsistent.nl  Wed Oct 22 01:27:18 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Tue, 21 Oct 2014 18:27:18 -0700
Subject: Hiding import behaviour
In-Reply-To: <1413927037441-5758463.post@n5.nabble.com>
References: <5440C5FF.3020101@plaimi.net>
 <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
 <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
 <1413909905533-5758451.post@n5.nabble.com>
 <1413927037441-5758463.post@n5.nabble.com>
Message-ID: <BACE21B5-C765-4AA1-BA87-21B5956FAE86@inconsistent.nl>

A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141021/b737a8fa/attachment.sig>

From gale at sefer.org  Wed Oct 22 10:48:06 2014
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 22 Oct 2014 13:48:06 +0300
Subject: GHC 7.4.2 on Ubuntu Trusty
Message-ID: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>

In order support some older software that we released, we need
to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have
GHC 7.8.3.

The binary tarball for GHC 7.4.2 does not install on Trusty due to
multiple incompatibilities. For example, GHC requires GMP 3, but
Trusty only provides GMP >= 4. Etc.

I tried building GHC 7.4.2. from source on Trusty. But the process
won't boot from our currently installed GHC 7.8.3. The oldest
GHC binary I can get is GHC 7.6.3, which happens to be
still available from the Ubuntu distribution itself (neither the binary
tarball nor compiling from source work for GHC 7.6.3 on Trusty
either). But booting from GHC 7.6.3 won't work either.

How do I get a working GHC 7.4.2 on Trusty?

Thanks,
Yitz

From ryan.trinkle at gmail.com  Wed Oct 22 11:20:08 2014
From: ryan.trinkle at gmail.com (Ryan Trinkle)
Date: Wed, 22 Oct 2014 07:20:08 -0400
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
Message-ID: <CAHNEpizc7+z0HVDHxaSp2vda7f0jGtw0eUMr7OSnML+Wr9S34w@mail.gmail.com>

Here's an off-the-wall solution idea: you could try the Nix package
manager.  It essentially sandboxes everything all the time, so you
shouldn't have any trouble with dependencies like this, and ghc 7.4.2 is
explicitly supported.  Of course, if your requirements include tight apt
integration, this won't help; but if you just need to get things running
reliably "somehow", I think Nix can handle it.

Feel free to message me off-list for more details.


Ryan

On Wed, Oct 22, 2014 at 6:48 AM, Yitzchak Gale <gale at sefer.org> wrote:

> In order support some older software that we released, we need
> to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have
> GHC 7.8.3.
>
> The binary tarball for GHC 7.4.2 does not install on Trusty due to
> multiple incompatibilities. For example, GHC requires GMP 3, but
> Trusty only provides GMP >= 4. Etc.
>
> I tried building GHC 7.4.2. from source on Trusty. But the process
> won't boot from our currently installed GHC 7.8.3. The oldest
> GHC binary I can get is GHC 7.6.3, which happens to be
> still available from the Ubuntu distribution itself (neither the binary
> tarball nor compiling from source work for GHC 7.6.3 on Trusty
> either). But booting from GHC 7.6.3 won't work either.
>
> How do I get a working GHC 7.4.2 on Trusty?
>
> Thanks,
> Yitz
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141022/5e44ed3c/attachment.html>

From shumovichy at gmail.com  Wed Oct 22 11:21:20 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Wed, 22 Oct 2014 14:21:20 +0300
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
Message-ID: <1413976880.2667.2.camel@gmail.com>

On Wed, 2014-10-22 at 13:48 +0300, Yitzchak Gale wrote:
> In order support some older software that we released, we need
> to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have
> GHC 7.8.3.
> 
> The binary tarball for GHC 7.4.2 does not install on Trusty due to
> multiple incompatibilities. For example, GHC requires GMP 3, but
> Trusty only provides GMP >= 4. Etc.

You can try to make a symlink from libgmp.so.10 to libgmp.so.3 AFAIK ghc
doesn't use anything specific to new gmp. Then you can recompile with
ghc from sources and link it with gmp10.

Also precise provides both gmp3 and gmp10, so you can bootstrap on
precise using 7.4.2/gmp3 to get 7.4.2/gmp10 binary.

> I tried building GHC 7.4.2. from source on Trusty. But the process
> won't boot from our currently installed GHC 7.8.3. The oldest
> GHC binary I can get is GHC 7.6.3, which happens to be
> still available from the Ubuntu distribution itself (neither the binary
> tarball nor compiling from source work for GHC 7.6.3 on Trusty
> either). But booting from GHC 7.6.3 won't work either.
> 
> How do I get a working GHC 7.4.2 on Trusty?
> 
> Thanks,
> Yitz
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



From gale at sefer.org  Wed Oct 22 12:50:18 2014
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 22 Oct 2014 15:50:18 +0300
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <20141022105441.GA14512@machine>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
 <20141022105441.GA14512@machine>
Message-ID: <CAOrUaLa5L0-LK-5S=m7Owt5PjrERmVVkNN8o+_UWiR=RGc8iKg@mail.gmail.com>

I wrote:
>> How do I get a working GHC 7.4.2 on Trusty?

Thanks to all for the suggestions.

Daniel Trstenjak wrote, off-list:
> I can only recommend: https://launchpad.net/~hvr/+archive/ubuntu/ghc

Thanks Daniel! I hadn't looked at Herbert's ppa for a while. Despite
the comments, which say it is only updated for precise but should
also work for trusty, the ppa actually *is* updated for trusty now.

This is trivially simple to use and worked great, so that's what I
ended up using.

But still - something really really needs to be done about GHC
portability. This thread makes it clear what a mess
we have inherited from the days when GHC was primarily a
research compiler. Let's face it - GHC is now also a serious
production compiler, and this urgently needs to be cleaned up.

Thanks,
Yitz

From iavor.diatchki at gmail.com  Thu Oct 23 02:31:26 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 22 Oct 2014 19:31:26 -0700
Subject: Type checker plugins
In-Reply-To: <54468C67.9090207@well-typed.com>
References: <54132257.4070803@well-typed.com>
 <CAGK9nurC=+jGrVqgVbvFivr=u90LA_88ZcuGGFtQ6cP1dSJT0g@mail.gmail.com>
 <CAHYVw0xPWktCrwi8Tr-womQxZe5kfV98MP76omev4DGjk5X+Cg@mail.gmail.com>
 <CAGK9nuoqsufGW1g8LFN4iZOOA-Bj2UDfD6eoewmCLa7v-t+Dgg@mail.gmail.com>
 <543FA4E8.7090609@well-typed.com>
 <CAGK9nuqtKKWnELS2TmhydK2oLkRVmRz10-VuP+om5=Q0jj8_SQ@mail.gmail.com>
 <CAGK9nur5Y7bhvdT=ZunJPXstyDqmSoFsPmrBwgndvUTQ15xzgA@mail.gmail.com>
 <54468C67.9090207@well-typed.com>
Message-ID: <CAGK9nup2bEa-bPrDN3z55su+VhYxLskd-uUuUgk+OJcn310PqQ@mail.gmail.com>

Hi,

It shouldn't be hard to do the merge, but I am not sure that I'll have time
to do it before the weekend---I'll give it a go then.

-Iavor

On Tue, Oct 21, 2014 at 9:40 AM, Adam Gundry <adam at well-typed.com> wrote:

> Thanks Iavor, this is really helpful!
>
> If you have a moment to merge Simon's more recent changes on
> wip/new-flatten-skolems-Aug14, I'm keen to try out the new
> unflattening... or I can have a go at the merge if it would help?
>
> You may be right that flattened constraints are easier to work with in
> some cases, so it would be great if the plugin could choose which it
> sees. Unfortunately I'm not sure we can easily unflatten *some*
> constraints, given the way unflattening will work in the new
> getInertUnsolved. One option might be for tcPluginSolve to be called in
> both places, with a boolean parameter.
>
> Cheers,
>
> Adam
>
>
> On 18/10/14 23:33, Iavor Diatchki wrote:
> > Hello,
> >
> > Just a heads up, if anyone is playing around with this:  I just updated
> > the plugin interface a bit.
> >
> > Here are the changes:
> >    - A plugin now gets 3 sets of constraints: given, derived, and wanted
> > (in that order)
> >    - Plugins are now also presented with dictionary constraints (i.e.,
> > you may see equalities, function equalities, and dictionaries)
> >    - A plugin does not need to return all constraints that need to be
> > put back in the inert set.  This is both simpler and more efficient, I
> > think.  So, now a plugin can return one of these two results:
> >       - All is good:  plugin returns some solved constraints, and some
> > new constraints to be processed by the constraint solver. The solved
> > constraints are removed from the inert set, and their evidence variables
> > are defined.  The new work is added to the work list.
> >       - Found contradiction: plugin returns a list of the conflicting
> > constraint; these are removed from the inert set, and re-added as
> > insoluable.
> >
> > Happy hacking,
> > -Iavor
> >
> >
> >
> >
> >
> >
> > On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki
> > <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> >
> >     Hello,
> >
> >     On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry <adam at well-typed.com
> >     <mailto:adam at well-typed.com>> wrote:
> >
> >
> >
> >         One problem I've run into is transforming the flattened
> >         CFunEqCans into
> >         unflattened form (so the flatten-skolems don't get in the way of
> >         AG-unification). Do you know if there is an easy way to do this,
> >         or do I
> >         need to rebuild the tree manually in the plugin?
> >
> >
> >     One thing that occurred to me about this:  when constraints are
> >     "flattened",
> >     it is easy for a plugin to pick-out only the one that it cares
> >     about.  If things were fully
> >     unflattened, this would not be the case... For example, if I have a
> >     constraint:
> >
> >     (2 + F a) ~ F a + F a
> >
> >     In the flattened form, this will become:
> >     (F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)
> >
> >     So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3,
> >     f2 ~ f3),
> >     and ignore (F a ~ f1), as it knows nothing about arbitrary type
> >     functions.
> >
> >     So, if we want to do un-flattening, I think we should do it only on
> >     those constraints
> >     that are of interest to the plugin.
> >
> >
> >
> >
> >         Also, I notice that you are providing only equality constraints
> >         to the
> >         plugin. Is there any reason we can't make other types of
> constraint
> >         available as well? For example, one might want to introduce a
> >         typeclass
> >         with a special solution strategy (cf. Coercible, or the Has
> class in
> >         OverloadedRecordFields).
> >
> >
> >     Yeah, we should probably pass-in all constraints, inlcluding derived
> >     ones.
> >     The reason it is not like that is pretty much historical now.
> >     So I'll have a go at making this change.
> >
> >     -Iavor
> >
> >
> >
> >
> >
> >
> >
> >         >   - As an example, I've extracted my work on using an SMT
> solver at the
> >         > type level as a separate plugin:
> >         >
> >         >       https://github.com/yav/type-nat-solver
> >         >
> >         >    - To see how to invoke a module that uses a plugin, have a
> look in
> >         > `examples/A.hs`.
> >         >      (Currently, the plugin assumes that you have `cvc4`
> installed and
> >         > available in the path).
> >         >
> >         >     - Besides this, we don't have much documentation yet.  For
> hackers:
> >         > we tried to use `tcPlugin` on
> >         >     `TcPlugin` in the names of all things plugin related, so
> you could
> >         > grep for this.  The basic API
> >         >      types and functions are defined in `TcRnTypes` and
> `TcRnMonad`.
> >         >
> >         > Happy hacking,
> >         > -Iavor
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141022/3e8d7af0/attachment.html>

From goodingm at gmail.com  Thu Oct 23 18:22:13 2014
From: goodingm at gmail.com (htebalaka)
Date: Thu, 23 Oct 2014 11:22:13 -0700 (PDT)
Subject: Hiding import behaviour
In-Reply-To: <1413927037441-5758463.post@n5.nabble.com>
References: <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
 <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
 <1413909905533-5758451.post@n5.nabble.com>
 <1413927037441-5758463.post@n5.nabble.com>
Message-ID: <1414088533486-5758553.post@n5.nabble.com>

Proposal is up for your viewing pleasure:
http://www.haskell.org/haskellwiki/PermissiveImportsProposal



--
View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758553.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From judah.jacobson at gmail.com  Fri Oct 24 05:37:39 2014
From: judah.jacobson at gmail.com (Judah Jacobson)
Date: Thu, 23 Oct 2014 22:37:39 -0700
Subject: ghci balkiness on OS X?
In-Reply-To: <CACbaDy6JzCTJuZFrsUyLGo87v2FYegrn1YsOXOo+d9LVRXpuPA@mail.gmail.com>
References: <CACbaDy6JzCTJuZFrsUyLGo87v2FYegrn1YsOXOo+d9LVRXpuPA@mail.gmail.com>
Message-ID: <CAF==i1_RJ4Hx7hy4Xc=td22vqn-3swkNMvXp9=wL0c969Viczw@mail.gmail.com>

I haven't seen this before myself (running on OS X), though in the past we
had a report of slowdown in long-running ghci sessions which was hard to
reproduce.  What versions of GHC and OS X are you using?

Do you know if this is a problem with text entry in general or only
haskeline?  If you run the command

:m +System.IO Control.Exception Control.Monad
(hSetBuffering stdin NoBuffering >> hSetEcho stdin False >> forever
(getChar >>= \c -> putStr ['{',c,'}'])) `finally` (hSetEcho stdin True >>
hSetBuffering stdin LineBuffering)

and hold down the 'a' key, does it smoothly output "{a}{a}{a}..." or does
it have similar hiccups?

-Judah



On Tue, Oct 21, 2014 at 5:02 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On my OS X, if I load a couple hundred modules into ghci as bytecode,
> text entry gets balky and laggy.  So e.g. if I hold down a key, the
> letters will stream in but have frequent hiccups.  This seems to
> adversely affect haskeline as well, such that, using vi mode,
> sometimes ^[ to move to command mode will be lost, or it will
> spontaneously go to insert mode, or ^[ followed by 'h' will be just
> beep and remain in insert mode.  If I load most of the modules
> compiled, this doesn't happen, or at least is not nearly so bad.
>
> It doesn't seem to be due to background work by ghci or anything,
> because it doesn't matter how long I wait after loading the modules.
> My previous random guess was that increased memory use made the GC
> work more, and my pauses were due to major collections.  But when I
> try on linux, ghci remains responsive no matter how many modules I
> load, so maybe it's an OS X only problem.
>
> Do any other OS X users see this effect?
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141023/96906bc0/attachment.html>

From eir at cis.upenn.edu  Fri Oct 24 13:40:03 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 24 Oct 2014 09:40:03 -0400
Subject: Hiding import behaviour
In-Reply-To: <1414088533486-5758553.post@n5.nabble.com>
References: <1413655348523-5758246.post@n5.nabble.com>
 <1413671982.2318.5.camel@joachim-breitner.de>
 <CAMgWh9vhqF0=Y4=06-ZHg-fTuVL8=mQMwPHoENsuAwC=y-ayMA@mail.gmail.com>
 <CAPeieQHJrsUQU5CVaC2zFnnsjPshWLfrVVW-kEoDjhYdysTsXw@mail.gmail.com>
 <5445854A.7060409@stilo.com>
 <CAPeieQFajS6ks3TEaRq8KswY9mE--hXUJshptvNPS8cByHQ+YA@mail.gmail.com>
 <544673D3.7030207@stilo.com>
 <CAPeieQFJ4Yi2c+4T-_iTJBVu24Jb0gm+NOGecG2drMavYD4RPA@mail.gmail.com>
 <1413909905533-5758451.post@n5.nabble.com>
 <1413927037441-5758463.post@n5.nabble.com>
 <1414088533486-5758553.post@n5.nabble.com>
Message-ID: <D4D49FA5-0343-426F-87C1-17932493ED29@cis.upenn.edu>

Thanks for writing this up so clearly.

I'm +1 on the proposal as written. I think the (smallish) drawbacks are mitigated by the fact that the whole feature is opt-in.

Implementation should be relatively straightforward.

Thanks,
Richard

On Oct 23, 2014, at 2:22 PM, htebalaka <goodingm at gmail.com> wrote:

> Proposal is up for your viewing pleasure:
> http://www.haskell.org/haskellwiki/PermissiveImportsProposal
> 
> 
> 
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/Hiding-import-behaviour-tp5758155p5758553.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From hallgren at chalmers.se  Fri Oct 24 14:23:58 2014
From: hallgren at chalmers.se (Thomas Hallgren)
Date: Fri, 24 Oct 2014 16:23:58 +0200
Subject: ghci balkiness on OS X?
In-Reply-To: <CAF==i1_RJ4Hx7hy4Xc=td22vqn-3swkNMvXp9=wL0c969Viczw@mail.gmail.com>
References: <CACbaDy6JzCTJuZFrsUyLGo87v2FYegrn1YsOXOo+d9LVRXpuPA@mail.gmail.com>
 <CAF==i1_RJ4Hx7hy4Xc=td22vqn-3swkNMvXp9=wL0c969Viczw@mail.gmail.com>
Message-ID: <m2dndv$i1s$1@ger.gmane.org>

I have noticed sluggish behaviour in ghci (ghc-7.8.3, OS X 10.9.5). In my case
at least, it seems to be caused by the idle time full garbage collection that
happens after 0.3s of idle time by default.

When you have say 300MB of live data in the heap, a major GC can take 0.5s or
so, and this is very noticeable when it happens as soon as there is more than a
0.3s pause between key strokes.

Foruntately, the idle time GC can be turned off by running ghci +RTS -I0, and
when I do that the problem goes away. Alternatively, using a longer timeout
(e.g. -I2) is enough to prevent the major GCs from happening while you are
typing, so it also helps a lot.

Thomas H


On 2014-10-24 07:37, Judah Jacobson wrote:
> I haven't seen this before myself (running on OS X), though in the past we had a
> report of slowdown in long-running ghci sessions which was hard to reproduce. 
> What versions of GHC and OS X are you using?
> 
> Do you know if this is a problem with text entry in general or only haskeline? 
> If you run the command
> 
> :m +System.IO Control.Exception Control.Monad
> (hSetBuffering stdin NoBuffering >> hSetEcho stdin False >> forever (getChar >>=
> \c -> putStr ['{',c,'}'])) `finally` (hSetEcho stdin True >> hSetBuffering stdin
> LineBuffering)
> 
> and hold down the 'a' key, does it smoothly output "{a}{a}{a}..." or does it
> have similar hiccups?
> 
> -Judah
> 
> 
> 
> On Tue, Oct 21, 2014 at 5:02 PM, Evan Laforge <qdunkan at gmail.com
> <mailto:qdunkan at gmail.com>> wrote:
> 
>     On my OS X, if I load a couple hundred modules into ghci as bytecode,
>     text entry gets balky and laggy.  So e.g. if I hold down a key, the
>     letters will stream in but have frequent hiccups.  This seems to
>     adversely affect haskeline as well, such that, using vi mode,
>     sometimes ^[ to move to command mode will be lost, or it will
>     spontaneously go to insert mode, or ^[ followed by 'h' will be just
>     beep and remain in insert mode.  If I load most of the modules
>     compiled, this doesn't happen, or at least is not nearly so bad.
> 
>     It doesn't seem to be due to background work by ghci or anything,
>     because it doesn't matter how long I wait after loading the modules.
>     My previous random guess was that increased memory use made the GC
>     work more, and my pauses were due to major collections.  But when I
>     try on linux, ghci remains responsive no matter how many modules I
>     load, so maybe it's an OS X only problem.
> 
>     Do any other OS X users see this effect?
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.org <mailto:Glasgow-haskell-users at haskell.org>
>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 



From qdunkan at gmail.com  Sat Oct 25 00:44:40 2014
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 24 Oct 2014 17:44:40 -0700
Subject: ghci balkiness on OS X?
In-Reply-To: <m2dndv$i1s$1@ger.gmane.org>
References: <CACbaDy6JzCTJuZFrsUyLGo87v2FYegrn1YsOXOo+d9LVRXpuPA@mail.gmail.com>
 <CAF==i1_RJ4Hx7hy4Xc=td22vqn-3swkNMvXp9=wL0c969Viczw@mail.gmail.com>
 <m2dndv$i1s$1@ger.gmane.org>
Message-ID: <CACbaDy5H7MTF6Lmksp2PYut7xrpjWD0p6DW=aExBwzUNDSW8uQ@mail.gmail.com>

On Fri, Oct 24, 2014 at 7:23 AM, Thomas Hallgren <hallgren at chalmers.se> wrote:
> Foruntately, the idle time GC can be turned off by running ghci +RTS -I0, and
> when I do that the problem goes away. Alternatively, using a longer timeout
> (e.g. -I2) is enough to prevent the major GCs from happening while you are
> typing, so it also helps a lot.

Aha, +RTS -I0 does the trick!  I'll bet it messes up haskeline because
the sudden delays cause it to time out between keystrokes.  But with
that flag, it stays responsive no matter how many modules I have
loaded.  Thanks.

I wonder why I can only get this to happen on OS X?  Maybe the linux
machine just has faster memory and can get through the GC quicker?
Anyway, I wonder if disabling idle GC would make sense for ghci in
general?  ghci, unlike a normal program, is unlikely to be doing
background work while its waiting on the prompt, so there is no new
garbage for the GC to detect.  Also, input latency is very noticeable,
though I suppose that goes for all interactive programs.  In fact I'm
tempted to try this on my interactive program.

On Thu, Oct 23, 2014 at 10:37 PM, Judah Jacobson
<judah.jacobson at gmail.com> wrote:
> and hold down the 'a' key, does it smoothly output "{a}{a}{a}..." or does it
> have similar hiccups?

I get hiccups, though they're usually after I pause for a bit.  This
is consistent with the "idle GC" theory, so I think that was probably
the problem.

From b.hilken at ntlworld.com  Sat Oct 25 13:53:19 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Sat, 25 Oct 2014 14:53:19 +0100
Subject: Recursion on TypeNats
Message-ID: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>

If you define your own type level naturals by promoting

data Nat = Z | S Nat

you can define data families recursively, for example

data family Power :: Nat -> * -> *
data instance Power Z a = PowerZ
data instance Power (S n) a = PowerS a (Power n a)

But if you use the built-in type level Nat, I can find no way to do the same thing. You can define a closed type family

type family Power (n :: Nat) a where
	Power 0 a = ()
	Power n a = (a, Power (n-1) a)

but this isn't the same thing (and requires UndecidableInstances).

Have I missed something? The user guide page is pretty sparse, and not up to date anyway.

If not, are there plans to add a "Successor" constructor to Nat? I would have thought this was the main point of using Nat rather than Int.

Barney.


From carter.schonwald at gmail.com  Sat Oct 25 17:37:04 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 25 Oct 2014 13:37:04 -0400
Subject: Recursion on TypeNats
In-Reply-To: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
Message-ID: <CAHYVw0wfNzudoDBGkmEq9r9j=eik7Xq6CRb0WGfYw3wRPcad-Q@mail.gmail.com>

you want the following (which doesnt require undediable instances)

data Nat = Z | S Nat

type family U (x :: Nat) where
  U  0 = Z
  U n = S (U (n-1))

this lets you convert type lits into your own peanos or whatever

hat tip to richard eisenburg for showing me this trick on the mailing list
a while ago


On Sat, Oct 25, 2014 at 9:53 AM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> If you define your own type level naturals by promoting
>
> data Nat = Z | S Nat
>
> you can define data families recursively, for example
>
> data family Power :: Nat -> * -> *
> data instance Power Z a = PowerZ
> data instance Power (S n) a = PowerS a (Power n a)
>
> But if you use the built-in type level Nat, I can find no way to do the
> same thing. You can define a closed type family
>
> type family Power (n :: Nat) a where
>         Power 0 a = ()
>         Power n a = (a, Power (n-1) a)
>
> but this isn't the same thing (and requires UndecidableInstances).
>
> Have I missed something? The user guide page is pretty sparse, and not up
> to date anyway.
>
> If not, are there plans to add a "Successor" constructor to Nat? I would
> have thought this was the main point of using Nat rather than Int.
>
> Barney.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141025/73fec7d0/attachment.html>

From carter.schonwald at gmail.com  Sat Oct 25 18:20:41 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 25 Oct 2014 11:20:41 -0700 (PDT)
Subject: Recursion on TypeNats
In-Reply-To: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
Message-ID: <1414261240986.7e659701@Nodemailer>

because you haven't helped write a patch change it yet :)?


-Carter

On Sat, Oct 25, 2014 at 9:53 AM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> If you define your own type level naturals by promoting
> data Nat = Z | S Nat
> you can define data families recursively, for example
> data family Power :: Nat -> * -> *
> data instance Power Z a = PowerZ
> data instance Power (S n) a = PowerS a (Power n a)
> But if you use the built-in type level Nat, I can find no way to do the same thing. You can define a closed type family
> type family Power (n :: Nat) a where
> 	Power 0 a = ()
> 	Power n a = (a, Power (n-1) a)
> but this isn't the same thing (and requires UndecidableInstances).
> Have I missed something? The user guide page is pretty sparse, and not up to date anyway.
> If not, are there plans to add a "Successor" constructor to Nat? I would have thought this was the main point of using Nat rather than Int.
> Barney.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141025/df1b7aab/attachment.html>

From b.hilken at ntlworld.com  Sat Oct 25 18:22:35 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Sat, 25 Oct 2014 19:22:35 +0100
Subject: Recursion on TypeNats
In-Reply-To: <CAHYVw0wfNzudoDBGkmEq9r9j=eik7Xq6CRb0WGfYw3wRPcad-Q@mail.gmail.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <CAHYVw0wfNzudoDBGkmEq9r9j=eik7Xq6CRb0WGfYw3wRPcad-Q@mail.gmail.com>
Message-ID: <22EF8D96-A8AF-490A-B32D-4944661E69CE@ntlworld.com>

> you want the following (which doesnt require undediable instances)
> 
> data Nat = Z | S Nat
> 
> type family U (x :: Nat) where 
>  U  0 = Z
>  U n = S (U (n-1))
> 
> this lets you convert type lits into your own peanos or whatever

Yes, you can do that, but why should you have to? Nat is already the natural numbers, so already has this structure. Why do we have to define it again, making our code that much less clear and readable?


From b.hilken at ntlworld.com  Sat Oct 25 18:33:06 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Sat, 25 Oct 2014 19:33:06 +0100
Subject: Recursion on TypeNats
In-Reply-To: <1414261240986.7e659701@Nodemailer>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <1414261240986.7e659701@Nodemailer>
Message-ID: <DA91938D-027B-4773-9801-112231BBAF9A@ntlworld.com>

> 
> because you haven't helped write a patch change it yet :) 
> 
> -Carter
> 

Would this be possible with the new type checker plugins? 

btw, your example gives me

    Nested type family application
      in the type family application: U (n - 1)
    (Use UndecidableInstances to permit this)
    In the equations for closed type family ?U?
    In the type family declaration for ?U?
Failed, modules loaded: none.


From carter.schonwald at gmail.com  Sun Oct 26 04:16:39 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 26 Oct 2014 00:16:39 -0400
Subject: Recursion on TypeNats
In-Reply-To: <DA91938D-027B-4773-9801-112231BBAF9A@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <1414261240986.7e659701@Nodemailer>
 <DA91938D-027B-4773-9801-112231BBAF9A@ntlworld.com>
Message-ID: <CAHYVw0xMC2kghVJP_ypJmWDp7f4yheD=UacVTy_J4WmeOr_CYQ@mail.gmail.com>

derp, my bad
https://github.com/wellposed/numerical/blob/master/src/Numerical/Nat.hs has
a fuller implementation of this though, that i've been using for a few
months

as for the plugin question, i think about adding constraint solves to the
type system... so i dont know if thats quite what you want though,

On Sat, Oct 25, 2014 at 2:33 PM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> >
> > because you haven't helped write a patch change it yet :)
> >
> > -Carter
> >
>
> Would this be possible with the new type checker plugins?
>
> btw, your example gives me
>
>     Nested type family application
>       in the type family application: U (n - 1)
>     (Use UndecidableInstances to permit this)
>     In the equations for closed type family ?U?
>     In the type family declaration for ?U?
> Failed, modules loaded: none.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141026/d0e096ab/attachment.html>

From amindfv at gmail.com  Sun Oct 26 19:28:41 2014
From: amindfv at gmail.com (Tom Murphy)
Date: Sun, 26 Oct 2014 12:28:41 -0700
Subject: Hiding module *exports*
Message-ID: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>

(Not to be confused with the "hiding import behavior" discussion also going
on)

--

Currently, I'm able to write "module Foo where" to export everything
defined in Foo.

If, though, I add to the module some definitions which I don't want to
export...

    data Lockbox = MkLockbox Int

    internalFunction = ...

...I then have to explicitly enumerate everything that I *do* want the
module to export, and add to that list each time I add to the module.

I propose that instead, we're able to simply say what we mean:

    module Foo hiding (Lockbox(MkLockbox), internalFunction) where

I think its semantics are immediately clear to the reader.

There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
(Foo(..))" sufficient to hide the type Foo and not just its constructors),
but are people +1 on this? I've frequently wanted this behavior.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141026/b443c93a/attachment.html>

From merijn at inconsistent.nl  Sun Oct 26 22:13:09 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sun, 26 Oct 2014 15:13:09 -0700
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <2D3F14D5-5A56-4C2E-9420-7077FF552746@inconsistent.nl>

Strong +1 from me, this is *especially* annoying when you want to selectively re-export parts of a module from somewhere or in case of exports generated by TH.

Cheers,
Merijn

> On 26 Oct 2014, at 12:28, Tom Murphy <amindfv at gmail.com> wrote:
> 
> (Not to be confused with the "hiding import behavior" discussion also going on)
> 
> --
> 
> Currently, I'm able to write "module Foo where" to export everything defined in Foo.
> 
> If, though, I add to the module some definitions which I don't want to export...
> 
>     data Lockbox = MkLockbox Int
> 
>     internalFunction = ...
> 
> ...I then have to explicitly enumerate everything that I *do* want the module to export, and add to that list each time I add to the module.
> 
> I propose that instead, we're able to simply say what we mean:
> 
>     module Foo hiding (Lockbox(MkLockbox), internalFunction) where
> 
> I think its semantics are immediately clear to the reader.
> 
> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo(..))" sufficient to hide the type Foo and not just its constructors), but are people +1 on this? I've frequently wanted this behavior.
> 
> Tom
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From alexander at plaimi.net  Mon Oct 27 08:15:43 2014
From: alexander at plaimi.net (Alexander Berntsen)
Date: Mon, 27 Oct 2014 09:15:43 +0100
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <544DFF2F.60106@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I like symmetry. +1 from me.

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRN/y8ACgkQRtClrXBQc7WR4AD/f6AXDZyAMk/oyn2SaVDigPr7
Xi/psgHQ+aoNKENSJLEA/13bfUPgW9sAaDNy+PwQ5QQb4PPcDE8NK/sVe3DVRXFJ
=nXtH
-----END PGP SIGNATURE-----

From hvr at gnu.org  Mon Oct 27 11:37:43 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 27 Oct 2014 12:37:43 +0100
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
 (Tom Murphy's message of "Sun, 26 Oct 2014 12:28:41 -0700")
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <87d29du4jc.fsf@gnu.org>

On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:

[...]

> I propose that instead, we're able to simply say what we mean:
>
>     module Foo hiding (Lockbox(MkLockbox), internalFunction) where
>
> I think its semantics are immediately clear to the reader.
>
> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
> (Foo(..))" sufficient to hide the type Foo and not just its constructors),
> but are people +1 on this? I've frequently wanted this behavior.

I'm generally +1 on this, and I even suggested that one myself some time
ago:

  http://www.haskell.org/pipermail/haskell-prime/2014-January/003910.html


Cheers,
  hvr

From alois.cochard at gmail.com  Mon Oct 27 11:39:06 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Mon, 27 Oct 2014 11:39:06 +0000
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <CAJHA+wrnOQsc4mrhybnPsrajdvxSob_0SjMi8oiJdoP6Sh4Dzg@mail.gmail.com>

+1 from me

I was looking for the feature a few times.

On 26 October 2014 19:28, Tom Murphy <amindfv at gmail.com> wrote:

> (Not to be confused with the "hiding import behavior" discussion also
> going on)
>
> --
>
> Currently, I'm able to write "module Foo where" to export everything
> defined in Foo.
>
> If, though, I add to the module some definitions which I don't want to
> export...
>
>     data Lockbox = MkLockbox Int
>
>     internalFunction = ...
>
> ...I then have to explicitly enumerate everything that I *do* want the
> module to export, and add to that list each time I add to the module.
>
> I propose that instead, we're able to simply say what we mean:
>
>     module Foo hiding (Lockbox(MkLockbox), internalFunction) where
>
> I think its semantics are immediately clear to the reader.
>
> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
> (Foo(..))" sufficient to hide the type Foo and not just its constructors),
> but are people +1 on this? I've frequently wanted this behavior.
>
> Tom
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141027/066502ad/attachment.html>

From hvr at gnu.org  Mon Oct 27 11:42:07 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 27 Oct 2014 12:42:07 +0100
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
 (Tom Murphy's message of "Sun, 26 Oct 2014 12:28:41 -0700")
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <878uk1u4c0.fsf@gnu.org>

On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:

[...]

>     module Foo hiding (Lockbox(MkLockbox), internalFunction) where
>
> I think its semantics are immediately clear to the reader.
>
> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
> (Foo(..))" sufficient to hide the type Foo and not just its constructors),
> but are people +1 on this? I've frequently wanted this behavior.

PS: As for semantics, I'd suggest to have

  module Foo hiding (Lockbox(MkLockbox), internalFunction) where

the same effect moving the definitions of `Foo` into an hidden/internal
module `_Foo` and having `Foo` re-export it in the following way:

  module Foo (module _Foo) where
  import _Foo hiding (Lockbox(MkLockbox), internalFunction)

that should result the least surprise IMHO

Cheers,
  hvr

From daniel.trstenjak at gmail.com  Mon Oct 27 13:41:14 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 27 Oct 2014 14:41:14 +0100
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <20141027134114.GA17163@machine>


Hi Tom,

+1

> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo
> (..))" sufficient to hide the type Foo and not just its constructors), but are
> people +1 on this? I've frequently wanted this behavior.

I would be surprised if 'Foo(..)' would mean in this case something
different, so yes, the type Foo should be hidden too.


Greetings,
Daniel

From hesselink at gmail.com  Mon Oct 27 13:57:17 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 27 Oct 2014 14:57:17 +0100
Subject: Hiding module *exports*
In-Reply-To: <20141027134114.GA17163@machine>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
 <20141027134114.GA17163@machine>
Message-ID: <CAPeieQHWF6jMCam6ZjaO23dNu1uBBcAhTgfwCUA3VWG9uavbOg@mail.gmail.com>

On Mon, Oct 27, 2014 at 2:41 PM, Daniel Trstenjak
<daniel.trstenjak at gmail.com> wrote:
>> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo
>> (..))" sufficient to hide the type Foo and not just its constructors), but are
>> people +1 on this? I've frequently wanted this behavior.
>
> I would be surprised if 'Foo(..)' would mean in this case something
> different, so yes, the type Foo should be hidden too.

One related question: how would you export only the type if you have

    newtype Foo = Foo ...

which is a pretty common pattern? Since "hiding (Foo(Foo))" would also
hide the type, I don't see many options, which is unfortunate.

In general, I'm +1 on the proposal.

Erik

From amindfv at gmail.com  Mon Oct 27 13:55:13 2014
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 27 Oct 2014 09:55:13 -0400
Subject: Hiding module *exports*
In-Reply-To: <878uk1u4c0.fsf@gnu.org>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
 <878uk1u4c0.fsf@gnu.org>
Message-ID: <05FDF872-D33C-4CBA-85BC-915E80DA0E3E@gmail.com>

El Oct 27, 2014, a las 7:42, Herbert Valerio Riedel <hvr at gnu.org> escribi?:

> On 2014-10-26 at 20:28:41 +0100, Tom Murphy wrote:
> 
> [...]
> 
>>    module Foo hiding (Lockbox(MkLockbox), internalFunction) where
>> 
>> I think its semantics are immediately clear to the reader.
>> 
>> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
>> (Foo(..))" sufficient to hide the type Foo and not just its constructors),
>> but are people +1 on this? I've frequently wanted this behavior.
> 
> PS: As for semantics, I'd suggest to have
> 
>  module Foo hiding (Lockbox(MkLockbox), internalFunction) where
> 
> the same effect moving the definitions of `Foo` into an hidden/internal
> module `_Foo` and having `Foo` re-export it in the following way:
> 
>  module Foo (module _Foo) where
>  import _Foo hiding (Lockbox(MkLockbox), internalFunction)
> 
> that should result the least surprise IMHO
> 

Right -- hiding a type necessarily hides its constructors (and importing a constructor necessarily imports its type), which actually implies an obvious semantics. So there's less to bikeshed than I had thought.

Tom

From eir at cis.upenn.edu  Mon Oct 27 14:09:48 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 27 Oct 2014 10:09:48 -0400
Subject: Recursion on TypeNats
In-Reply-To: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
Message-ID: <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>

No, there's not another way to do this with built-in Nats, and there probably won't ever be.

There are two advantages to the built-in Nats over hand-rolled ones: 1) Better syntax / error messages. 2) Built-in Nats are much more efficient than hand-rolled ones, because the hand-rolled ones are unary and take up space linear in the value of the number. If you re-hash your proposal for a Successor constructor down to the term level, it looks juts like (n+k)-patterns, which were discarded as a bad idea.

The reason that the type-level numbers are natural numbers and not integers is because natural numbers have a simpler theory to solve for. I'm personally hoping for proper type-level integers at some point, and the type-checker plugins approach may make that a reality sooner than later.

I hope this helps!

Richard

On Oct 25, 2014, at 9:53 AM, Barney Hilken <b.hilken at ntlworld.com> wrote:

> If you define your own type level naturals by promoting
> 
> data Nat = Z | S Nat
> 
> you can define data families recursively, for example
> 
> data family Power :: Nat -> * -> *
> data instance Power Z a = PowerZ
> data instance Power (S n) a = PowerS a (Power n a)
> 
> But if you use the built-in type level Nat, I can find no way to do the same thing. You can define a closed type family
> 
> type family Power (n :: Nat) a where
> 	Power 0 a = ()
> 	Power n a = (a, Power (n-1) a)
> 
> but this isn't the same thing (and requires UndecidableInstances).
> 
> Have I missed something? The user guide page is pretty sparse, and not up to date anyway.
> 
> If not, are there plans to add a "Successor" constructor to Nat? I would have thought this was the main point of using Nat rather than Int.
> 
> Barney.
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From amindfv at gmail.com  Mon Oct 27 14:15:28 2014
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 27 Oct 2014 10:15:28 -0400
Subject: Hiding module *exports*
In-Reply-To: <CAPeieQHWF6jMCam6ZjaO23dNu1uBBcAhTgfwCUA3VWG9uavbOg@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
 <20141027134114.GA17163@machine>
 <CAPeieQHWF6jMCam6ZjaO23dNu1uBBcAhTgfwCUA3VWG9uavbOg@mail.gmail.com>
Message-ID: <A6E3024C-4C9E-4097-B07F-C8E876C9A7FE@gmail.com>

El Oct 27, 2014, a las 9:57, Erik Hesselink <hesselink at gmail.com> escribi?:

> On Mon, Oct 27, 2014 at 2:41 PM, Daniel Trstenjak
> <daniel.trstenjak at gmail.com> wrote:
>>> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo
>>> (..))" sufficient to hide the type Foo and not just its constructors), but are
>>> people +1 on this? I've frequently wanted this behavior.
>> 
>> I would be surprised if 'Foo(..)' would mean in this case something
>> different, so yes, the type Foo should be hidden too.
> 
> One related question: how would you export only the type if you have
> 
>    newtype Foo = Foo ...
> 
> which is a pretty common pattern? Since "hiding (Foo(Foo))" would also
> hide the type, I don't see many options, which is unfortunate.
> 
> In general, I'm +1 on the proposal.
> 

I'd say "hiding (Foo)" hides the type and constructor; "hiding (Foo(Foo))" hides only the constructor.

Tom


> Erik
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From b.hilken at ntlworld.com  Mon Oct 27 14:39:44 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Mon, 27 Oct 2014 14:39:44 +0000
Subject: Recursion on TypeNats
In-Reply-To: <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
Message-ID: <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>

> No, there's not another way to do this with built-in Nats, and there probably won't ever be.

I do hope you're wrong.

> There are two advantages to the built-in Nats over hand-rolled ones: 1) Better syntax / error messages. 2) Built-in Nats are much more efficient than hand-rolled ones, because the hand-rolled ones are unary and take up space linear in the value of the number. If you re-hash your proposal for a Successor constructor down to the term level, it looks juts like (n+k)-patterns, which were discarded as a bad idea.

(n+k) patterns are clearly a bad idea on integers, because the integers don't have the inductive structure, but they're a good idea on natural numbers, which is why they were in the language originally.

> The reason that the type-level numbers are natural numbers and not integers is because natural numbers have a simpler theory to solve for. I'm personally hoping for proper type-level integers at some point, and the type-checker plugins approach may make that a reality sooner than later.

Type-level integers could well be useful, but they shouldn't replace type-level naturals, because they have completely different uses. At the value level, you can fudge the differences, because you can always return bottom, but at the type level you have to take correctness much more seriously if your type system is to be any use at all.

The fact that Carter (and I) are forced to define hand-rolled nats on top of the built in ones demonstrates a clear need for this feature. It seems to me a valuable extension, whether the syntax uses Successor or (n+k). Why can't we combine the advantages of built-in Nats and hand-rolled ones?

Barney.




From eir at cis.upenn.edu  Mon Oct 27 14:58:16 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 27 Oct 2014 10:58:16 -0400
Subject: Recursion on TypeNats
In-Reply-To: <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
 <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>
Message-ID: <9C265A68-DF22-4F7F-B214-70B2323E9B06@cis.upenn.edu>

Your argument here is compelling. I have wanted type-level integers from the beginning and saw Nats as just a step toward integers. But, of course, this is silly -- you're right that Nats deserve their own place.

Perhaps make a feature request for this. It may be related to type-level pattern synonyms, as proposed in #8828, comment:2.

Richard

On Oct 27, 2014, at 10:39 AM, Barney Hilken <b.hilken at ntlworld.com> wrote:

>> No, there's not another way to do this with built-in Nats, and there probably won't ever be.
> 
> I do hope you're wrong.
> 
>> There are two advantages to the built-in Nats over hand-rolled ones: 1) Better syntax / error messages. 2) Built-in Nats are much more efficient than hand-rolled ones, because the hand-rolled ones are unary and take up space linear in the value of the number. If you re-hash your proposal for a Successor constructor down to the term level, it looks juts like (n+k)-patterns, which were discarded as a bad idea.
> 
> (n+k) patterns are clearly a bad idea on integers, because the integers don't have the inductive structure, but they're a good idea on natural numbers, which is why they were in the language originally.
> 
>> The reason that the type-level numbers are natural numbers and not integers is because natural numbers have a simpler theory to solve for. I'm personally hoping for proper type-level integers at some point, and the type-checker plugins approach may make that a reality sooner than later.
> 
> Type-level integers could well be useful, but they shouldn't replace type-level naturals, because they have completely different uses. At the value level, you can fudge the differences, because you can always return bottom, but at the type level you have to take correctness much more seriously if your type system is to be any use at all.
> 
> The fact that Carter (and I) are forced to define hand-rolled nats on top of the built in ones demonstrates a clear need for this feature. It seems to me a valuable extension, whether the syntax uses Successor or (n+k). Why can't we combine the advantages of built-in Nats and hand-rolled ones?
> 
> Barney.
> 
> 
> 
> 


From david.feuer at gmail.com  Mon Oct 27 16:56:59 2014
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 27 Oct 2014 12:56:59 -0400
Subject: Hiding module *exports*
In-Reply-To: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
References: <CAO9Q0tVLUyC6-VW_c=su_6V4qmHXtFZCJmsSL3CAj5xWE+sjiQ@mail.gmail.com>
Message-ID: <CAMgWh9vYmBFcgGLftvL41oLD0dpvoNNjVA-zKsDV4xzxkg4xLQ@mail.gmail.com>

+1.

On Sun, Oct 26, 2014 at 3:28 PM, Tom Murphy <amindfv at gmail.com> wrote:

> (Not to be confused with the "hiding import behavior" discussion also
> going on)
>
> --
>
> Currently, I'm able to write "module Foo where" to export everything
> defined in Foo.
>
> If, though, I add to the module some definitions which I don't want to
> export...
>
>     data Lockbox = MkLockbox Int
>
>     internalFunction = ...
>
> ...I then have to explicitly enumerate everything that I *do* want the
> module to export, and add to that list each time I add to the module.
>
> I propose that instead, we're able to simply say what we mean:
>
>     module Foo hiding (Lockbox(MkLockbox), internalFunction) where
>
> I think its semantics are immediately clear to the reader.
>
> There's a little bit of bikeshedding that needs to happen (e.g. is "hiding
> (Foo(..))" sufficient to hide the type Foo and not just its constructors),
> but are people +1 on this? I've frequently wanted this behavior.
>
> Tom
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141027/cadc0da9/attachment-0001.html>

From b.hilken at ntlworld.com  Mon Oct 27 21:13:05 2014
From: b.hilken at ntlworld.com (Barney Hilken)
Date: Mon, 27 Oct 2014 21:13:05 +0000
Subject: Recursion on TypeNats
In-Reply-To: <9C265A68-DF22-4F7F-B214-70B2323E9B06@cis.upenn.edu>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
 <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>
 <9C265A68-DF22-4F7F-B214-70B2323E9B06@cis.upenn.edu>
Message-ID: <B8422272-08EC-4720-BB8A-88FFD52920E9@ntlworld.com>

Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731

Unfortunately I don't know enough about ghc internals to try implementing it.


From gale at sefer.org  Tue Oct 28 20:58:08 2014
From: gale at sefer.org (Yitzchak Gale)
Date: Tue, 28 Oct 2014 22:58:08 +0200
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <87a94n808i.fsf@gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
 <20141022105441.GA14512@machine>
 <CAOrUaLa5L0-LK-5S=m7Owt5PjrERmVVkNN8o+_UWiR=RGc8iKg@mail.gmail.com>
 <87a94n808i.fsf@gmail.com>
Message-ID: <CAOrUaLaL00xpJWJnT-_+fTt475rKcO4xrkRLOtg_EDh9RySdHA@mail.gmail.com>

I wrote:
>> This thread makes it clear what a mess
>> we have inherited from the days when GHC was primarily a
>> research compiler. Let's face it - GHC is now also a serious
>> production compiler, and this urgently needs to be cleaned up.

hvr wrote:
> Are you referring to the GMP dependency or something else?
> ...I'm not sure what can be done differently here.

Agreed. No, not any one of those many little details. I mean
the general extreme difficulty of getting almost any version
of GHC working on almost any platform, unless the two
were released within a fairly short time of each other.

Well, that is, not counting your wonderful ppa for Ubuntu.
That is fantastic - but the dire need for it is evidence for
the severity of the problem.

How about this: Currently, every GHC source distribution
requires no later than its own version of GHC for bootstrapping.
Going backwards, that chops up the sequence of GHC versions
into tiny incompatible pieces - there is no way to start with a
working GHC and work backwards to an older version by compiling
successively older GHC sources.

If instead each GHC could be compiled using at least one
subsequent version, the chain would not be broken. I.e.,
always provide a compatibility flag or some other reasonably
simple mechanism that would enable the current GHC to
compile the source code of at least the last previous released
version.

I realize that this might be disruptive to GHC devs, because
as a compiler with a research heritage, GHC experiments with
its own new features on its own source code. But as a compiler
that is used commercially, some general kind of backward
portability is critically important.

The other direction is equally problematic. Although
GHC does support bootstrapping itself from a few previous
releases, porting GHC to a new platform has become harder
and harder as GHC becomes more complex. I think this could
become a threat to the viability of GHC - technology is always
changing.

As a commercial developer, I am always plagued by nagging
worry about GHC portability, forward and backward. Will we
always be able in the future to support code we release, or will
it die someday because there will no longer exist a GHC able
to compile it? Will our whole technology die someday just
because we can't get GHC working on a platform we need
to support?

Thanks,
Yitz

From ezyang at mit.edu  Tue Oct 28 22:10:26 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 28 Oct 2014 15:10:26 -0700
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <CAOrUaLaL00xpJWJnT-_+fTt475rKcO4xrkRLOtg_EDh9RySdHA@mail.gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
 <20141022105441.GA14512@machine>
 <CAOrUaLa5L0-LK-5S=m7Owt5PjrERmVVkNN8o+_UWiR=RGc8iKg@mail.gmail.com>
 <87a94n808i.fsf@gmail.com>
 <CAOrUaLaL00xpJWJnT-_+fTt475rKcO4xrkRLOtg_EDh9RySdHA@mail.gmail.com>
Message-ID: <1414533995-sup-9843@sabre>

Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
> How about this: Currently, every GHC source distribution
> requires no later than its own version of GHC for bootstrapping.
> Going backwards, that chops up the sequence of GHC versions
> into tiny incompatible pieces - there is no way to start with a
> working GHC and work backwards to an older version by compiling
> successively older GHC sources.
> 
> If instead each GHC could be compiled using at least one
> subsequent version, the chain would not be broken. I.e.,
> always provide a compatibility flag or some other reasonably
> simple mechanism that would enable the current GHC to
> compile the source code of at least the last previous released
> version.

Here is an alternate proposal: when we make a new major version release,
we should also make a minor version release of the previous series, which
is prepped so that it can compile from the new major version.  If it
is the case that one version of the compiler can compile any other
version in the same series, this would be sufficient to go backwards.

Concretely, the action plan is very simple too: take 7.6 and apply as
many patches as is necessary to make it compile from 7.8, and cut
a release with those patches.

Edward

From iavor.diatchki at gmail.com  Wed Oct 29 00:24:37 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 28 Oct 2014 17:24:37 -0700
Subject: Recursion on TypeNats
In-Reply-To: <B8422272-08EC-4720-BB8A-88FFD52920E9@ntlworld.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
 <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>
 <9C265A68-DF22-4F7F-B214-70B2323E9B06@cis.upenn.edu>
 <B8422272-08EC-4720-BB8A-88FFD52920E9@ntlworld.com>
Message-ID: <CAGK9nup=uUZBSy24=HxhtOJek=ufiONO_fEi4NRtQQkvqkFM2g@mail.gmail.com>

Hello,

actually type-level integers are easier to work with than type-level
naturals (e.g., one can cancel things by subtracting at will).   I agree
that ideally we want to have both integers and naturals (probably as
separate kinds).  I just don't know what notation to use to distinguish the
two.

-Iavor



On Mon, Oct 27, 2014 at 2:13 PM, Barney Hilken <b.hilken at ntlworld.com>
wrote:

> Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731
>
> Unfortunately I don't know enough about ghc internals to try implementing
> it.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141028/a6d65f81/attachment.html>

From mike at proclivis.com  Wed Oct 29 06:18:52 2014
From: mike at proclivis.com (Michael Jones)
Date: Wed, 29 Oct 2014 00:18:52 -0600
Subject: Thread behavior in 7.8.3
Message-ID: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>

I have a general question about thread behavior in 7.8.3 vs 7.6.X

I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination.

When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so.

When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4.

The program is compiled -O2 with profiling. The -N2/4 version uses more memory,  but in both cases with 7.8 and with 7.6 there is no space leak.

I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running.

One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler.

What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help?

I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get.

Any hints appreciated.

Mike



From nair.sreenidhi at gmail.com  Wed Oct 29 15:27:21 2014
From: nair.sreenidhi at gmail.com (Sreenidhi Nair)
Date: Wed, 29 Oct 2014 20:57:21 +0530
Subject: Irreducible predicates error in Template Haskell
Message-ID: <CABhZaDc2RzS9i6PV-G0y4wMAQrev1uSB0YhazSK=1_wbXkdawg@mail.gmail.com>

Hello,

we were trying to reify a typeclass, which had a ConstraintKind and we hit
upon this error: "Can't represent irreducible predicates in Template
Haskell:".

It seems that there is already a ghc bug [
https://ghc.haskell.org/trac/ghc/ticket/7021 ] filed and its status is set
as fixed, but there is a comment at the bottom in which the reviewer
recommends against merging immediately. Does anybody know when it would get
merged in?

-- 
Yours truly,
Sreenidhi Nair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/574e0dd2/attachment.html>

From eir at cis.upenn.edu  Wed Oct 29 15:58:59 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 29 Oct 2014 11:58:59 -0400
Subject: Irreducible predicates error in Template Haskell
In-Reply-To: <CABhZaDc2RzS9i6PV-G0y4wMAQrev1uSB0YhazSK=1_wbXkdawg@mail.gmail.com>
References: <CABhZaDc2RzS9i6PV-G0y4wMAQrev1uSB0YhazSK=1_wbXkdawg@mail.gmail.com>
Message-ID: <3180B639-9314-4B61-A4C0-27B23E164B60@cis.upenn.edu>

This fix will not get merged into the 7.8.x development stream, but it is already available in HEAD and will be available in GHC 7.10.x. We try not to make breaking changes (and this is a breaking change) in the middle of a major version.

Richard

On Oct 29, 2014, at 11:27 AM, Sreenidhi Nair <nair.sreenidhi at gmail.com> wrote:

> Hello,
> 
> we were trying to reify a typeclass, which had a ConstraintKind and we hit upon this error: "Can't represent irreducible predicates in Template Haskell:".
> 
> It seems that there is already a ghc bug [ https://ghc.haskell.org/trac/ghc/ticket/7021 ] filed and its status is set as fixed, but there is a comment at the bottom in which the reviewer recommends against merging immediately. Does anybody know when it would get merged in? 
> 
> -- 
> Yours truly,
> Sreenidhi Nair
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/ea13c532/attachment.html>

From bgamari.foss at gmail.com  Wed Oct 29 16:24:42 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Wed, 29 Oct 2014 12:24:42 -0400
Subject: Thread behavior in 7.8.3
In-Reply-To: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
Message-ID: <87h9ymu9md.fsf@gmail.com>

Michael Jones <mike at proclivis.com> writes:

> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>
> I moved from 7.6 to 7.8 and my application behaves very differently. I
> have three threads, an application thread that plots data with
> wxhaskell or sends it over a network (depends on settings), a thread
> doing usb bulk writes, and a thread doing usb bulk reads. Data is
> moved around with TChan, and TVar is used for coordination.
>
Are you using Bas van Dijk's `usb` library by any chance? If so, you
should be aware of this [1] issue.

> When the application was compiled with 7.6, my stream of usb traffic
> was smooth. With 7.8, there are lots of delays where nothing seems to
> be running. These delays are up to 40ms, whereas with 7.6 delays were
> a 1ms or so.
>
> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
> fine without with -N2/4.
>
> The program is compiled -O2 with profiling. The -N2/4 version uses
> more memory, but in both cases with 7.8 and with 7.6 there is no space
> leak.
>
Have you looked at the RTS's output when run with `+RTS -sstderr`?
Is productivity any different between the two tests?

> I tired to compile and use -ls so I could take a look with
> threadscope, but the application hangs and writes no data to the file.
> The CPU fans run wild like it is in an infinite loop.
>
Oh dear, this doesn't sound good at all. Have you tried getting a
backtrace out of gdb? Usually this isn't terribly useful but in this
case since the event log is involved it might be getting stuck in the RTS
which should give a useful backtrace. If not, perhaps strace will give
some clues as to what is happening (you'll probably want to hide
SIGVTALM to improve signal/noise)?

Cheers,

- Ben


[1] https://github.com/basvandijk/usb/issues/7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/f552044a/attachment.sig>

From mike at proclivis.com  Wed Oct 29 16:38:21 2014
From: mike at proclivis.com (Michael Jones)
Date: Wed, 29 Oct 2014 10:38:21 -0600
Subject: Thread behavior in 7.8.3
In-Reply-To: <87h9ymu9md.fsf@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <87h9ymu9md.fsf@gmail.com>
Message-ID: <12E34FCF-1878-44A4-AF60-02CB09CF4A78@proclivis.com>

Ben,

I am using Bas van Dijk?s usb, and I am past the -threading issue by using the latest commit.

I don?t have any easy way of making comparisons between 7.6 and 7.8 productivity, but from oscilloscope activity, I can?t see any difference. The only difference I see is the thread scheduling on 7.8 for -N1 vs -N2/4.

If ?sstderr gives some notion of productivity, I?ll have to do an experiment between -N1 and -N2/4. Unchartered territory for me. I?ll setup and experiment tonight.

I am not familiar with strace. I?ll fix that soon.

Mike

On Oct 29, 2014, at 10:24 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> Michael Jones <mike at proclivis.com> writes:
> 
>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>> 
>> I moved from 7.6 to 7.8 and my application behaves very differently. I
>> have three threads, an application thread that plots data with
>> wxhaskell or sends it over a network (depends on settings), a thread
>> doing usb bulk writes, and a thread doing usb bulk reads. Data is
>> moved around with TChan, and TVar is used for coordination.
>> 
> Are you using Bas van Dijk's `usb` library by any chance? If so, you
> should be aware of this [1] issue.
> 
>> When the application was compiled with 7.6, my stream of usb traffic
>> was smooth. With 7.8, there are lots of delays where nothing seems to
>> be running. These delays are up to 40ms, whereas with 7.6 delays were
>> a 1ms or so.
>> 
>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
>> fine without with -N2/4.
>> 
>> The program is compiled -O2 with profiling. The -N2/4 version uses
>> more memory, but in both cases with 7.8 and with 7.6 there is no space
>> leak.
>> 
> Have you looked at the RTS's output when run with `+RTS -sstderr`?
> Is productivity any different between the two tests?
> 
>> I tired to compile and use -ls so I could take a look with
>> threadscope, but the application hangs and writes no data to the file.
>> The CPU fans run wild like it is in an infinite loop.
>> 
> Oh dear, this doesn't sound good at all. Have you tried getting a
> backtrace out of gdb? Usually this isn't terribly useful but in this
> case since the event log is involved it might be getting stuck in the RTS
> which should give a useful backtrace. If not, perhaps strace will give
> some clues as to what is happening (you'll probably want to hide
> SIGVTALM to improve signal/noise)?
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://github.com/basvandijk/usb/issues/7



From eir at cis.upenn.edu  Wed Oct 29 17:25:41 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 29 Oct 2014 13:25:41 -0400
Subject: Recursion on TypeNats
In-Reply-To: <CAGK9nup=uUZBSy24=HxhtOJek=ufiONO_fEi4NRtQQkvqkFM2g@mail.gmail.com>
References: <802159B9-E07D-4535-AF73-D1B4E866DF72@ntlworld.com>
 <AC50EBC6-BAF6-4F83-907B-92BD53937886@cis.upenn.edu>
 <C71B46BF-6151-4276-B56B-3AA918B85C66@ntlworld.com>
 <9C265A68-DF22-4F7F-B214-70B2323E9B06@cis.upenn.edu>
 <B8422272-08EC-4720-BB8A-88FFD52920E9@ntlworld.com>
 <CAGK9nup=uUZBSy24=HxhtOJek=ufiONO_fEi4NRtQQkvqkFM2g@mail.gmail.com>
Message-ID: <7B2AF66A-585C-4CE4-A4F1-365F8A2B0070@cis.upenn.edu>

I don't think we'll need notation to differentiate: just use overloaded literals, like we do in terms. Something that would operate vaguely like this:

> type family 3 :: k where
>   3 :: Nat = ... -- 3 as a Nat
>   3 :: Integer = ... -- 3 as an Integer

I'm not at all suggesting it be implemented this way, but we already have the ability to branch in type families based on result kind, so the mechanism is already around. Unfortunately, this would be unhelpful if the user asked for (3 :: Bool), which would kind-check but be stuck.

Richard

On Oct 28, 2014, at 8:24 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> Hello,
> 
> actually type-level integers are easier to work with than type-level naturals (e.g., one can cancel things by subtracting at will).   I agree that ideally we want to have both integers and naturals (probably as separate kinds).  I just don't know what notation to use to distinguish the two. 
> 
> -Iavor
> 
> 
> 
> On Mon, Oct 27, 2014 at 2:13 PM, Barney Hilken <b.hilken at ntlworld.com> wrote:
> Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731
> 
> Unfortunately I don't know enough about ghc internals to try implementing it.
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/bd07228d/attachment.html>

From bgamari.foss at gmail.com  Wed Oct 29 21:57:51 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Wed, 29 Oct 2014 17:57:51 -0400
Subject: Thread behavior in 7.8.3
In-Reply-To: <12E34FCF-1878-44A4-AF60-02CB09CF4A78@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <87h9ymu9md.fsf@gmail.com>
 <12E34FCF-1878-44A4-AF60-02CB09CF4A78@proclivis.com>
Message-ID: <87egtqtu74.fsf@gmail.com>

Michael Jones <mike at proclivis.com> writes:

> Ben,
>
> I am using Bas van Dijk?s usb, and I am past the -threading issue by
> using the latest commit.
>
Excellent; I hadn't noticed the "proclivis" in your email address

> I don?t have any easy way of making comparisons between 7.6 and 7.8
> productivity, but from oscilloscope activity, I can?t see any
> difference. The only difference I see is the thread scheduling on 7.8
> for -N1 vs -N2/4.
>
> If ?sstderr gives some notion of productivity, I?ll have to do an
> experiment between -N1 and -N2/4. Unchartered territory for me. I?ll
> setup and experiment tonight.
>
Indeed it does; "productivity" in this context refers to the fraction of
runtime spent in evaluation (as opposed to in the garbage collector, for
instance).

> I am not familiar with strace. I?ll fix that soon.
>
It's often an invaluable tool; that being said it remains to seen
whether it yields anything useful in this particular case.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/c97b8958/attachment.sig>

From jwlato at gmail.com  Wed Oct 29 23:12:16 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 30 Oct 2014 07:12:16 +0800
Subject: Thread behavior in 7.8.3
In-Reply-To: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
Message-ID: <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>

By any chance do the delays get shorter if you run your program with `+RTS
-C0.005` ?  If so, I suspect you're having a problem very similar to one
that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
reason), involving possible misbehavior of the thread scheduler.

On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:

> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>
> I moved from 7.6 to 7.8 and my application behaves very differently. I
> have three threads, an application thread that plots data with wxhaskell or
> sends it over a network (depends on settings), a thread doing usb bulk
> writes, and a thread doing usb bulk reads. Data is moved around with TChan,
> and TVar is used for coordination.
>
> When the application was compiled with 7.6, my stream of usb traffic was
> smooth. With 7.8, there are lots of delays where nothing seems to be
> running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or
> so.
>
> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine
> without with -N2/4.
>
> The program is compiled -O2 with profiling. The -N2/4 version uses more
> memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
>
> I tired to compile and use -ls so I could take a look with threadscope,
> but the application hangs and writes no data to the file. The CPU fans run
> wild like it is in an infinite loop. It at least pops an unpainted
> wxhaskell window, so it got partially running.
>
> One of my libraries uses option -fsimpl-tick-factor=200 to get around the
> compiler.
>
> What do I need to know about changes to threading and event logging
> between 7.6 and 7.8? Is there some general documentation somewhere that
> might help?
>
> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
> installed myself, after removing 7.6 with apt-get.
>
> Any hints appreciated.
>
> Mike
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141030/7a429a3a/attachment-0001.html>

From mike at proclivis.com  Thu Oct 30 00:02:16 2014
From: mike at proclivis.com (Michael Jones)
Date: Wed, 29 Oct 2014 18:02:16 -0600
Subject: Thread behavior in 7.8.3
In-Reply-To: <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
Message-ID: <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>

John,

Adding -C0.005 makes it much better. Using -C0.001 makes it behave more like -N4.

Thanks. This saves my project, as I need to deploy on a single core Atom and was stuck.

Mike

On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:

> By any chance do the delays get shorter if you run your program with `+RTS -C0.005` ?  If so, I suspect you're having a problem very similar to one that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some reason), involving possible misbehavior of the thread scheduler.
> 
> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:
> I have a general question about thread behavior in 7.8.3 vs 7.6.X
> 
> I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination.
> 
> When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so.
> 
> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4.
> 
> The program is compiled -O2 with profiling. The -N2/4 version uses more memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
> 
> I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running.
> 
> One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler.
> 
> What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help?
> 
> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get.
> 
> Any hints appreciated.
> 
> Mike
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141029/58ddf00b/attachment.html>

From jwlato at gmail.com  Thu Oct 30 00:19:46 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 30 Oct 2014 08:19:46 +0800
Subject: Thread behavior in 7.8.3
In-Reply-To: <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
Message-ID: <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>

I guess I should explain what that flag does...

The GHC RTS maintains capabilities, the number of capabilities is specified
by the `+RTS -N` option.  Each capability is a virtual machine that
executes Haskell code, and maintains its own runqueue of threads to process.

A capability will perform a context switch at the next heap block
allocation (every 4k of allocation) after the timer expires.  The timer
defaults to 20ms, and can be set by the -C flag.  Capabilities perform
context switches in other circumstances as well, such as when a thread
yields or blocks.

My guess is that either the context switching logic changed in ghc-7.8, or
possibly your code used to trigger a switch via some other mechanism (stack
overflow or something maybe?), but is optimized differently now so instead
it needs to wait for the timer to expire.

The problem we had was that a time-sensitive thread was getting scheduled
on the same capability as a long-running non-yielding thread, so the
time-sensitive thread had to wait for a context switch timeout (even though
there were free cores available!).  I expect even with -N4 you'll still see
occasional delays (perhaps <5% of calls).

We've solved our problem with judicious use of `forkOn`, but that won't
help at N1.

We did see this behavior in 7.6, but it's definitely worse in 7.8.

Incidentally, has there been any interest in a work-stealing scheduler?
There was a discussion from about 2 years ago, in which Simon Marlow noted
it might be tricky, but it would definitely help in situations like this.

John L.

On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com> wrote:

> John,
>
> Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
> like -N4.
>
> Thanks. This saves my project, as I need to deploy on a single core Atom
> and was stuck.
>
> Mike
>
> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
>
> By any chance do the delays get shorter if you run your program with `+RTS
> -C0.005` ?  If so, I suspect you're having a problem very similar to one
> that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
> reason), involving possible misbehavior of the thread scheduler.
>
> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:
>
>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>
>> I moved from 7.6 to 7.8 and my application behaves very differently. I
>> have three threads, an application thread that plots data with wxhaskell or
>> sends it over a network (depends on settings), a thread doing usb bulk
>> writes, and a thread doing usb bulk reads. Data is moved around with TChan,
>> and TVar is used for coordination.
>>
>> When the application was compiled with 7.6, my stream of usb traffic was
>> smooth. With 7.8, there are lots of delays where nothing seems to be
>> running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or
>> so.
>>
>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine
>> without with -N2/4.
>>
>> The program is compiled -O2 with profiling. The -N2/4 version uses more
>> memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
>>
>> I tired to compile and use -ls so I could take a look with threadscope,
>> but the application hangs and writes no data to the file. The CPU fans run
>> wild like it is in an infinite loop. It at least pops an unpainted
>> wxhaskell window, so it got partially running.
>>
>> One of my libraries uses option -fsimpl-tick-factor=200 to get around the
>> compiler.
>>
>> What do I need to know about changes to threading and event logging
>> between 7.6 and 7.8? Is there some general documentation somewhere that
>> might help?
>>
>> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
>> installed myself, after removing 7.6 with apt-get.
>>
>> Any hints appreciated.
>>
>> Mike
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141030/c484a7ba/attachment.html>

From ezyang at mit.edu  Thu Oct 30 00:24:28 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 29 Oct 2014 17:24:28 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
Message-ID: <1414628541-sup-9692@sabre>

I don't think this is directly related to the problem, but if you have a
thread that isn't yielding, you can force it to yield by using
-fno-omit-yields on your code.  It won't help if the non-yielding code
is in a library, and it won't help if the problem was that you just
weren't setting timeouts finely enough (which sounds like what was
happening). FYI.

Edward

Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
> I guess I should explain what that flag does...
> 
> The GHC RTS maintains capabilities, the number of capabilities is specified
> by the `+RTS -N` option.  Each capability is a virtual machine that
> executes Haskell code, and maintains its own runqueue of threads to process.
> 
> A capability will perform a context switch at the next heap block
> allocation (every 4k of allocation) after the timer expires.  The timer
> defaults to 20ms, and can be set by the -C flag.  Capabilities perform
> context switches in other circumstances as well, such as when a thread
> yields or blocks.
> 
> My guess is that either the context switching logic changed in ghc-7.8, or
> possibly your code used to trigger a switch via some other mechanism (stack
> overflow or something maybe?), but is optimized differently now so instead
> it needs to wait for the timer to expire.
> 
> The problem we had was that a time-sensitive thread was getting scheduled
> on the same capability as a long-running non-yielding thread, so the
> time-sensitive thread had to wait for a context switch timeout (even though
> there were free cores available!).  I expect even with -N4 you'll still see
> occasional delays (perhaps <5% of calls).
> 
> We've solved our problem with judicious use of `forkOn`, but that won't
> help at N1.
> 
> We did see this behavior in 7.6, but it's definitely worse in 7.8.
> 
> Incidentally, has there been any interest in a work-stealing scheduler?
> There was a discussion from about 2 years ago, in which Simon Marlow noted
> it might be tricky, but it would definitely help in situations like this.
> 
> John L.
> 
> On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com> wrote:
> 
> > John,
> >
> > Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
> > like -N4.
> >
> > Thanks. This saves my project, as I need to deploy on a single core Atom
> > and was stuck.
> >
> > Mike
> >
> > On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
> >
> > By any chance do the delays get shorter if you run your program with `+RTS
> > -C0.005` ?  If so, I suspect you're having a problem very similar to one
> > that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
> > reason), involving possible misbehavior of the thread scheduler.
> >
> > On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:
> >
> >> I have a general question about thread behavior in 7.8.3 vs 7.6.X
> >>
> >> I moved from 7.6 to 7.8 and my application behaves very differently. I
> >> have three threads, an application thread that plots data with wxhaskell or
> >> sends it over a network (depends on settings), a thread doing usb bulk
> >> writes, and a thread doing usb bulk reads. Data is moved around with TChan,
> >> and TVar is used for coordination.
> >>
> >> When the application was compiled with 7.6, my stream of usb traffic was
> >> smooth. With 7.8, there are lots of delays where nothing seems to be
> >> running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or
> >> so.
> >>
> >> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine
> >> without with -N2/4.
> >>
> >> The program is compiled -O2 with profiling. The -N2/4 version uses more
> >> memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
> >>
> >> I tired to compile and use -ls so I could take a look with threadscope,
> >> but the application hangs and writes no data to the file. The CPU fans run
> >> wild like it is in an infinite loop. It at least pops an unpainted
> >> wxhaskell window, so it got partially running.
> >>
> >> One of my libraries uses option -fsimpl-tick-factor=200 to get around the
> >> compiler.
> >>
> >> What do I need to know about changes to threading and event logging
> >> between 7.6 and 7.8? Is there some general documentation somewhere that
> >> might help?
> >>
> >> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
> >> installed myself, after removing 7.6 with apt-get.
> >>
> >> Any hints appreciated.
> >>
> >> Mike
> >>
> >>
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users at haskell.org
> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>
> >
> >
> >

From jwlato at gmail.com  Thu Oct 30 00:31:45 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 30 Oct 2014 08:31:45 +0800
Subject: Thread behavior in 7.8.3
In-Reply-To: <1414628541-sup-9692@sabre>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
 <1414628541-sup-9692@sabre>
Message-ID: <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>

My understanding is that -fno-omit-yields is subtly different.  I think
that's for the case when a function loops without performing any heap
allocations, and thus would never yield even after the context switch
timeout.  In my case the looping function does perform heap allocations and
does eventually yield, just not until after the timeout.

Is that understanding correct?

(technically, doesn't it change to yielding after stack checks or something
like that?)



On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> I don't think this is directly related to the problem, but if you have a
> thread that isn't yielding, you can force it to yield by using
> -fno-omit-yields on your code.  It won't help if the non-yielding code
> is in a library, and it won't help if the problem was that you just
> weren't setting timeouts finely enough (which sounds like what was
> happening). FYI.
>
> Edward
>
> Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
> > I guess I should explain what that flag does...
> >
> > The GHC RTS maintains capabilities, the number of capabilities is
> specified
> > by the `+RTS -N` option.  Each capability is a virtual machine that
> > executes Haskell code, and maintains its own runqueue of threads to
> process.
> >
> > A capability will perform a context switch at the next heap block
> > allocation (every 4k of allocation) after the timer expires.  The timer
> > defaults to 20ms, and can be set by the -C flag.  Capabilities perform
> > context switches in other circumstances as well, such as when a thread
> > yields or blocks.
> >
> > My guess is that either the context switching logic changed in ghc-7.8,
> or
> > possibly your code used to trigger a switch via some other mechanism
> (stack
> > overflow or something maybe?), but is optimized differently now so
> instead
> > it needs to wait for the timer to expire.
> >
> > The problem we had was that a time-sensitive thread was getting scheduled
> > on the same capability as a long-running non-yielding thread, so the
> > time-sensitive thread had to wait for a context switch timeout (even
> though
> > there were free cores available!).  I expect even with -N4 you'll still
> see
> > occasional delays (perhaps <5% of calls).
> >
> > We've solved our problem with judicious use of `forkOn`, but that won't
> > help at N1.
> >
> > We did see this behavior in 7.6, but it's definitely worse in 7.8.
> >
> > Incidentally, has there been any interest in a work-stealing scheduler?
> > There was a discussion from about 2 years ago, in which Simon Marlow
> noted
> > it might be tricky, but it would definitely help in situations like this.
> >
> > John L.
> >
> > On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com>
> wrote:
> >
> > > John,
> > >
> > > Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
> > > like -N4.
> > >
> > > Thanks. This saves my project, as I need to deploy on a single core
> Atom
> > > and was stuck.
> > >
> > > Mike
> > >
> > > On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
> > >
> > > By any chance do the delays get shorter if you run your program with
> `+RTS
> > > -C0.005` ?  If so, I suspect you're having a problem very similar to
> one
> > > that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
> > > reason), involving possible misbehavior of the thread scheduler.
> > >
> > > On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com>
> wrote:
> > >
> > >> I have a general question about thread behavior in 7.8.3 vs 7.6.X
> > >>
> > >> I moved from 7.6 to 7.8 and my application behaves very differently. I
> > >> have three threads, an application thread that plots data with
> wxhaskell or
> > >> sends it over a network (depends on settings), a thread doing usb bulk
> > >> writes, and a thread doing usb bulk reads. Data is moved around with
> TChan,
> > >> and TVar is used for coordination.
> > >>
> > >> When the application was compiled with 7.6, my stream of usb traffic
> was
> > >> smooth. With 7.8, there are lots of delays where nothing seems to be
> > >> running. These delays are up to 40ms, whereas with 7.6 delays were a
> 1ms or
> > >> so.
> > >>
> > >> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
> fine
> > >> without with -N2/4.
> > >>
> > >> The program is compiled -O2 with profiling. The -N2/4 version uses
> more
> > >> memory,  but in both cases with 7.8 and with 7.6 there is no space
> leak.
> > >>
> > >> I tired to compile and use -ls so I could take a look with
> threadscope,
> > >> but the application hangs and writes no data to the file. The CPU
> fans run
> > >> wild like it is in an infinite loop. It at least pops an unpainted
> > >> wxhaskell window, so it got partially running.
> > >>
> > >> One of my libraries uses option -fsimpl-tick-factor=200 to get around
> the
> > >> compiler.
> > >>
> > >> What do I need to know about changes to threading and event logging
> > >> between 7.6 and 7.8? Is there some general documentation somewhere
> that
> > >> might help?
> > >>
> > >> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
> > >> installed myself, after removing 7.6 with apt-get.
> > >>
> > >> Any hints appreciated.
> > >>
> > >> Mike
> > >>
> > >>
> > >> _______________________________________________
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users at haskell.org
> > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> > >>
> > >
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141030/14f5a76d/attachment-0001.html>

From ezyang at mit.edu  Thu Oct 30 00:41:16 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 29 Oct 2014 17:41:16 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
 <1414628541-sup-9692@sabre>
 <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>
Message-ID: <1414629638-sup-1751@sabre>

Yes, that's right.

I brought it up because you mentioned that there might still be
occasional delays, and those might be caused by a thread not being
preemptible for a while.

Edward

Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
> My understanding is that -fno-omit-yields is subtly different.  I think
> that's for the case when a function loops without performing any heap
> allocations, and thus would never yield even after the context switch
> timeout.  In my case the looping function does perform heap allocations and
> does eventually yield, just not until after the timeout.
> 
> Is that understanding correct?
> 
> (technically, doesn't it change to yielding after stack checks or something
> like that?)
> 
> On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > I don't think this is directly related to the problem, but if you have a
> > thread that isn't yielding, you can force it to yield by using
> > -fno-omit-yields on your code.  It won't help if the non-yielding code
> > is in a library, and it won't help if the problem was that you just
> > weren't setting timeouts finely enough (which sounds like what was
> > happening). FYI.
> >
> > Edward
> >
> > Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
> > > I guess I should explain what that flag does...
> > >
> > > The GHC RTS maintains capabilities, the number of capabilities is
> > specified
> > > by the `+RTS -N` option.  Each capability is a virtual machine that
> > > executes Haskell code, and maintains its own runqueue of threads to
> > process.
> > >
> > > A capability will perform a context switch at the next heap block
> > > allocation (every 4k of allocation) after the timer expires.  The timer
> > > defaults to 20ms, and can be set by the -C flag.  Capabilities perform
> > > context switches in other circumstances as well, such as when a thread
> > > yields or blocks.
> > >
> > > My guess is that either the context switching logic changed in ghc-7.8,
> > or
> > > possibly your code used to trigger a switch via some other mechanism
> > (stack
> > > overflow or something maybe?), but is optimized differently now so
> > instead
> > > it needs to wait for the timer to expire.
> > >
> > > The problem we had was that a time-sensitive thread was getting scheduled
> > > on the same capability as a long-running non-yielding thread, so the
> > > time-sensitive thread had to wait for a context switch timeout (even
> > though
> > > there were free cores available!).  I expect even with -N4 you'll still
> > see
> > > occasional delays (perhaps <5% of calls).
> > >
> > > We've solved our problem with judicious use of `forkOn`, but that won't
> > > help at N1.
> > >
> > > We did see this behavior in 7.6, but it's definitely worse in 7.8.
> > >
> > > Incidentally, has there been any interest in a work-stealing scheduler?
> > > There was a discussion from about 2 years ago, in which Simon Marlow
> > noted
> > > it might be tricky, but it would definitely help in situations like this.
> > >
> > > John L.
> > >
> > > On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com>
> > wrote:
> > >
> > > > John,
> > > >
> > > > Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
> > > > like -N4.
> > > >
> > > > Thanks. This saves my project, as I need to deploy on a single core
> > Atom
> > > > and was stuck.
> > > >
> > > > Mike
> > > >
> > > > On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
> > > >
> > > > By any chance do the delays get shorter if you run your program with
> > `+RTS
> > > > -C0.005` ?  If so, I suspect you're having a problem very similar to
> > one
> > > > that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
> > > > reason), involving possible misbehavior of the thread scheduler.
> > > >
> > > > On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com>
> > wrote:
> > > >
> > > >> I have a general question about thread behavior in 7.8.3 vs 7.6.X
> > > >>
> > > >> I moved from 7.6 to 7.8 and my application behaves very differently. I
> > > >> have three threads, an application thread that plots data with
> > wxhaskell or
> > > >> sends it over a network (depends on settings), a thread doing usb bulk
> > > >> writes, and a thread doing usb bulk reads. Data is moved around with
> > TChan,
> > > >> and TVar is used for coordination.
> > > >>
> > > >> When the application was compiled with 7.6, my stream of usb traffic
> > was
> > > >> smooth. With 7.8, there are lots of delays where nothing seems to be
> > > >> running. These delays are up to 40ms, whereas with 7.6 delays were a
> > 1ms or
> > > >> so.
> > > >>
> > > >> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
> > fine
> > > >> without with -N2/4.
> > > >>
> > > >> The program is compiled -O2 with profiling. The -N2/4 version uses
> > more
> > > >> memory,  but in both cases with 7.8 and with 7.6 there is no space
> > leak.
> > > >>
> > > >> I tired to compile and use -ls so I could take a look with
> > threadscope,
> > > >> but the application hangs and writes no data to the file. The CPU
> > fans run
> > > >> wild like it is in an infinite loop. It at least pops an unpainted
> > > >> wxhaskell window, so it got partially running.
> > > >>
> > > >> One of my libraries uses option -fsimpl-tick-factor=200 to get around
> > the
> > > >> compiler.
> > > >>
> > > >> What do I need to know about changes to threading and event logging
> > > >> between 7.6 and 7.8? Is there some general documentation somewhere
> > that
> > > >> might help?
> > > >>
> > > >> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
> > > >> installed myself, after removing 7.6 with apt-get.
> > > >>
> > > >> Any hints appreciated.
> > > >>
> > > >> Mike
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Glasgow-haskell-users mailing list
> > > >> Glasgow-haskell-users at haskell.org
> > > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> > > >>
> > > >
> > > >
> > > >
> >

From simonpj at microsoft.com  Thu Oct 30 08:19:35 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 30 Oct 2014 08:19:35 +0000
Subject: Thread behavior in 7.8.3
In-Reply-To: <1414629638-sup-1751@sabre>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
 <1414628541-sup-9692@sabre>
 <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>
 <1414629638-sup-1751@sabre>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3823D4@DB3PRD3001MB020.064d.mgd.msft.net>

I wonder if the knowledge embodied in this thread might usefully be summarised in the user manual?  Or on the GHC section of the Haskell wiki https://www.haskell.org/haskellwiki/GHC?

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Edward Z. Yang
|  Sent: 30 October 2014 00:41
|  To: John Lato
|  Cc: GHC Users List
|  Subject: Re: Thread behavior in 7.8.3
|  
|  Yes, that's right.
|  
|  I brought it up because you mentioned that there might still be
|  occasional delays, and those might be caused by a thread not being
|  preemptible for a while.
|  
|  Edward
|  
|  Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
|  > My understanding is that -fno-omit-yields is subtly different.  I
|  > think that's for the case when a function loops without performing
|  any
|  > heap allocations, and thus would never yield even after the context
|  > switch timeout.  In my case the looping function does perform heap
|  > allocations and does eventually yield, just not until after the
|  timeout.
|  >
|  > Is that understanding correct?
|  >
|  > (technically, doesn't it change to yielding after stack checks or
|  > something like that?)
|  >
|  > On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang <ezyang at mit.edu>
|  wrote:
|  >
|  > > I don't think this is directly related to the problem, but if you
|  > > have a thread that isn't yielding, you can force it to yield by
|  > > using -fno-omit-yields on your code.  It won't help if the
|  > > non-yielding code is in a library, and it won't help if the
|  problem
|  > > was that you just weren't setting timeouts finely enough (which
|  > > sounds like what was happening). FYI.
|  > >
|  > > Edward
|  > >
|  > > Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
|  > > > I guess I should explain what that flag does...
|  > > >
|  > > > The GHC RTS maintains capabilities, the number of capabilities
|  is
|  > > specified
|  > > > by the `+RTS -N` option.  Each capability is a virtual machine
|  > > > that executes Haskell code, and maintains its own runqueue of
|  > > > threads to
|  > > process.
|  > > >
|  > > > A capability will perform a context switch at the next heap
|  block
|  > > > allocation (every 4k of allocation) after the timer expires.
|  The
|  > > > timer defaults to 20ms, and can be set by the -C flag.
|  > > > Capabilities perform context switches in other circumstances as
|  > > > well, such as when a thread yields or blocks.
|  > > >
|  > > > My guess is that either the context switching logic changed in
|  > > > ghc-7.8,
|  > > or
|  > > > possibly your code used to trigger a switch via some other
|  > > > mechanism
|  > > (stack
|  > > > overflow or something maybe?), but is optimized differently now
|  so
|  > > instead
|  > > > it needs to wait for the timer to expire.
|  > > >
|  > > > The problem we had was that a time-sensitive thread was getting
|  > > > scheduled on the same capability as a long-running non-yielding
|  > > > thread, so the time-sensitive thread had to wait for a context
|  > > > switch timeout (even
|  > > though
|  > > > there were free cores available!).  I expect even with -N4
|  you'll
|  > > > still
|  > > see
|  > > > occasional delays (perhaps <5% of calls).
|  > > >
|  > > > We've solved our problem with judicious use of `forkOn`, but
|  that
|  > > > won't help at N1.
|  > > >
|  > > > We did see this behavior in 7.6, but it's definitely worse in
|  7.8.
|  > > >
|  > > > Incidentally, has there been any interest in a work-stealing
|  scheduler?
|  > > > There was a discussion from about 2 years ago, in which Simon
|  > > > Marlow
|  > > noted
|  > > > it might be tricky, but it would definitely help in situations
|  like this.
|  > > >
|  > > > John L.
|  > > >
|  > > > On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones
|  > > > <mike at proclivis.com>
|  > > wrote:
|  > > >
|  > > > > John,
|  > > > >
|  > > > > Adding -C0.005 makes it much better. Using -C0.001 makes it
|  > > > > behave more like -N4.
|  > > > >
|  > > > > Thanks. This saves my project, as I need to deploy on a single
|  > > > > core
|  > > Atom
|  > > > > and was stuck.
|  > > > >
|  > > > > Mike
|  > > > >
|  > > > > On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com>
|  wrote:
|  > > > >
|  > > > > By any chance do the delays get shorter if you run your
|  program
|  > > > > with
|  > > `+RTS
|  > > > > -C0.005` ?  If so, I suspect you're having a problem very
|  > > > > similar to
|  > > one
|  > > > > that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8
|  for
|  > > > > some reason), involving possible misbehavior of the thread
|  scheduler.
|  > > > >
|  > > > > On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones
|  > > > > <mike at proclivis.com>
|  > > wrote:
|  > > > >
|  > > > >> I have a general question about thread behavior in 7.8.3 vs
|  > > > >> 7.6.X
|  > > > >>
|  > > > >> I moved from 7.6 to 7.8 and my application behaves very
|  > > > >> differently. I have three threads, an application thread that
|  > > > >> plots data with
|  > > wxhaskell or
|  > > > >> sends it over a network (depends on settings), a thread doing
|  > > > >> usb bulk writes, and a thread doing usb bulk reads. Data is
|  > > > >> moved around with
|  > > TChan,
|  > > > >> and TVar is used for coordination.
|  > > > >>
|  > > > >> When the application was compiled with 7.6, my stream of usb
|  > > > >> traffic
|  > > was
|  > > > >> smooth. With 7.8, there are lots of delays where nothing
|  seems
|  > > > >> to be running. These delays are up to 40ms, whereas with 7.6
|  > > > >> delays were a
|  > > 1ms or
|  > > > >> so.
|  > > > >>
|  > > > >> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6
|  it
|  > > > >> runs
|  > > fine
|  > > > >> without with -N2/4.
|  > > > >>
|  > > > >> The program is compiled -O2 with profiling. The -N2/4 version
|  > > > >> uses
|  > > more
|  > > > >> memory,  but in both cases with 7.8 and with 7.6 there is no
|  > > > >> space
|  > > leak.
|  > > > >>
|  > > > >> I tired to compile and use -ls so I could take a look with
|  > > threadscope,
|  > > > >> but the application hangs and writes no data to the file. The
|  > > > >> CPU
|  > > fans run
|  > > > >> wild like it is in an infinite loop. It at least pops an
|  > > > >> unpainted wxhaskell window, so it got partially running.
|  > > > >>
|  > > > >> One of my libraries uses option -fsimpl-tick-factor=200 to
|  get
|  > > > >> around
|  > > the
|  > > > >> compiler.
|  > > > >>
|  > > > >> What do I need to know about changes to threading and event
|  > > > >> logging between 7.6 and 7.8? Is there some general
|  > > > >> documentation somewhere
|  > > that
|  > > > >> might help?
|  > > > >>
|  > > > >> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
|  > > > >> ball and installed myself, after removing 7.6 with apt-get.
|  > > > >>
|  > > > >> Any hints appreciated.
|  > > > >>
|  > > > >> Mike
|  > > > >>
|  > > > >>
|  > > > >> _______________________________________________
|  > > > >> Glasgow-haskell-users mailing list
|  > > > >> Glasgow-haskell-users at haskell.org
|  > > > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|  > > > >>
|  > > > >
|  > > > >
|  > > > >
|  > >
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From mike at proclivis.com  Thu Oct 30 15:50:20 2014
From: mike at proclivis.com (Michael Jones)
Date: Thu, 30 Oct 2014 09:50:20 -0600
Subject: Thread behavior in 7.8.3
In-Reply-To: <1414629638-sup-1751@sabre>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
 <1414628541-sup-9692@sabre>
 <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>
 <1414629638-sup-1751@sabre>
Message-ID: <630636C9-5471-41B0-BFFB-DACEE47903A9@proclivis.com>

My hope is that if my threads are doing IO, the scheduler acts when there is an IO action with delay, or when STM blocks, etc.

So at the end of my pipe out, I have:

sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
sendTransactions dev dts = repeatedly $ do
  dts' <- liftIO $ atomically $ readTVar dts
  when (dts' == True) (do
      (_, transactions) <- await
      liftIO $ sendOut dev transactions)

And my pipe in:

returnTransactionResults :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> SourceT m (Spec, Char)
returnTransactionResults dev dts = repeatedly $ do
  (status, spec) <- liftIO $ readIn2 dev
  oldDts <- liftIO $ atomically $ readTVar dts
  let dts' = (ord $ status!!1) .&. 0x20
  let newDts = dts' /= 0
  when (oldDts /= newDts) (
    liftIO $ atomically $ writeTVar dts newDts)
  when (length spec /= 0) (mapM_ (\ch -> yield (executeSpec, ch)) spec)

sendOut will do a usb bulk write, and readIn2 will do a use bulk read. Hopefully, somewhere in the usb code IO blocks for an interrupt (probably in libusb), and that allows the scheduler to switch threads. Given the behavior, I assume this is not the case, and it requires time slicing to switch threads.

I also send data between the in/out pipes via TChan. Remembering that each pipe is in a thread, hopefully if a readTChan blocks, the scheduler reschedules and the other thread runs.

For context, I do a lot of RTOS work, so my worldview of the expected behavior comes from that perspective.

Mike


On Oct 29, 2014, at 6:41 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Yes, that's right.
> 
> I brought it up because you mentioned that there might still be
> occasional delays, and those might be caused by a thread not being
> preemptible for a while.
> 
> Edward
> 
> Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
>> My understanding is that -fno-omit-yields is subtly different.  I think
>> that's for the case when a function loops without performing any heap
>> allocations, and thus would never yield even after the context switch
>> timeout.  In my case the looping function does perform heap allocations and
>> does eventually yield, just not until after the timeout.
>> 
>> Is that understanding correct?
>> 
>> (technically, doesn't it change to yielding after stack checks or something
>> like that?)
>> 
>> On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> 
>>> I don't think this is directly related to the problem, but if you have a
>>> thread that isn't yielding, you can force it to yield by using
>>> -fno-omit-yields on your code.  It won't help if the non-yielding code
>>> is in a library, and it won't help if the problem was that you just
>>> weren't setting timeouts finely enough (which sounds like what was
>>> happening). FYI.
>>> 
>>> Edward
>>> 
>>> Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
>>>> I guess I should explain what that flag does...
>>>> 
>>>> The GHC RTS maintains capabilities, the number of capabilities is
>>> specified
>>>> by the `+RTS -N` option.  Each capability is a virtual machine that
>>>> executes Haskell code, and maintains its own runqueue of threads to
>>> process.
>>>> 
>>>> A capability will perform a context switch at the next heap block
>>>> allocation (every 4k of allocation) after the timer expires.  The timer
>>>> defaults to 20ms, and can be set by the -C flag.  Capabilities perform
>>>> context switches in other circumstances as well, such as when a thread
>>>> yields or blocks.
>>>> 
>>>> My guess is that either the context switching logic changed in ghc-7.8,
>>> or
>>>> possibly your code used to trigger a switch via some other mechanism
>>> (stack
>>>> overflow or something maybe?), but is optimized differently now so
>>> instead
>>>> it needs to wait for the timer to expire.
>>>> 
>>>> The problem we had was that a time-sensitive thread was getting scheduled
>>>> on the same capability as a long-running non-yielding thread, so the
>>>> time-sensitive thread had to wait for a context switch timeout (even
>>> though
>>>> there were free cores available!).  I expect even with -N4 you'll still
>>> see
>>>> occasional delays (perhaps <5% of calls).
>>>> 
>>>> We've solved our problem with judicious use of `forkOn`, but that won't
>>>> help at N1.
>>>> 
>>>> We did see this behavior in 7.6, but it's definitely worse in 7.8.
>>>> 
>>>> Incidentally, has there been any interest in a work-stealing scheduler?
>>>> There was a discussion from about 2 years ago, in which Simon Marlow
>>> noted
>>>> it might be tricky, but it would definitely help in situations like this.
>>>> 
>>>> John L.
>>>> 
>>>> On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com>
>>> wrote:
>>>> 
>>>>> John,
>>>>> 
>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave more
>>>>> like -N4.
>>>>> 
>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>> Atom
>>>>> and was stuck.
>>>>> 
>>>>> Mike
>>>>> 
>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
>>>>> 
>>>>> By any chance do the delays get shorter if you run your program with
>>> `+RTS
>>>>> -C0.005` ?  If so, I suspect you're having a problem very similar to
>>> one
>>>>> that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
>>>>> reason), involving possible misbehavior of the thread scheduler.
>>>>> 
>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com>
>>> wrote:
>>>>> 
>>>>>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>>> 
>>>>>> I moved from 7.6 to 7.8 and my application behaves very differently. I
>>>>>> have three threads, an application thread that plots data with
>>> wxhaskell or
>>>>>> sends it over a network (depends on settings), a thread doing usb bulk
>>>>>> writes, and a thread doing usb bulk reads. Data is moved around with
>>> TChan,
>>>>>> and TVar is used for coordination.
>>>>>> 
>>>>>> When the application was compiled with 7.6, my stream of usb traffic
>>> was
>>>>>> smooth. With 7.8, there are lots of delays where nothing seems to be
>>>>>> running. These delays are up to 40ms, whereas with 7.6 delays were a
>>> 1ms or
>>>>>> so.
>>>>>> 
>>>>>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
>>> fine
>>>>>> without with -N2/4.
>>>>>> 
>>>>>> The program is compiled -O2 with profiling. The -N2/4 version uses
>>> more
>>>>>> memory,  but in both cases with 7.8 and with 7.6 there is no space
>>> leak.
>>>>>> 
>>>>>> I tired to compile and use -ls so I could take a look with
>>> threadscope,
>>>>>> but the application hangs and writes no data to the file. The CPU
>>> fans run
>>>>>> wild like it is in an infinite loop. It at least pops an unpainted
>>>>>> wxhaskell window, so it got partially running.
>>>>>> 
>>>>>> One of my libraries uses option -fsimpl-tick-factor=200 to get around
>>> the
>>>>>> compiler.
>>>>>> 
>>>>>> What do I need to know about changes to threading and event logging
>>>>>> between 7.6 and 7.8? Is there some general documentation somewhere
>>> that
>>>>>> might help?
>>>>>> 
>>>>>> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and
>>>>>> installed myself, after removing 7.6 with apt-get.
>>>>>> 
>>>>>> Any hints appreciated.
>>>>>> 
>>>>>> Mike
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Glasgow-haskell-users mailing list
>>>>>> Glasgow-haskell-users at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 



From jwlato at gmail.com  Thu Oct 30 16:36:21 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 30 Oct 2014 09:36:21 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <630636C9-5471-41B0-BFFB-DACEE47903A9@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <CAJ727GgdtTsQanz1K6aKbY1bAx-Vqfp8auLRmGzt3UtDx-93Hw@mail.gmail.com>
 <1414628541-sup-9692@sabre>
 <CAJ727Gjg1qJ4kTgCYWLhksKajZ0ZSowAUKmBguuGb8=McN7RRw@mail.gmail.com>
 <1414629638-sup-1751@sabre>
 <630636C9-5471-41B0-BFFB-DACEE47903A9@proclivis.com>
Message-ID: <CAJ727GgkLa3mZvfun-Tk9ee_67QUABnX30K3sxV+jXu_DpXykw@mail.gmail.com>

Hmm, I think maybe part of the problem is in your STM blocks.

On Thu, Oct 30, 2014 at 8:50 AM, Michael Jones <mike at proclivis.com> wrote:

> My hope is that if my threads are doing IO, the scheduler acts when there
> is an IO action with delay, or when STM blocks, etc.
>
> So at the end of my pipe out, I have:
>
> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool ->
> ProcessT m (Spec, String) ()
> sendTransactions dev dts = repeatedly $ do
>   dts' <- liftIO $ atomically $ readTVar dts
>   when (dts' == True) (do
>       (_, transactions) <- await
>       liftIO $ sendOut dev transactions)
>

When the dts TVar is false, this will just spin, causing the thread to keep
running.  Can you change it to something like:

  _okToProceed <- liftIO $ atomically $ do
      dts' <- readTVar dts
      when (not dts') retry
  (_,transactions) <- await
  liftIO $ sendOut dev transactions

I think this should be better, because now, if dts is False, the STM
transaction will block, allowing the thread to be descheduled.  Furthermore
it won't be rescheduled until another thread has updated dts.

It looks like returnTransactionResults may suffer from the same issue, you
should be able to fix it in a similar manner.

John L.


>
> And my pipe in:
>
> returnTransactionResults :: MonadIO m => SMBusDevice DeviceDC590 -> TVar
> Bool -> SourceT m (Spec, Char)
> returnTransactionResults dev dts = repeatedly $ do
>   (status, spec) <- liftIO $ readIn2 dev
>   oldDts <- liftIO $ atomically $ readTVar dts
>   let dts' = (ord $ status!!1) .&. 0x20
>   let newDts = dts' /= 0
>   when (oldDts /= newDts) (
>     liftIO $ atomically $ writeTVar dts newDts)
>   when (length spec /= 0) (mapM_ (\ch -> yield (executeSpec, ch)) spec)
>
> sendOut will do a usb bulk write, and readIn2 will do a use bulk read.
> Hopefully, somewhere in the usb code IO blocks for an interrupt (probably
> in libusb), and that allows the scheduler to switch threads. Given the
> behavior, I assume this is not the case, and it requires time slicing to
> switch threads.
>
> I also send data between the in/out pipes via TChan. Remembering that each
> pipe is in a thread, hopefully if a readTChan blocks, the scheduler
> reschedules and the other thread runs.
>
> For context, I do a lot of RTOS work, so my worldview of the expected
> behavior comes from that perspective.
>
> Mike
>
>
> On Oct 29, 2014, at 6:41 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
>
> > Yes, that's right.
> >
> > I brought it up because you mentioned that there might still be
> > occasional delays, and those might be caused by a thread not being
> > preemptible for a while.
> >
> > Edward
> >
> > Excerpts from John Lato's message of 2014-10-29 17:31:45 -0700:
> >> My understanding is that -fno-omit-yields is subtly different.  I think
> >> that's for the case when a function loops without performing any heap
> >> allocations, and thus would never yield even after the context switch
> >> timeout.  In my case the looping function does perform heap allocations
> and
> >> does eventually yield, just not until after the timeout.
> >>
> >> Is that understanding correct?
> >>
> >> (technically, doesn't it change to yielding after stack checks or
> something
> >> like that?)
> >>
> >> On Thu, Oct 30, 2014 at 8:24 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >>
> >>> I don't think this is directly related to the problem, but if you have
> a
> >>> thread that isn't yielding, you can force it to yield by using
> >>> -fno-omit-yields on your code.  It won't help if the non-yielding code
> >>> is in a library, and it won't help if the problem was that you just
> >>> weren't setting timeouts finely enough (which sounds like what was
> >>> happening). FYI.
> >>>
> >>> Edward
> >>>
> >>> Excerpts from John Lato's message of 2014-10-29 17:19:46 -0700:
> >>>> I guess I should explain what that flag does...
> >>>>
> >>>> The GHC RTS maintains capabilities, the number of capabilities is
> >>> specified
> >>>> by the `+RTS -N` option.  Each capability is a virtual machine that
> >>>> executes Haskell code, and maintains its own runqueue of threads to
> >>> process.
> >>>>
> >>>> A capability will perform a context switch at the next heap block
> >>>> allocation (every 4k of allocation) after the timer expires.  The
> timer
> >>>> defaults to 20ms, and can be set by the -C flag.  Capabilities perform
> >>>> context switches in other circumstances as well, such as when a thread
> >>>> yields or blocks.
> >>>>
> >>>> My guess is that either the context switching logic changed in
> ghc-7.8,
> >>> or
> >>>> possibly your code used to trigger a switch via some other mechanism
> >>> (stack
> >>>> overflow or something maybe?), but is optimized differently now so
> >>> instead
> >>>> it needs to wait for the timer to expire.
> >>>>
> >>>> The problem we had was that a time-sensitive thread was getting
> scheduled
> >>>> on the same capability as a long-running non-yielding thread, so the
> >>>> time-sensitive thread had to wait for a context switch timeout (even
> >>> though
> >>>> there were free cores available!).  I expect even with -N4 you'll
> still
> >>> see
> >>>> occasional delays (perhaps <5% of calls).
> >>>>
> >>>> We've solved our problem with judicious use of `forkOn`, but that
> won't
> >>>> help at N1.
> >>>>
> >>>> We did see this behavior in 7.6, but it's definitely worse in 7.8.
> >>>>
> >>>> Incidentally, has there been any interest in a work-stealing
> scheduler?
> >>>> There was a discussion from about 2 years ago, in which Simon Marlow
> >>> noted
> >>>> it might be tricky, but it would definitely help in situations like
> this.
> >>>>
> >>>> John L.
> >>>>
> >>>> On Thu, Oct 30, 2014 at 8:02 AM, Michael Jones <mike at proclivis.com>
> >>> wrote:
> >>>>
> >>>>> John,
> >>>>>
> >>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
> more
> >>>>> like -N4.
> >>>>>
> >>>>> Thanks. This saves my project, as I need to deploy on a single core
> >>> Atom
> >>>>> and was stuck.
> >>>>>
> >>>>> Mike
> >>>>>
> >>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
> >>>>>
> >>>>> By any chance do the delays get shorter if you run your program with
> >>> `+RTS
> >>>>> -C0.005` ?  If so, I suspect you're having a problem very similar to
> >>> one
> >>>>> that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some
> >>>>> reason), involving possible misbehavior of the thread scheduler.
> >>>>>
> >>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com>
> >>> wrote:
> >>>>>
> >>>>>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
> >>>>>>
> >>>>>> I moved from 7.6 to 7.8 and my application behaves very
> differently. I
> >>>>>> have three threads, an application thread that plots data with
> >>> wxhaskell or
> >>>>>> sends it over a network (depends on settings), a thread doing usb
> bulk
> >>>>>> writes, and a thread doing usb bulk reads. Data is moved around with
> >>> TChan,
> >>>>>> and TVar is used for coordination.
> >>>>>>
> >>>>>> When the application was compiled with 7.6, my stream of usb traffic
> >>> was
> >>>>>> smooth. With 7.8, there are lots of delays where nothing seems to be
> >>>>>> running. These delays are up to 40ms, whereas with 7.6 delays were a
> >>> 1ms or
> >>>>>> so.
> >>>>>>
> >>>>>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs
> >>> fine
> >>>>>> without with -N2/4.
> >>>>>>
> >>>>>> The program is compiled -O2 with profiling. The -N2/4 version uses
> >>> more
> >>>>>> memory,  but in both cases with 7.8 and with 7.6 there is no space
> >>> leak.
> >>>>>>
> >>>>>> I tired to compile and use -ls so I could take a look with
> >>> threadscope,
> >>>>>> but the application hangs and writes no data to the file. The CPU
> >>> fans run
> >>>>>> wild like it is in an infinite loop. It at least pops an unpainted
> >>>>>> wxhaskell window, so it got partially running.
> >>>>>>
> >>>>>> One of my libraries uses option -fsimpl-tick-factor=200 to get
> around
> >>> the
> >>>>>> compiler.
> >>>>>>
> >>>>>> What do I need to know about changes to threading and event logging
> >>>>>> between 7.6 and 7.8? Is there some general documentation somewhere
> >>> that
> >>>>>> might help?
> >>>>>>
> >>>>>> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball
> and
> >>>>>> installed myself, after removing 7.6 with apt-get.
> >>>>>>
> >>>>>> Any hints appreciated.
> >>>>>>
> >>>>>> Mike
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Glasgow-haskell-users mailing list
> >>>>>> Glasgow-haskell-users at haskell.org
> >>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141030/59c435d7/attachment-0001.html>