gmane.comp.lang.haskell.glasgow.user

RE: A language extension for dealing with Prelude.foldr vsFoldable.foldrand similar dilemmas

Simon Peyton-Jones — 2013-05-24T16:00:00

Oh my!  Now it's getting complicated.  
* I suppose that if Data.List re-exports foldr, it would go with the more specific type.  
* In your example, can I also use the more-polymorphic foldr, perhaps by saying Data.Foldable.foldr?
* I wonder what would happen if Data.Foo specialised foldr in a different way, and some module imported both Data.List and Data.Foo.  Maybe it would be ok if one of the two specialised types was more specific than the other but not if they were comparable?
* What happens for classes?  Can you specialise the signatures there?  And make instances of that specialised class?
* Ditto data types

It feel a bit like a black hole to me.

Simon
| -----Original Message-----
| From: Daniel Gorín [mailto:dgorin< at >dc.uba.ar]
| Sent: 24 May 2013 08:42
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users< at >haskell.org
| Subject: Re: A language extension for dealing with Prelude.foldr vs
| Foldable.foldr and similar dilemmas
| 
| On May 24, 2013, at 9:28 AM, Simon Peyton-Jones wrote:
| 
| > How abou

Re: A language extension for dealing with Prelude.foldr vsFoldable.foldrand similar dilemmas

Daniel Gorín — 2013-05-24T07:42:29


It would not be the same! Using your example one will get that the following fails to compile:


The problem is that Data.List.foldr and Data.Foldable.foldr are here different symbols with the same name. 
This is precisely why Foldable, Traversable, Category, etc are awkward to use. The proposal is to make Data.List reexport Data.Foldable.foldr (with a more specialized type) so that the module above can be accepted.

Thanks,
Daniel

RE: A language extension for dealing with Prelude.foldr vsFoldable.foldrand similar dilemmas

Simon Peyton-Jones — 2013-05-24T07:28:40

How about (in Haskell98)

module Data.List ( foldr, ...)
import qualified Data.Foldable
foldr :: (a -> b -> b) -> b -> [a] -> b
foldr = Data.Foldable.foldr

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces< at >haskell.org [mailto:glasgow-haskell-
| users-bounces< at >haskell.org] On Behalf Of Daniel Gorín
| Sent: 24 May 2013 01:27
| To: glasgow-haskell-users< at >haskell.org
| Subject: A language extension for dealing with Prelude.foldr vs Foldable.foldr
| and similar dilemmas
| 
| 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 d

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

Re: porting to uClibc-based 686 Linux

Dubiousjim — 2013-05-21T06:02:55

Just to follow-up on my earlier emails about trying to port GHC to a
uClibc-based Linux, I finally did get this working, on both x86 and
x86_64.

There were a bunch of small stumbling blocks and one big one that I
finally traced to the fact that the native gcc on my target system had
the Gentoo hardening patches, and one needed to supply a "-nopie" option
to selectively disable these. (This was counter-intuitive because the
error messages made it seem that what was wanted was to *enable* PIE
compiling, not to disable it.) I finally identified this issue when
reading http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml.

Anyway, I've written up what it took to port GHC to our system on our
distro's wiki:

http://wiki.alpinelinux.org/wiki/Porting_GHC_to_Alpine

Perhaps that might help others attempting similar feats, or might help
the ghc devs working on the build system to make this less painful in
the future.

Re: nightly builds: empty directory

Mateusz Kowalczyk — 2013-05-20T17:27:15

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

On 20/05/13 17:08, Carter Schonwald wrote:
refers to directories for the nightly builds, that are actually empty:
http://www.haskell.org/ghc/**dist/stable/dist/<http://www.haskell.org/ghc/dist/stable/dist/>
I'd like to add that there's already a thread about this very thing on
ghc-devs at [1].

[1] - http://www.mail-archive.com/ghc-devs< at >haskell.org/msg01214.html

- -- 
Mateusz K.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRmlzzAAoJEM1mucMq2pqX120P/0517GGdtRUHzbGUNreTR9yz
b4UW0GbznnO4mzKGemSWjSQLH8AeFCPPOnCNO2EqfytyexJ58y8UzjwPvbxtB5Mf
H0xmWNcLoUmmPgRSfpKIw4MlOTpKYhpv8N2Equl26nH22lmtsG6S80ex8d7FROcm
8QIZ/NlK7T77IjqxKHZX4D4ZMWGqTQG3Q3RAaYnHSHbc1ApZ0Io8lj8bPUXQeiSe
sOLYW2V9wL5DQW43KxGnr4cCOFZugSiioCDlsN8Ko9cREU2qLEcXgmsN9iV0zaR2
ScEuKOTw/jSWAyp9T/ywV52XsByhpQKCe90rqXWdRJMyU7ZJtG5OqBftzSWNJppS
0WaQ/NxqK0xtfHXxS1oCtxyoIIfpq+2Lu/z0Rahi9ahXJ3ltlZOFjmr1utETf0HN
Jb2EhjaHfqMZ9PYx7P6DKpIzMkgWSRUMlBsQuRj2idhD8Qn5YX2KeZnt+xjclVA0
xrrtHQl

