Re: A modest proposal (re the Platform)

[Johan Tibell]

+1
On Jan 19, 2014 3:15 PM, "Mark Lentczner"  wrote:

> Looks like GHC 7.8 is pretty near release.
>
> And while I know that we really like to have a GHC out for a while, and
> perhaps see the .1 release, before we incorporate it into the Platform,
> this GHC, while including many new and anticipated things, seems pretty
> well hammered on.
>
> Combine that with the now two-month late (all my fault) HP release for
> 2013.4.0.0 isn't slated to really have all that much new in it, in part
> because it is the same GHC as the last HP release.
>
> Now - it would really look foolish, and taken poorly (methinks) if we
> release a HP this month - only to have GHC 7.8 release early Feb. Folks
> would really be head scratching, and wondering about the platform.
>
> SO - I'm proposing ditching the now late 2013.4.0.0 (I admit, I'm finding
> it hard to get excited by it!) and instead move right to putting out
> 2014.2.0.0 - aimed for mid-March to mid-April.
>
> This release would have several big changes:
>
>- GHC 7.8
>- New shake based build for the Platform
>- Support for validation via package tests
>- Support for a "server variant" (no OpenGL or other GUI stuff if we
>had any)
>- Automated version info w/historical version matrix page
>- Several significant packages: I'd like to see Aeson at the very
>least, updated OpenGL stuff
>
> I'd also propose changes for the Mac build (though this is obviously
> independent):
>
>- Built from GHC source, not dist. release. (guarantees consistent
>release)
>- Only 64bit (I know, controversial...)
>
> Thoughts?
>
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: More aggressive dictionary removal?

[Johan Tibell]

I think the difference between the inlinable and specialize pragma is
whether the specialization needs to be driven by the call site or not. If
you have a handful of known types you want to specialize for up front, you
can use the specialize pragma. If the set is large or unknown (like in the
case of container keys/value, the inlinable pragma does the right thing.)

On Thu, Jan 28, 2016 at 1:54 PM, Simon Peyton Jones 
wrote:

> Aggressive inlining is one way, but specialisation ought to get a long
> way, and makes fewer copies of the specialised code.
>
>
>
> It’s hard to help without a concrete example
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Conal
> Elliott
> *Sent:* 28 January 2016 00:05
> *To:* ghc-devs@haskell.org
> *Subject:* More aggressive dictionary removal?
>
>
>
> I'm looking for pointers on getting GHC to eliminate more overloading &
> polymorphism. I think this sort of thing mainly happens in the Specialise
> module. The default GHC flag settings get me a couple levels of
> monomorphization and dictionary removal, but I want to go further. I've
> tried -fspecialise-aggressively, but it didn't seem to make a difference,
> and I haven't found this flag described in the GHC user's guide. Anyone
> have pointers to more information?
>
> Thanks, - Conal
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: More aggressive dictionary removal?

[Johan Tibell]

The best way I know is to put INLINABLE on all functions with dictionaries
that you want removed. That's what we do in e.g. containers. The pragma is
perhaps a bit misnamed, as it doesn't only imply that we make the source of
the function available for inlining, but also that we specialize the
dictionary arguments at every call site, when known.

On Thu, Jan 28, 2016 at 1:04 AM, Conal Elliott  wrote:

> I'm looking for pointers on getting GHC to eliminate more overloading &
> polymorphism. I think this sort of thing mainly happens in the Specialise
> module. The default GHC flag settings get me a couple levels of
> monomorphization and dictionary removal, but I want to go further. I've
> tried -fspecialise-aggressively, but it didn't seem to make a difference,
> and I haven't found this flag described in the GHC user's guide. Anyone
> have pointers to more information?
>
> Thanks, - Conal
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Birthday greetings

[Johan Tibell]

Happy birthday!

On Tue, Jan 19, 2016 at 9:31 AM, raichoo  wrote:

> Happy Birthday!
>
> Thanks for all your work, I'm very happy with Haskell and GHC, especially
> now that I
> can use it at work :D.
>
> I've been digging through GHC for months now, hoping to contribute
> something back this year :)
>
> Kind regards,
> raichoo
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -XStrict: Why some binders are not made strict?

[Johan Tibell]

Agreed.

(Sorry for the sporadic communication. This is a very busy time at work.)

I thought about this a bit more recently.

Here's one way where I think "force every binder" goes wrong:

-- In a Strict module
f (Just x) = Just x

This is not the identity. This might matter in practice if a user defines a
data type, in a lazy module, that uses a lazy field to cache an expensive
calculation:

-- In a lazy module:
data CachedHash = CH a Int
mkCH x = CH x (expensiveHash x)

The intention here is that we only evaluate the expensive hash function
when needed. However, if we evaluate every binder this is no longer
transparent to users of the module, because doing this forces both fields:

f (CH x h) = CH x h

This also seems a bit "one sided" in that we do not evaluate expr in `Just
` under Strict, to not break modularity, but we would do it if you
pattern-matched on the contents of Just.

I'm also worried that we might make a choice here that we can't undo. I at
least understand the meaning of Strict in relation to strict languages.
"Evaluate every binder" is a new thing. Perhaps it deserves its own pragma,
StrictBinders.

On Mon, Dec 14, 2015 at 6:50 PM, Adam Sandberg Eriksson <
a...@sandbergericsson.se> wrote:

> Hello,
>
> Given the upcoming 8.0 feature freeze I think the correct approach for
> 8.0 is to document the current implementation (I'll try to do that this
> week).
>
> It would probably be good if interested parties would document their
> input in a ticket.
>
> Cheers,
> --Adam
>
>
> On Sat, 12 Dec 2015, at 12:55 AM, Roman Cheplyaka wrote:
> > Thanks Simon, this is an interesting and compelling interpretation. But
> > I'm wondering whether it is enough to specify the dynamic semantics
> > unambiguously.
> >
> > Two examples:
> >
> > 1.
> >
> >   let _ = undefined in ()
> >
> > Intuitively, since we are talking about /strictness/, this should
> > evaluate to bottom. However, it seems that your rule also admits () as
> > an answer; it is equivalent to () under lazy evaluation *and* it does
> > not create any thunks.
> >
> > 2.
> >
> >   f g = g undefined
> >
> > When compiled lazily, this code doesn't construct any thunks:
> >
> >   f = \r srt:SRT:[02v :-> undefined] [g_suM] g_suM undefined;
> >
> > So, under your rule, this is an admissible code for -XStrict, too. But
> > we can hardly call it strict.
> >
> > On 12/12/2015 12:38 AM, Simon Peyton Jones wrote:
> > > | As I said, I prefer this semantics mainly because it's easier to
> > > | explain: all variables (and underscores) bound in a strict module
> refer
> > > | to WHNF values. Do you have a similarly simple explanation for the
> > > | semantics you're suggesting?
> > >
> > > Here's one, which is roughly what the current implementation does
> (modulo bugs):
> > >
> > > * Code compiled under -XStrict constructs no thunks.
> > >
> > > So consider
> > >
> > > module M1 where data T = C Int Int
> > > module M2 where f n = C (n+1) (n-1)
> > > module M3 where g x = let C y z = f x in ...
> > >
> > > Look at M3.  Usually we'd get a thunk for (f 4), but not with
> -XStrict.  But even with -XStrict in M3, y,z might be bound to thunks.
> > >
> > > If you compile M2 with -XStrict, function f won't build thunks for
> (n+1), (n-1) but will evaluate them instead.
> > >
> > > If you compile M1 with StrictData, then C is made strict, so again M2
> will build no thunks even if M2 was compiled without -XStrict.
> > >
> > > I quite like this design.  It's not clear to me that anything useful
> is gained by forcing y and z in M3 before evaluating the body "...".
> > >
> > >
> > > So Roman's design makes sense, but so does the implemented design
> (modulo any bugs).  The trouble is that the implemented design is not well
> described.
> > >
> > > Simon
> > >
> > > | -Original Message-
> > > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> Roman
> > > | Cheplyaka
> > > | Sent: 11 December 2015 12:57
> > > | To: Johan Tibell 
> > > | Cc: ghc-devs@haskell.org
> > > | Subject: Re: -XStrict: Why some binders are not made strict?
> > > |
> > > | On 12/11/2015 02:21 PM, Johan Tibell wrote:
> > > | > If we force strictness all the way down it's not really
> call-by-value
> > > | > either, because the caller doesn't know what 

Re: -XStrict: Why some binders are not made strict?

[Johan Tibell]

I believe Scala has optional lazy values, but you could also consider in
strict languages if you do manual thunking.

If we force strictness all the way down it's not really call-by-value
either, because the caller doesn't know what to evaluate (I think).

In addition, making pattern matching strict in this way makes it hard to
mix and match strict and lazy data types (e.g. Maybe), because using a lazy
data type from another module will make it appear strict in your code
(hurting modularity).

On Fri, Dec 11, 2015 at 7:54 AM, Roman Cheplyaka  wrote:

> On 12/10/2015 04:34 PM, Johan Tibell wrote:
> > I'm snowed under but I promise I will try to reply soon! To think about
> > in the mean time: what do existing strict languages with pattern
> > matching do?
>
> Well, strict languages do not have lazy data to force to begin with, do
> they?
>
> Personally, I find the simple intuition of "all patterns are strict by
> default" rather appealing.
>
> E.g. I wouldn't expect the expressions
>
>   let (v1,v2) = a in f v2
>
> and
>
>   let (v1,v2) = a; v3 = v2 in f v3
>
> to have different semantics.
>
> If we decide to adopt this semantics, we need to address the meaning of
> the pattern
>
>   ~(v1, v2)
>
> under -XStrict. Intuitively, ~ should propagate to the subpatterns. An
> alternative is to disallow this pattern under -XStrict and require writing
> all ~s explicitly, which may get tedious:
>
>   ~(~v1, ~v2)
>   ~(~v1, ~(~v2, ~v3))
>   etc.
>
> We also need to ensure the consistency between this extension and the
> unlifted data types proposal [1], given their similarity. Interestingly, I
> don't see constructor patterns explained there either.
>
> [1]:
> https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Dynamicsemanticsofunliftedtypes
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Does the Strict extension make monadic bindings strict?

[Johan Tibell]

I believe this is just a bug, since the desugaring ought to be strict in
the \x.

On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan 
wrote:

> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument will have a
> bang pattern. But then this code:
>
> do x <- ...
>return (x + 1)
>
> which is just a syntactic sugar for `... >>= \x -> return (x + 1)`
> doesn't have the bang pattern in `x`.
>
> (See also a related email I sent to ghc-devs yesterday:
> https://mail.haskell.org/pipermail/ghc-devs/2015-December/010699.html)
>
> 2015-12-08 12:27 GMT-05:00 David Kraeutmann :
> > While there's a fundamental difference between (>>=) and let-bindings, it
> > might be worth adding to the docs that -XStrict only makes let bindings
> > strict.
> >
> >
> > On 12/08/2015 06:22 PM, Rob Stewart wrote:
> >
> > Are the following two programs equivalent with respect to the strictness
> > of `readFile`?
> >
> > --8<---cut here---start->8---
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > main = do
> >   !contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > And:
> >
> > --8<---cut here---start->8---
> > {-# LANGAUGE Strict #-}
> >
> > module Main where
> >
> > main = do
> >   contents <- readFile "foo.txt"
> >   print contents
> > --8<---cut here---end--->8---
> >
> > The documentation on "Strict-by-default pattern bindings" gives
> > let/where binding as an example, but there is not a monadic bind example.
> >
> http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-by-default-pattern-bindings
> >
> > Inspecting GHC Core for these two programs suggests that
> >
> > !contents <- readFile "foo.txt"
> >
> > is not equivalent to (with Strict enabled):
> >
> > contents <- readFile "foo.txt"
> >
> > Here's core using BangPatterns:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >case contents_asg of contents1_Xsk { __DEFAULT ->
> >print @ String $dShow_rYy contents1_Xsk
> >})
> >
> > Here's core using Strict:
> >
> > (readFile (unpackCString# "foo.txt"#))
> > (\ (contents_asg :: String) ->
> >print @ String $dShow_rYv contents_asg)
> >
> > Does this core align with the design of the Strict extension?
> >
> > If it does, are users going to understand that using Strict is going to
> > make let/where bindings strict, but is not going to make <- or >>=
> > bindings strict?
> >
> > --
> > Rob Stewart
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: -XStrict: Why some binders are not made strict?

[Johan Tibell]

I'm snowed under but I promise I will try to reply soon! To think about in
the mean time: what do existing strict languages with pattern matching do?

On Tue, Dec 8, 2015 at 3:42 PM, Simon Peyton Jones 
wrote:

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

Taking a step back

[Johan Tibell]

Friends,

I'm taking a step back from day-to-day library work.

There are two main reasons I use Haskell: on one hand I find writing
Haskell educational and fun. On the other I hope to make it a viable
alternative to existing mainstream languages. With recent changes to our
core libraries, and the general direction these are moving in, I believe
we're moving away from becoming a viable alternative to those mainstream
languages.

This has some practical implications for how I spend my Haskell hacking
time. Much of what I do is maintaining and working on libraries that are
needed for real world usage, but that aren't that interesting to work on.
I've lost the motivation to work on these.

I've decided to take a step back from the core maintenance work on cabal,
network, containers, and a few others* starting now. I've already found
replacement maintainers for these.

I still plan to hack on random side projects, including GHC, and to
continue coming to Haskell events and conference, just with a shorter bug
backlog to worry about. :)

-- Johan Tibell

* For now I will still hack on unordered-containers and ekg, as there are
some things I'd like to experiment with there.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

Yup, I think I have it figured out. Will just need to find the time to
write the remaining code.

On Tue, Sep 22, 2015 at 10:13 AM, Simon Peyton Jones 
wrote:

> Johan
>
>
>
> Sorry I’ve been buried.  Let’s fix a time for a Skype call if you’d like
> to chat about this stuff.
>
>
>
> Quick response to the below. I think that afterwards we want it to look
> like this:
>
>
>
> post-unarise
>
>
>
> f = \r [ ds1::Int#  ds2::Ptr ]
>
>   case ds1 of
>
>   0#  ->  
>
>  1#  -> 
>
>
>
> ds2 is the thing that contains either an Int or a char; ds1 is the tag
> that distinguishes htem.
>
>
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 14 September 2015 17:03
> *To:* Ryan Newton; Simon Peyton Jones
> *Cc:* Simon Marlow; ghc-devs@haskell.org
> *Subject:* Re: Converting unboxed sum types in StgCmm
>
>
>
> I've given this a yet some more thought. Given this simple core program:
>
>
>
> f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
>
> [GblId, Arity=1, Str=DmdType]
>
> f =
>
>   \ (ds_dmE :: (#|#) Int Char) ->
>
> case ds_dmE of _ [Occ=Dead] {
>
>   (#_|#) x_amy -> x_amy;
>
>   (#|_#) ipv_smK -> patError @ Int "UnboxedSum.hs:5:1-15|function f"#
>
> }
>
>
>
> We will get this stg pre-unarise:
>
>
>
> unarise
>
>   [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
>
>[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
>
>\r srt:SRT:[0e :-> patError] [ds_svm]
>
>case ds_svm of _ [Occ=Dead] {
>
>  (#_|#) x_svo [Occ=Once] -> x_svo;
>
>  (#|_#) _ [Occ=Dead] -> patError
> "UnboxedSum.hs:5:1-15|function f"#;
>
>};]
>
>
>
> What do we want it to look like afterwards? I currently, have this,
> modeled after unboxed tuples:
>
>
>
> post-unarise:
>
>   [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
>
>[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
>
>\r srt:SRT:[0e :-> patError] [ds_gvu ds_gvv]
>
>case (#_|#) [ds_gvu ds_gvv] of _ [Occ=Dead] {  -- <-- WHAT
> SHOULD GO HERE?
>
>  (#_|#) x_svo [Occ=Once] -> x_svo;
>
>  (#|_#) _ [Occ=Dead] -> patError
> "UnboxedSum.hs:5:1-15|function f"#;
>
>};]
>
>
>
> Here I have performed the same rewriting of the scrutinee in the case
> statement as for unboxed tuples, but note that this doesn't quite work, as
> we don't know which data constructor to apply in "..." in case ... of. In
> the case of tuples it's easy; there is only one.
>
>
>
> It seems to me that we just want to rewrite the case altogether into
> something that looks at the tag field of the data constructor. Also, in stg
> we use the same DataCon as in core, but after stg the unboxed sum case
> really only has one constructor (one with the union of all the fields),
> which makes it awkward to reuse the original DataCon.
>
>
>
>
>
>
>
> On Mon, Sep 14, 2015 at 7:27 AM, Ryan Newton  wrote:
>
>
>-
>data RepType = UbxTupleRep [UnaryType]
>| UbxSumRep [UnaryType]
>| UnaryRep UnaryType
>
> Not, fully following, but ... this reptype business is orthogonal to
> whether you add a normal type to the STG level that models anonymous,
> untagged unions, right?
>
>
>
> That is, when using Any for pointer types, they could use indicative
> phantom types, like "Any (Union Bool Char)", even if there's not full
> support for doing anything useful with (Union Bool Char) by itself.  Maybe
> the casting machinery could greenlight a cast from Any (Union Bool Char) to
> Bool at least?
>
>
>
> There's already the unboxed union itself, (|# #|) , but that's different
> than a pointer to a union of types...
>
>
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I've given this a yet some more thought. Given this simple core program:

f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
[GblId, Arity=1, Str=DmdType]
f =
  \ (ds_dmE :: (#|#) Int Char) ->
case ds_dmE of _ [Occ=Dead] {
  (#_|#) x_amy -> x_amy;
  (#|_#) ipv_smK -> patError @ Int "UnboxedSum.hs:5:1-15|function f"#
}

We will get this stg pre-unarise:

unarise
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_svm]
   case ds_svm of _ [Occ=Dead] {
 (#_|#) x_svo [Occ=Once] -> x_svo;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };]

What do we want it to look like afterwards? I currently, have this, modeled
after unboxed tuples:

post-unarise:
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_gvu ds_gvv]
   case (#_|#) [ds_gvu ds_gvv] of _ [Occ=Dead] {  -- <-- WHAT
SHOULD GO HERE?
 (#_|#) x_svo [Occ=Once] -> x_svo;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };]

Here I have performed the same rewriting of the scrutinee in the case
statement as for unboxed tuples, but note that this doesn't quite work, as
we don't know which data constructor to apply in "..." in case ... of. In
the case of tuples it's easy; there is only one.

It seems to me that we just want to rewrite the case altogether into
something that looks at the tag field of the data constructor. Also, in stg
we use the same DataCon as in core, but after stg the unboxed sum case
really only has one constructor (one with the union of all the fields),
which makes it awkward to reuse the original DataCon.



On Mon, Sep 14, 2015 at 7:27 AM, Ryan Newton  wrote:

>
>>-
>>data RepType = UbxTupleRep [UnaryType]
>>| UbxSumRep [UnaryType]
>>| UnaryRep UnaryType
>>
>> Not, fully following, but ... this reptype business is orthogonal to
> whether you add a normal type to the STG level that models anonymous,
> untagged unions, right?
>
> That is, when using Any for pointer types, they could use indicative
> phantom types, like "Any (Union Bool Char)", even if there's not full
> support for doing anything useful with (Union Bool Char) by itself.  Maybe
> the casting machinery could greenlight a cast from Any (Union Bool Char) to
> Bool at least?
>
> There's already the unboxed union itself, (|# #|) , but that's different
> than a pointer to a union of types...
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

Another question, in need to add something to AltType in StgSyn, would this
work

data AltType
  = PolyAlt -- Polymorphic (a type variable)
  | UbxTupAlt Int   -- Unboxed tuple of this arity
  | UbxSumAlt Int   -- Unboxed sum of this arity
  | AlgAltTyCon -- Algebraic data type; the AltCons will be DataAlts
  | PrimAlt   TyCon -- Primitive data type; the AltCons will be LitAlts

or do I also have to capture which alternative was used here? Why do we
capture the arity in *tuple* case here?

On Mon, Sep 14, 2015 at 6:21 AM, Johan Tibell 
wrote:

> I took a stab at this but ran into something I don't understand. For
> recence, the whole implementation of unboxed sums is at
> https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums and the
> implementation of unarisation is at
> https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums#diff-f5bc1f9e9c230db4cf882bf18368a818
> .
>
> Running the compiler on the following file:
>
> {-# LANGUAGE UnboxedSums #-}
> module Test where
>
> f :: (# Int | Char #) -> Int
> f (# x | #) = x
> {-# NOINLINE f #-}
>
> g = f (# 1 | #)
>
> Yields an error, like so:
>
> ghc-stage2: panic! (the 'impossible' happened)
>   (GHC version 7.11.20150912 for x86_64-apple-darwin):
> StgCmmEnv: variable not found
>   ds_svq
>   local binds for:
>   ds_gvz
>   ds_gvA
>
> I probably got something wrong in UnariseStg, but I can't see what. I
> printed this debug information to see the stg I'm rewriting:
>
> unarise
>   [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
>[GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
>\r srt:SRT:[0e :-> patError] [ds_svq]
>case ds_svq of _ [Occ=Dead] {
>  (#_|#) x_svs [Occ=Once] -> x_svs;
>  (#|_#) _ [Occ=Dead] -> patError
> "UnboxedSum.hs:5:1-15|function f"#;
>};,
>g :: Int
>[GblId, Str=DmdType] =
>\u srt:SRT:[r1 :-> f] []
>let {
>  sat_svu [Occ=Once] :: Int
>  [LclId, Str=DmdType] =
>  NO_CCS I#! [1#];
>} in
>  case (#_|#) [sat_svu] of sat_svv { __DEFAULT -> f sat_svv; };]
> unariseAlts
>   [81 :-> [realWorld#], svq :-> [ds_gvz, ds_gvA]]
>   UbxTup 2
>   wild_svr
>   [((#_|#), [x_svs], [True], x_svs),
>((#|_#),
> [ipv_svt],
> [False],
> patError "UnboxedSum.hs:5:1-15|function f"#)]
>
> It's ds_svg that's being complained about above. I find that a bit
> confusing as that variable is never used on any RHS.
>
> Some questions that might help me get there:
>
>- I added a new RepType for unboxed sums, like so:
>
>data RepType = UbxTupleRep [UnaryType]
>| UbxSumRep [UnaryType]
>| UnaryRep UnaryType
>
>Does this constructor make sense? I store the already flattened
>representation of the sum in here, rather than having something like
>[[UnaryType]] and storing each alternative.
>- In unariseAlts there's a bndr argument. Is that the binder of the
>scrutinee as a whole (e.g. the 'x' in case e of x { ... -> ... })?
>
> Any other idea what I might have gotten wrong?
>
>
> On Mon, Sep 14, 2015 at 1:03 AM, Simon Marlow  wrote:
>
>> On 10/09/2015 10:37, Simon Peyton Jones wrote:
>>
>>> The problem is that stg is too strongly typed
>>>
>>> It’s not really typed, or at least only in a very half-hearted way.  To
>>> be concrete I think you can just use Any for any Pointer arg.   All STG
>>> needs to know, really, is which things are pointers.  Detailed type info
>>> like “are you a Char or a Bool” is strictly jam; indeed never used I
>>> think.  (I could be wrong but I’m pretty sure I’m not wrong in a
>>> fundamental way.
>>>
>>
>> Yes, the only thing the code generator needs to do with types is convert
>> them to PrimReps (see idPrimRep), and all GC pointer types have the same
>> PrimRep (PtrRep).
>>
>> Cheers
>> Simon
>>
>>
>>
>>
>>> SImon
>>>
>>> *From:*Johan Tibell [mailto:johan.tib...@gmail.com]
>>> *Sent:* 09 September 2015 23:22
>>> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
>>> *Subject:* Converting unboxed sum types in StgCmm
>>>
>>> Hi!
>>>
>>> The original idea for implementing the backend part of the unboxed sums
>>> proposal was to convert from the core representation to the actual data
>>> representation (i.e. a tag followed by some pointer and non-pointer
>>> fields) in the unarise s

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I took a stab at this but ran into something I don't understand. For
recence, the whole implementation of unboxed sums is at
https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums and the
implementation of unarisation is at
https://github.com/ghc/ghc/compare/master...tibbe:unboxed-sums#diff-f5bc1f9e9c230db4cf882bf18368a818
.

Running the compiler on the following file:

{-# LANGUAGE UnboxedSums #-}
module Test where

f :: (# Int | Char #) -> Int
f (# x | #) = x
{-# NOINLINE f #-}

g = f (# 1 | #)

Yields an error, like so:

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.11.20150912 for x86_64-apple-darwin):
StgCmmEnv: variable not found
  ds_svq
  local binds for:
  ds_gvz
  ds_gvA

I probably got something wrong in UnariseStg, but I can't see what. I
printed this debug information to see the stg I'm rewriting:

unarise
  [f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
   [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] =
   \r srt:SRT:[0e :-> patError] [ds_svq]
   case ds_svq of _ [Occ=Dead] {
 (#_|#) x_svs [Occ=Once] -> x_svs;
 (#|_#) _ [Occ=Dead] -> patError "UnboxedSum.hs:5:1-15|function
f"#;
   };,
   g :: Int
   [GblId, Str=DmdType] =
   \u srt:SRT:[r1 :-> f] []
   let {
 sat_svu [Occ=Once] :: Int
 [LclId, Str=DmdType] =
 NO_CCS I#! [1#];
   } in
 case (#_|#) [sat_svu] of sat_svv { __DEFAULT -> f sat_svv; };]
unariseAlts
  [81 :-> [realWorld#], svq :-> [ds_gvz, ds_gvA]]
  UbxTup 2
  wild_svr
  [((#_|#), [x_svs], [True], x_svs),
   ((#|_#),
[ipv_svt],
[False],
patError "UnboxedSum.hs:5:1-15|function f"#)]

It's ds_svg that's being complained about above. I find that a bit
confusing as that variable is never used on any RHS.

Some questions that might help me get there:

   - I added a new RepType for unboxed sums, like so:

   data RepType = UbxTupleRep [UnaryType]
   | UbxSumRep [UnaryType]
   | UnaryRep UnaryType

   Does this constructor make sense? I store the already flattened
   representation of the sum in here, rather than having something like
   [[UnaryType]] and storing each alternative.
   - In unariseAlts there's a bndr argument. Is that the binder of the
   scrutinee as a whole (e.g. the 'x' in case e of x { ... -> ... })?

Any other idea what I might have gotten wrong?


On Mon, Sep 14, 2015 at 1:03 AM, Simon Marlow  wrote:

> On 10/09/2015 10:37, Simon Peyton Jones wrote:
>
>> The problem is that stg is too strongly typed
>>
>> It’s not really typed, or at least only in a very half-hearted way.  To
>> be concrete I think you can just use Any for any Pointer arg.   All STG
>> needs to know, really, is which things are pointers.  Detailed type info
>> like “are you a Char or a Bool” is strictly jam; indeed never used I
>> think.  (I could be wrong but I’m pretty sure I’m not wrong in a
>> fundamental way.
>>
>
> Yes, the only thing the code generator needs to do with types is convert
> them to PrimReps (see idPrimRep), and all GC pointer types have the same
> PrimRep (PtrRep).
>
> Cheers
> Simon
>
>
>
>
>> SImon
>>
>> *From:*Johan Tibell [mailto:johan.tib...@gmail.com]
>> *Sent:* 09 September 2015 23:22
>> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
>> *Subject:* Converting unboxed sum types in StgCmm
>>
>> Hi!
>>
>> The original idea for implementing the backend part of the unboxed sums
>> proposal was to convert from the core representation to the actual data
>> representation (i.e. a tag followed by some pointer and non-pointer
>> fields) in the unarise stg-to-stg
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fsimplStg%2fUnariseStg.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U%2bFUNsL87iEemajTnAW9SxD9N5b4%2bG8QB1q19%2fX%2bBI4%3d
>> >
>> pass.
>>
>> I have now realized that this won't work. The problem is that stg is too
>> strongly typed. When we "desugar" sum types we need to convert functions
>> receiving a value e.g. from
>>
>>  f :: (# Bool | Char #) -> ...
>>
>> to
>>
>>  f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...
>>
>> Since stg is still typed with normal Haskell types (e.g. Bool, Char,
>> etc), this is not possible, as we cannot represent an argument which has
>> two different types.
>>
>> It seems to me that we will have to do the conversion in the stg-to-cmm
>> <
>> https:

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I'll give that a try. The main use of the stg types in the stg-to-cmm pass
is to call idPrimRep (which call typePrimRep) to figure out which register
type we need to use. I guess as long as I rewrite the stg types so they
give me the typePrimRep I want in the end I should be fine.

On Thu, Sep 10, 2015 at 2:37 AM, Simon Peyton Jones 
wrote:

> The problem is that stg is too strongly typed
>
>
>
> It’s not really typed, or at least only in a very half-hearted way.  To be
> concrete I think you can just use Any for any Pointer arg.   All STG needs
> to know, really, is which things are pointers.  Detailed type info like
> “are you a Char or a Bool” is strictly jam; indeed never used I think.  (I
> could be wrong but I’m pretty sure I’m not wrong in a fundamental way.
>
>
>
> SImon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 09 September 2015 23:22
> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org
> *Subject:* Converting unboxed sum types in StgCmm
>
>
>
> Hi!
>
>
>
> The original idea for implementing the backend part of the unboxed sums
> proposal was to convert from the core representation to the actual data
> representation (i.e. a tag followed by some pointer and non-pointer fields)
> in the unarise stg-to-stg
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fsimplStg%2fUnariseStg.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U%2bFUNsL87iEemajTnAW9SxD9N5b4%2bG8QB1q19%2fX%2bBI4%3d>
> pass.
>
>
>
> I have now realized that this won't work. The problem is that stg is too
> strongly typed. When we "desugar" sum types we need to convert functions
> receiving a value e.g. from
>
>
>
> f :: (# Bool | Char #) -> ...
>
>
>
> to
>
>
>
> f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...
>
>
>
> Since stg is still typed with normal Haskell types (e.g. Bool, Char, etc),
> this is not possible, as we cannot represent an argument which has two
> different types.
>
>
>
> It seems to me that we will have to do the conversion in the stg-to-cmm
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fcodeGen%2fStgCmm.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aXKZ78eGNKbJ6eZkxZgyJHgsAXpgOBjg3Zvqj%2bq7pk0%3d>
> pass, which is quite a bit more involved. For example, StgCmmEnv.idToReg
> function will have to change from
>
>
>
> idToReg :: DynFlags -> NonVoid Id -> LocalReg
>
>
>
> to
>
>
>
> idToReg :: DynFlags -> NonVoid Id -> [LocalReg]
>
>
>
> to accommodate the fact that we might need more than one register to store
> a binder.
>
>
>
> Any ideas for a better solution?
>
>
>
> -- Johan
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Converting unboxed sum types in StgCmm

[Johan Tibell]

I wonder if rewriting any aliased pointer field as Any in Stg and any
non-pointer field as Word# would work. I suspect that not all non-pointer
fields (e.g. Double# on 32-bit) can be represented as Word#.

On Wed, Sep 9, 2015 at 3:22 PM, Johan Tibell  wrote:

> Hi!
>
> The original idea for implementing the backend part of the unboxed sums
> proposal was to convert from the core representation to the actual data
> representation (i.e. a tag followed by some pointer and non-pointer fields)
> in the unarise stg-to-stg
> <https://github.com/ghc/ghc/blob/master/compiler/simplStg/UnariseStg.hs>
> pass.
>
> I have now realized that this won't work. The problem is that stg is too
> strongly typed. When we "desugar" sum types we need to convert functions
> receiving a value e.g. from
>
> f :: (# Bool | Char #) -> ...
>
> to
>
> f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...
>
> Since stg is still typed with normal Haskell types (e.g. Bool, Char, etc),
> this is not possible, as we cannot represent an argument which has two
> different types.
>
> It seems to me that we will have to do the conversion in the stg-to-cmm
> <https://github.com/ghc/ghc/blob/master/compiler/codeGen/StgCmm.hs> pass,
> which is quite a bit more involved. For example, StgCmmEnv.idToReg function
> will have to change from
>
> idToReg :: DynFlags -> NonVoid Id -> LocalReg
>
> to
>
> idToReg :: DynFlags -> NonVoid Id -> [LocalReg]
>
> to accommodate the fact that we might need more than one register to store
> a binder.
>
> Any ideas for a better solution?
>
> -- Johan
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Converting unboxed sum types in StgCmm

[Johan Tibell]

Hi!

The original idea for implementing the backend part of the unboxed sums
proposal was to convert from the core representation to the actual data
representation (i.e. a tag followed by some pointer and non-pointer fields)
in the unarise stg-to-stg

pass.

I have now realized that this won't work. The problem is that stg is too
strongly typed. When we "desugar" sum types we need to convert functions
receiving a value e.g. from

f :: (# Bool | Char #) -> ...

to

f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...

Since stg is still typed with normal Haskell types (e.g. Bool, Char, etc),
this is not possible, as we cannot represent an argument which has two
different types.

It seems to me that we will have to do the conversion in the stg-to-cmm
 pass,
which is quite a bit more involved. For example, StgCmmEnv.idToReg function
will have to change from

idToReg :: DynFlags -> NonVoid Id -> LocalReg

to

idToReg :: DynFlags -> NonVoid Id -> [LocalReg]

to accommodate the fact that we might need more than one register to store
a binder.

Any ideas for a better solution?

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Unpacking sum types

[Johan Tibell]

After some discussions with SPJ I've now rewritten the proposal in terms of
unboxed sums (which should suffer from the extra seq problem you mention
above).

On Tue, Sep 1, 2015 at 11:31 AM, Dan Doel  wrote:

> I wonder: are there issues with strict/unpacked fields in the sum
> type, with regard to the 'fill in stuff' behavior?
>
> For example:
>
> data C = C1 !Int | C2 ![Int]
>
> data D = D1 !Double {-# UNPACK #-} !C
>
> Naively we might think:
>
> data D' = D1 !Double !Tag !Int ![Int]
>
> But this is obviously not going to work at the
> Haskell-implemented-level. Since we're at a lower level, we could just
> not seq the things from the opposite constructor, but are there
> problems that arise from that? Also of course the !Int will probably
> also be unpacked, so such prim types need different handling (fill
> with 0, I guess).
>
> --
>
> Also, I guess this is orthogonal, but having primitive, unboxed sums
> (analogous to unboxed tuples) would be nice as well. Conceivably they
> could be used as part of the specification of unpacked sums, since we
> can apparently put unboxed tuples in data types now. I'm not certain
> if they would cover all cases, though (like the strictness concerns
> above).
>
> -- Dan
>
>
> On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell 
> wrote:
> > I have a draft design for unpacking sum types that I'd like some feedback
> > on. In particular feedback both on:
> >
> >  * the writing and clarity of the proposal and
> >  * the proposal itself.
> >
> > https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes
> >
> > -- Johan
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RFC: Unpacking sum types

[Johan Tibell]

I have a draft design for unpacking sum types that I'd like some feedback
on. In particular feedback both on:

 * the writing and clarity of the proposal and
 * the proposal itself.

https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ArrayArrays

[Johan Tibell]

Works for me.

On Mon, Aug 31, 2015 at 3:50 PM, Ryan Yates  wrote:

> Any time works for me.
>
> Ryan
>
> On Mon, Aug 31, 2015 at 6:11 PM, Ryan Newton  wrote:
> > Dear Edward, Ryan Yates, and other interested parties --
> >
> > So when should we meet up about this?
> >
> > May I propose the Tues afternoon break for everyone at ICFP who is
> > interested in this topic?  We can meet out in the coffee area and
> congregate
> > around Edward Kmett, who is tall and should be easy to find ;-).
> >
> > I think Ryan is going to show us how to use his new primops for combined
> > array + other fields in one heap object?
> >
> > On Sat, Aug 29, 2015 at 9:24 PM Edward Kmett  wrote:
> >>
> >> Without a custom primitive it doesn't help much there, you have to store
> >> the indirection to the mask.
> >>
> >> With a custom primitive it should cut the on heap root-to-leaf path of
> >> everything in the HAMT in half. A shorter HashMap was actually one of
> the
> >> motivating factors for me doing this. It is rather astoundingly
> difficult to
> >> beat the performance of HashMap, so I had to start cheating pretty
> badly. ;)
> >>
> >> -Edward
> >>
> >> On Sat, Aug 29, 2015 at 5:45 PM, Johan Tibell 
> >> wrote:
> >>>
> >>> I'd also be interested to chat at ICFP to see if I can use this for my
> >>> HAMT implementation.
> >>>
> >>> On Sat, Aug 29, 2015 at 3:07 PM, Edward Kmett 
> wrote:
> >>>>
> >>>> Sounds good to me. Right now I'm just hacking up composable accessors
> >>>> for "typed slots" in a fairly lens-like fashion, and treating the set
> of
> >>>> slots I define and the 'new' function I build for the data type as
> its API,
> >>>> and build atop that. This could eventually graduate to
> template-haskell, but
> >>>> I'm not entirely satisfied with the solution I have. I currently
> distinguish
> >>>> between what I'm calling "slots" (things that point directly to
> another
> >>>> SmallMutableArrayArray# sans wrapper) and "fields" which point
> directly to
> >>>> the usual Haskell data types because unifying the two notions meant
> that I
> >>>> couldn't lift some coercions out "far enough" to make them vanish.
> >>>>
> >>>> I'll be happy to run through my current working set of issues in
> person
> >>>> and -- as things get nailed down further -- in a longer lived medium
> than in
> >>>> personal conversations. ;)
> >>>>
> >>>> -Edward
> >>>>
> >>>> On Sat, Aug 29, 2015 at 7:59 AM, Ryan Newton 
> wrote:
> >>>>>
> >>>>> I'd also love to meet up at ICFP and discuss this.  I think the array
> >>>>> primops plus a TH layer that lets (ab)use them many times without
> too much
> >>>>> marginal cost sounds great.  And I'd like to learn how we could be
> either
> >>>>> early users of, or help with, this infrastructure.
> >>>>>
> >>>>> CC'ing in Ryan Scot and Omer Agacan who may also be interested in
> >>>>> dropping in on such discussions @ICFP, and Chao-Hong Chen, a Ph.D.
> student
> >>>>> who is currently working on concurrent data structures in Haskell,
> but will
> >>>>> not be at ICFP.
> >>>>>
> >>>>>
> >>>>> On Fri, Aug 28, 2015 at 7:47 PM, Ryan Yates 
> >>>>> wrote:
> >>>>>>
> >>>>>> I completely agree.  I would love to spend some time during ICFP and
> >>>>>> friends talking about what it could look like.  My small array for
> STM
> >>>>>> changes for the RTS can be seen here [1].  It is on a branch
> somewhere
> >>>>>> between 7.8 and 7.10 and includes irrelevant STM bits and some
> >>>>>> confusing naming choices (sorry), but should cover all the details
> >>>>>> needed to implement it for a non-STM context.  The biggest surprise
> >>>>>> for me was following small array too closely and having a word/byte
> >>>>>> offset miss-match [2].
> >>>>>>
> >>>>>> [1]:
> >>>>>>
> https://github.com/fryguybob/ghc/compare/ghc-htm-bloom...fryg

Re: ArrayArrays

[Johan Tibell]

I'd also be interested to chat at ICFP to see if I can use this for my HAMT
implementation.

On Sat, Aug 29, 2015 at 3:07 PM, Edward Kmett  wrote:

> Sounds good to me. Right now I'm just hacking up composable accessors for
> "typed slots" in a fairly lens-like fashion, and treating the set of slots
> I define and the 'new' function I build for the data type as its API, and
> build atop that. This could eventually graduate to template-haskell, but
> I'm not entirely satisfied with the solution I have. I currently
> distinguish between what I'm calling "slots" (things that point directly to
> another SmallMutableArrayArray# sans wrapper) and "fields" which point
> directly to the usual Haskell data types because unifying the two notions
> meant that I couldn't lift some coercions out "far enough" to make them
> vanish.
>
> I'll be happy to run through my current working set of issues in person
> and -- as things get nailed down further -- in a longer lived medium than
> in personal conversations. ;)
>
> -Edward
>
> On Sat, Aug 29, 2015 at 7:59 AM, Ryan Newton  wrote:
>
>> I'd also love to meet up at ICFP and discuss this.  I think the array
>> primops plus a TH layer that lets (ab)use them many times without too much
>> marginal cost sounds great.  And I'd like to learn how we could be either
>> early users of, or help with, this infrastructure.
>>
>> CC'ing in Ryan Scot and Omer Agacan who may also be interested in
>> dropping in on such discussions @ICFP, and Chao-Hong Chen, a Ph.D. student
>> who is currently working on concurrent data structures in Haskell, but will
>> not be at ICFP.
>>
>>
>> On Fri, Aug 28, 2015 at 7:47 PM, Ryan Yates  wrote:
>>
>>> I completely agree.  I would love to spend some time during ICFP and
>>> friends talking about what it could look like.  My small array for STM
>>> changes for the RTS can be seen here [1].  It is on a branch somewhere
>>> between 7.8 and 7.10 and includes irrelevant STM bits and some
>>> confusing naming choices (sorry), but should cover all the details
>>> needed to implement it for a non-STM context.  The biggest surprise
>>> for me was following small array too closely and having a word/byte
>>> offset miss-match [2].
>>>
>>> [1]:
>>> https://github.com/fryguybob/ghc/compare/ghc-htm-bloom...fryguybob:ghc-htm-mut
>>> [2]: https://ghc.haskell.org/trac/ghc/ticket/10413
>>>
>>> Ryan
>>>
>>> On Fri, Aug 28, 2015 at 10:09 PM, Edward Kmett  wrote:
>>> > I'd love to have that last 10%, but its a lot of work to get there and
>>> more
>>> > importantly I don't know quite what it should look like.
>>> >
>>> > On the other hand, I do have a pretty good idea of how the primitives
>>> above
>>> > could be banged out and tested in a long evening, well in time for
>>> 7.12. And
>>> > as noted earlier, those remain useful even if a nicer typed version
>>> with an
>>> > extra level of indirection to the sizes is built up after.
>>> >
>>> > The rest sounds like a good graduate student project for someone who
>>> has
>>> > graduate students lying around. Maybe somebody at Indiana University
>>> who has
>>> > an interest in type theory and parallelism can find us one. =)
>>> >
>>> > -Edward
>>> >
>>> > On Fri, Aug 28, 2015 at 8:48 PM, Ryan Yates 
>>> wrote:
>>> >>
>>> >> I think from my perspective, the motivation for getting the type
>>> >> checker involved is primarily bringing this to the level where users
>>> >> could be expected to build these structures.  it is reasonable to
>>> >> think that there are people who want to use STM (a context with
>>> >> mutation already) to implement a straight forward data structure that
>>> >> avoids extra indirection penalty.  There should be some places where
>>> >> knowing that things are field accesses rather then array indexing
>>> >> could be helpful, but I think GHC is good right now about handling
>>> >> constant offsets.  In my code I don't do any bounds checking as I know
>>> >> I will only be accessing my arrays with constant indexes.  I make
>>> >> wrappers for each field access and leave all the unsafe stuff in
>>> >> there.  When things go wrong though, the compiler is no help.  Maybe
>>> >> template Haskell that generates the appropriate wrappers is the right
>>> >> direction to go.
>>> >> There is another benefit for me when working with these as arrays in
>>> >> that it is quite simple and direct (given the hoops already jumped
>>> >> through) to play with alignment.  I can ensure two pointers are never
>>> >> on the same cache-line by just spacing things out in the array.
>>> >>
>>> >> On Fri, Aug 28, 2015 at 7:33 PM, Edward Kmett 
>>> wrote:
>>> >> > They just segfault at this level. ;)
>>> >> >
>>> >> > Sent from my iPhone
>>> >> >
>>> >> > On Aug 28, 2015, at 7:25 PM, Ryan Newton 
>>> wrote:
>>> >> >
>>> >> > You presumably also save a bounds check on reads by hard-coding the
>>> >> > sizes?
>>> >> >
>>> >> > On Fri, Aug 28, 2015 at 3:39 PM, Edward Kmett 
>>> wrote:
>>> >> >>
>>> >> >> Also there are 4 different 

Re: OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing

[Johan Tibell]

The proposed change to my library is here:
https://github.com/tibbe/cassava/pull/95/files

We remove the OverlappingInstances pragma and instead add an OVERLAPPABLE
pragma like so:

instance {-# OVERLAPPABLE #-} FromField a => FromField (Maybe a) where

This causes clients of the library that previously compiled (e.g.
the music-parts package) to no longer compile, due to a now
lacking OVERLAPPING pragma in their code.

The issue here is I'm trying to the right thing (move to new pragmas), but
that causes clients to fail to compile. My question is: how do we avoid
that? Would it be OK if they added the OVERLAPPING pragma first and then I
change my library to use OVERLAPPABLE?

On Tue, Aug 25, 2015 at 1:25 PM, Simon Peyton Jones 
wrote:

> What's the right way to migrate code? Just switching my library to the new
> pragmas breaks code, so that doesn't seem very attractive.
>
>
>
> I don’t understand.  Can you describe the problem more precisely, perhaps
> with an example?
>
>
>
> S
>
>
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
> Tibell
> *Sent:* 25 August 2015 10:42
> *To:* ghc-devs@haskell.org
> *Subject:* OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
>
>
>
> It was brought to my attention that cassava, my library,
> uses OverlappingInstances, which is now deprecated. There's a suggested fix
> here: https://github.com/tibbe/cassava/pull/95.
>
>
>
> The fix seems correct but, as Mikhail points out, makes some client code
> no longer compile (due to a now missing OVERLAPPABLE pragma).
>
>
>
> What's the right way to migrate code? Just switching my library to the new
> pragmas breaks code, so that doesn't seem very attractive. Do clients have
> to migrate before the libraries they use?
>
>
>
> -- Johan
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing

[Johan Tibell]

It was brought to my attention that cassava, my library,
uses OverlappingInstances, which is now deprecated. There's a suggested fix
here: https://github.com/tibbe/cassava/pull/95.

The fix seems correct but, as Mikhail points out, makes some client code no
longer compile (due to a now missing OVERLAPPABLE pragma).

What's the right way to migrate code? Just switching my library to the new
pragmas breaks code, so that doesn't seem very attractive. Do clients have
to migrate before the libraries they use?

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MonadFail proposal (MFP): Moving fail out of Monad

[Johan Tibell]

On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka  wrote:

> On 10/06/15 14:22, Johan Tibell wrote:
> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> > mailto:dluposchain...@googlemail.com>>
> > wrote:
> >
> > I think there are two important consequences of MonadFail. First of
> > all, we can
> > all safely write failable patterns if we so desire. Second, the
> > compiler can
> > ensure other people's codebases do not lie to us (knowingly or
> > unknowingly).
> >
> >
> > The second is a bit overstated I think. Any function you call can still
> > have partial pattern matches in all the other places Haskell allows them
> > and you wouldn't know from the type.
>
> For most of them, at least you get a warning from GHC (not for patterns
> inside lambda, sadly, although that should be fixable). But for
>
> do
>   Just x <- a
>   ...
>
> it's not possible in principle to give a warning, because it's not clear
> whether the implicit call to fail is intended.
>

That's a good point. An alternative to changing fail would to add a warning
for partial matches even in do-notation.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MonadFail proposal (MFP): Moving fail out of Monad

[Johan Tibell]

On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky <
dluposchain...@googlemail.com> wrote:

> I think there are two important consequences of MonadFail. First of all,
> we can
> all safely write failable patterns if we so desire. Second, the compiler
> can
> ensure other people's codebases do not lie to us (knowingly or
> unknowingly).
>

The second is a bit overstated I think. Any function you call can still
have partial pattern matches in all the other places Haskell allows them
and you wouldn't know from the type.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MonadFail proposal (MFP): Moving fail out of Monad

[Johan Tibell]

Thanks for putting this together.

The proposal says:

"As a consequence, in current Haskell, you can not use Monad-polymorphic
code safely, because although it claims to work for all Monads, it might
just crash on you. This kind of implicit non-totality baked into the class
is terrible."

Is this actually a problem in practice? Is there any code we can point to
that suffers because of the current state of affairs? Could it be included
in the proposal?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: StrictData and the parser

[Johan Tibell]

On Thu, Jun 4, 2015 at 10:30 PM, Edward Z. Yang  wrote:

> Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700:
> > Looks to me like it's confused about whether a ~ is part of an equality
> > constraint or is a laziness annotation. The former would be illegal at
> that
> > point, though, I'd think? Somewhere it believes a constraint might be
> > possible there, via btype.
> >
> > As ezyang says in the message I see just came in, you'll need extra
> > production rules to distinguish that top level. Although I'd wonder why
> it
> > believes an equality constraint is acceptable there in the first place;
> is
> > that a lurking bug in the parser?
>
> In general, the parser is more liberal than is actually required; we
> can give better error messages this way.
>
> Second, here is where it's ambiguous:
>
> T a ~b
>
> where T is a TyCon.  Does this parse as
>
> T a (~b)
>
> or
>
> T a ~ b
>
> Parser doesn't currently distinguish these cases.
>

I guess we should parse it as T a (~b), just as we have unary minus bind
"tighter" with the following token.


>
> Edward
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Branchless implementation for literal case – is it worth it?

[Johan Tibell]

On Apr 19, 2015 09:44, "Joachim Breitner"  wrote:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
> f :: Int -> Bool
> f a = case a of
> 1  -> True
> 5  -> True
> 8  -> True
> 9  -> True
> 11 -> True
> 19 -> True
> _  -> False
> {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
> let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>  `orI#` a ==# 11 `orI#` a ==# 19
> case p of
>   1 -> do_something
>   0 -> do_something_else
>
> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage¹.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
> If it is not better, I can again refactor the switch generation and
> simplify it a bit again.
>
> Hmm, only now I see that rwbarton has replied there. Not sure why I
> missed that. Anyways, more voices are welcome :-)
>
> Greetings,
> Joachim
>
> ¹ This should not preclude an implementation on the Core level, which
> SPJ preferred. But I improved other aspects of the code generation as
> well, so this is worthwhile on its own.
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HP 2015.2.0.0 and GHC 7.10

[Johan Tibell]

cabal-install should be 1.22.2.0 (latest). Otherwise looks good.
On Mar 25, 2015 7:32 AM, "Mark Lentczner"  wrote:

> *Hey you* yes you... Platform committee member, or Platform library
> maintainer, Platform packager... that's right, you:
>
> GHC 7.10 is about to be released. Wouldn't it rock if we came out with a
> Platform within days? Or on the same day?
>
> I know, I know, our process is long and full of discussion, and hard, and
> slow let's smash that, eh? How'z'bout it?
>
> OKAY? Good! Your task is:
>
>- look over the the source file at GitHub
>
> 
>  that
>defines the release
>- see if the version of your stuff looks right
>- yeah, I bumped it all to latest, major or minor version change - so
>APIs probably broke from last HP
>- look near the end where there is a bunch of stuff I kinda just added
>to get it all to compile
>- read the notes about those things in the first message of this
>thread (copied below)
>- weigh in - short and sweet - if you have an opinion
>- if you have a spare Mac - download it and try it!
>
>
> Crazy, right? I know... but, can we do this?
>
> — Mark
>
> On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner  > wrote:
>
>> I've gone ahead and built a very provisional, alpha version of 2015.2.0.0
>> using GHC 7.10 RC3.
>>
>> I bumped all the GHC libs to the versions in 7.10, and bumped all the
>> Platform libs to the latest versions I could find on Hackage. There were a
>> few issues:
>>
>>- *old-locale and old-time* - no longer part of GHC, but
>>cabal-install, cgi & HTTP need them - and they are part of the platform -
>>so included now as added packages. Not sure this is a great idea, since
>>they are now very deprecated... but until cabal-install, cgi, & HTTP
>>update, not sure what else to do.
>>- *tf-random* - is now required by alex and QuickCheck - seems a
>>shame to add this, as now we're going to have two random packages
>>- *network-uri *- was split out of network, and needed by
>>cabal-install, cgi, & HTTP. I suppose we should include it, as it was
>>functionality and API that was part of the platform
>>- *exceptions* & *multipart* - needed by cgi - is exceptions now
>>subsumed by something in transformers? and... multipart? maybe time to 
>> drop
>>cgi? We didn't have it last time anyway as it wouldn't compile!
>>- *scientific* - needed by attoparsec - debated in detail last time
>>... and we're still here!
>>
>> The Platform is significantly larger now: On OS X it has gone from 316M
>> to 499M! Most of this is due to new OpenGL libs which are now huge (went
>> from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the
>> whole installed magilla is 1.5G! Even the compressed installer is now 250M!
>>
>> If you want to poke at it, the source is in the pre-release branch at
>> GitHub ,
>> and the OS X builds are at my usual platform staging area:
>>
>> Index of /mark/platform 
>>
>>
>> Remember, it already includes GHC, so no need to download the GHC binary
>> for OS X that is there, too.
>>
>> I'll try to get a generic linux build up soonish... but my VM now runs
>> out of memory trying to build OpenGL - and adding more only makes my
>> machine thrash to death!
>>
>> - Mark
>>
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cabal and simultaneous installations of the same package

[Johan Tibell]

On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones 
wrote:

> But time has passed and it hasn't happened. Is this because I'm
> misunderstanding?  Or because it is harder than I think?  Or because there
> are much bigger problems?  Or because there is insufficient effort
> available?  Or what?


I have no idea what the status of this is or if GHC indeed has all the
things we need. Perhaps Edward could comment.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [core libraries] tyConHash -- quick fix?

[Johan Tibell]

SGTM. I'm probably the only user of the newly exported symbol (by using it
in hashable).

On Thu, Mar 12, 2015 at 1:38 AM, Simon Peyton Jones 
wrote:

> Yes, but the original 'tyConHash' was not exported, so no one will be
> annoyed if we change its name.  We only started exporting it recently.
> Hence my suggestion to change its name to tyConFingerprint.
>
> Simon
>
> |  -Original Message-
> |  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
> |  Sent: 11 March 2015 09:48
> |  To: Simon Peyton Jones
> |  Cc: ghc-devs@haskell.org; core-libraries-commit...@haskell.org
> |  Subject: Re: [core libraries] tyConHash -- quick fix?
> |
> |  On 2015-03-11 at 10:39:41 +0100, Simon Peyton Jones wrote:
> |
> |  [...]
> |
> |  > This is new in 7.10, so we could fix it now with no trouble.
> |  > Simon
> |
> |  Here's a bit more background information:
> |
> |  Afaics, tyConHash was introduced in
> |
> |
> |  http://git.haskell.org/ghc.git/commitdiff/e0b63e02b78d0bd31a073738b1154
> |  a93d22dccca
> |
> |  and it was recently re-exported via
> |
> |
> |  http://git.haskell.org/ghc.git/commitdiff/56e0ac98c3a439b8757a2e886db25
> |  9270bdc85f0
> |
> |  which followed the same questionable naming scheme for the really new
> |  'typeRepHash' field accessor
> |
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The suggested redundant import solution doesn't work for explicit import lists

[Johan Tibell]

I guess for re-exports we could relax the requirement that the symbol comes
from only one module. I don't know if that is better though. If I saw

import Data.Monoid (Monoid)
import Prelude (Monoid)

I'd say that code wasn't the pretties, because it would confuse users, who
would have to figure out that the two were the same. Re-exports are
generally confusing, because they break abstraction by saying that two
things are the same and will continue to be so, which isn't always what you
want.


On Thu, Feb 26, 2015 at 6:06 PM, Simon Peyton Jones 
wrote:

> OK. I've created a ticket
>https://ghc.haskell.org/trac/ghc/ticket/10117
>
> In fact there is a pretty good specification here
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/UnusedImports
>
> So back to you: based on the existing, can you think of a variant that
> would work better?
>
> Simon
>
> |  -Original Message-
> |  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
> |  Sent: 24 February 2015 12:00
> |  To: Simon Peyton Jones
> |  Cc: Herbert Valerio Riedel; Johan Tibell; Edward Kmett; Austin Seipp
> |  Subject: Re: The suggested redundant import solution doesn't work for
> |  explicit import lists
> |
> |  Simon,
> |
> |  The problem:
> |
> |   trying to avoid redundant-import warnings due symbols having moved to
> |  'Prelude' due to AMP/FTP w/o CPP usage
> |
> |  e.g.
> |
> |import Control.Applicative (Applicative)
> |
> |foo :: Applicative f => ...
> |foo = ...
> |
> |  now warns that 'Applicative' is redundant, as it's exported from
> |  'Prelude' now. 'Monoid' is another such example that's now re-exported
> |  from 'Prelude' (but wasn't before GHC 7.10).
> |
> |
> |  One thing that happens to work is the trick shown at
> |  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto
> |  f...isredundant
> |  i.e.
> |
> |module Foo (Int, Word, Monoid(..)) where
> |
> |import Data.Monoid
> |import Data.Word
> |import Prelude
> |
> |  as in that case, 'Prelude' is explicitly imported last, and so GHC
> |  doesn't warn about Data.{Word,Monoid} being redundant (due to the way
> |  the redundancy-check is implemented in GHC)
> |
> |  However, if the example above is rewritten as
> |
> |module Foo (Int, Word, Monoid(..)) where
> |
> |import Data.Monoid (Monoid(..))
> |import Data.Word (Word)
> |import Prelude
> |
> |  GHC would warn, as it handles import-listed symbols differently than
> |  wildcard imports...
> |
> |  and the question is, whether we can easily get the latter example to
> |  become warning free as well w/o risking breakages elsewhere...
> |
> |  ...is it clearer now what I'm suggesting?
> |
> |  Cheers,
> |hvr
> |
> |  On 2015-02-24 at 12:50:35 +0100, Simon Peyton Jones wrote:
> |  > I'm sorry, but can someone re-articulate the question?   I'm deep
> |  underwater, so reluctant to reverse-engineer the question from the
> |  thread.
> |  > I think you are asking for some feature.  But I'm not sure what the
> |  spec is.
> |  >
> |  > Simon
> |  >
> |  > | -Original Message-
> |  > | From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
> |  > | Sent: 24 February 2015 11:29
> |  > | To: Johan Tibell
> |  > | Cc: Edward Kmett; Simon Peyton Jones; Austin Seipp
> |  > | Subject: Re: The suggested redundant import solution doesn't work
> |  > | for explicit import lists
> |  > |
> |  > | Johan,
> |  > |
> |  > | You're right, I'm afraid the Prelude-trick doesn't work well with
> |  > | import-lists... not sure though if it's worth the risk to tweak
> |  GHC
> |  > | 7.10.1's redundant-warning detection to make it work here too...
> |  > |
> |  > | @SPJ, any comments?
> |  > |
> |  > | for more context:
> |  > |
> |  > |  -
> |  > |
> |  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto
> |  f..
> |  > | .isredundant
> |  > |  -
> |  > |
> |  http://www.reddit.com/r/haskell/comments/2wx64g/ghc_710_will_use_pla
> |  > | n_ftp
> |  > | /covdas0
> |  > |
> |  > | Cheers,
> |  > |   hvr
> |  > |
> |  > | On 2015-02-24 at 11:47:30 +0100, Johan Tibell wrote:
> |  > | > The suggested fix for unused imports resulting from the move of
> |  e.g.
> |  > | > Data.Monoid doesn't work when using explicit import lists:
> |  > | >
> |  > | > $ cat Test.hs
> |  > | > module

Re: FYI: Cabal-1.22.1.0 has been released

[Johan Tibell]

Greg,

Yes I agree. I forget sometimes and we haven't managed to make it a policy
(I don't merge all pull requests myself.)

On Mon, Feb 23, 2015 at 9:45 PM, Greg Weber  wrote:

> Rather than putting all the burden of the changelog on yourself and others
> doing the release. you could try asking on every pull request that is
> changelog-worthy for the author to put an entry in the changelog. This is
> what GHC does (similar with respect to the user guide).
>
> On Mon, Feb 23, 2015 at 11:54 AM, Johan Tibell 
> wrote:
>
>> Make that 1.22.1.1. Had to fix a regression for Configure-based .cabal
>> files.
>>
>> On Sun, Feb 22, 2015 at 1:35 PM, Johan Tibell 
>> wrote:
>>
>>> We will probably want to ship that with GHC 7.10.
>>>
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FYI: Cabal-1.22.1.0 has been released

[Johan Tibell]

We will probably want to ship that with GHC 7.10.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Delaying 7.10?

[Johan Tibell]

I think delaying is OK, but we should probably say something like "we're
delaying for X and Y, but that doesn't mean that you can not sneak in Z*".

* Unless Z is the StrictData language pragma and your name is Johan. ;)

On Thu, Jan 29, 2015 at 9:58 AM, Simon Peyton Jones 
wrote:

>  Friends
>
> In a call with a bunch of type hackers, we were discussing
>
>https://ghc.haskell.org/trac/ghc/ticket/9858
>
> This is a pretty serious bug.  It allows a malicious person to construct
> his own unsafeCoerce, and so completely subverts Safe Haskell.
>
> Actually there are two bugs (see comment:19).  The first is easily fixed.
> But the second is not.
>
> We explored various quick fixes, but the real solution is not far out of
> reach.  It amounts to this:
>
> ·Every data type is automatically in Typeable.  No need to say
> “deriving(Typeable)” or “AutoDeriveTypeable” (which would become deprecated)
>
> ·In implementation terms, the constraint solver treats Typeable
> specially, much as it already treats Coercible specially.
>
> It’s not a huge job.  It’d probably take a couple of days of
> implementation work, and some time for shaking out bugs and consequential
> changes.  The biggest thing might be simply working out implementation
> design choices.  (For example, there is a modest code-size cost to making
> everything Typeable, esp because that includes the data constructors of the
> type (which can be used in types, with DataKinds).  Does that matter?
> Should we provide a way to suppress it?  If so, we’d also need a way to
> express whether or not the Typable instance exists in the interface file.)
>
> But it is a substantial change that will touch a lot of lines of code.
> Moreover, someone has to do it, and Iavor (who heroically volunteered)
> happens to be travelling next week.
>
> So it’s really not the kind of thing we would usually do after RC2.
>
> But (a) it’s serious and, as it happens, (b) there is also the BBP Prelude
> debate going on.
>
> Hence the question: should we simply delay 7.10  by, say, a month?  After
> all, the timetable is up to us.  Doing so might give a bit more breathing
> space to the BBP debate, which might allow time for reflection and/or
> implementation of modest features to help the transition.  (I know that
> several are under discussion.)  Plus, anyone waiting for 7.10 can simply
> use RC2, which is pretty good.
>
> Would that be a relief to the BBP debate?  Or any other opinions.
>
> Simon
>
> PS: I know, I know: there is endless pressure to delay releases to get
> stuff in.  If we give in to that pressure, we never make a release.  But we
> should know when to break our own rules.  Perhaps this is such an occasion.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC support for the new "record" package

[Johan Tibell]

On Tue, Jan 27, 2015 at 3:12 AM, Simon Peyton Jones 
wrote:

> |  1. What are the IV instances provided in base? These could give
> |  selector functions, lenses, both or neither.
>
> My instinct: just selector functions.  Leave lenses for a lens package.
>

+1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC support for the new "record" package

[Johan Tibell]

I really like this proposal (except I would bike shed about the syntax for
record selector to be dot, like in the majority of languages.)

On Fri, Jan 23, 2015 at 3:41 PM, Simon Peyton Jones 
wrote:

> | I just
> | noticed that it effectively gives us a syntax for identifier-like Symbol
> | singletons, which could be useful in completely different contexts
>
> Indeed so.  I have written a major increment to
>
> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign
> which people reading this thread may find interesting.  Look for "Plan B".
>
> For the first time I think I can see a nice, simple, elegant, orthogonal
> story.
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC support for the new "record" package

[Johan Tibell]

On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow  wrote:

> On 21/01/2015 16:01, Johan Tibell wrote:
>
>> My thoughts mostly mirror those of Adam and Edward.
>>
>> 1) I want something that is backwards compatible.
>>
>
> Backwards compatible in what sense?  Extension flags provide backwards
> compatibility, because you just don't turn on the extension until you want
> to use it.  That's how all the other extensions work; most of them change
> syntax in some way or other that breaks existing code.


In this case in the sense of avoiding splitting code into a new-Haskell vs
old-Haskell. This means that existing records should work well (and ideally
also get the improved name resolution when used in call sites that have the
pragma enabled) in the new record system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: 32-bit performance wibbles (387f1d1)

[Johan Tibell]

Don't worry about the merge commit.
On Jan 22, 2015 11:57 AM, "Simon Peyton Jones" 
wrote:

> BOTHER!
>
> I have no idea how my commit, which was meant to change two all.T files,
> also ended up adding libraries/haskell98.
>
> I'll revert and re-commit.
>
> I also inadvertently did 'git pull' rather than 'git pull --rebase' so
> there's a merge node too.  But I don't know how to undo that, and probably
> no harm done.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf
> |  Of g...@git.haskell.org
> |  Sent: 22 January 2015 09:41
> |  To: ghc-comm...@haskell.org
> |  Subject: [commit: ghc] master: 32-bit performance wibbles (387f1d1)
> |
> |  Repository : ssh://g...@git.haskell.org/ghc
> |
> |  On branch  : master
> |  Link   :
> |  http://ghc.haskell.org/trac/ghc/changeset/387f1d1ec334788c3e891e9304d4
> |  27bc804998f4/ghc
> |
> |  >---
> |
> |  commit 387f1d1ec334788c3e891e9304d427bc804998f4
> |  Author: Simon Peyton Jones 
> |  Date:   Tue Jan 20 17:31:13 2015 +
> |
> |  32-bit performance wibbles
> |
> |  Less for GHC, more for Haddock
> |
> |
> |  >---
> |
> |  387f1d1ec334788c3e891e9304d427bc804998f4
> |   libraries/{integer-simple => haskell98}/.gitignore |   0
> |   libraries/haskell98/Array.hs   |  15 +
> |   libraries/haskell98/Bits.hs|   8 +
> |   libraries/haskell98/CError.hs  |   8 +
> |   libraries/haskell98/CForeign.hs|   7 +
> |   libraries/haskell98/CPUTime.hs |   9 +
> |   libraries/haskell98/CString.hs |   7 +
> |   libraries/haskell98/CTypes.hs  |   7 +
> |   libraries/haskell98/Char.hs|  18 +
> |   libraries/haskell98/Complex.hs |  11 +
> |   libraries/haskell98/Directory.hs   |  46 +++
> |   libraries/haskell98/ForeignPtr.hs  |   7 +
> |   libraries/haskell98/IO.hs  |  74 
> |   libraries/haskell98/Int.hs |   7 +
> |   libraries/haskell98/Ix.hs  |  10 +
> |   libraries/haskell98/LICENSE|  28 ++
> |   libraries/haskell98/List.hs|  34 ++
> |   libraries/haskell98/Locale.hs  |  17 +
> |   libraries/haskell98/MarshalAlloc.hs|   7 +
> |   libraries/haskell98/MarshalArray.hs|   7 +
> |   libraries/haskell98/MarshalError.hs|  22 ++
> |   libraries/haskell98/MarshalUtils.hs|   7 +
> |   libraries/haskell98/Maybe.hs   |  16 +
> |   libraries/haskell98/Monad.hs   |  19 +
> |   libraries/haskell98/Numeric.hs |  48 +++
> |   libraries/haskell98/Prelude.hs | 196 ++
> |   libraries/haskell98/Ptr.hs |   7 +
> |   libraries/haskell98/Random.hs  | 407
> |  +
> |   libraries/haskell98/Ratio.hs   |  10 +
> |   libraries/{integer-gmp => haskell98}/Setup.hs  |   0
> |   libraries/haskell98/StablePtr.hs   |   7 +
> |   libraries/haskell98/Storable.hs|   7 +
> |   libraries/haskell98/System.hs  |  15 +
> |   libraries/haskell98/Time.hs|  22 ++
> |   libraries/haskell98/Word.hs|   7 +
> |   libraries/haskell98/changelog.md   |  15 +
> |   libraries/haskell98/haskell98.cabal|  86 +
> |   libraries/haskell98/prologue.txt   |   9 +
> |   testsuite/tests/perf/compiler/all.T|   7 +-
> |   testsuite/tests/perf/haddock/all.T |  13 +-
> |   40 files changed, 1240 insertions(+), 7 deletions(-)
> |
> |  Diff suppressed because of size. To see it, use:
> |
> |  git diff-tree --root --patch-with-stat --no-color --find-copies-
> |  harder --ignore-space-at-eol --cc
> |  387f1d1ec334788c3e891e9304d427bc804998f4
> |  ___
> |  ghc-commits mailing list
> |  ghc-comm...@haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-commits
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC support for the new "record" package

[Johan Tibell]

My thoughts mostly mirror those of Adam and Edward.

1) I want something that is backwards compatible.

2) Anonymous records are nice to have, but I don't want to have all records
be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)

3) I don't think it's a good idea to have lots of functions be polymorphic
in the record types of their arguments. If that falls out for free (like it
does both in ORF and Nikita's proposals) that's nice, but I think anonymous
records should be used sparsely.

To me, anonymous records look a lot like Go's interfaces, which structural
typing I don't think is a great idea. Go's interfaces give the appearance
of giving you more polymorphic functions (i.e. functions with arguments of
type { f :: T, ... }), but you have to express the required laws on these
record fields purely in terms of comments. With type class-based
polymorphism you're somewhat more specific and deliberate when you state
what kind of values your functions are polymorphic over. You don't just say
"this value must support a function f :: T" but instead "this value must
support a function f :: T, where the behavior of f is specified by the type
class it's defined in". I also have extensive experience of duck typing
from Python and there I think duck typing has not played out well (somewhat
collaborate by the fact that Python is adding base classes so it's possible
to talk about the laws I mentioned above.)

4) There are issues with strictness and unpacking.

5) I don't know if I want to commit the *language* to a particular lens
type.

On Wed, Jan 21, 2015 at 2:11 PM, Edward Kmett  wrote:

> Personally, I think the two proposals, ORF and Nikita's record approach
> address largely differing needs.
>
> The ORF proposal has the benefit that it doesn't require GHC itself to
> know anything about lenses in order to work and is mostly compatible with
> the existing field accessor combinators.
>
> Nikita's proposal on the other hand builds a form of Trex-like records
> where it has its own little universe to play in, and doesn't have to
> contort itself to make the field accessors backwards compatible. As its own
> little world, the fact that the ORF can't deal with certain types of fields
> just becomes a limitation on this little universe, and all existing code
> would continue to work.
>
> I, too, have a lot of skin in the game with the existing ORF proposal, but
> ultimately we're going to be stuck with whatever solution we build for a
> long time, and it is, we both have to confess, admittedly quite
> complicated, so it seems exploring the consequences of a related design
> which has different constraints on its design does little harm.
>
> I'm mostly paying the work the courtesy it deserves by considering to its
> logical conclusion what such a design would look like fleshed out in a way
> that maximized how nice the result could be to use. I'm curious, as mostly
> a thought experiment, how nice a design we could get in the end under these
> slightly different assumptions.
>
> If, in the end, having an anonymous record syntax that is distinct from
> the existing one is too ugly, it is okay for us to recoil from it and go
> back to committing to the existing proposal, but I for one would prefer to "
> steelman "
> Nikita's trick first.
>
> Thus far, all of this is but words in a handful of emails. I happen to
> think the existing ORF implementation is about as good as we can get
> operating under the assumptions it does. That said, operating under
> different assumptions may get us a nicer user experience. I'm not sure,
> though, hence the thought experiment.
>
> -Edward
>
> On Wed, Jan 21, 2015 at 5:05 AM, Adam Gundry  wrote:
>
>> As someone with quite a lot of skin in this game, I thought it might be
>> useful to give my perspective on how this relates to ORF. Apologies that
>> this drags on a bit...
>>
>> Both approaches use essentially the same mechanism for resolving
>> overloaded field names (typeclasses indexed by type-level strings,
>> called Has/Upd or FieldOwner). ORF allows fields to be both selectors
>> and various types of lenses, whereas the record library always makes
>> them van Laarhoven lenses, but this isn't really a fundamental difference.
>>
>> The crucial difference is that ORF adds no new syntax, and solves
>> Has/Upd constraints for existing datatypes, whereas the record library
>> adds a new syntax for anonymous records and their fields that is
>> completely separate from existing datatypes, and solves FieldOwner
>> constraints only for these anonymous records (well, their desugaring).
>>
>> On the one hand, anonymous records are a very desirable feature, and in
>> some ways making them separate is a nice simplification. However, they
>> are not as expressive as the existing Haskell record datatypes (sums,
>> strict/unpacked fields, higher-rank fields), and having two records
>> mechanisms is a

Re: Clarification of HsBang and isBanged

[Johan Tibell]

Yet more questions.

I think I'm on the wrong track. I was trying to change MkId.dataConArgRep
in order to make user-defined fields get the right strictness. However,
some debug tracing suggests that this function isn't used (or isn't only
used) to compute the strictness and "unpackedness" of a data constructor
defined in the module being compiled, but also for modules being imported.
Is that correct?

The code (including tests) is here:
https://github.com/ghc/ghc/compare/601e345e5df6%5E...1cee34c71e80

The parser changes I'm making seem to not be quite right. I've changed the
strict_mark parser in Parser.y to read:

strict_mark :: { Located ([AddAnn],HsBang) }
: '!'{ sL1 $1([],
 HsSrcBang Nothing  (Just True)) }
| '~'{ sL1 $1([],
 HsSrcBang Nothing  (Just False)) }
| '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just True)  Nothing) }
| '{-# NOUNPACK' '#-}'   { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just False) Nothing) }
| '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just True)  (Just True)) }
| '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just False) (Just True)) }
| '{-# UNPACK' '#-}' '~' { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just True)  (Just False)) }
| '{-# NOUNPACK' '#-}' '~'   { sLL $1 $> ([mo $1,mc $2],
HsSrcBang (Just False) (Just False)) }
-- Although UNPACK with no '!' and UNPACK with '~' are illegal,
we get a
-- better error message if we parse them here

but parsing this data type

data Lazy a = L ~a

gives this error

DsStrictData.hs:14:1:
parse error (possibly incorrect indentation or mismatched brackets)

-- Johan


On Sun, Jan 11, 2015 at 8:11 PM, Johan Tibell 
wrote:

> Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into
> account either. Should it?
>
> reifyStrict :: DataCon.HsSrcBang -> TH.Strict
> reifyStrict HsNoBang = TH.NotStrict
> reifyStrict (HsSrcBang _ False)  = TH.NotStrict
> reifyStrict (HsSrcBang (Just True) True) = TH.Unpacked
> reifyStrict (HsSrcBang _ True)   = TH.IsStrict
>     reifyStrict HsStrict = TH.IsStrict
> reifyStrict (HsUnpack {})= TH.Unpacked
>
> Should
>
> reifyStrict (HsSrcBang _ True)   = TH.IsStrict
>
> be TH.Unpacked if we have -funbox-strict-fields?
>
> On Sun, Jan 11, 2015 at 6:28 PM, Johan Tibell 
> wrote:
>
>> Those comments and the renaming really help. Here are a couple of more
>> questions I got after exploring some more:
>>
>> DsMeta.repBangTy look wrong to me:
>>
>> repBangTy :: LBangType Name -> DsM (Core (TH.StrictTypeQ))
>> repBangTy ty= do
>>   MkC s <- rep2 str []
>>   MkC t <- repLTy ty'
>>   rep2 strictTypeName [s, t]
>>   where
>> (str, ty') = case ty of
>>L _ (HsBangTy (HsSrcBang (Just True) True) ty) ->
>> (unpackedName,  ty)
>>L _ (HsBangTy (HsSrcBang _ True) ty)   ->
>> (isStrictName,  ty)
>>_  ->
>> (notStrictName, ty)
>>
>> Shouldn't the second case look at whether -funbox-strict-fields or
>> -funbox-small-strict-fields is set and use unpackedName instead of
>> isStrictName if so? What is repBangTy for?
>>
>> A related question, in MkId.dataConArgRep we have:
>>
>> dataConArgRep _ _ arg_ty HsStrict
>>   = strict_but_not_unpacked arg_ty
>>
>> Here we're not looking at -funbox-strict-fields
>> and -funbox-small-strict-fields. Is it the case that we only need to look
>> at these flags in the case of HsSrcBang, because HsStrict can only be
>> generated by us (and we presumably looked at the flags when we converted a
>> HsSrcBang to a HsStrict)?
>>
>> On Thu, Jan 8, 2015 at 4:09 PM, Simon Peyton Jones > > wrote:
>>
>>>  I’m glad you are getting back to strictness.
>>>
>>>
>>>
>>> Good questions.
>>>
>>>
>>>
>>> I’ve pushed (or will as soon as I have validated) a patch that adds type
>>> synonyms, updates comments (some of which were indeed misleading), and
>>> changes a few names for clarity and consistency

Re: Clarification of HsBang and isBanged

[Johan Tibell]

Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into
account either. Should it?

reifyStrict :: DataCon.HsSrcBang -> TH.Strict
reifyStrict HsNoBang = TH.NotStrict
reifyStrict (HsSrcBang _ False)  = TH.NotStrict
reifyStrict (HsSrcBang (Just True) True) = TH.Unpacked
reifyStrict (HsSrcBang _ True)   = TH.IsStrict
reifyStrict HsStrict = TH.IsStrict
reifyStrict (HsUnpack {})= TH.Unpacked

Should

reifyStrict (HsSrcBang _ True)   = TH.IsStrict

be TH.Unpacked if we have -funbox-strict-fields?

On Sun, Jan 11, 2015 at 6:28 PM, Johan Tibell 
wrote:

> Those comments and the renaming really help. Here are a couple of more
> questions I got after exploring some more:
>
> DsMeta.repBangTy look wrong to me:
>
> repBangTy :: LBangType Name -> DsM (Core (TH.StrictTypeQ))
> repBangTy ty= do
>   MkC s <- rep2 str []
>   MkC t <- repLTy ty'
>   rep2 strictTypeName [s, t]
>   where
> (str, ty') = case ty of
>L _ (HsBangTy (HsSrcBang (Just True) True) ty) ->
> (unpackedName,  ty)
>L _ (HsBangTy (HsSrcBang _ True) ty)   ->
> (isStrictName,  ty)
>_  ->
> (notStrictName, ty)
>
> Shouldn't the second case look at whether -funbox-strict-fields or
> -funbox-small-strict-fields is set and use unpackedName instead of
> isStrictName if so? What is repBangTy for?
>
> A related question, in MkId.dataConArgRep we have:
>
> dataConArgRep _ _ arg_ty HsStrict
>   = strict_but_not_unpacked arg_ty
>
> Here we're not looking at -funbox-strict-fields
> and -funbox-small-strict-fields. Is it the case that we only need to look
> at these flags in the case of HsSrcBang, because HsStrict can only be
> generated by us (and we presumably looked at the flags when we converted a
> HsSrcBang to a HsStrict)?
>
> On Thu, Jan 8, 2015 at 4:09 PM, Simon Peyton Jones 
> wrote:
>
>>  I’m glad you are getting back to strictness.
>>
>>
>>
>> Good questions.
>>
>>
>>
>> I’ve pushed (or will as soon as I have validated) a patch that adds type
>> synonyms, updates comments (some of which were indeed misleading), and
>> changes a few names for clarity and consistency.  I hope that answers all
>> your questions.
>>
>>
>>
>> Except these:
>>
>>
>>
>> · Why is there a coercion in `HsUnpack` but not in `HsUserBang
>> (Just True) True`?  Because the former is implementation generated but the
>> latter is source code specified.
>>
>> · Why isn't this information split over two data types.  Because
>> there’s a bit of overlap. See comments with HsSrcBang
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>> *Sent:* 08 January 2015 07:36
>> *To:* ghc-devs@haskell.org
>> *Cc:* Simon Peyton Jones
>> *Subject:* Clarification of HsBang and isBanged
>>
>>
>>
>> HsBang is defined as:
>>
>> -- HsBang describes what the *programmer* wrote
>>
>> -- This info is retained in the DataCon.dcStrictMarks field
>>
>> data HsBang
>>
>>   = HsUserBang   -- The user's source-code request
>>
>>(Maybe Bool)   -- Just True{-# UNPACK #-}
>>
>>   -- Just False   {-# NOUNPACK #-}
>>
>>   -- Nothing  no pragma
>>
>>Bool   -- True <=> '!' specified
>>
>>
>>
>>   | HsNoBang  -- Lazy field
>>
>>   -- HsUserBang Nothing False means the same
>> as HsNoBang
>>
>>
>>
>>   | HsUnpack  -- Definite commitment: this field is
>> strict and unboxed
>>
>>(Maybe Coercion)   --co :: arg-ty ~ product-ty
>>
>>
>>
>>   | HsStrict  -- Definite commitment: this field is
>> strict but not unboxed
>>
>>
>> This data type is a bit unclear to me:
>>
>>  * What are the reasons for the following constructor overlaps?
>>* `HsNoBang` and `HsUserBang Nothing False`
>>* `HsStrict` and `HsUserBang Nothing True`
>>* `HsUnpack mb_co` and `HsUserBang (Just True) True`
>>
>>
>> * Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
>> True) True`?
>>

Re: Clarification of HsBang and isBanged

[Johan Tibell]

Those comments and the renaming really help. Here are a couple of more
questions I got after exploring some more:

DsMeta.repBangTy look wrong to me:

repBangTy :: LBangType Name -> DsM (Core (TH.StrictTypeQ))
repBangTy ty= do
  MkC s <- rep2 str []
  MkC t <- repLTy ty'
  rep2 strictTypeName [s, t]
  where
(str, ty') = case ty of
   L _ (HsBangTy (HsSrcBang (Just True) True) ty) ->
(unpackedName,  ty)
   L _ (HsBangTy (HsSrcBang _ True) ty)   ->
(isStrictName,  ty)
   _  ->
(notStrictName, ty)

Shouldn't the second case look at whether -funbox-strict-fields or
-funbox-small-strict-fields is set and use unpackedName instead of
isStrictName if so? What is repBangTy for?

A related question, in MkId.dataConArgRep we have:

dataConArgRep _ _ arg_ty HsStrict
  = strict_but_not_unpacked arg_ty

Here we're not looking at -funbox-strict-fields
and -funbox-small-strict-fields. Is it the case that we only need to look
at these flags in the case of HsSrcBang, because HsStrict can only be
generated by us (and we presumably looked at the flags when we converted a
HsSrcBang to a HsStrict)?

On Thu, Jan 8, 2015 at 4:09 PM, Simon Peyton Jones 
wrote:

>  I’m glad you are getting back to strictness.
>
>
>
> Good questions.
>
>
>
> I’ve pushed (or will as soon as I have validated) a patch that adds type
> synonyms, updates comments (some of which were indeed misleading), and
> changes a few names for clarity and consistency.  I hope that answers all
> your questions.
>
>
>
> Except these:
>
>
>
> · Why is there a coercion in `HsUnpack` but not in `HsUserBang
> (Just True) True`?  Because the former is implementation generated but the
> latter is source code specified.
>
> · Why isn't this information split over two data types.  Because
> there’s a bit of overlap. See comments with HsSrcBang
>
>
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 08 January 2015 07:36
> *To:* ghc-devs@haskell.org
> *Cc:* Simon Peyton Jones
> *Subject:* Clarification of HsBang and isBanged
>
>
>
> HsBang is defined as:
>
> -- HsBang describes what the *programmer* wrote
>
> -- This info is retained in the DataCon.dcStrictMarks field
>
> data HsBang
>
>   = HsUserBang   -- The user's source-code request
>
>(Maybe Bool)   -- Just True{-# UNPACK #-}
>
>   -- Just False   {-# NOUNPACK #-}
>
>   -- Nothing  no pragma
>
>Bool   -- True <=> '!' specified
>
>
>
>   | HsNoBang  -- Lazy field
>
>   -- HsUserBang Nothing False means the same
> as HsNoBang
>
>
>
>   | HsUnpack  -- Definite commitment: this field is strict
> and unboxed
>
>(Maybe Coercion)   --co :: arg-ty ~ product-ty
>
>
>
>   | HsStrict  -- Definite commitment: this field is strict
> but not unboxed
>
>
> This data type is a bit unclear to me:
>
>  * What are the reasons for the following constructor overlaps?
>* `HsNoBang` and `HsUserBang Nothing False`
>* `HsStrict` and `HsUserBang Nothing True`
>* `HsUnpack mb_co` and `HsUserBang (Just True) True`
>
>
> * Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just True)
> True`?
>
>
>
> * Is there a difference in what the user wrote in the case of HsUserBang
> and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
> compiler as opposed to being written by the user (the function
> documentation notwithstanding)?
>
> A very related function is isBanged:
>
> isBanged :: HsBang -> Bool
>
> isBanged HsNoBang  = False
>
> isBanged (HsUserBang Nothing bang) = bang
>
> isBanged _ = True
>
>
>
> What's the meaning of this function? Is it intended to communicate what
> the user wrote or whether result of what the user wrote results in a strict
> function?
>
>
> Context: I'm adding a new StrictData language pragma [1] that makes fields
> strict by default and a '~' annotation of fields to reverse the default
> behavior. My intention is to change HsBang like so:
>
> -   Bool   -- True <=> '!' specified
> +   (Maybe Bool)   -- True <=> '!' specified, False <=> '~'
> +  -- specified, Nothing <=> unspecified
>
> 1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>
>
> -- Johan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Johan Tibell]

Could we get this for 7.10 so our debug info story is more "well-rounded"?

On Fri, Jan 9, 2015 at 5:11 PM, Simon Marlow  wrote:

> I've been building the RTS with debug symbols for our internal GHC build
> at FB, because it makes investigating problems a lot easier.  I should
> probably upstream this patch.
>
> Shipping libraries with debug symbols should be fine, as long as they can
> be stripped - Peter, does stripping remove everything that -g creates?
>
> Cheers,
> Simon
>
>
> On 02/01/2015 23:18, Johan Tibell wrote:
>
>> Hi!
>>
>> We are now able to generate DWARF debug info, by passing -g to GHC. This
>> will allow for better debugging (e.g. using GDB) and profiling (e.g.
>> using Linux perf events). To make this feature more user accessible we
>> need to ship debug info for the core libraries (and perhaps the RTS).
>> The reason we need to ship debug info is that it's difficult, or
>> impossible in the case of base, for the user to rebuild these
>> libraries.The question is, how do we do this well? I don't think our
>> "way" solution works very well. It causes us to recompile too much and
>> GHC doesn't know which "ways" have been built or not.
>>
>> I believe other compilers, e.g. GCC, ship debug symbols in separate
>> files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then
>> look up.
>>
>> -- Johan
>>
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Johan Tibell]

On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek 
wrote:

> > I think Java's (!) policy for deprecation is good
> I think it's not. It keeps the library code a mess and many times I have
> seen users using
> functions that have been deprecated for years just because it's easier to
> suppress a warning than
> change the code. I don't want Haskell to go down that path and I'm
> strongly in favour of removing
> these functions. Especially that we're talking about internal TH module -
> I'll be surprised if
> there are more than 10 users.


It also keeps Java having users. ;) More seriously, we who maintain the
core libraries spend too much time dealing with breakages due to
continuously moving libraries when we could spend time on building upwards
to make Haskell a better platform for building applications. *In practice*
our code is worse because of these continuous breakages (as it's full with
hard to maintain CPP), not better.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Johan Tibell]

On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek 
wrote:

> > I agree. You'll get rid of the redundancy in the library by removing it
> but
> > you're users will have to live with (...)
> That's why I want to deprecate them first and give users one release cycle
> to switch to new
> functions. I assumed that's enough but we could make this two or three
> release cycles. The reall
> question is how to remember that we should remove this at some point?
>

If we want to avoid the CPP we need warning to be in major version X if
that's when the old function is deprecated and the new one is added and the
actual removal in X+2. At that point I'd just consider keeping the function
and avoid the hassle. :)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Johan Tibell]

On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel 
wrote:

> Why hide them? DEPRECATEd entities have the deprecation-message shown in
> discouraging red letters (including any hyperlinks to their
> replacements) in the generated Haddock documentation...
>

I think Java's (!) policy for deprecation is good: Deprecation is (mostly)
for functions that are error prone or otherwise dangerous. Unless the cost
of keeping the function is large, removing functions should be avoided. The
docs can point to the newer functions, but DEPRECATION pragmas will just
add noise to users' compiles.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Johan Tibell]

On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka  wrote:

> On 09/01/15 12:02, Jan Stolarek wrote:
> >> We could file a tracking bug against the 7.14 milestone.
> > I was considering that but we don't have 7.14 milestone yet.
> >
> >> Just curious, is there a way to keep these functions for backwards
> compat
> >> in 7.14 or is that unfeasible?
> > They could stay, technically that's not a problem. But I'm adding new
> functions that can do the
> > same thing (and more), so we have redundancy.
>
> Can you hide them in the haddock but leave in the module, so that we
> don't break existing code?
>

I agree. You'll get rid of the redundancy in the library by removing it but
you're users will have to live with

#if MIN_VERSION_template_haskell(X,Y,X)
-- new way
#else
-- old way
#endif

for 3+ years (which is typically how many GHC versions popular libraries
try to support).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: warn-redundant-constraints present as errors

[Johan Tibell]

I think using the words error and warning makes sense. For example, this is
how Clang (LLVM) does it:

format-strings.c:91:13: warning: '.*' specified field precision is missing
a matching 'int' argument
  printf("%.*d");
^

t.c:7:39: error: invalid operands to binary expression ('int' and 'struct
A')
  return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
   ~~ ^ ~

(Also note how lovely it is to have a caret pointing at the error.)

On Fri, Jan 9, 2015 at 10:39 AM, Simon Peyton Jones 
wrote:

>  Alan’s point is a bug – I will fix.
>
>
>
> Konstantine’s point is reasonable.  we could easily say
>
>
>
> Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Error:
>  blah blah
>
>
>
> (the bit in red is the new bit)
>
> But I’m not sure that everyone else would want that.   If a consensus
> forms it would be easy to excecute
>
>
>
> I suppose there could be yet another flag to control it (!)
>
>
>
> Simon
>
>
>
> *From:* Konstantine Rybnikov [mailto:k...@k-bx.com]
> *Sent:* 09 January 2015 09:19
> *To:* Alan & Kim Zimmerman
> *Cc:* ghc-devs@haskell.org; Simon Peyton Jones
> *Subject:* Re: warn-redundant-constraints present as errors
>
>
>
> On a slightly unrelated note I should say it would be great to have errors
> contain word "Error:". This is especially nice to have because when you
> build with "-j" your error that stops compilation gets lost somewhere in
> the middle of many warnings (which my projects have, unfortunately).
>
>
>
> On Thu, Jan 8, 2015 at 11:45 PM, Alan & Kim Zimmerman 
> wrote:
>
> This is a great feature, here is some feedback
>
> My syntax highlighter in emacs expects warnings to have the word "warning"
> in them.
>
> So for the two warnings reported below, the first is highlighted as an
> error, and the second as a warning
>
>
> Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17:
> Redundant constraint: SYB.Data t
> In the type signature for:
>duplicateDecl :: SYB.Data t =>
> [GHC.LHsBind GHC.Name]
> -> t -> GHC.Name -> GHC.Name -> RefactGhc
> [GHC.LHsBind GHC.Name]
>
> Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning:
> Defined but not used: ‘toks
>
>   This is in a ghci session, and the file loads without problems, so it
> is indeed a warning.
>
> Can we perhaps add the word "Warning" to the output for Redundant
> constraints?
>
> I also had a situation where it asked me to remove a whole lot of
> constraints from different functions, I did them in batches, so did not
> remove them all from the file at once, and at some point I had to add at
> least one of them back, albeit based on an error message.
>
>
>
> Regards
>
>   Alan
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Deprecating functions

[Johan Tibell]

We could file a tracking bug against the 7.14 milestone.

Just curious, is there a way to keep these functions for backwards compat
in 7.14 or is that unfeasible?

On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek 
wrote:

> I want to deprecate some Template Haskell functions in GHC 7.12 and then
> remove them in GHC 7.14
> (or whatever version that comes after 7.12). Do we have any workflow for
> remembering these kind
> of things? I was thinking about adding a conditional error:
>
> #if __GLASGOW_HASKELL__ > 712
> #error Remove functions foo bar from TH
> #endif
>
> Is this a good way of doing this? Or should I do it differently?
>
> Janek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Johan Tibell]

We should merge this fix to the 7.10 branch.
On Jan 8, 2015 11:52 PM, "Peter Wortmann"  wrote:

>
> (sorry for late answer)
>
> Yes, that's pretty much what this would boil down to. The patch is trivial:
>
> https://github.com/scpmw/ghc/commit/29acc#diff-1
>
> I think this is a good idea anyways. We can always re-introduce the data
> for higher -g levels.
>
> Greetings,
>   Peter
>
>
> On 05/01/2015 00:59, Johan Tibell wrote:
>
>> What about keeping exactly what -g1 keeps for gcc (i.e. functions,
>> external variables, and line number tables)?
>>
>> On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann > <mailto:sc...@leeds.ac.uk>> wrote:
>>
>>
>>
>> Okay, I ran a little experiment - here's the size of the debug
>> sections that Fission would keep (for base library):
>>
>>.debug_abbrev:  8932 - 0.06%
>>.debug_line:  374134 - 2.6%
>>.debug_frame: 671200 - 4.5%
>>
>> Not that much. On the other hand, .debug_info is a significant
>> contributor:
>>
>>.debug_info(full):   4527391 - 30%
>>
>> Here's what this contains: All procs get a corresponding DWARF
>> entry, and we declare all Cmm blocks as "lexical blocks". The latter
>> isn't actually required right now - to my knowledge, GDB simply
>> ignores it, while LLDB shows it as "inlined" routines. In either
>> case, it just shows yet more GHC-generated names, so it's really
>> only useful for profiling tools that know Cmm block names.
>>
>> So here's what we get if we strip out block information:
>>
>>.debug_info(!block): 1688410 - 11%
>>
>> This eliminates a good chunk of information, and might therefore be
>> a good idea for "-g1" at minimum. If we want this as default for
>> 7.10, this would make the total overhead about 18%. Acceptable? I
>> can supply a patch if needed.
>>
>> Just for comparison - for Fission we'd strip proc records as well,
>> which would cause even more extreme savings:
>>
>>.debug_info(!proc):36081 - 0.2%
>>
>> At this point the overhead would be just about 7% - but without
>> doing Fission properly this would most certainly affect debuggers.
>>
>> Greetings,
>>Peter
>>
>> On 03/01/2015 21:22, Johan Tibell wrote:
>> > How much debug info (as a percentage) do we currently generate?
>> Could we just keep it in there in the release?
>>
>> _
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>> http://www.haskell.org/__mailman/listinfo/ghc-devs
>> <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>>
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Clarification of HsBang and isBanged

[Johan Tibell]

>From looking at the code a bit more I'm pretty sure that only HsUserBang
corresponds to what the user wrote and the remaining constructors are used
to note the actual decision we made (e.g. are we going to unpack). Is that
correct Simon PJ? If that is the case, why isn't this information split
over two data types (which would make functions over HsBang simpler)?

On Thu, Jan 8, 2015 at 9:22 AM, Alan & Kim Zimmerman 
wrote:

> I know there was a bug in the parser related to setting the HsBang value,
> it could be that this whole area has just not received solid scrutiny
> before now.
>
> Alan
>
> On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell 
> wrote:
>
>> I also note that the definition of isBanged is confusing:
>>
>> isBanged :: HsBang -> Bool
>> isBanged HsNoBang  = False
>> isBanged (HsUserBang Nothing bang) = bang
>> isBanged _ = True
>>
>> Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
>> annotations with a missing "!", considered "banged"?
>>
>> On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell 
>> wrote:
>>
>>> HsBang is defined as:
>>>
>>> -- HsBang describes what the *programmer* wrote
>>> -- This info is retained in the DataCon.dcStrictMarks field
>>> data HsBang
>>>   = HsUserBang   -- The user's source-code request
>>>(Maybe Bool)   -- Just True{-# UNPACK #-}
>>>   -- Just False   {-# NOUNPACK #-}
>>>   -- Nothing  no pragma
>>>Bool   -- True <=> '!' specified
>>>
>>>   | HsNoBang  -- Lazy field
>>>   -- HsUserBang Nothing False means the same
>>> as HsNoBang
>>>
>>>   | HsUnpack  -- Definite commitment: this field is
>>> strict and unboxed
>>>(Maybe Coercion)   --co :: arg-ty ~ product-ty
>>>
>>>   | HsStrict  -- Definite commitment: this field is
>>> strict but not unboxed
>>>
>>> This data type is a bit unclear to me:
>>>
>>>  * What are the reasons for the following constructor overlaps?
>>>* `HsNoBang` and `HsUserBang Nothing False`
>>>* `HsStrict` and `HsUserBang Nothing True`
>>>* `HsUnpack mb_co` and `HsUserBang (Just True) True`
>>>
>>> * Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just
>>> True) True`?
>>>
>>> * Is there a difference in what the user wrote in the case of HsUserBang
>>> and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
>>> compiler as opposed to being written by the user (the function
>>> documentation notwithstanding)?
>>>
>>> A very related function is isBanged:
>>>
>>> isBanged :: HsBang -> Bool
>>> isBanged HsNoBang  = False
>>> isBanged (HsUserBang Nothing bang) = bang
>>> isBanged _ = True
>>>
>>> What's the meaning of this function? Is it intended to communicate what
>>> the user wrote or whether result of what the user wrote results in a strict
>>> function?
>>>
>>> Context: I'm adding a new StrictData language pragma [1] that makes
>>> fields strict by default and a '~' annotation of fields to reverse the
>>> default behavior. My intention is to change HsBang like so:
>>>
>>> -   Bool   -- True <=> '!' specified
>>> +   (Maybe Bool)   -- True <=> '!' specified, False <=> '~'
>>> +  -- specified, Nothing <=> unspecified
>>>
>>> 1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>>>
>>> -- Johan
>>>
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Clarification of HsBang and isBanged

[Johan Tibell]

I also note that the definition of isBanged is confusing:

isBanged :: HsBang -> Bool
isBanged HsNoBang  = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True

Why is `HsUserBang (Just False) False`, corresponding to a NOUNPACK
annotations with a missing "!", considered "banged"?

On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell  wrote:

> HsBang is defined as:
>
> -- HsBang describes what the *programmer* wrote
> -- This info is retained in the DataCon.dcStrictMarks field
> data HsBang
>   = HsUserBang   -- The user's source-code request
>(Maybe Bool)   -- Just True{-# UNPACK #-}
>   -- Just False   {-# NOUNPACK #-}
>   -- Nothing  no pragma
>Bool   -- True <=> '!' specified
>
>   | HsNoBang  -- Lazy field
>   -- HsUserBang Nothing False means the same
> as HsNoBang
>
>   | HsUnpack  -- Definite commitment: this field is strict
> and unboxed
>(Maybe Coercion)   --co :: arg-ty ~ product-ty
>
>   | HsStrict  -- Definite commitment: this field is strict
> but not unboxed
>
> This data type is a bit unclear to me:
>
>  * What are the reasons for the following constructor overlaps?
>* `HsNoBang` and `HsUserBang Nothing False`
>* `HsStrict` and `HsUserBang Nothing True`
>* `HsUnpack mb_co` and `HsUserBang (Just True) True`
>
> * Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just True)
> True`?
>
> * Is there a difference in what the user wrote in the case of HsUserBang
> and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
> compiler as opposed to being written by the user (the function
> documentation notwithstanding)?
>
> A very related function is isBanged:
>
> isBanged :: HsBang -> Bool
> isBanged HsNoBang  = False
> isBanged (HsUserBang Nothing bang) = bang
> isBanged _ = True
>
> What's the meaning of this function? Is it intended to communicate what
> the user wrote or whether result of what the user wrote results in a strict
> function?
>
> Context: I'm adding a new StrictData language pragma [1] that makes fields
> strict by default and a '~' annotation of fields to reverse the default
> behavior. My intention is to change HsBang like so:
>
> -   Bool   -- True <=> '!' specified
> +   (Maybe Bool)   -- True <=> '!' specified, False <=> '~'
> +  -- specified, Nothing <=> unspecified
>
> 1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
>
> -- Johan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Clarification of HsBang and isBanged

[Johan Tibell]

HsBang is defined as:

-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
  = HsUserBang   -- The user's source-code request
   (Maybe Bool)   -- Just True{-# UNPACK #-}
  -- Just False   {-# NOUNPACK #-}
  -- Nothing  no pragma
   Bool   -- True <=> '!' specified

  | HsNoBang  -- Lazy field
  -- HsUserBang Nothing False means the same as
HsNoBang

  | HsUnpack  -- Definite commitment: this field is strict
and unboxed
   (Maybe Coercion)   --co :: arg-ty ~ product-ty

  | HsStrict  -- Definite commitment: this field is strict
but not unboxed

This data type is a bit unclear to me:

 * What are the reasons for the following constructor overlaps?
   * `HsNoBang` and `HsUserBang Nothing False`
   * `HsStrict` and `HsUserBang Nothing True`
   * `HsUnpack mb_co` and `HsUserBang (Just True) True`

* Why is there a coercion in `HsUnpack` but not in `HsUserBang (Just True)
True`?

* Is there a difference in what the user wrote in the case of HsUserBang
and HsNoBang/HsUnpack/HsStrict e.g are the latter three generated by the
compiler as opposed to being written by the user (the function
documentation notwithstanding)?

A very related function is isBanged:

isBanged :: HsBang -> Bool
isBanged HsNoBang  = False
isBanged (HsUserBang Nothing bang) = bang
isBanged _ = True

What's the meaning of this function? Is it intended to communicate what the
user wrote or whether result of what the user wrote results in a strict
function?

Context: I'm adding a new StrictData language pragma [1] that makes fields
strict by default and a '~' annotation of fields to reverse the default
behavior. My intention is to change HsBang like so:

-   Bool   -- True <=> '!' specified
+   (Maybe Bool)   -- True <=> '!' specified, False <=> '~'
+  -- specified, Nothing <=> unspecified

1. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Redundant constraints

[Johan Tibell]

I think this probably makes sense, especially since you can silence the
warning when you intend to add an unnecessary constraint.

I had one thought though: consider an abstract data type with functions
that operates over it. I might want to require e.g Ord in the definition of
a function so I have freedom to change my implementation later, even though
the current implementation doesn't need Ord. Think of it as separating
specification and implementation. An example is 'nub'. I initially might
implement it as a O(n^2) algorithm using only Eq, but I might want to leave
the door open to using Ord to create something better, without later having
to break backwards compatibility.

On Wed, Jan 7, 2015 at 4:19 PM, Simon Peyton Jones 
wrote:

>   Friends
>
> I’ve pushed a big patch that adds –fwarn-redundant-constraints (on by
> default).  It tells you when a constraint in a signature is unnecessary,
> e.g.
>
>  f :: Ord a => a -> a -> Bool
>
>  f x y = True
>
> I think I have done all the necessary library updates etc, so everything
> should build fine.
>
> Four libraries which we don’t maintain have such warnings (MANY of them in
> transformers) so I’m ccing the maintainers:
>
> o   containers
>
> o   haskeline
>
> o   transformers
>
> o   binary
>
>
>
> Enjoy!
>
>
>
> Simon
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Johan Tibell]

What about keeping exactly what -g1 keeps for gcc (i.e. functions, external
variables, and line number tables)?

On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann  wrote:

>
>
> Okay, I ran a little experiment - here's the size of the debug sections
> that Fission would keep (for base library):
>
>   .debug_abbrev:  8932 - 0.06%
>   .debug_line:  374134 - 2.6%
>   .debug_frame: 671200 - 4.5%
>
> Not that much. On the other hand, .debug_info is a significant contributor:
>
>   .debug_info(full):   4527391 - 30%
>
> Here's what this contains: All procs get a corresponding DWARF entry, and
> we declare all Cmm blocks as "lexical blocks". The latter isn't actually
> required right now - to my knowledge, GDB simply ignores it, while LLDB
> shows it as "inlined" routines. In either case, it just shows yet more
> GHC-generated names, so it's really only useful for profiling tools that
> know Cmm block names.
>
> So here's what we get if we strip out block information:
>
>   .debug_info(!block): 1688410 - 11%
>
> This eliminates a good chunk of information, and might therefore be a good
> idea for "-g1" at minimum. If we want this as default for 7.10, this would
> make the total overhead about 18%. Acceptable? I can supply a patch if
> needed.
>
> Just for comparison - for Fission we'd strip proc records as well, which
> would cause even more extreme savings:
>
>   .debug_info(!proc):36081 - 0.2%
>
> At this point the overhead would be just about 7% - but without doing
> Fission properly this would most certainly affect debuggers.
>
> Greetings,
>   Peter
>
> On 03/01/2015 21:22, Johan Tibell wrote:
> > How much debug info (as a percentage) do we currently generate? Could we
> just keep it in there in the release?
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Cabal 1.22 RC ready to test

[Johan Tibell]

I'm pretty sure we just need to update the submodule.

On Sat, Jan 3, 2015 at 5:20 PM, Alan & Kim Zimmerman 
wrote:

> I tried to build https://github.com/ghc/packages-Cabal earlier today and
> got the same error, but it went fine with the version at
> https://github.com/haskell/cabal
>
>
>
> On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell 
> wrote:
>
>> It might be as simple as bumping the Cabal submodule in GHC to match the
>> upstream 1.22 branch.
>>
>> On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat 
>> wrote:
>>
>>>
>>> On 3 January 2015 at 15:05, Johan Tibell  wrote:
>>>
>>>> The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
>>>> perplexing:
>>>>
>>>> [62 of 77] Compiling Distribution.Client.Config (
>>>> Distribution/Client/Config.hs,
>>>> dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
>>>> )
>>>> Distribution/Client/Config.hs:56:12:
>>>> Module
>>>> ‘Distribution.Simple.Compiler’
>>>> does not export
>>>> ‘DebugInfoLevel(..)’
>>>> cabal: Error: some packages failed to install:
>>>> cabal-install-1.22.0.0 failed during the building phase. The exception
>>>> was:
>>>> ExitFailure 1
>>>>
>>>> Distribution.Simple.Compiler most definitely does export
>>>> DebugInfoLevel, otherwise it wouldn't compile with the other GHC versions.
>>>>
>>>> Does GHC do something special with Cabal nowadays when it's no longer
>>>> tied to GHC?
>>>>
>>>> Is it because the Cabal-1.22.0.0 bundled with ghc is now different to
>>> the Cabal-1.22.0.0 in github? I get the same error compiling the master
>>> branch cabal-install with ghc-7.10.0-20141222.
>>>
>>> I think one solution is to increase the version number of Cabal in
>>> github (for 1.22 and master branches), and to make the latest cabal-install
>>> depend on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no
>>> longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes
>>> the error for ghc-7.10.0-20141222.
>>>
>>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Johan Tibell]

How much debug info (as a percentage) do we currently generate? Could we
just keep it in there in the release?

On Sat, Jan 3, 2015 at 1:33 PM, Peter Wortmann  wrote:

>
>
> The debian package seems to simply put un-stripped libraries into a
> special path (/usr/lib/debug/...). This should be relatively
> straight-forward to implement. Note though that from a look at the RPM
> infrastructure, they have a tool in there (dwarfread) which actually parses
> through DWARF information and updates paths, so there is possibly more
> going on here.
>
> On the other hand, supporting -gsplit-dwarf seems to be a different
> mechanism, called Fission[1]. I haven't looked too much at the
> implementation yet, but to me it looks like it means generating copies of
> debug sections (such as .debug-line.dwo) which will then be extracted using
> "objcopy --extract-dwo". This might take a bit more work to implement, both
> on DWARF generation code as well as infrastructure.
>
> Interestingly enough, doing this kind of splitting will actually buy us
> next to nothing - with Fission both .debug_line and .debug_frame would
> remain in the binary unchanged, so all we'd export would be some fairly
> inconsequential data from .debug_info. In contrast to other programming
> languages, we just don't have that much debug information in the first
> place. Well, at least not yet.
>
> Greetings,
>   Peter
>
> [1] https://gcc.gnu.org/wiki/DebugFission
>
>
>
> On 03/01/2015 00:18, Johan Tibell wrote:
>
>> Hi!
>>
>> We are now able to generate DWARF debug info, by passing -g to GHC. This
>> will allow for better debugging (e.g. using GDB) and profiling (e.g.
>> using Linux perf events). To make this feature more user accessible we
>> need to ship debug info for the core libraries (and perhaps the RTS).
>> The reason we need to ship debug info is that it's difficult, or
>> impossible in the case of base, for the user to rebuild these
>> libraries.The question is, how do we do this well? I don't think our
>> "way" solution works very well. It causes us to recompile too much and
>> GHC doesn't know which "ways" have been built or not.
>>
>> I believe other compilers, e.g. GCC, ship debug symbols in separate
>> files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then
>> look up.
>>
>> -- Johan
>>
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Cabal 1.22 RC ready to test

[Johan Tibell]

It might be as simple as bumping the Cabal submodule in GHC to match the
upstream 1.22 branch.

On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat  wrote:

>
> On 3 January 2015 at 15:05, Johan Tibell  wrote:
>
>> The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
>> perplexing:
>>
>> [62 of 77] Compiling Distribution.Client.Config (
>> Distribution/Client/Config.hs,
>> dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
>> )
>> Distribution/Client/Config.hs:56:12:
>> Module
>> ‘Distribution.Simple.Compiler’
>> does not export
>> ‘DebugInfoLevel(..)’
>> cabal: Error: some packages failed to install:
>> cabal-install-1.22.0.0 failed during the building phase. The exception
>> was:
>> ExitFailure 1
>>
>> Distribution.Simple.Compiler most definitely does export DebugInfoLevel,
>> otherwise it wouldn't compile with the other GHC versions.
>>
>> Does GHC do something special with Cabal nowadays when it's no longer
>> tied to GHC?
>>
>> Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the
> Cabal-1.22.0.0 in github? I get the same error compiling the master branch
> cabal-install with ghc-7.10.0-20141222.
>
> I think one solution is to increase the version number of Cabal in github
> (for 1.22 and master branches), and to make the latest cabal-install depend
> on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no longer
> works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the
> error for ghc-7.10.0-20141222.
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Cabal 1.22 RC ready to test

[Johan Tibell]

On Sat, Jan 3, 2015 at 2:36 AM, Mikhail Glushenkov <
the.dead.shall.r...@gmail.com> wrote:

> Hi,
>
> On 3 January 2015 at 03:36, Johan Tibell  wrote:
> > If I don't hear anything the next few days I will make the release.
>
> The test suite doesn't compile with GHC HEAD on Travis.
>

The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite
perplexing:

[62 of 77] Compiling Distribution.Client.Config (
Distribution/Client/Config.hs,
dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o
)
Distribution/Client/Config.hs:56:12:
Module
‘Distribution.Simple.Compiler’
does not export
‘DebugInfoLevel(..)’
cabal: Error: some packages failed to install:
cabal-install-1.22.0.0 failed during the building phase. The exception was:
ExitFailure 1

Distribution.Simple.Compiler most definitely does export DebugInfoLevel,
otherwise it wouldn't compile with the other GHC versions.

Does GHC do something special with Cabal nowadays when it's no longer tied
to GHC?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Johan Tibell]

Brandon,

If we just built GHC with debug symbols enabled, everything should just
work from a packaging perspective?

On Fri, Jan 2, 2015 at 7:26 PM, Brandon Allbery  wrote:

> On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell 
> wrote:
>
>> I believe other compilers, e.g. GCC, ship debug symbols in separate files
>> (https://packages.debian.org/sid/libc-dbg
>>
>> ) that e.g. GDB can then look up.
>>
>
> Lookaside debugging information is (a) a Linux-ism, although possibly also
> included in mingw --- but not OS X or the *BSDs (b) on RPM-based systems at
> least, is split out of objects into separate files, and thence into debug
> packages, by the standard RPM support macros before the standard strip step
> (I expect debuild does something similar on Debian-ish systems).
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Shipping core libraries with debug symbols

[Johan Tibell]

Hi!

We are now able to generate DWARF debug info, by passing -g to GHC. This
will allow for better debugging (e.g. using GDB) and profiling (e.g. using
Linux perf events). To make this feature more user accessible we need to
ship debug info for the core libraries (and perhaps the RTS). The reason we
need to ship debug info is that it's difficult, or impossible in the case
of base, for the user to rebuild these libraries.The question is, how do we
do this well? I don't think our "way" solution works very well. It causes
us to recompile too much and GHC doesn't know which "ways" have been built
or not.

I believe other compilers, e.g. GCC, ship debug symbols in separate files (
https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up.

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install

[Johan Tibell]

Try

cabal install --allow-newer=base -j3 cabal-install

Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the
upper bound on the base dependency if 1.20 is indeed compatible with the
latest base.

On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts 
wrote:

>
>
> ​$ ​
> cabal update
> Downloading the latest package list from hackage.haskell.org
> Note: *there is a new version of cabal-install available.*
> To upgrade, run: cabal install cabal-install
> bash-3.2$ *cabal install -j3 cabal-install *
> *​...​*
>
>
> *Resolving dependencies...cabal: Could not resolve dependencies:*
> trying: cabal-install-1.20.0.6 (user goal)
> trying: base-4.8.0.0/installed-779... (dependency of
> cabal-install-1.20.0.6)
> next goal: process (dependency of cabal-install-1.20.0.6)
> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> process
> => unix==2.7.1.0/installed-4ae...)
> trying: process-1.2.1.0
> next goal: directory (dependency of cabal-install-1.20.0.6)
> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.5 && <4.8)
> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.6)
> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.5)
> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.4)
> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
> process => directory>=1.1 && <1.3)
> Dependency tree exhaustively searched.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Right way to turn off dynamic linking in build.mk

[Johan Tibell]

I think that results in libs being built the dyn way as well, which
probably doesn't hurt but takes quite a bit of time.

On Tue, Dec 30, 2014 at 4:07 PM, John Lato  wrote:

> I don't have an authoritative answer, but in the past I set
> DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT as Johan originally suggested
> and didn't have any issues with the resulting build.
>
> On Tue Dec 30 2014 at 9:00:07 AM Johan Tibell 
> wrote:
>
>> Not a good answer, I just set
>>
>> GhcLibWays = v
>> DYNAMIC_GHC_PROGRAMS = NO
>> DYNAMIC_BY_DEFAULT   = NO
>>
>> at the bottom of the file. This feels a bit hacky because we're
>> overriding GhcLibWays (e.g. we could be dropping the prof way by
>> accident). I think it should be possible to state our desire (i.e. I don't
>> want dyn) somewhere in the file and have that just work. Trying to manually
>> change things like GhcLibWays is error prone.
>>
>> On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz 
>> wrote:
>>
>>> On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell 
>>> wrote:
>>> > Some times when I play around with GHC I'd like to turn off dynamic
>>> > linking to make GHC compile faster. I'm not sure what the right way
>>> > to do this in build.mk. It's made confusing by the conditional
>>> > statements in that file:
>>> >
>>> > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)
>>> >
>>> > This line make me worry that if I don't put
>>> >
>>> > DYNAMIC_GHC_PROGRAMS = NO
>>> >
>>> > in the right place in build.mk it wont "take".
>>> >
>>> > There's also this one:
>>> >
>>> > ifeq "$(PlatformSupportsSharedLibs)" "YES"
>>> > GhcLibWays += dyn
>>> > endif
>>> >
>>> > Seeing this makes me wonder if
>>> >
>>> > DYNAMIC_GHC_PROGRAMS = NO
>>> > DYNAMIC_BY_DEFAULT   = NO
>>> >
>>> > is enough or if the build system still sniffs out the fact that my
>>> > platform supports dynamic linking.
>>> >
>>> > Could someone please give an authoritative answer to how to turn off
>>> > dynamic linking?
>>>
>>> Hi Johan,
>>>
>>> did you find the answer?
>>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Cabal 1.22 RC now available

[Johan Tibell]

I've just uploaded the Cabal-1.22.0.0 RC:

http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz

I know it's a bit late, but if you could update the GHC 7.10 branch to use
it (Git tag: Cabal-v1.22.0.0-rc) that would be great.

When do you need the actual release to happen, so it's out before GHC 7.10?

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Right way to turn off dynamic linking in build.mk

[Johan Tibell]

Not a good answer, I just set

GhcLibWays = v
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT   = NO

at the bottom of the file. This feels a bit hacky because we're
overriding GhcLibWays
(e.g. we could be dropping the prof way by accident). I think it should be
possible to state our desire (i.e. I don't want dyn) somewhere in the file
and have that just work. Trying to manually change things like GhcLibWays
is error prone.

On Tue, Dec 30, 2014 at 11:48 AM, Tuncer Ayaz  wrote:

> On Thu, Dec 18, 2014 at 9:52 AM, Johan Tibell 
> wrote:
> > Some times when I play around with GHC I'd like to turn off dynamic
> > linking to make GHC compile faster. I'm not sure what the right way
> > to do this in build.mk. It's made confusing by the conditional
> > statements in that file:
> >
> > GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)
> >
> > This line make me worry that if I don't put
> >
> > DYNAMIC_GHC_PROGRAMS = NO
> >
> > in the right place in build.mk it wont "take".
> >
> > There's also this one:
> >
> > ifeq "$(PlatformSupportsSharedLibs)" "YES"
> > GhcLibWays += dyn
> > endif
> >
> > Seeing this makes me wonder if
> >
> > DYNAMIC_GHC_PROGRAMS = NO
> > DYNAMIC_BY_DEFAULT   = NO
> >
> > is enough or if the build system still sniffs out the fact that my
> > platform supports dynamic linking.
> >
> > Could someone please give an authoritative answer to how to turn off
> > dynamic linking?
>
> Hi Johan,
>
> did you find the answer?
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Right way to turn off dynamic linking in build.mk

[Johan Tibell]

Some times when I play around with GHC I'd like to turn off dynamic linking
to make GHC compile faster. I'm not sure what the right way to do this in
build.mk. It's made confusing by the conditional statements in that file:

GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)

This line make me worry that if I don't put

DYNAMIC_GHC_PROGRAMS = NO

in the right place in build.mk it wont "take".

There's also this one:

ifeq "$(PlatformSupportsSharedLibs)" "YES"
GhcLibWays += dyn
endif

Seeing this makes me wonder if

DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT   = NO

is enough or if the build system still sniffs out the fact that my platform
supports dynamic linking.

Could someone please give an authoritative answer to how to turn off
dynamic linking?

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Last call for 7.8.4

[Johan Tibell]

Cabal 1.18.1.5 is out.

On Mon, Dec 15, 2014 at 5:16 PM, Johan Tibell 
wrote:
>
> I will make the actual cabal 1.18 release today as the RCs looked good.
>
> On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp 
> wrote:
>>
>> Hello *,
>>
>> I've just pushed a final round of patches to the 7.8 branch, including
>> the notorious Cabal fix for the -fPIC bug that was discussed earlier
>> in the week, and a handful of other bugfixes for ARM among other
>> things (/cc Joachim :)
>>
>> I am planning on making the final 7.8.4 release this week; barring any
>> pending minor issues (e.g. build wibbles) in the tree (which I do not
>> think should be needed), the only thing I will commit is A) release
>> notes and B) the version number changes.
>>
>> There will not likely be a 7.8.4-rc2, so this is a last call for any
>> bugs you'd like to see fixed. I may have missed something
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Last call for 7.8.4

[Johan Tibell]

I will make the actual cabal 1.18 release today as the RCs looked good.

On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp  wrote:
>
> Hello *,
>
> I've just pushed a final round of patches to the 7.8 branch, including
> the notorious Cabal fix for the -fPIC bug that was discussed earlier
> in the week, and a handful of other bugfixes for ARM among other
> things (/cc Joachim :)
>
> I am planning on making the final 7.8.4 release this week; barring any
> pending minor issues (e.g. build wibbles) in the tree (which I do not
> think should be needed), the only thing I will commit is A) release
> notes and B) the version number changes.
>
> There will not likely be a 7.8.4-rc2, so this is a last call for any
> bugs you'd like to see fixed. I may have missed something
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

[Johan Tibell]

Ben,

Is this something that worked in cabal-install 1.18.0.5 and that stopped
working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you
expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target
a very few critical bugs. They are not attempts to backport all bugfixes
from master.

In 1.18 the critical fixes are:
12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when
GHC is using dynamic libraries.
4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6
6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make
list fields work like Flags.
7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config
file #1884

As for installing, after downloading the two tarballs to a temp dir this
works for me:

cabal install Cabal-1.18.1.5.tar.gz cabal-install-1.18.0.6.tar.gz

-- Johan

On Fri, Dec 12, 2014 at 4:52 AM, Ben Gamari  wrote:
>
> Johan Tibell  writes:
>
> > I've uploaded release candidates for Cabal/cabal-install patch releases
> on
> > the 1.18 and 1.20 branches:
> >
> >
> https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz
> >
> https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz
> >
> >
> https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz
> >
> https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz
> >
> > Please test, especially if one of your fixes are in this release. You can
> > install both both lib and exe using: cabal install 
> > 
> >
> First I'll look at Cabal-1.18.1.5 and cabal-install-1.18.0.6.
>
> Unfortunately there still seems to be trouble invoking cabal in a tree
> previously used by a previous Cabal version. For instance,
>
> $ tar -zxf cabal-install-1.18.0.6.tar.gz
> $ cd cabal-install-1.18.0.6
> $ cabal install
> $ cabal install --enable-tests
> Warning: The package list for 'hackage.haskell.org' is 71 days old.
> Run 'cabal update' to get the latest list of available packages.
> Resolving dependencies...
> Configuring cabal-install-1.18.0.6...
> Building cabal-install-1.18.0.6...
> cabal: dist/package.conf.inplace: inappropriate type
> Failed to install cabal-install-1.18.0.6
> cabal: Error: some packages failed to install:
> cabal-install-1.18.0.6 failed during the building phase. The exception
> was:
> ExitFailure 1
>
> I have noticed this problem in the past as well. Deleting dist/ resolves
> the issue. I seem to recall some discussion where it was claimed this
> was fixed although I could be wrong.  This was reproducible on x86_64
> (building with GHC 7.8.3 and 7.6.3) and ARM.
>
> After this was resolved I encountered the following,
>
> $ cabal install --enable-tests
> ...
>
> Preprocessing test suite 'unit-tests' for cabal-install-1.18.0.6...
>
> Distribution/Client/Targets.hs:100:8:
> Could not find module `Network.URI'
> It is a member of the hidden package `network-2.4.2.2'.
> Perhaps you need to add `network' to the build-depends in your
> .cabal file.
> It is a member of the hidden package `network-uri-2.6.0.1'.
> Perhaps you need to add `network-uri' to the build-depends in your
> .cabal file.
> Use -v to see a list of the files searched for.
> Failed to install cabal-install-1.18.0.6
> cabal: Error: some packages failed to install:
>
> This is fixed in master. It seems you should probably cherry-pick
> 2826c97d11a495085008c4bddf499fcfd05e0df2 onto the release branch.
>
> After this I was able to run the testsuite. cabal-install was fine;
> Cabal failed with,
>
> TestSuiteExeV10/TestWithHpc:
>   : [Failed]
> expected: 'setup build' should succeed
>   output: "/opt/exp/haskell-packages/Cabal-1.18.1.5/tests/Setup
> configure --user -w /opt/exp/ghc/root-ghc-7.8/bin/ghc --enable-tests
> --enable-library-coverage" in PackageTests/TestSuiteExeV10
> Setup: Option --enable-library-coverage is obsolete! Please use
> --enable-coverage instead.
>
> ...
>
> BuildTestSuiteDetailedV09:
>   : [Failed]
> build failed!
> expected: False
>  but got: True
>
> I didn't investigate into the cause of these any further.
>
> I also used the new cabal executable to install Yesod has progressed
> quite (on the ARM, even) far and shows no sign failure.
>
> I'll take a look at the 1.20 releases tomorrow.
>
> Cheers,
>
>  - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

[Johan Tibell]

Apparently this no longer works:

cabal install
http://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz
http://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz

Some change on the web server side means that the web server tries to
redirect to an https page, even though cabal-install doesn't support it.

On Fri, Dec 12, 2014 at 2:22 AM, Johan Tibell 
wrote:

> I've uploaded release candidates for Cabal/cabal-install patch releases on
> the 1.18 and 1.20 branches:
>
> https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz
>
> https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz
>
> https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz
>
> https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz
>
> Please test, especially if one of your fixes are in this release. You can
> install both both lib and exe using: cabal install 
> 
>
> Changelogs:
>
> Cabal-1.18.1.5:
> e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org
> moved
> fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to
> 1.18.1.5
> 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when
> GHC is using dynamic libraries.
>
> cabal-install-1.18.0.6:
> 79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number
> to 1.18.0.6
> 97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of
> https://github.com/snoyberg/cabal into 1.18
> 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6
> 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make
> list fields work like Flags.
> 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config
> file #1884
>
> Cabal-1.20.0.3
> 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number
> to 1.20.0.4
> 813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to
> 1.20.0.3
> cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org
> moved
> b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when
> GHC is using dynamic libraries.
> 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert
> 97c6a72984931f4ccf628736024d3459a033af6c.
> 343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/
>
> cabal-install-1.20.0.4
> 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number
> to 1.20.0.4
> caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in
> frozen constraints
> b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of
> https://github.com/snoyberg/cabal into 1.20
> 1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network
> constraint"
> 58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network
> constraint
> a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6
> 5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make
> list fields work like Flags.
> 13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config
> file #1884
> 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert
> 97c6a72984931f4ccf628736024d3459a033af6c.
> aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file
> as UTF-8
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Including Cabal-1.18.1.5 in GHC 7.8.4

[Johan Tibell]

I'm going to make a bugfix release on the Cabal 1.18 branch the next few
days. The release candidate is already out.

Here are the commits:

e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org
moved
fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to
1.18.1.5
12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when
GHC is using dynamic libraries.

The only one of interest is that we now pass -fPIC when needed.

Should we include this bugfix release in the GHC release? It's quite
difficult for some users to upgrade from the Cabal version that ships with
GHC so included the newest one makes sense.

P.S. I'm looking to make a 1.22 release soon as well, for inclusion in GHC
7.10.

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

[Johan Tibell]

I've uploaded release candidates for Cabal/cabal-install patch releases on
the 1.18 and 1.20 branches:

https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz
https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz

https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz
https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-1.20.0.4.tar.gz

Please test, especially if one of your fixes are in this release. You can
install both both lib and exe using: cabal install 


Changelogs:

Cabal-1.18.1.5:
e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org
moved
fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to
1.18.1.5
12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when
GHC is using dynamic libraries.

cabal-install-1.18.0.6:
79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number
to 1.18.0.6
97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of
https://github.com/snoyberg/cabal into 1.18
4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6
6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make
list fields work like Flags.
7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config
file #1884

Cabal-1.20.0.3
7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number
to 1.20.0.4
813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to
1.20.0.3
cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org
moved
b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when
GHC is using dynamic libraries.
93aba465d35d03b29b1d9bd3a456815272a38a41 Revert
97c6a72984931f4ccf628736024d3459a033af6c.
343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/

cabal-install-1.20.0.4
7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number
to 1.20.0.4
caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in
frozen constraints
b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of
https://github.com/snoyberg/cabal into 1.20
1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network
constraint"
58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network constraint
a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6
5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make
list fields work like Flags.
13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config
file #1884
93aba465d35d03b29b1d9bd3a456815272a38a41 Revert
97c6a72984931f4ccf628736024d3459a033af6c.
aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file
as UTF-8
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Linker change in GHC 7.8 leads to widespread issues

[Johan Tibell]

I've merged the patches into the 1.20 branch. Look forward to a patch
release this weekend.

On Thu, Dec 4, 2014 at 1:43 PM, Yitzchak Gale  wrote:

> Bryan O'Sullivan wrote:
> >> It seems that something somewhere in linker-land
> >> changed in GHC 7.8 such that packages that include
> >> C components now need to be built with
> >> position-independent code on some platforms...
> >> I am not sure whether the correct fix is to pepper…
> >> packages... with "-fPIC"... or to instead teach Cabal
> >> to do this.
>
> Aha! Thanks for this explanation of what I have been
> suffering from.
>
> Mikhail Glushenkov wrote:
> > I've now fixed this issue in Cabal HEAD and also pushed the fix to
> > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out
> > soon.
>
> Thanks a million for the speedy response to this
> serious issue!
>
> I can't wait for the point releases. I'll go with HEAD on one
> of the branches for now.
>
> -Yitz
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Linker change in GHC 7.8 leads to widespread issues

[Johan Tibell]

If someone can figure out what the right fix is and if it happens to be in
Cabal I'd be happy to merge any changes.

On Tue, Dec 2, 2014 at 10:43 PM, Miëtek Bak  wrote:

> On 2014-12-02, at 21:31, Carter Schonwald 
> wrote:
>
> > whats an example of such a package?
>
>
> text-icu.
> https://github.com/bos/text-icu/pull/9
>
> FWIW, I’m in favour of fixing this at the Cabal level.
> https://github.com/haskell/cabal/issues/2207
>
> --
> Miëtek
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Johan Tibell]

Yes, ideally this would have been caught by a Windows build bot.

On Mon, Dec 1, 2014 at 4:34 PM, Simon Peyton Jones 
wrote:

>  Indeed.  But each bisect takes quite a while.  So my attention switches
> and it takes a while to get back.  I was hoping some machine might do it
> for me.
>
>
>
> Herbert suggested some commits to revert. I’ll try that first
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 01 December 2014 09:45
> *To:* Herbert Valerio Riedel
> *Cc:* ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
> *Subject:* Re: Windows build broken again: urgent
>
>
>
> In general I think a good course of action when this happens is:
>
> * Use git bisect to find the offending commit. This works now because we
> moved to submodules.
> * Revert the commit.
> * Push the patch to master and notify the author.
>
> This style of early rollback will become more important as we grow as it
> puts the onus on fixing on the right person and minimizes negative impact
> on other developers.
>
> On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel" 
> wrote:
>
> Hello Simon,
>
> On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> > |  Just a hunch... could it have been broken by one of the recent linker-
> > |  related patches since Nov 24th?
> >
> > That seems very plausible, yes.  But still there's the question of
> > what to do about it.
>
>  a) Empirically: Try locally 'git revert'ing
>
>  383733b9191a36e2d3f757700842dbc3855911d9
>
>  and/or
>
>  b5e8b3b162b3ff15ae6caf1afc659565365f54a8
>
>  and see if your problem goes away, or
>
>  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
> he sees something odd in those patches that could have broken
> Windows' GHCi...
>
> Cheers,
>   hvr
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Johan Tibell]

In general I think a good course of action when this happens is:

* Use git bisect to find the offending commit. This works now because we
moved to submodules.
* Revert the commit.
* Push the patch to master and notify the author.

This style of early rollback will become more important as we grow as it
puts the onus on fixing on the right person and minimizes negative impact
on other developers.
On Dec 1, 2014 9:43 AM, "Herbert Valerio Riedel"  wrote:

> Hello Simon,
>
> On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
> > |  Just a hunch... could it have been broken by one of the recent linker-
> > |  related patches since Nov 24th?
> >
> > That seems very plausible, yes.  But still there's the question of
> > what to do about it.
>
>  a) Empirically: Try locally 'git revert'ing
>
>  383733b9191a36e2d3f757700842dbc3855911d9
>
>  and/or
>
>  b5e8b3b162b3ff15ae6caf1afc659565365f54a8
>
>  and see if your problem goes away, or
>
>  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
> he sees something odd in those patches that could have broken
> Windows' GHCi...
>
> Cheers,
>   hvr
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ANN: Updating flag description in the User's Guide

[Johan Tibell]

Agreed. For example, the HTTP standard has moved away from X-prefixed
headers for similar reasons.

On Thu, Nov 6, 2014 at 2:13 PM, Jan Stolarek  wrote:

> > What about standardizing on an 'experimental' prefix such as
> -fx-use-rpaths
> > or -fx-kill-oneshot? These flags would not be added to the user guide and
> > their intent clear when actually using them.
> As already stated in an earlier reply I think we should have documentation
> for the sake of other
> developers.
>
> I don't like the idea of separate prefix for experimental flags. This
> could be problematic when
> the flag becomes stable - we would have to change its name and that would
> break backwards
> compatibility.
>
> Janek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)

[Johan Tibell]

I think this flag is useful for debugging e.g. why something didn't
optimize the way you thought.
On Nov 6, 2014 1:05 PM,  wrote:

> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/ad8457f93807e3b7a9a24867ed69dc93662a29e3/ghc
>
> >---
>
> commit ad8457f93807e3b7a9a24867ed69dc93662a29e3
> Author: Jan Stolarek 
> Date:   Wed Nov 5 13:37:25 2014 +0100
>
> Remove -ddump-simpl-phases flag
>
>
> >---
>
> ad8457f93807e3b7a9a24867ed69dc93662a29e3
>  compiler/main/DynFlags.hs| 15 +++
>  compiler/simplCore/CoreMonad.lhs | 40
> ++--
>  compiler/simplCore/SimplCore.lhs |  9 +
>  docs/users_guide/debugging.xml   | 11 ---
>  docs/users_guide/flags.xml   |  6 --
>  5 files changed, 14 insertions(+), 67 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
> git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc ad8457f93807e3b7a9a24867ed69dc93662a29e3
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Call Arity, oneShot or both

[Johan Tibell]

Thanks for the interesting analysis Joachim. I wouldn't trust nofib's
runtime numbers (but the allocation ones should be good). The tests don't
run long enough and the way we don't handle typical noise issues (e.g.
clock resolution, benchmark length, etc) well enough. I'd love to see some
numbers using Criterion instead.

It might also be worth to check for which programs the Core changed.

On Sat, Oct 25, 2014 at 9:24 AM, Joachim Breitner 
wrote:

> Hi,
>
>
> some months ago I tried to make foldl a good consumer in the common
> case. The starting point is always to write
>
> foldl k a xs = foldr (\v f a -> f (v `k` a)) id xs a
>
> and then somehow make GHC produce good code with this. I came up with
> two solutions: A more sophisticated compiler analysis (Call Arity), or
> an explicit annotation in the form of
>
> foldlB k a xs = foldr (\v f -> oneShot (\a -> f (v `k` a))) id
> xs a
>
> where oneShot :: (a -> b) -> (a -> b) is a built-in function,
> semantically the identity, but telling the compiler that it can assume
> that the (\a -> ...) is called at most once.
>
> Back then, we decided to use Call Arity, on the grounds that it might
> improve other code as well, despite not having a lot of evindence that
> this may happen.
>
> Then recently David Feuer built on my work by making more functions
> fuse, including functions like scanl that are not built on foldl, but
> benefit from the same analysis. This supports the usefulness of Call
> Arity.
>
> But he also found cases where Call Arity is not powerful enough and GHC
> would produce bad code. So I wanted to properly compare Call Arity with
> the oneShot approach.
>
>
> Based on todays master (0855b249), I disabled Call Arity and changed the
> definitions of foldl, foldl', scanl and scanl' to use oneShot, and ran
> nofib.
>
> The result are mixed. With the current code, the oneShot machinery does
> not always work as expected:
>
> Program   SizeAllocs   Runtime   Elapsed  TotalMem
> Min  -0.1% -1.5% -2.8% -2.8% -5.8%
> Max  +0.4% +4.7% +5.8% +5.6% +5.4%
>  Geometric Mean  -0.0% +0.1% +0.3% +0.3% +0.1%
>
> The biggest loser is calendar, which uses scanl. I am not fully sure
> what went wrong here: Either the one-shot annotation on the lambda’s
> variable got lost somewhere in the pipeline, or despite it being there,
> the normal arity analysis did not use it.
>
> But there is also a winner, fft2, with -1.5% allocations. Here Call
> Arity was not good enough, but oneShot did the jobs.
>
> There is also the option of combining both. Then we do not get the
> regression, but still the improvement for fft2:
>
> Min  -0.1% -1.5% -3.9% -3.8% -5.8%
> Max  +0.2% +0.1% +6.4% +6.3%+13.1%
>  Geometric Mean  -0.0% -0.0% +0.0% +0.0% +0.1%
>
>
>
> The oneShot code is on the branch wip/oneShot. The changes are clearly
> not ready to be merged. In particular, there is the question of how to
> best keep the oneShot annotation in the unfoldings: The isOneShotLambda
> flag is currently not stored in the interface. I work around this by
> making sure that the oneShot function is never inlined in unfoldings,
> but maybe it would be better to serialize the isOneShotLambda flag in
> interfaces, which might have other good effects?
>
>
>
> If we want as much performance as possible, we should simply include
> both approaches. But there might be other things to consider... so not
> sure what the best thing to do is.
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: `arc` changes my commit messages

[Johan Tibell]

This is probably the biggest shortcoming of Phab. If you don't want this
merging behavior you need to make a separate Phab review *per commit*.

When I use arc I usually use git to rewrite the message after the review to
something less messy.

On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg 
wrote:

> Hi all,
>
> Is there a way to put `arc` into a read-only mode?
>
> Frequently while working on a patch, I make several commits, preferring to
> separate out testing commits from productive work commits and
> non-productive (whitespace, comments) commits. Sometimes each of these
> categories are themselves broken into several commits. These commits are
> *not* my internal workflow. They are intentionally curated by rebasing as
> I'm ready to publish the patch, as I think the patches are easy to read
> this way. (Tell me if I'm wrong, here!) I've resolved myself not to use
> `arc land`, but instead to apply the patch using git.
>
> Yet, when I call `arc diff`, even if I haven't amended my patch during the
> `arc diff`ing process, the commit message of the tip of my branch is
> changed, and without telling me. I recently pushed my (tiny, uninteresting)
> fix to #9692. Luckily, my last commit happened to be the meat, so the
> amended commit message is still wholly relevant. But, that won't always be
> the case, and I was surprised to see a Phab-ified commit message appear in
> the Trac ticket after pushing.
>
> I know I could use more git-ery to restore my old commit message. But is
> there a way to stop `arc` from doing the message change in the first place?
>
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Johan Tibell]

Same here. My interaction with the user guide is infrequent enough that it
doesn't matter much to me.

On Wed, Oct 8, 2014 at 10:49 AM, Jan Stolarek 
wrote:

> > Therefore I'd like to hear your opinion on migrating away from the
> > current Docbook XML markup to some other similarly expressive but yet
> > more lightweight markup documentation system such as Asciidoc[1] or
> > ReST/Sphinx[2].
> My opinion is that I don't really care. I only edit the User Guide once
> every couple of months or
> so. I don't have problems with Docbook but if others want something else I
> can adjust.
>
> Janek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Johan Tibell]

I re-targeted some of the bugs that were "obviously" the same SpecConstr
issue to 7.8.4. There are a few others that should probably also be
re-targeted, but I couldn't tell from a quick scan of the long comment
threads.

Looking at the 7.8.4 status page, it's now quite clear that the SpecConstr
bug is a show stopper i.e. it affects lots of people/core libraries and
doesn't really have a good workaround, as turning of SpecConstr will most
likely make e.g. vector too slow.

On Tue, Oct 7, 2014 at 11:23 AM, Johan Tibell 
wrote:

> On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones  > wrote:
>
>> | 8960 looks rather serious and potentially makes all of 7.8 a no-go
>> | for some users.
>>
>
> I think this is the big issue. If you look at all the related bugs linked
> from #8960, lots of users are affected. I think this bug alone probably
> warrants a release. We should also move all those related bugs to the 7.8.4
> milestone, so the impact of this issue is more clear.
>
>
>> My conclusion
>>
>>  * I think we (collectively!) should make a serious attempt to fix
>> show-stopping
>>bugs on a major release branch.  (I agree that upgrading to the next
>> major
>>release often simply brings in a new wave of bugs because of GHC's
>>rapid development culture.)
>>
>>  * We can only possibly do this if
>>a) we can distinguish "show-stopping" from "nice to have"
>>b) we get some help (thank you John Lato for implicitly offering)
>>
>
> All sounds good to me. I can help with backporting bug fixes if needed. In
> return I would encourage people to not mix bug fixes with "I rewrote the
> compiler" commits. :)
>
> I would define a "show-stopping" bug as one that simply prevents you from
>> using the release altogether, or imposes a very large cost at the user end.
>>
>
> Agreed.
>
> -- Johan
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Johan Tibell]

On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones 
wrote:

> | 8960 looks rather serious and potentially makes all of 7.8 a no-go
> | for some users.
>

I think this is the big issue. If you look at all the related bugs linked
from #8960, lots of users are affected. I think this bug alone probably
warrants a release. We should also move all those related bugs to the 7.8.4
milestone, so the impact of this issue is more clear.


> My conclusion
>
>  * I think we (collectively!) should make a serious attempt to fix
> show-stopping
>bugs on a major release branch.  (I agree that upgrading to the next
> major
>release often simply brings in a new wave of bugs because of GHC's
>rapid development culture.)
>
>  * We can only possibly do this if
>a) we can distinguish "show-stopping" from "nice to have"
>b) we get some help (thank you John Lato for implicitly offering)
>

All sounds good to me. I can help with backporting bug fixes if needed. In
return I would encourage people to not mix bug fixes with "I rewrote the
compiler" commits. :)

I would define a "show-stopping" bug as one that simply prevents you from
> using the release altogether, or imposes a very large cost at the user end.
>

Agreed.

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Show instance for SrcSpan

[Johan Tibell]

Aside: I really miss derived Show instances in GHC. The Outputable class is
only really useful if you already know how things work. If you e.g. want to
see the AST used to represent some piece of Haskell code, in all its glory,
the Outputable instances aren't useful because they elide too much
information.

On Mon, Oct 6, 2014 at 3:11 PM, Mateusz Kowalczyk 
wrote:

> On 10/06/2014 01:59 PM, Alan & Kim Zimmerman wrote:
> > Is there any reason I can't put in a diff request to replace the derived
> > Show instance for SrcSpan with a handcrafted one that does not
> exhausively
> > list the constructors, making it more readable?
> >
> > Alan
> >
>
> Why? If you're looking for pretty output then you should be changing
> Outputable.
>
>
> --
> Mateusz K.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Again: Uniques in GHC

[Johan Tibell]

On Mon, Oct 6, 2014 at 11:58 AM,  wrote:

>  - The export-list of Unique has some comments stating that function X is
> only exported for module Y, yet is used elsewhere. This may be because
> these comments do not show up in haddock etc. leading some people to think
> they're up for general use. In my refactoring, I'm sticking the restriction
> in the function name, so it's no longer mkUniqueGrimily, but rather
> mkUniqueOnlyForUniqSupply (making the name even longer should discourage
> their use more). If at all possible, these should be removed altogether
> asap.
>

Since you're touching this code base it would be a terrific time to add
some Haddocks! (We recently decided, on the ghc-devs@ list, that all new
top-level entities, i.e. functions, data types, and classes, should have
Haddocks.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Johan Tibell]

On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel 
wrote:

> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
> > The danger, of course, is that people aren't very enthusiastic about
> > bug-fixing older versions of a compiler, but for
> > language/compiler-uptake, this might actually be a Better Way.
>
> Maybe some of the commercial GHC users might be interested in donating
> the manpower to maintain older GHC versions. It's mostly a
> time-consuming QA & auditing process to maintain old GHCs.
>

What can we do to make that process cheaper? In particular, which are the
manual steps in making a new GHC release today?

In the long run back porting bugfixes is the route successful OSS projects
take. Once people have written large enough Haskell programs they will stop
jumping onto the newer version all the time and will demand backports of
bug fixes. This is already happening to some extent in cabal (as cabal is
tied to a ghc release which means we need to backport changes sometimes.)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GitHub pull requests

[Johan Tibell]

At least for cabal there was a large uptick in contributions once we moved
to GitHub.

On Sun, Oct 5, 2014 at 7:03 AM, Ben Gamari  wrote:

> Richard Eisenberg  writes:
>
> > I've just finished reading this:
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
> >
> > For better or worse, I don't read reddit often enough to hold a
> > conversation there, so I'll ask my question here: Is there a way we
> > can turn GitHub pull requests into Phab code reviews? I'm thinking of
> > something like this:
> >
> > ...
> >
> I'm still quite unsure of how many people exist who,
>
>  * find a bug they need to fix,
>  * are willing to dig into the GHC codebase and fix it,
>  * clean up their fix enough to submit upstream, and
>  * take the initiative to send the fix upstream
>
> and yet aren't willing to take the five (twenty?) minutes to familiarize
> themselves with Phabricator and the arc toolchain.
>
> That being said, I'm all for lowering barriers. I started to write up a
> quick hack [1] to implement this sort of process. It's a bit late at the
> moment so I'll just put it up here for comment for the time being. It's
> a bit messy, the security implications are haven't been considered at
> all, and half of it is pseudo-code at best. That being said, it's a
> start and if someone picks it up and finishes it before I wake up
> tomorrow I won't be offended.
>
> Cheers,
>
> - Ben
>
>
> [1] https://gist.github.com/bgamari/72020a6186be205d0f33
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Johan Tibell]

On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp  wrote:

>  - Cull and probably remove the 7.8.4 milestone.
>- Simply not enough time to address almost any of the tickets
>  in any reasonable timeframe before 7.10.1, while also shipping them.
>- Only one, probably workarouadble, not game-changing
>  bug (#9303) marked for 7.8.4.
>- No particular pressure on any outstanding bugs to release immediately.
>- ANY release would be extremely unlikely, but if so, only
>  backed by the most critical of bugs.
>- We will move everything in 7.8.4 milestone to 7.10.1 milestone.
>  - To accurately catalogue what was fixed.
>  - To eliminate confusion.
>

#8960 looks rather serious and potentially makes all of 7.8 a no-go for
some users. I'm worried that we're (in general) pushing too many bug fixes
towards future major versions. Since major versions tend to add new bugs,
we risk getting into a situation where no major release is really solid.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken (again)

[Johan Tibell]

We need to get a windows build not up for phabricator that stops breaking
changes from getting submitted.
On Oct 2, 2014 10:40 PM, "Simon Peyton Jones"  wrote:

>  Sigh.  The testsuite fails utterly on Windows, with thousands of
> identical errors
>
> => tc012(normal) 3039 of 4088 [1, 2677, 88]
>
> cd .\typecheck\should_compile && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe'
> -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
> -rtsopts -fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns
> >tc012.comp.stderr 2>&1
>
> sh: line 0: cd: .typecheckshould_compile: No such file or directory
>
> Compile failed (status 256) errors were:
>
> *** unexpected failure for tc012(normal)
>
> Presumably this is some kind of Windows escape-character problem.  But it
> has worked fine for years, so what is going on?
>
> It’s very tiresome dealing with Windows breakage so frequently.   A few
> regression test failures, maybe, but outright breakage is very bad.
>
> Simon
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

Sounds good to me.

On Thu, Sep 25, 2014 at 11:18 AM, Simon Peyton Jones 
wrote:

>  There’s a danger of disappearing into a bikeshed here.  I think it’s
> clear that:
>
> · If we have it at all, ExtraCommas should be a {-# LANGUAGE
> ExtraCommas #-} extension, like any other.
>
> · ExtraCommas should leave tuples alone (always)
>
>
>
> Provided there is that LANGUAGE extension, I have no objection to having
> it in GHC if Alexander wants to implement it.  It has low impact, and some
> people like it a lot.  People who don’t like it don’t have to switch on the
> extension.
>
>
>
> It’s unclear whether extra commas in literal lists [a,,b,,] should behave
> like TupleSections or like ExtraCommas.  My instinct is the former, because
> the only difference is round vs square parens.That would suggest
> continuing to make extra commas illegal in literal lists, for now anyway.
> That’s a conservative choice, which is usually the side to err on when it’s
> a toss-up.
>
>
>
> OK?
>
>
>
> Simon
>
>
>
>
>
>
>
> *From:* Iavor Diatchki [mailto:iavor.diatc...@gmail.com]
> *Sent:* 25 September 2014 08:14
> *To:* Alexander Berntsen
> *Cc:* Edward Kmett; Simon Peyton Jones; ghc-devs@haskell.org
> *Subject:* Re: Permitting trailing commas for record syntax ADT
> declarations
>
>
>
> Hello,
>
>
>
> My 2c: I don't think that supporting trailing commas is worth the
> additional complexity to the compiler and the language.
>
>
>
> I work with Haskell on a daily basis, and I honestly don't think that this
> is going to simplify my job in any way.  On the other hand, it seems like
> it it will make it more complex to write tools that process Haskell, and to
> explain the syntax of the language to beginners.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen 
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 24/09/14 08:50, Edward Kmett wrote:
> > I'm personally of the "it should be a language extension like
> > everything else" mindset
> Yeah, I'm going the Pragma route.
>
> > If we limit it to record-like notions, and import/export lists,
> > then we don't have to deal with conflicts with TupleSections and
> > while it is inconsistent to have tuples behave differently, than
> > other comma-separated lists, I'd really rather retain tuple
> > sections, which I use somewhat heavily, than lose them to mindless
> > uniformity over how we handle comma-separated lists.
> I'm implementing it for things where I 100% subjectively feel it makes
> sense. This does *not* include tuples, for the reason you mention.
>
> When I get the time, I will make a Wiki page outlining what I'm changing
> and my motivation for doing it. We can then have a discussion about
> where to draw the line.
>
>
> I need to figure out a more elegant solution than tweaking the parser
> for each individual item. If someone knows their way around this code,
> please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact
> info. I'll be busy today with a haskell workshop, but I plan on
> spending the rest of the week on this business.
> - --
> Alexander
> alexan...@plaimi.net
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6
> /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe
> =l/sh
>
> -END PGP SIGNATURE-
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

The reason to support trailing commas are entirely related to engineering
and not language expressiveness. Having trailing commas means that diff
tools and version control systems work better. This is why most languages
support them.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

I must say that requiring a language pragma makes the feature quite a bit
more heavy weight. We're not changing the meaning of any existing programs,
just allowing some new ones. One could argue that perhaps the HaskellXX
standard might pick up this new pragma and thus making it unnecessary
eventually, but the standardization process is dead (and even when it was
alive, it was lagging actual practice enough that it was largely ignored.)


On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka  wrote:

> On 23/09/14 10:11, Alexander Berntsen wrote:
> > On 22/09/14 21:07, Simon Peyton Jones wrote:
> >> have a language extension TrailingCommas (or something) to enable
> >> the extension
> > For clarification: are you overruling the "do we sneak it in HEAD or
> > use pragma(s)"-vote and telling me to do the latter?
> >
> > If we can sneak it into HEAD (this is @ you Johan, too), I suggest
> > that someone applies my patches to make import and export lists
> > support leading commas (presently they only support trailing commas,
> > per the report) -- and following this I can just send a bunch of
> > "Permit leading/trailing ',' in Foo" patches to Phabricator, and you
> > guys can bikeshed over there about which ones you actually want to
> > commit. ;-)
> >
> > If I am to go down the pragma route, I guess I can make a
> > RudundantCommas pragma or something like that, that implements
> > trailing commas for imports/exports, and leading/trailing commas for
> > the suggestions in this thread.
> >
> > I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to
> > the pragma route either.
>
> Here's my reasoning:
>
> If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be
> accepted, because they do not belong to Haskell 2010.
>
> Which means that you do need an extension to identify this difference in
> behavior.
>
> Roman
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

Don't worry about supporting trailing/leading commas everywhere for now.
Have it work for records first. We can always add support in more places
later.

On Mon, Sep 22, 2014 at 9:07 PM, Simon Peyton Jones 
wrote:

>  I’m all for it.  To progress it you need to
>
> ·open a Trac ticket,
>
> ·start a wiki page to describe the design specifically (e.g give
> all the changed syntax rules)
>
> ·have a language extension TrailingCommas (or something) to
> enable the extension
>
> ·perhaps suggest switching on the extension if the program parses
> with it, but fails without
>
> ·develop a patch
>
>
>
> Easy really!  I doubt it’s controversial.
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
> Tibell
> *Sent:* 22 September 2014 14:28
> *To:* Alexander Berntsen
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Permitting trailing commas for record syntax ADT
> declarations
>
>
>
> +1
>
>
>
> I think this makes sense and we should allow trailing commas wherever the
> syntax allows it without adding ambiguity (e.g. tuple sections prevent
> trailing commas for tuple declarations.)
>
>
>
> P.S. Last time we tried to discuss something like this (on libraries@ I
> believe) the whole discussion devolved into a "lets rewrite all of
> Haskell". Lets not do that here. Thanks!
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel 
wrote:

> On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote:
> > Forwarding this & my reply to the ML as well,
> >
> >
> > On 22/09/14 14:27, David Luposchainsky wrote:
> >> +1. While you're at it, you may also want to consider allowing
> >> leading commas for the folks that write their exports/records "the
> >> other way round"
> > Sure. Both styles are common in the wild, so that makes sense.
>
> +1 (I'd even say that leading-comma style is the predominant one these
> days thanks to [1] et al.)
>
> [snip]
>
>
>  [1]:
> https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md


 And to complete the circle. I designed [1] to work with the lack of
support for a trailing comma. If we supported a trailing comma my style
guide would probably be different.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

+1

I think this makes sense and we should allow trailing commas wherever the
syntax allows it without adding ambiguity (e.g. tuple sections prevent
trailing commas for tuple declarations.)

P.S. Last time we tried to discuss something like this (on libraries@ I
believe) the whole discussion devolved into a "lets rewrite all of
Haskell". Lets not do that here. Thanks!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: AMP performance effect

[Johan Tibell]

On Fri, Sep 12, 2014 at 3:52 PM, Joachim Breitner 
wrote:

> nothing overly exciting, but since I am running this ghcspeed thing, I
> guess I should inform you about changes, just to get some practice doing
> that :-)


I'm very much in support of doing this.

Once we think pagespeed is stable enough, I would be for sending automated
emails on regressions.

If you need a different machine to host it, you can reach out to
ad...@haskell.org. If they don't have one, I have a quiet quite powerful
machine in a data center.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Does the 'stage=2' setting not work anymore in build.mk?

[Johan Tibell]

I think make maintainer-clean removes it. I find this hidden pieces of
state annoying. It has definitely tripped me up in the past. Perhaps we can
have make clean remove it?


On Fri, Aug 29, 2014 at 2:14 PM, Dr. ERDI Gergo  wrote:

> On Fri, 29 Aug 2014, Edward Z. Yang wrote:
>
>  OK, it's definitely worked for me in that time.  Do you have
>> mk/are-validating.mk in your tree? Also do try on a fresh working copy.
>>
>
> Yes I do! Is that the remnant of some failed validation process? Should I
> remove it?
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build fails -- again!

[Johan Tibell]

I think reverting the patch (and notifying the author) is an OK course of
action if it's affecting other people's work. I believe it's common
practice at many other places. The patch can always be replied later, after
fixing it.

P.S. We should re-open the bug if we revert the patch (i.e. by git revert
SHA1 && git push).


On Fri, Aug 22, 2014 at 2:07 PM, Simon Peyton Jones 
wrote:

> Friends
>
> My Windows build is still broken, and has been since Andreas's patch
> commit f9f89b7884ccc8ee5047cf4fffdf2b36df6832df
> on Tues 19th.
>
> Please can someone help?  I'm begging.
>
> I suppose that if I hear nothing I can simply revert his patch but that
> seems like the Wrong Solution
>
> Thanks
>
> Simon
>
> | -Original Message-
> | From: Simon Peyton Jones
> | Sent: 20 August 2014 23:48
> | To: 'Gabor Greif'; 'ghc-devs@haskell.org'; 'Andreas Voellmy'
> | Subject: RE: Windows build fails -- again!
> |
> | Help!  My Windows build is still falling over as below.
> |
> | Andreas, you seem to be the author of the commit that broke this.  I'd
> | really appreciate a fix.  (From anyone!)
> |
> | thank you
> |
> | Simon
> |
> | | -Original Message-
> | | From: Simon Peyton Jones
> | | Sent: 20 August 2014 09:26
> | | To: Gabor Greif; ghc-devs@haskell.org
> | | Subject: RE: Windows build fails -- again!
> | |
> | | Thanks Gabor.  But it makes no difference.  Your change is inside an
> | | #ifdef that checks for windows, and your change is in the no-windows
> | | branch only.
> | |
> | | Also there are two IOManager.h file
> | | includes/rts/IOManager.h
> | | rts/win32/IOManager.h
> | |
> | | Should there be?  It seems terribly confusing, and I have no idea which
> | | will win when it is #included.
> | |
> | | Thanks
> | |
> | | Simon
> | |
> | | | -Original Message-
> | | | From: Gabor Greif [mailto:ggr...@gmail.com]
> | | | Sent: 19 August 2014 23:38
> | | | To: Simon Peyton Jones
> | | | Subject: Re: Windows build fails -- again!
> | | |
> | | | Simon,
> | | |
> | | | try this (attached) patch:
> | | |
> | | | $ git am 0001-Make-sure-that-a-prototype-is-included-for-
> | | | setIOMana.patch
> | | |
> | | | Cheers,
> | | |
> | | | Gabor
> | | |
> | | | PS: on MacOS all is good, so I could not test it at all
> | | |
> | | | On 8/20/14, Simon Peyton Jones  wrote:
> | | | > Aaargh!  My windows build is broken, again.
> | | | > It's very painful that this keeps happening.
> | | | > Can anyone help?
> | | | > Simon
> | | | >
> | | | > "inplace/bin/ghc-stage1.exe" -optc-U__i686 -optc-march=i686
> | | | > -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall
> | | | > -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
> | | | > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
> | | | > -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs
> | | | > -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist
> | | | > -optc-Iincludes/dist-derivedconstants/header
> | | | > -optc-Iincludes/dist-ghcconstants/header -optc-Irts
> | | | > -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-
> | aliasing
> | | | > -optc-fno-common -optc-O2 -optc-fomit-frame-pointer
> | | | > -optc-DRtsWay=\"rts_v\" -static  -H32m -O -Werror -Wall -H64m -O0
> | | | > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
> | | | > -Iincludes/dist-ghcconstants/header
> | | | > -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts
> | | | > -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -
> | | | Irts/dist/build
> | | | > -Irts/dist/build/autogen   -O2-c rts/Task.c -o
> | | | > rts/dist/build/Task.o
> | | | >
> | | | > cc1.exe: warnings being treated as errors
> | | | >
> | | | >
> | | | >
> | | | > rts\Capability.c:1080:6:
> | | | >
> | | | >  error: no previous prototype for 'setIOManagerControlFd'
> | | | >
> | | | > rts/ghc.mk:236: recipe for target 'rts/dist/build/Capability.o'
> | | | failed
> | | | >
> | | | > make[1]: *** [rts/dist/build/Capability.o] Error 1
> | | | >
> | | | > make[1]: *** Waiting for unfinished jobs
> | | | >
> | | | > Makefile:71: recipe for target 'all' failed
> | | | >
> | | | > make: *** [all] Error 2
> | | | >
> | | | > HEAD (master)$
> | | | >
> | | | >
> | | | >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build fails -- again!

[Johan Tibell]

f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably to blame.

Found by running `git log -SsetIOManagerControlFd`. The -S flag is a good
way to find when a symbol is added/removed.


On Wed, Aug 20, 2014 at 12:16 AM, Simon Peyton Jones 
wrote:

>  Aaargh!  My windows build is broken, again.
>
> It’s very painful that this keeps happening.
>
> Can anyone help?
>
> Simon
>
> "inplace/bin/ghc-stage1.exe" -optc-U__i686 -optc-march=i686
> -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall -optc-Wextra
> -optc-Wstrict-prototypes -optc-Wmissing-prototypes
> -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
> -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs
> -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist
> -optc-Iincludes/dist-derivedconstants/header
> -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build
> -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2
> -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -static  -H32m -O -Werror
> -Wall -H64m -O0 -Iincludes -Iincludes/dist
> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header
> -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts
> -dcmm-lint  -i -irts -irts/dist/build -irts/dist/build/autogen
> -Irts/dist/build -Irts/dist/build/autogen   -O2-c rts/Task.c -o
> rts/dist/build/Task.o
>
> cc1.exe: warnings being treated as errors
>
>
>
> rts\Capability.c:1080:6:
>
>  error: no previous prototype for 'setIOManagerControlFd'
>
> rts/ghc.mk:236: recipe for target 'rts/dist/build/Capability.o' failed
>
> make[1]: *** [rts/dist/build/Capability.o] Error 1
>
> make[1]: *** Waiting for unfinished jobs
>
> Makefile:71: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
> HEAD (master)$
>
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: How's the integration of DWARF support coming along?

[Johan Tibell]

Seeing the code on Phab it two weeks sounds great.

Do you mind expanding on what tick scopes are. It sounds scarily like
something that happens at runtime. :)


On Wed, Aug 13, 2014 at 8:49 PM, Peter Wortmann  wrote:

>
>
> At this point I have a bit more time on my hands again (modulo post-thesis
> vacations), but we are basically still in “review hell”.
>
> I think “just” for perf_events support we’d need the following patches[1]:
> 1. Source notes (Core support)
> 2. Source notes (CorePrep & Stg support)
> 3. Source notes (Cmm support)
> 4. Tick scopes
> 5. Debug data extraction (NCG support)
> 6. Generate .loc/.file directives
>
> We have a basic “okay” from the Simons up to number 2 (conditional on
> better documentation). Number 4 sticks out because Simon Marlow wanted to
> have a closer look at it - this is basically about how to maintain source
> ticks in a robust fashion on the Cmm level (see also section 5.5 of my
> thesis[2]).
>
> Meanwhile I have ported NCG DWARF generation over to Mac Os, and am
> working on reviving LLVM support. My plan was to check that I didn’t
> accidentally break Linux support, then push for review again in a week or
> so (Phab?).
>
> Greetings,
>   Peter
>
> [1] https://github.com/scpmw/ghc/commits/profiling-import
> [2] http://www.personal.leeds.ac.uk/~scpmw/static/thesis.pdf
>
> On 13 Aug 2014, at 20:01, Johan Tibell  johan.tib...@gmail.com>> wrote:
>
> What's the minimal amount of work we need to do to just get the dwarf data
> in the codegen by 7.10 (RC late december) so we can start using e.g. linux
> perf events to profile Haskell programs?
>
>
> On Wed, Aug 13, 2014 at 7:31 PM, Arash Rouhani  <mailto:rar...@student.chalmers.se>> wrote:
> Hi Johan!
>
> I haven't done much (just been lazy) lately, I've tried to benchmark my
> results but I don't get any sensible results at all yet.
>
> Last time Peter said he's working on a more portable way to read dwarf
> information that doesn't require Linux. But I'm sure he'll give a more
> acurate update than me soon in this mail thread.
>
> As for stack traces, I don't think there's any big tasks left, but I
> summarize what I have in mind:
>
>  *   The haskell interface is done and I've iterated on it a bit, so it's
> in a decent shape at least. Some parts still need testing.
>  *   I wish I could implement the `forceCaseContinuation` that I've
> described in my thesis. If someone is good with code generation (I just
> suck at it, it's probably simple) and is willing to assist me a bit, please
> say so. :)
>  *   I tried benchmarking, I gave up after not getting any useful results.
>  *   I'm unfortunately totally incapable to help out with dwarf debug data
> generation, only Peter knows that part, particularly I never grasped his
> theoretical framework of causality in Haskell.
>  *   Peter and I have finally agreed on a simple and sensible way to
> implement `catchWithStack` that have all most good properties you would
> like. I just need to implement it and test it. I can definitely man up and
> implement this. :)
>
> Here's my master thesis btw [1], it should answer Ömer's question of how
> we retrieve a stack from a language you think won't have a stack. :)
>
> Cheers,
> Arash
>
> [1]: http://arashrouhani.com/papers/master-thesis.pdf
>
>
>
>
>
> On 2014-08-13 17:02, Johan Tibell wrote:
> Hi,
>
> How's the integration of DWARF support coming along? It's probably one of
> the most important improvements to the runtime in quite some time since
> unlocks *two* important features, namely
>
>  * trustworthy profiling (using e.g. Linux perf events and other
> low-overhead, code preserving, sampling profilers), and
>  * stack traces.
>
> The former is really important to move our core libraries performance up a
> notch. Right now -prof is too invasive for it to be useful when evaluating
> the hotspots in these libraries (which are already often heavily tuned).
>
> The latter one is really important for real life Haskell on the server,
> where you can sometimes can get some crash that only happens once a day
> under very specific conditions. Knowing where the crash happens is then
> *very* useful.
>
> -- Johan
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs