Sreenidhi Nair | 29 Oct 16:27 2014
Picon

Irreducible predicates error in Template Haskell

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
Michael Jones | 29 Oct 07:18 2014

Thread behavior in 7.8.3

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
Yitzchak Gale | 28 Oct 21:58 2014

Re: GHC 7.4.2 on Ubuntu Trusty

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
Tom Murphy | 26 Oct 20:28 2014
Picon

Hiding module *exports*

(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
Barney Hilken | 25 Oct 15:53 2014

Recursion on TypeNats

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.
Yitzchak Gale | 22 Oct 14:50 2014

Re: GHC 7.4.2 on Ubuntu Trusty

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
Yitzchak Gale | 22 Oct 12:48 2014

GHC 7.4.2 on Ubuntu Trusty

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
Evan Laforge | 22 Oct 02:02 2014
Picon

ghci balkiness on OS X?

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?
Jeremy | 20 Oct 14:53 2014
Picon

Dynamic only GHC

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.
Malcolm Gooding | 17 Oct 00:19 2014
Picon

Hiding import behaviour

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.
Adam Gundry | 16 Oct 22:49 2014

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/

Gmane