Re: nightly builds: empty directory

Carter Schonwald — 2013-05-20T16:08:05

Henning, you can git clone ghc from github and follow the directions on the
trac wiki to build your own ghc they will correspond with head.

On Monday, May 20, 2013, Henning Thielemann wrote:

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

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/

:-(

RE: A type not inferred with RankNTypes

Simon Peyton-Jones — 2013-05-13T14:55:25

Interesting example.  It's a fairly-fundamental limitation of type inference.   Here is a simpler version

foo :: forall a. (forall t. (t~a) => t) -> a

Re: Missing snapshots

Páli Gábor János — 2013-05-13T11:51:47

For your information, the FreeBSD daily builds are available dating
back to January 2012 here (for both HEAD and STABLE, i386 and amd64):

http://haskell.inf.elte.hu/ghc/dist/freebsd8/

I am aware that it may not be in the interest of a greater crowd (and
the original question was probably referring to the Linux or Mac OS X
builds) but it may be useful to know that.

Re: A type not inferred with RankNTypes

Adam Gundry — 2013-05-13T09:16:56

Hi,


On 13/05/13 03:47, Akio Takano wrote:


I think that this is a relatively subtle point about constraint solving
during type inference. I'll work through what is going on to try to make
sense of your results. Apologies if this is far too much information.
(Full disclosure: I don't really understand GHC's constraint solver, but
I know enough to make some intelligent guesses.)

TL;DR: The constraint solver is not stable under adding information, so
making extra hypotheses available can stop your program from
typechecking. This is a bad thing, but difficult to avoid.


The essence of your working example is


When checking bar, the constraint solver is given

exists a . forall t . Scalar t ~ a => Fractional (AD t)

which can be rewritten using the Fractional (AD t) instance to

exists a . forall t . Scalar t ~ a => Fractional (Scalar t)

and thence to

exists a . forall t . Fractional a

so the |Fractional a| constraint floats out to the top level, and bar is
given the type

Fractional a => a

(which speci

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

Re: Missing snapshots

Ian Lynagh — 2013-05-12T21:56:46

Yes, uploading new snapshots is waiting for me to find some time to
implement a way to upload without needing an account.

I've no idea what happened to the old ones, though.



Thanks
Ian

Re: Missing snapshots

Carter Schonwald — 2013-05-12T20:50:40

huh you're right!

I seem to recall that that snapshots hadn't been updated since december
while they were still up though...



On Sun, May 12, 2013 at 8:10 AM, Mateusz Kowalczyk
<fuuzetsu< at >fuuzetsu.co.uk>wrote:

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

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

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

Herbert Valerio Riedel — 2013-05-06T14:26:54


Is this the bound-main-thread issue? That is, would wrapping the main
thread in 'runInUnboundThread' help here?


that seems to be a rather good guess: I inhibited the GC by disabling
the idle-timer using "+RTS -N4 -I0" and with that the HEC
busy-waiting is gone;

So actually this isn't FFI-specific at all, as I could trigger the very
same effect by using a non-allocating/tight-loop evaluation such as the
following:

  do
    _ <- forkIO (evaluate (busyfun 0 0) >> putStrLnTime "busyfun finished")
  where
    busyfun :: Int -> Int -> Int
    busyfun !n !m = if m < 0 then n else busyfun (n+1) (m+1)


cheers,
  hvr

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

Andreas Voellmy — 2013-05-06T13:10:10

When an unsafe call is made, the OS thread currently running on the HEC
makes the call without releasing the HEC. If the main thread was on the run
queue of the HEC making the foreign unsafe call when the foreign call was
made, then no other HECs will pick up the main thread. Hence the two sleep
calls in your program happen sequentially instead of concurrently.

I'm not completely sure what is causing the busy wait, but here is one
guess: when a GC is triggered on one HEC, it signals to all the other HECs
to stop the mutator and run the collection.  This waiting may be a busy
wait, because the wait is typically brief.  If this is true, then since one
thread is off in a unsafe foreign call, there is one HEC that refuses to
start the GC and all the other HECs are busy-waiting for the signal.  The
GC could be triggered by a period of inactivity.  Again, this is just a
guess - you might try to verify this by turning off the periodic triggering
of GC and checking whether the start GC barrier is a busy-wait.



On

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<---------------

Re: Simplifying Core pretty-printing via GHC API?

Conal Elliott — 2013-05-02T01:28:20

I think I found an answer: invoke
parseStaticFlags<http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc/GHC.html#v:parseStaticFlags>,
passing in the flags specified as if on the ghc command line. For instance:

    parseStaticFlags $ noLoc <$> ["-dsuppress-uniques",
"-dsuppress-type-applications", "-dsuppress-idinfo"]

This call must be made before a compilation gets made. I'm (now) doing it
before calling runGhc for the first time.

Johan: I'm working toward making a GHC back-end that maps from Core to a
programmable logic architecture (similar to FPGA).

Re: Simplifying Core pretty-printing via GHC API?

Johan Tibell — 2013-05-01T22:59:43


I'd also be interested in the answer and whatever you're working on Conal.
I spend more time looking at core than I like and anything that can made
that time more efficient would be great.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users< at >haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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