gmane.comp.lang.haskell.glasgow.user

A language extension for dealing with Prelude.foldr vs Foldable.foldrand similar dilemmas

Daniel Gorín — 2013-05-24T00:27:02

Hi all,

Given the ongoing discussion in the libraries mailing list on replacing (or removing) list functions in the Prelude in favor of the Foldable / Traversable generalizations, I was wondering if this wouldn't be better handled by a mild (IMO) extension to the module system. 

In a nutshell, the idea would be 1) to allow a module to export a specialized version of a symbol (e.g., Prelude could export Foldable.foldr but with the specialized type (a -> b -> b) -> b -> [a] -> b) and 2) provide a disambiguation mechanism by which when a module imports several versions of the same symbol (each, perhaps, specialized), a sufficiently general type is assigned to it.

The attractive I see in this approach is that (enabling an extension) one could just import and use Foldable and Traversable (and even Category!) without qualifying nor hiding anything; plus no existing code would break and beginners would still get  the friendlier error of the monomorphic functions. I also expect it to be relatively easy to impleme

nightly builds: empty directory

Henning Thielemann — 2013-05-20T07:10:14

The page

    http://www.haskell.org/ghc/download

refers to directories for the nightly builds, that are actually empty:

    http://www.haskell.org/ghc/dist/current/dist/
    http://www.haskell.org/ghc/dist/stable/dist/

:-(

A type not inferred with RankNTypes

Akio Takano — 2013-05-13T02:47:03

Hi,

The attached program does not typecheck if I don't include a type signature
for 'bar' (the line C). I can't figure out if this is a limitation in the
type system or a bug in GHC. One thing that confuses me is that replacing
the line (B) with (A) makes the program typecheck.

Could anyone help me figuring out what is going on?

I'm using GHC 7.6.2. The error was:

 % ghc forall.hs
[1 of 1] Compiling Foo              ( forall.hs, forall.o )

forall.hs:18:11:
    Could not deduce (Fractional a) arising from the literal `0.1'
    from the context (Num (Scalar t), Scalar t ~ a)
      bound by a type expected by the context:
                 (Num (Scalar t), Scalar t ~ a) => AD t
      at forall.hs:18:7-13
    Possible fix:
      add (Fractional a) to the context of
        a type expected by the context:
          (Num (Scalar t), Scalar t ~ a) => AD t
        or the inferred type of bar :: a
    In the first argument of `foo', namely `0.1'
    In the expression: foo 0.1
    In an equation for `bar': bar = f

Missing snapshots

Mateusz Kowalczyk — 2013-05-12T12:10:49

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

On the GHC download page [1], there are no available snapshots. Both
HEAD and STABLE branch dist directories are empty.

Any idea what the deal is?

[1] - http://www.haskell.org/ghc/download
- -- 
Mateusz K.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5
eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B
ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o
f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA
973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/
q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb
C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+
+OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo
ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB
T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq
haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyM

Why do remaining HECs busy-wait during unsafe-FFI calls?

Herbert Valerio Riedel — 2013-05-06T11:29:29

Hello,

Recently, I stumbled over E.Z.Yang's "Safety first: FFI and
threading"[1] post and then while experimenting with unsafe-imported FFI
functions I've noticed a somewhat surprising behaviour:

Consider the following contrived program:

--8<---------------cut here---------------start------------->8---
import Foreign.C
import Control.Concurrent
import Control.Monad
import Data.Time.Clock.POSIX (getPOSIXTime)

foreign import ccall unsafe "unistd.h sleep" c_sleep_unsafe :: CUInt -> IO CUInt

main :: IO ()
main = do
    putStrLnTime "main started"
    _ <- forkIO (sleepLoop 10 >> putStrLnTime "sleepLoop finished")
    yield
    putStrLnTime "after forkIO"
    threadDelay (11*1000*1000) -- 11 seconds
    putStrLnTime "end of main"
  where
    putStrLnTime s = do
t <- getPOSIXTime
        putStrLn $ init (show t) ++ "\t" ++ s

    sleepLoop n = do
        n' <- c_sleep_unsafe n
        unless (n' == 0) $ do
            putStrLnTime "c_sleep_unsafe got interrupted"
            sleepLoop n'

--8<---------------

Simplifying Core pretty-printing via GHC API?

Conal Elliott — 2013-05-01T21:13:00

I'm using the GHC API to compile Haskell source code to Core. I'd like to
pretty-print the result with the sort of simplifications I get with
-dsuppress-type-applications, -dsuppress-uniques, etc (used in combination
with -ddump-simpl on ghc's command line). How can I set these options via
the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)?

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

ANNOUNCE: GHC version 7.6.3

Ian Lynagh — 2013-04-21T13:23:02

   =============================================================
    The (Interactive) Glasgow Haskell Compiler -- version 7.6.3
   =============================================================

The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3.

This is a bugfix release relative to 7.6.2, so we recommend upgrading.

Full release notes are here:

  http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/release-7-6-3.html

How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.


Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler

Why is GHC so much worse than JHC when computing the Ackermannfunction?

Mikhail Glushenkov — 2013-04-20T08:55:10

Hi all,

This came up on StackOverflow [1]. When compiled with GHC (7.4.2 &
7.6.2), this simple program:

main = print $ ack 4 1
  where ack :: Int -> Int -> Int
        ack 0 n = n+1
        ack m 0 = ack (m-1) 1
        ack m n = ack (m-1) (ack m (n-1))

consumes all available memory on my machine and slows down to a crawl.
However, when compiled with JHC it runs in constant space and is about
as fast as the straightforward Ocaml version (see the SO question for
benchmark numbers).

I was able to fix the space leak by using CPS-conversion, but the
CPS-converted version is still about 10 times slower than the naive
version compiled with JHC.

I looked both at the Core and Cmm, but couldn't find anything
obviously wrong with the generated code - 'ack' is compiled to a
simple loop of type 'Int# -> Int# -> Int#'. What's more frustrating is
that running the program with +RTS -hc makes the space leak
mysteriously vanish.

Can someone please explain where the space leak comes from and if it's
possible to further

mask, catch, myThreadId, throwTo

Felipe Almeida Lessa — 2013-04-15T19:57:46

Hey!

I have some code that is not behaving the way I thought it should.

The gist of it is

  sleeper =
    mask_ $
    forkIOWithUnmask $ \restore ->
      forever $
        restore sleep `catch` throwBack

  throwBack (Ping tid) = myThreadId >>= throwTo tid . Pong
  throwBack (Pong tid) = myThreadId >>= throwTo tid . Ping

Since (a) throwBack is executed on a masked state, (b) myThreadId is
uninterruptible, and (c) throwTo is uninterruptible, my understanding
is that the sleeper thread should catch all PingPong exceptions and
never let any one of them through.

However, that's not what I am seeing.  Running with -threaded and at
least -N2 I can reliably get sleeper to be killed.  Please see the
complete code at:

  https://gist.github.com/meteficha/5390079

The expected result is 100 Pongs and 0 Pings.  Running with -N1 that's
what I get.  Running with -N2 I get a few Pongs and then 1 Ping.
Running with -N3 or more usually gives me just 1 Ping and not a single
Pong.

I'm testing with GHC 7.4.1.  I've trie

Using old code generator

Roman Cheplyaka — 2013-04-12T10:26:55

Hi,

I'm looking for a workaround for #7574 [1] (I run into it when trying to
build the 'statistics' package with profiling enabled with GHC HEAD.)

The symptom is

  ghc-stage2: panic! (the 'impossible' happened)
    (GHC version 7.7.20130407 for i386-unknown-linux):
    allocateRegsAndSpill: Cannot read from uninitialized register
      %vI_cCdO

[1]: http://hackage.haskell.org/trac/ghc/ticket/7574

Do I understand correctly that this bug is specific to the new codegen?
If so, is it possible to ask the compiler to use the old codegen?
Is it okay to mix together packages compiled with both codegens?

Thanks,
Roman

porting to uClibc-based 686 Linux

Dubiousjim — 2013-04-01T17:11:20

My preferred system is a 686 Linux distro based on uClibc. No ghc
binaries available yet there. I'd like to remedy that.

I have ghc 7.4.2 running on an 686 Linux distro based on glibc (and also
on two different versions of Mac OS X, but they seem more distant and so
less likely to be helpful). In fact, ghc 7.6.2 binaries are also
available for that system, but I'd like to keep in synch with the last
released Haskell platform (which is what I've got on the Macs). That's
supposed to be updated in May, so if it's only possible to port ghg >=
7.6.x to my target system, that won't be so terrible. I'm hoping though
to be able to port a ghc < 7.8.x, because I don't expect to see that
version in any soon-to-be-released Haskell platform. (I mention this
because
http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation says:
"Support for cross-compilation works reasonably well in 7.8.1. Previous
versions had various issues which are usually work-aroundable.")

Ok, so I'm getting stuck trying to build a version of ghc

Problems installing 7.6.2 on MACOS

Dominic Steinitz — 2013-03-27T11:40:13

Hi,

I followed the instructions pointed to from here: http://www.haskell.org/ghc/download_ghc_7_6_2#macosx_x86_64





But sadly I get:



and



Any advice on how to get 7.6.2 working would be much appreciated.

Dominic.

Here's some more information:


7.4.1 still works fine:

ghc and aarch64?

Jens Petersen — 2013-03-26T02:33:13

I am curious if anyone has started or is planning to work on porting
GHC to the new ARM 64bit architecture AArch64 for Linux?

Jens

Allowing (Char ~ Bool => Void)?

Shachaf Ben-Kiki — 2013-03-24T09:16:51

Is there a good reason that GHC doesn't allow any value of type (Char
~ Bool => Void), even undefined?

There are various use cases for this. It's allowed indirectly, via
GADT pattern matches -- "foo :: Is Char Bool -> Void; foo x = case x
of {}" (with EmptyCase in HEAD) -- but not directly.

One thing this prevents, for instance, is CPSifying GADTs:

    data Foo a = a ~ Char => A | a ~ Bool => B -- valid
    newtype Bar a = Bar { runBar :: forall r. (a ~ Char => r) -> (a ~
Bool => r) -> r } -- unusable

Trying to use a type like the latter in practice runs into problems
quickly because one needs to provide an absurd value of type (Char ~
Bool => r), which is generally impossible (even if we're willing to
cheat with ⊥!). It seems that this sort of thing should be doable.

    Shachaf

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

Does GHC on cygwin have an I/O manager?

kudah — 2013-03-24T08:19:14

I've been desperate to get any semblance of I/O performance from
Haskell on Windows. Does ghc still build under cygwin, and if so, does
the cygwin build have a working I/O manager?

Also, is it possible yet to build a ghc cross-compiler targeting
windows?

Compiled code

migmit — 2013-03-22T23:00:07

Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason?

Seems like the answer is "yes" — by creating a fake .hs file (with no real content) and touch-in .hi and .o files I tricked ghc so that it didn't attempt to recompile the module, so the information in .hi and .o files is sufficient. But ghc insists on having the .hs file around, and I didn't find a way to turn it off. Is there any? Or there is a specific reason not to have it?

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

ImplicitParams and MonoLocalBinds

Roman Cheplyaka — 2013-03-22T08:39:45

The value of the following expression

  let ?y = 2  in
  let  p = ?y in
  let ?y = 1  in
  p

depends on whether the second binding is generalised.

MonomorphismRestriction makes it not generalise, hence the value is 2.

What surprises me is that MonoLocalBinds doesn't have this effect.

  Prelude> :set -XImplicitParams -XNoMonomorphismRestriction -XMonoLocalBinds 
  Prelude> let ?y = 2 in let p = ?y in let ?y = 1 in p
  1

What's going on here?

Roman

Polymorphic implicit parameters

Roman Cheplyaka — 2013-03-20T08:58:04

I'm curious as to why GHC doesn't accept the following (contrived)
module:

  {-# LANGUAGE ImplicitParams, RankNTypes #-}

  f :: (?g :: (forall a . a -> a)) => a -> a
  f = ?g

The error message is:

  Illegal polymorphic or qualified type: forall a. a -> a
  In the type signature for `f':
    f :: ?g :: (forall a. a -> a) => a -> a

It's not a big deal since one can wrap the polymorphism in a newtype,
but it's somewhat unexpected.

Roman

Does GHC 7.8 make targeting bare metal ARM any easier?

Jeremy Shaw — 2013-03-20T01:07:40

There have been at least a couple projects, such as hOp and HaLVM
which attempt to run GHC on the bare metal or something similar.

Both these projects required a substantial set of patches against GHC
to remove dependencies things like POSIX/libc. Due to the highly
invasive nature, they are also highly prone to bitrot.

With GHC 7.8, I believe we will be able to cross-compile to the
Raspberry Pi platform. But, what really appeals to me is going that
extra step and avoiding the OS entirely and running on the bare metal.
Obviously, you give up a lot -- such as drivers, network stacks, etc.
But, there is also a lot of potential to do neat things, and not have
to worry about properly shutting down an embedded linux box.

Also, since the raspberry pi is a very limited, uniform platform,
(compared to general purpose PCs) it is feasible to create network
drivers, etc, because only one chipset needs to be supported.
(Ignoring issues regarding binary blobs, undocumented chipsets, usb
WIFI, etc).

I'm wondering if th

Release plans

Ian Lynagh — 2013-03-19T22:35:26

Hi all,

Thank you to everyone who gave us feedback on when we should release
7.8.1, and on future release plans in general. We've looked at all the
responses, and we think that the best plan is to continue to make major
releases annually, with minor "patch-level" releases between them.

Additionally, we may recommend particular snapshots, and provide binary
builds for all tier-1 platforms, for people who wish to test new
features etc in HEAD.

There is more detail on how all this will work here:
    http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases



We will therefore aim for a 7.8.1 release in October. We do not
currently expect to make a 7.6.3 release, although that may
change if serious bugs in 7.6.2 are discovered.


Would a 7.7.x recommended snapshot be useful to you? Tell us if you
want one. Compared to 7.6 it would contain:
  * polykinded Typeable library
  * major improvements in DPH (vectorisation avoidance, new vectoriser)
  * type holes
  * rebindable list syntax
  * major ch

scope invariants in core

Ranjit Jhala — 2013-03-18T18:06:00

Hi all,

I have been manipulating CoreExpr to convert it to A-Normal Form.
Mostly, things have been working fine, but I hit an error this
morning of the form:

    lq_anf__d11u is out of scope

where lq_anf__d11u is a binder I have introduced in the transformed expression

    Data.ByteString.Internal.c_strlen =
   (\ (ds_d11l :: GHC.Ptr.Ptr Foreign.C.Types.CChar) ->
      case ds_d11l of lq_anf__d11t { GHC.Ptr.Ptr ds_d11n ->
      let {
        lq_anf__d11x
          :: GHC.Prim.State# GHC.Prim.RealWorld
             -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Word.Word32 #)
        [LclId]
        lq_anf__d11x =
          \ (ds_d11q :: GHC.Prim.State# GHC.Prim.RealWorld) ->
            case {__pkg_ccall main strlen GHC.Prim.Addr#
                         -> GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
GHC.Prim.Word# #)}
                   ds_d11n ds_d11q
            of lq_anf__d11u { __DEFAULT ->
            case lq_anf__d11u of lq_anf__d11v { (# d