Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Johan Tibell]

It might be enough to just add a NOWARN  pragma that acts on
a single line/expression. I've seen it in both C++ and Python linters and
it works reasonably well and it's quite general.

On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari  wrote:

> Sven Panne  writes:
>
> > 2015-10-05 17:09 GMT+02:00 Gershom B :
> >
> >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (b...@serpentine.com
> )
> >> wrote:
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >>
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
> >
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
>
> -- in Control.Applicative
> {-# ALLOW redundant_import (<$>) #-}
> (<$>) :: (a -> b) -> f a -> f b
> (<$>) = fmap
>
> asking the compiler to pretend that any import of the symbol did not
> exist when looking for redundant imports. This would allow library
> authors to appropriately mark definitions when they are moved,
> saving downstream users from having to make any change whatsoever.
>
>  2. Or alternatively we could make this a idea a bit more precise,
>
> -- in Control.Applicative
> {-# ALLOW redundant_import Prelude.(<$>) #-}
> (<$>) :: (a -> b) -> f a -> f b
> (<$>) = fmap
>
> Which would ignore imports of `Control.Applicative.(<$>)` only if
> `Prelude.(<$>)` were also in scope.
>
>  3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,
>
> import {-# ALLOW redundant_import #-} Control.Applicative
>
> -- or perhaps
> import Control.Applicative
> {-# ALLOW redundant_import Control.Applicative #-}
>
> allowing the user to explicitly state that they are aware that this
> import may be redundant.
>
>  4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
> import list,
>
> import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})
>
> allowing the user to explicitly state that they are aware that this
> imported function may be redundant.
>
> In general I'd like to reiterate that many of the comments in this
> thread describe genuine sharp edges in our language which have presented
> a real cost in developer time during the AMP and and FTP transitions. I
> think it is worth thinking of ways to soften these edges; we may be
> surprised how easy it is to fix some of them.
>
> - Ben
>
>
> [1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Johan Tibell]

(Resending with smaller recipient list to avoid getting stuck in the
moderator queue.)

On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <h...@gnu.org> wrote:

> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> > On the libraries I maintain and have a copy of on my computer right now:
> 329
>
>
> Although this was already pointed out to you in a response to a Tweet of
> yours, I'd like to expand on this here to clarify:
>
>
> You say that you stick to the 3-major-ghc-release support-window
> convention for your libraries. This is good, because then you don't need
> any CPP at all! Here's why:
>
> [...]
>

So what do I have to write today to have my Monad instances be:

 * Warning free - Warnings are useful. Turning them off or having spurious
warnings both contribute to bugs.
 * Use imports that either are qualified or have explicit import lists -
Unqualified imports makes code more likely to break when dependencies add
exports.
 * Don't use CPP.

Neither AMP or MRP includes a recipe for this in their proposal. AMP got
one post-facto on the Wiki. It turns out that the workaround there didn't
work (we tried it in Cabal and it conflicted with one of the above
requirements.)

PS: I'm a bit disappointed you seem to dismiss this proposal right away
> categorically without giving us a chance to address your
> concerns. The proposal is not a rigid all-or-nothing thing that
> can't be tweaked and revised.  That's why we're having these
> proposal-discussions in the first place (rather than doing blind
> +1/-1 polls), so we can hear everyone out and try to maximise the
> agreement (even if we will never reach 100% consensus on any
> proposal).
>
> So please, keep on discussing!
>

The problem by discussions is that they are done between two groups with
quite a difference in experience. On one hand you have people like Bryan,
who have considerable contributions to the Haskell ecosystem and much
experience in large scale software development (e.g. from Facebook). On the
other hand you have people who don't. That's okay. We've all been at the
latter group at some point of our career.

What's frustrating is that people don't take a step bad and realize that
they might be in the latter group and should perhaps listen to those in the
former. This doesn't happen, instead we get lots of "C++ and Java so bad
and we don't want to be like them." Haskell is not at risk of becoming C++
or Java (which are a large improvement compared to the languages came
before them). We're at risk of missing our window of opportunity. I think
that would be a shame, as I think Haskell is a step forward compared to
those languages and I would like to see more software that used be written
in Haskell.

We've been through this many times before on the libraries list. I'm not
going to win an argument on this mailing list. Between maintaining
libraries you all use and managing a largish team at Google, I don't have
much time for a discussion which approaches a hundred emails and is won by
virtue of having lots of time to write emails.

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

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Johan Tibell]

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins 
wrote:

>
> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B  wrote:
>
>> My understanding of the argument here, which seems to make sense to me,
>> is that the AMP already introduced a significant breaking change with
>> regards to monads. Books and lecture notes have already not caught up to
>> this, by and large. Hence, by introducing a further change, which
>> _completes_ the general AMP project, then by the time books and lecture
>> notes are all updated, they will be able to tell a much nicer story than
>> the current one?
>
>
> This is a multi-year, "boil the ocean"-style project, affecting literally
> every Haskell user, and the end result after all of this labor is going to
> be... a slightly spiffier bike shed?
>
> Strongly -1 from me also. My experience over the last couple of years is
> that every GHC release breaks my libraries in annoying ways that require
> CPP to fix:
>
> ~/personal/src/snap λ  find . -name '*.hs' | xargs egrep
> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
> 64
>
>
> As a user this is another bikeshedding change that is not going to benefit
> me at all. Maintaining a Haskell library can be an exasperating exercise of
> running on a treadmill to keep up with busywork caused by changes to the
> core language and libraries. My feeling is starting to become that the
> libraries committee is doing as much (if not more) to *cause* problems
> and work for me than it is doing to improve the common infrastructure.
>

On the libraries I maintain and have a copy of on my computer right now: 329
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Johan Tibell]

On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink  wrote:

> On 5 October 2015 at 20:58, Sven Panne  wrote:
> > 2015-10-05 17:09 GMT+02:00 Gershom B :
> >>
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
>
> Does the hack mentioned on the GHC trac [1] work for this? It seems a
> bit fragile but that page says it works and it avoids CPP.
>

No it doesn't, if you also don't want closed import lists (which you
should).
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: HEADS UP: Final call for 7.10.2 is soon

[Johan Tibell]

There have been some requests for a Cabal library release for 7.10.2. I
remember something about truncate directories/symbol names being an issue.
I'm CC:ing the Cabal mailing list for comments.

On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani mech...@botik.ru wrote:

 Please,
 consider my recent bug report
 overlapping instances in 7.10.1
 (see my resent email to this list).

 --
 Sergei



 On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote:
  Hi *,
 
  I've just finished merging all the latest patches for GHC 7.10.2 into
  the STABLE branch. All in all, we've fixed a lot of bugs (over 80
  tickets closed)!
 
  So, we'll probably be doing a 7.10.2 release here in a few weeks. The
  tentative plan was around the 14th, although it's not set in stone.
  (At worst, it would be pushed from the 14th to the 21st).
 
  With that in mind, if I could quickly direct your attention to the GHC
  bug tracker and the status page[1] - it would be really helpful if you
  check if the things you want are fixed!
 
  Specifically, if you want something fixed for the 7.10.2 release:
 
- Make sure there is a ticket. It really needs to exist or we'll just
 forget!
 
- If your bug is critical, please explain why! We really want to
  kill showstoppers ASAP, because bugs are much cheaper to fix early. If
  that's the case we can bump the priority if it's necessary to make
  things clear.
 
- Set the milestone to 7.10.2. It'll automatically appear on the
 status page.
 
  That should be it - we'll be monitoring the status page regularly to
  keep track of new things. The current bug list is pretty small - we
  may move some of them out, or fix several more. So just try to let us
  know.
 
  As a sidenote, I'm quite happy with this release - it's fixed dozens
  of tricky bugs, improved some nasty corner cases in compiler
  performance, and overall seems like it will be high quality. Thanks to
  everyone who submitted patches!
 
  I'll send out another email next week as another reminder.
 
  [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2
 


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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 george.colpi...@gmail.com
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-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

That would be nice if we had a clean slate, but I don't people are going to
change their whole import lists now. Adding a comma at the end is less
disruptive.

On Fri, Sep 26, 2014 at 11:06 PM, John Wiegley jo...@newartisans.com
wrote:

  Richard Eisenberg e...@cis.upenn.edu writes:

  What if we just stopped requiring commas in import/export lists? As far
 as I
  can tell, they're not necessary for proper parsing.

 +1

 John
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Permitting trailing commas for record syntax ADT declarations

[Johan Tibell]

I don't think that's necessarily is good style. I don't think we want two
different ways of doing import lists. The original proposal was to address
a quite small but important engineer issue: without allow *one* trailing
comma your version control history gets messed up, because the wrong person
gets blamed for a line of code. The standard programming language way of
solving that problem is to allow a trailing comma.

On Fri, Sep 26, 2014 at 11:16 PM, Brandon Allbery allber...@gmail.com
wrote:

 On Fri, Sep 26, 2014 at 5:12 PM, Johan Tibell johan.tib...@gmail.com
 wrote:

 That would be nice if we had a clean slate, but I don't people are going
 to change their whole import lists now.


 I read the proposal as making all commas optional, not as requiring them
 to not be present.

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 'import ccall unsafe' and parallelism

[Johan Tibell]

Hi!

On Thu, Aug 14, 2014 at 5:54 PM, Christian Höner zu Siederdissen 
choe...@tbi.univie.ac.at wrote:

 However, due to the way ghc handles unsafe imports, namely block
 everything else whenever 'cfun' is called, I happen to have only one
 active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall
 safe' more than I'd be willing to pay.


Calls to unsafe functions do not block everything! Other Haskell threads
can continue running on other capabilities (make sure you run your program
with +RTS -N). However, make sure that the C function itself never blocks,
or it might deadlock your program.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Johan Tibell]

On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
 On 30 July 2014 22:07, Andreas Abel andreas.a...@ifi.lmu.de wrote:
 I am a bit surprised by the distinction you outline below.  This is maybe
 because I am native German, not English.  The German equivalent of
 overlap, überschneiden/überlappen, is used exclusively in a symmetrical
 fashion.  It's like in English, if I say our interests overlap, then it is
 pointless to ask whether my interest are overlapping yours or are overlapped
 by yours.  I want to alert you to the fact that non-native English speaker
 might have little understanding for a distinction between OVERLAPPING and
 OVERLAPPABLE.

 Let's try to guess what it meant:  Given

 A) instance Bla Char
 B) instance Bla a = Bla [a]
 C) instance Bla String

 you will in context A,B write C as OVERLAPPING,
 and in context A,C write B as OVERLAPPABLE?

 IIUC, B will be OVERLAPPABLE (you can overlap this) and C will be
 OVERLAPPING (I'm overlapping an existing one) whereas C will be
 plain.

Apologies if this question doesn't make sense.

Can we really talk about overlapping, given that instances can be
written in different modules, moved between modules, or removed?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Johan Tibell]

On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org wrote:
 On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
 instance {-# OVERLAPPABLE #-} Show a = Show [a] where …

 Is the syntax somewhat flexible in where the pragma can be placed?
 For example, some might prefer

   {-# OVERLAPPING #-}
   instance Show [Char] where …

 This variant may also be more convenient in cases where you need to
 CPP-guard that pragma, as it's on a separate line.

Agreed, and if we remove the old pragma (even with a deprecation
cycle) you'll see quite a few of those as many library authors try to
have their libraries compile with the last 3 major GHC versions.

P.S. For e.g. INLINABLE we require that you mention the function name
next to the pragma (which means that you can e.g. put the pragma after
the declaration). What's the rationale to not require

{-# OVERLAPPING Show [Char] #-}

here? Perhaps it's too annoying to have to repeat the types?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Johan Tibell]

On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:

 On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
 What's the rationale to not require

 {-# OVERLAPPING Show [Char] #-}

 here? Perhaps it's too annoying to have to repeat the types?

 This one might be written at the top of the file, so it would be easier
 to overlook it, than having it directly at the instance declaration,
 which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.

The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8.3 release

[Johan Tibell]

I would say sooner. Here are still unmerged things that I think we could
merge before (i.e. easy to merge):

https://ghc.haskell.org/trac/ghc/ticket/9001
https://ghc.haskell.org/trac/ghc/ticket/9078
https://ghc.haskell.org/trac/ghc/ticket/8475
https://ghc.haskell.org/trac/ghc/ticket/8783
https://ghc.haskell.org/trac/ghc/ticket/9068
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: include a cabal-install executable in future GHC releases

[Johan Tibell]

Thanks. Between you and Mikhail we got the Windows side covered. :)


On Sun, May 4, 2014 at 11:13 AM, Niklas Larsson metanik...@gmail.comwrote:

 Hi!

 I put a Windows build here:
 https://www.dropbox.com/s/at7wc1dh0lfr7lc/cabal.exe.zip

 Niklas
 2014-05-04 2:24 GMT+02:00 Johan Tibell johan.tib...@gmail.com:

 I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm
 waiting for someone to send me a Windows one.


 On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley ash...@semantic.orgwrote:

 I couldn't find them, and they're not listed at 
 http://www.haskell.org/cabal/download.html (except OS X), or at 
 http://www.haskell.org/haskellwiki/Cabal-Install, or at 
 http://hackage.haskell.org/package/cabal-install.

 -- Ashley


 On 2014-05-03 17:00, Carter Schonwald wrote:

 I think there's now hosted official cabal install binaries online.  I'm
 Afk but they should be a short google away. Should be linked more
 prominently though

 On Saturday, May 3, 2014, Ashley Yakeley ash...@semantic.org mailto:
 ash...@semantic.org wrote:

 So I want to install GHC + cabal on a new system, building cabal
 packages with profiling and documentation. Here's what I have to do:

 1. Download, unpack and install GHC.

 2. Download and unpack cabal-install, and run bootstrap.sh. As
 part of the bootstrap, it will download and build a bunch of
 packages.

 3. Delete the downloaded packages (rm -rf ~/.ghc/*) because they
 were built without profiling or documentation.

 4. Call cabal update to get a default .cabal/config file.

 5. Edit .cabal/config to switch on library-profiling,
 executable-profiling, and documentation.

 6. Build my stuff.

 This would be much simplified if binary versions of cabal-install
 were available. (It would be even simpler if they were just
 included in the GHC builds -- I could eliminate 2  3.)

 -- Ashley Yakeley
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: include a cabal-install executable in future GHC releases

[Johan Tibell]

I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm waiting
for someone to send me a Windows one.


On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley ash...@semantic.org wrote:

 I couldn't find them, and they're not listed at 
 http://www.haskell.org/cabal/download.html (except OS X), or at 
 http://www.haskell.org/haskellwiki/Cabal-Install, or at 
 http://hackage.haskell.org/package/cabal-install.

 -- Ashley


 On 2014-05-03 17:00, Carter Schonwald wrote:

 I think there's now hosted official cabal install binaries online.  I'm
 Afk but they should be a short google away. Should be linked more
 prominently though

 On Saturday, May 3, 2014, Ashley Yakeley ash...@semantic.org mailto:
 ash...@semantic.org wrote:

 So I want to install GHC + cabal on a new system, building cabal
 packages with profiling and documentation. Here's what I have to do:

 1. Download, unpack and install GHC.

 2. Download and unpack cabal-install, and run bootstrap.sh. As
 part of the bootstrap, it will download and build a bunch of packages.

 3. Delete the downloaded packages (rm -rf ~/.ghc/*) because they
 were built without profiling or documentation.

 4. Call cabal update to get a default .cabal/config file.

 5. Edit .cabal/config to switch on library-profiling,
 executable-profiling, and documentation.

 6. Build my stuff.

 This would be much simplified if binary versions of cabal-install
 were available. (It would be even simpler if they were just
 included in the GHC builds -- I could eliminate 2  3.)

 -- Ashley Yakeley
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Removing -fext-core

[Johan Tibell]

+1
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildbots

[Johan Tibell]

We now have a (Linux) travis-ci buildbot so we should be able to use
whatever script that buildbot runs.

To make a full validate you simply check out the source repos and run:

CPUS=N sh validate

(CPUS=N is optional of course.)


On Tue, Apr 1, 2014 at 9:42 AM, harry volderm...@hotmail.com wrote:

 It having been suggested that a buildbot for Windows may be needed, and it
 being possible that I may receive permission from management for setting
 one
 up in my department's server room, I set about attempting to discover what
 this actually entails.

 A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot,
 which tells me that Buildbot is currently down, and we are working on a
 replacement. See Builder for more details. If I follow the 'down' link , I
 get to the GHC status April 2010 page, which says that buildbot has been
 abandoned, suggesting that the page should be deleted. Could someone
 confirm
 before I go ahead and delete it?

 The Builder page has clear instructions on how to set up a build slave, and
 a link to the build results. The build results contains an assortment of
 dud
 links and builds from August and earlier.

 What is the current state of automated builds?



 --
 View this message in context:
 http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html
 Sent from the Haskell - Glasgow-haskell-users mailing list archive at
 Nabble.com.
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildbots

[Johan Tibell]

On Tue, Apr 1, 2014 at 10:07 AM, harry volderm...@hotmail.com wrote:

 Johan Tibell-2 wrote
  We now have a (Linux) travis-ci buildbot so we should be able to use
  whatever script that buildbot runs.

 Does this mean that the Builder page is also no longer relevant? And if so,
 how could a Windows buildbot be set up?


I don't know whether the old buildbot is still in use. I haven't seen any
emails from it in quite a while. I'll wait for some other people on the
list to chime in.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildbots

[Johan Tibell]

On Tue, Apr 1, 2014 at 12:46 PM, Joachim Breitner
m...@joachim-breitner.dewrote:

 Hi,

 Am Dienstag, den 01.04.2014, 10:25 + schrieb Simon Peyton Jones:
  Joachim Breitner has set up Travis-CI.  (I don't know exactly what
  that is, but it sounds useful.)

 Travis is a free cloud service that runs arbitrary tests (in our case, a
 stripped version of validate) upon pushes to git repositories on github.
 I set it up to validate our master, so we get a nice history of
 successes and failures on
 https://travis-ci.org/nomeata/ghc-complete/builds
 and I get mails when things fail; that is when I send hopefully polite
 enough mails to ghc-dev, asking people to fix their commits.

 (Unless I broke it myself; then I silently fix it and hide.)


If the false positive rate is low, feel free to automatically have the
emails sent to ghc-devs@. We want to know when we broke stuff ASAP.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Haskell Support on Windows

[Johan Tibell]

On Mon, Mar 31, 2014 at 2:57 PM, Niklas Larsson metanik...@gmail.comwrote:

  Seems to me that a less pessimistic solution would be to set up a
 windows buildbot.


+1

I believe there's at least one investment bank that uses Haskell on
Windows. Perhaps they could set one up. ;)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: include a cabal-install executable in future GHC releases

[Johan Tibell]

On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel h...@gnu.orgwrote:

 On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
  I feel this blurs the roles of GHC and the Platform.

 IMO, that's a weak argument, as the roles are already blurred:

 GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
 provided by the HP instead. Moreover, GHC ships with a set of base
 libraries (which, and thus effectively GHC forces 20 or so packages
 (fixed to specific package versions) into the HP and takes away
 authority from the HP release process. But now the difficult to explain
 thing is that GHC also bundles the library part of CABAL but
 deliberately leaves out CABAL's frontend tool `cabal-install` only to
 justify the existence of the HP a bit more? :-)


Cabal is part of GHC's build process and GHC uses data types from Cabal.
That's why it's there. It's not because we want Cabal to be included (just
like we don't want to ship those libs.) These are technical limitations.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: include a cabal-install executable in future GHC releases

[Johan Tibell]

We could offer OS X and Linux binaries in addition to the Windows binaries
already downloaded on the cabal home page (http://www.haskell.org/cabal/)
if someone could commit to building them.

Aside: Right now building the Windows binaries is a very ad-hoc process (I
email Mikhail who has a Windows machine and ask him to build one). I'm not
very keen to make the process even slower, given that that will mean I will
make fewer cabal releases. Ideally the binaries could be produced on a
build bot. The very least we should have the Makefile in the cabal repo
being able to create the binary in a reproducible manner.

-- Johan



On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam gan...@earth.liwrote:

 I feel this blurs the roles of GHC and the Platform.

 Can't the cabal-install that comes with the Platform can be used with a
 later GHC installation? If that's correct, then the only use case that
 this proposal covers is someone who wants to use a bleeding edge GHC and
 no other version on a new machine. A separate binary distribution of
 cabal-install should be more than adequate for that and it avoids
 coupling GHC to other things.

 So a weak -1.


 On 20/01/2014 00:02, Carter Schonwald wrote:
  Hey everyone,
 
  I'd like to propose that GHC releases 7.8.1 onwards include a
  cabal-install (aka cabal) executable, but not include the library deps
  of cabal-install that aren't already distributed with ghc.(unless ghc
  should have those deps baked in, which theres very very good reasons not
  to do.).
 
  currently if someone wants just a basic haskell install of the freshest
  ghc  they have to install a ghc bindist, then do a boostrap build of
  cabal-install by hand (if they want to actually get anything done :) ).
 
  This is not a human friendly situation for folks who are new to haskell
  tooling, but want to try out haskell dev on a server style vm or the
 like!
 
  point being: It'd be great for haskell usability (and egads amounts of
  config time, even by seasoned users) the ghc bindists / installers
  included a cabal-install binary
 
  thoughts?
  -Carter
 
 
 
 
 
  ___
  Libraries mailing list
  librar...@haskell.org
  http://www.haskell.org/mailman/listinfo/libraries
 

 ___
 Libraries mailing list
 librar...@haskell.org
 http://www.haskell.org/mailman/listinfo/libraries

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Enabling TypeHoles by default

[Johan Tibell]

I can make another cabal release if needed, if someone submits a pull
request with the right fix (i.e. add TypedHoles with TypeHoles as a
synonym.)


On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp aus...@well-typed.com wrote:

 At the very least, Type(d)Holes would never appear explicitly since it
 would be enabled by default. But it might be turned off (but I don't
 know who would do that for the most part.) Cabal at least might still
 need an update.

 In any case, Herbert basically summed it up: the time window is kind
 of close, and we would need to re-release/redeploy a few things most
 likely. I really think it mostly depends on the Cabal team and what
 their priorities are. I've CC'd Duncan and Johan for their opinions.

 On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel h...@gnu.org
 wrote:
  Hi,
 
  On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
  On 14.01.2014 17:07, Austin Seipp wrote:
  We probably won't change the name right now however. It's already
  been put into Cabal (as a recognized extension,) so the name has
  propagated a slight bit. We can however give it a new name and
  deprecate the old -XTypeHoles in the future. Or, we could change
  it, but I'm afraid it's probably a bit too late in the cycle for
  other devs to change.
 
  Removing a name later on is more time-consuming, with or without
  deprecation. People get used to the wrong name and stop caring, but
  I can already picture the type holes are really typed holes
  discussions on IRC. I'm strongly in favour of introducing the new name
  (and the deprecation for the synonym) as early as possible. This
  change should not be very extensive anyway, so why not slip it in?
 
  Well, as Austin hinted at, this would also require a Cabal-1.18.x
  release in time for the final 7.8, and a recompile of Hackage to pick it
  up so that people can start using the new 'TypedHoles' token in their
  .cabal files... so there's a bit of coordination required to make this
  happen in a timely manner... Or put differently, somebody has to care
  enough to invest some time and pull this through :-)
 
  Cheers,
hvr
 



 --
 Regards,

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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Enabling TypeHoles by default

[Johan Tibell]

Stupid question: is it really only better error messages? What about being
allowed to use _ on the RHS?


On Tue, Jan 14, 2014 at 6:23 PM, Joachim Breitner
m...@joachim-breitner.dewrote:

 Hi,

 heh, I wanted to throw in the same argument: If its just more elaborate
 error messages, why do we need a flag for it? So count that as +1 from
 me.

 Greetings,
 Joachim


 Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
  I'm actually more in favor of Richard's proposal of just removing the
  flag to be honest, now that he mentioned it. And it's not like it's
  much more code.
 
  In any case, as Duncan informed me we'll have a Cabal release anyway,
  so I'll work on sorting this out and enabling it.
 
  On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts dun...@well-typed.com
 wrote:
   On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
   I can make another cabal release if needed, if someone submits a pull
   request with the right fix (i.e. add TypedHoles with TypeHoles as a
   synonym.)
  
   Thanks Johan, or I'm happy to do it.
  
   Duncan
  
   On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp aus...@well-typed.com
 wrote:
  
At the very least, Type(d)Holes would never appear explicitly since
 it
would be enabled by default. But it might be turned off (but I don't
know who would do that for the most part.) Cabal at least might
 still
need an update.
   
In any case, Herbert basically summed it up: the time window is kind
of close, and we would need to re-release/redeploy a few things most
likely. I really think it mostly depends on the Cabal team and what
their priorities are. I've CC'd Duncan and Johan for their opinions.
   
On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel 
 h...@gnu.org
wrote:
 Hi,

 On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
 On 14.01.2014 17:07, Austin Seipp wrote:
 We probably won't change the name right now however. It's
 already
 been put into Cabal (as a recognized extension,) so the name has
 propagated a slight bit. We can however give it a new name and
 deprecate the old -XTypeHoles in the future. Or, we could change
 it, but I'm afraid it's probably a bit too late in the cycle for
 other devs to change.

 Removing a name later on is more time-consuming, with or without
 deprecation. People get used to the wrong name and stop
 caring, but
 I can already picture the type holes are really typed holes
 discussions on IRC. I'm strongly in favour of introducing the
 new name
 (and the deprecation for the synonym) as early as possible. This
 change should not be very extensive anyway, so why not slip it
 in?

 Well, as Austin hinted at, this would also require a Cabal-1.18.x
 release in time for the final 7.8, and a recompile of Hackage to
 pick it
 up so that people can start using the new 'TypedHoles' token in
 their
 .cabal files... so there's a bit of coordination required to make
 this
 happen in a timely manner... Or put differently, somebody has to
 care
 enough to invest some time and pull this through :-)

 Cheers,
   hvr

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

 --
 Joachim “nomeata” Breitner
   m...@joachim-breitner.de • http://www.joachim-breitner.de/
   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0x4743206C
   Debian Developer: nome...@debian.org

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Giving function a larger arity

[Johan Tibell]

And plan 2 doesn't require a magic data type. :)


On Tue, Nov 12, 2013 at 9:36 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:

  There is a difference between plan A and B.  For example, if

 f :: (OneShot a - b) - [a] - [b]

 then EVERY function passed to f would have to be one-shot (Plan A).  But
 under plan B you could have two calls



 …f (\x. blah)….. f (\y{-#ONESHOT#-}. blah2)….



 and only the second would be a one-shot lambda.



 So if anything plan B seems more flexible.



 Simon





 *From:* John Lato [mailto:jwl...@gmail.com]
 *Sent:* 12 November 2013 00:12

 *To:* Simon Peyton-Jones
 *Cc:* glasgow-haskell-users@haskell.org; Akio Takano
 *Subject:* Re: Giving function a larger arity



 Yes, that's what I meant.  I was thinking that from an implementation
 perspective, it would be nice if all the one-shot hacks were in a single
 place, and if plan A facilitated that it would be a good reason to support
 that approach.  But I suppose checking an annotation is no harder than
 checking a type, so it's probably irrelevant.



 On Mon, Nov 11, 2013 at 3:29 PM, Simon Peyton-Jones simo...@microsoft.com
 wrote:

  Well, Plan A is indeed an extended version of the ”state hack”. Instead
 of just (State# RealWorld#) being magically considered one-shot, we’d also
 add (OneShot t).



 Simon



 *From:* John Lato [mailto:jwl...@gmail.com]

 *Sent:* 11 November 2013 17:29

 *To:* Simon Peyton-Jones
 *Cc:* glasgow-haskell-users@haskell.org; Akio Takano
 *Subject:* RE: Giving function a larger arity



 Originally I thought Plan B would make more sense, but if Plan A were
 implemented could this one-shot type annotation be unified with the state
 hack? I'm envisioning something like RULES, where if the type matches ghc
 knows it's a one-shot lambda.

 I think it would be better to not do any analysis and leave this
 completely up to the user. My intention is to get a mechanism to tell ghc
 it's okay to recompute something in a lambda, essentially a manual state
 hack. I seem to recall wanting this, but I don't remember the exact use
 case. It's possible it was one-shot anyway.

 John L.

 On Nov 11, 2013 5:12 AM, Simon Peyton-Jones simo...@microsoft.com
 wrote:

  Strangely enough I’ve been thinking about eta expansion in the last day
 or two.  It’s one of GHC’s more delicate corners, because

 1.   There can be big performance boosts

 2.   If you push a redex inside a lambda

 But as you point out (2) may be arbitrarily bad unless you know the lambda
 is called at most once (is “one-shot”).



 There is really no good way to declare a lambda to be one-shot right now.
 As you discovered, full laziness tends to defeat your attempts to do so!
 (A workaround is to switch off full laziness, but that doesn’t feel right.)



 What is a more general solution?  I can think of two.



 A.  Declare one-shot-ness in the type.  Something like this:

 newtype OneShot a = OS a

 newtype Builder = Builder (OneShot (Ptr ()) - IO (Ptr ()))

 plus telling GHC that anything with a OneShot type is a
 one-shot lambda.



 B.  Declaring one-shot-ness in the terms.  Something like

 ..Builder (\x {-# ONESHOT #-} - blah)…

 That would declare this particular lambda to be one-shot,
 but not any other.



 Notes

 · Plan A would require a bit of fiddling to move your values in
 and out of the OneShot type.  And it’d make the terms a bit bigger at
 compile time.

 · Plan B is more explicit all the use sites.

 · Both plans would be vulnerable to user error.  I could imagine
 and analysis that would guarantee that you met the one-shot claim; but it
 would necessarily be quite conservative.  That might or might not be OK

 · GHC already embodies a version of (A): the “state hack” means
 that  a lambda whose binder is a state token (State# RealWorld#) is treated
 as one-shot.  We have many bug reports describing when this hack makes
 things bad, but it is such a huge win for more programs that it is on by
 default.(Your “rebuild” idea might work better with (State# Realorld#
 - Builder) rather than (() - Builder) for that reason.)



 Simon



 *From:* Glasgow-haskell-users [mailto:
 glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Akio Takano
 *Sent:* 11 November 2013 09:19
 *To:* glasgow-haskell-users@haskell.org
 *Subject:* Giving function a larger arity



 Hi,

 I've been trying to get a certain type of programs compiled into efficient
 code, but I haven't been able to find a good way to do it, so I'm asking
 for help.

 Specifically, it involves a library that defines a newtype whose
 representation is a function. Attached Lib.hs is an example of such a
 library. It defines a newtype (Builder), and functions (fromInt, mappend)
 that deal with it.

 In user code I want to write a (often-recursive) function that produces a
 value of the newtype (the 'upto' function in arity.hs is an example). The
 

Re: love for hpc?

[Johan Tibell]

Aside: cabal supports hpc and puts the various files (e.g. .tix) in
separate directories to avoid problems like these.


On Thu, Nov 7, 2013 at 8:55 AM, Roman Cheplyaka r...@ro-che.info wrote:

 So Evan's prediction was accurate ;-)

 * Carter Schonwald carter.schonw...@gmail.com [2013-11-07 00:29:24-0500]
  Evan,
 
  if  you want to get involved in working on HPC, go for it! theres many
 many
  pieces of ghc that need more proactive ownership.
 
  i should probably use HPC a bit as i start getting my numerical libs out,
  and i'm sure future me will appreciate current you working on making it
  better
 
  -Carter
 
 
  On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge qdun...@gmail.com wrote:
 
   Is anyone out there using HPC?  It seems like it was gotten into a
   more or less working if not ideal state, and then abandoned.
  
   Things I've noticed lately:
  
   The GHC runtime just quits on the spot if there's already a tix file.
   This bit me when I was parallelizing tests.  It's also completely
   unsafe when run concurrently, mostly it just overwrites the file,
   sometimes it quits.  Sure to cause headaches for someone trying to
   parallelize tests.
  
   You can't change the name of the output tix file, so I worked around
   by hardlinking the binary to a bunch of new ones, and then doing 'hpc
   sum' on the results.
  
   The hpc command is super slow.  It might have to do with it doing its
   parsing with Prelude's 'read', and it certainly doesn't help the error
   msgs.
  
   And the whole thing is generally minimally documented.
  
   I can already predict the answer will be yes, HPC could use some
   love, roll up your sleeves and welcome!  It does look like it could
   be improved a lot with just a bit of effort, but that would be a yak
   too far for me, at the moment.  I'm presently just curious if anyone
   else out there is using it, and if they feel like it could do with a
   bit of polishing.
   ___
   Glasgow-haskell-users mailing list
   Glasgow-haskell-users@haskell.org
   http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
  

  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Compiling arbitrary Haskell code

[Johan Tibell]

Whatever guarantees GHC offers (e.g. using Safe Haskell), I would always
run things like these in a sandbox. It's much better for security to
dissallow everything and then whitelist some things (e.g. let the sandbox
communicate with the rest of the world in some limited way) than the other
way around.

Same goes for running untrusted code.


On Fri, Oct 11, 2013 at 1:30 PM, Christopher Done chrisd...@gmail.comwrote:

 Is there a definitive list of things in GHC that are unsafe to
 _compile_ if I were to take an arbitrary module and compile it?

 E.g. off the top of my head, things that might be dangerous:

 * TemplateHaskell/QuasiQuotes -- obviously
 * Are rules safe?
 * #includes — I presume there's some security risk with including any old
 file?
 * FFI -- speaks for itself

 I'm interested in the idea of compiling Haskell code on lpaste.org,
 for core, rule firings, maybe even Th expansion, etc. When sandboxing
 code that I'm running, it's really easy if I whitelist what code is
 available (parsing with HSE, whitelisting imports, extensions). The
 problem of infinite loops or too much allocation is fairly
 straight-forwardly solved by similar techniques applied in mueval.

 SafeHaskell helps a lot here, but suppose that I want to also allow
 TemplateHaskell, GeneralizedNewtypeDeriving and stuff like that,
 because a lot of real code uses those. They only seem to be restricted
 to prevent cheeky messing with APIs in ways the authors of the APIs
 didn't want -- but that shouldn't necessarily be a security—in terms
 of my system—problem, should it? Ideally I'd very strictly whitelist
 which modules are allowed to be used (e.g. a version of TH that
 doesn't have runIO), and extensions, and then compile any code that
 uses them.

 I'd rather not have to setup a VM just to compile Haskell code safely.
 I'm willing to put some time in to investigate it, but if there's
 already previous work done for this, I'd appreciate any links.

 At the end of the day, there's always just supporting a subset of
 Haskell using SafeHaskell. I'm just curious about the more general
 case, for use-cases similar to my own.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Telling Cassava to ignore lines

[Johan Tibell]

Hi,

It depends on what you mean by doesn't parse. From your message is assume
the CSV is valid, but some of the actual values fails to convert (using
FromField). There are a couple of things you could try:

 1. Define a newtype for your field that calls runParser using e.g. the Int
parser and if it fails, return some other value. I should probably add an
Either instance that covers this case, but there's none there now.

newtype MaybeInt = JustI !Int | ParseFailed

instance FromField MaybeInt where
parseField s = case runParser (parseField s) of
Left err - pure ParseFailed
Right (n :: Int) - JustI $ n

(This is from memory, so I might have gotten some of the details wrong.)

 2. Use the Streaming module, which lets you skip whole records that fails
to parse (see the docs for the Cons constructor).

-- Johan



On Tue, Sep 17, 2013 at 6:43 PM, Andrew Cowie 
and...@operationaldynamics.com wrote:

 I'm happily using Cassava to parse CSV, only to discover that
 non-conforming lines in the input data are causing the parser to error
 out.

 let e = decodeByName y' :: Either String (Header, Vector Person)

 chugs along fine until line 461 of the input when

 parse error (endOfInput) at ...

 Ironically when my Person (ha) data type was all fields of :: Text it
 just worked, but now that I've specified one or two of the fields as Int
 or Float or whatever, it's mis-parsing.

 Is there a way to tell it to just ignore lines that don't parse, rather
 than it killing the whole run? Cassava understands skipping the *header*
 line (and indeed using it to do the -by-name field mapping).

 Otherwise the only thing I can see is going back to all the fields
 being :: Text, and then running over that as an intermediate structure
 and validating whether or not things parse to i.e. float.

 AfC
 Sydney


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: 7.8 Release Update

[Johan Tibell]

Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship
with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0.

On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 Yes I will try to review it this week. (This is the first time I've had 
 access to the code.)

 Simon

 | -Original Message-
 | From: Austin Seipp [mailto:ase...@pobox.com]
 | Sent: 09 September 2013 16:25
 | To: Trevor Elliott
 | Cc: Austin Seipp; ghc-d...@haskell.org; glasgow-haskell-
 | us...@haskell.org; Simon Peyton-Jones
 | Subject: Re: 7.8 Release Update
 |
 | Excellent. Simon, are you privvy to this work at all? We lightly
 | talked about it last week, but I'm not sure if you've reviewed it. Or
 | perhaps Pedro or someone else could if we have time (I seem to
 | remember he drew up the initial design points.)
 |
 | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott tre...@galois.com
 | wrote:
 |  Hi Austin,
 | 
 |  Iavor and I have got the data kinds syntax changes up to date with
 | master,
 |  on the data-kind-syntax branch.  The -XDataKinds section of the manual
 | has
 |  been updated to describe the new syntax.  During a validate run, there
 | were
 |  some problems building haddock, so I'm going to look into that
 | tonight.
 | 
 |  There are tests for the data kind syntax in the test suite, currently
 | on the
 |  data-kind-syntax branch.
 | 
 |  Other than the haddock fix, I think that we're ready to go.
 | 
 |  Thanks!
 | 
 |  --trevor
 | 
 | 
 |  On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote:
 | 
 |  Friends,
 | 
 |  After talking with SPJ, we've decided that the cutoff date for the
 | 7.8
 |  feature window will essentially start on Monday, the 16th. This is
 | the
 |  beginning of the week before ICFP. This is a week from tomorrow.
 | 
 |  Afterwords, I suspect we will cut the 7.8 branch in early October (my
 |  notes tentatively say Oct. 9th.) This will give us a few weeks of
 |  straight bugfixing.
 | 
 |  Don't let this scare you too much. We're doing this at the beginning
 |  of the week so we have time to sort things out. Bug fixes will of
 |  course continuously be welcome until the 7.8 branch.
 | 
 |  However, for pending features, I'd like a status update. Everyone
 |  mentioned below, please reply to clarify anything:
 | 
 |* Iavor Diatchki and SPJ are working together on the type-nats-
 | simple
 |  branch. I believe this will hopefully land in time. Iavor, SPJ - can
 |  you comment here?
 | 
 |* Trevor and Iavor are also working on kinds without data. Any word
 |  here?
 | 
 |* Geoffrey is currently moving, but he says the SIMD work and new
 |  template-haskell work will land by the end of this week, which is
 |  great.
 | 
 |* Patrick Palka has a few loose ends to tie off for the parallel
 |  compilation driver. I talked to him today, and after Andreas
 | committed
 |  his bugfix to base, I believe everything is now working, with the
 |  deadlocks sorted out. Patrick, can you confirm? We can get this
 | merged
 |  ASAP if so.
 | 
 |* Pedro and Richard - what's the story on propositional equality,
 |  etc? This is mentioned on the status page[1] but I'm not sure what
 |  else needs to be done. I know Pedro committed the work to make manual
 |  Typeable instances an error, which is great.
 | 
 |* Luite and Edsko will be talking about some final changes to the
 |  hooks patch, and afterwords it can hopefully be integrated. I'll keep
 |  up with them this week.
 | 
 |* I am currently working on integrating the Applicative-Monad
 |  warning, but this requires some upstream patches for the build to
 |  work. However, we still need to sync several upstream libraries, and
 |  this will be happening over the next few weeks. Therefore, I may
 |  commit it, and incrementally fix validation errors as time goes on
 | and
 |  me and Herbert sync upstreams.
 | 
 |  IMO, most of these look to be in good shape, I think.
 | 
 |  If you *do not think you'll make it by the 16th*, please let me know.
 |  We can possibly still land it the week of the 16th, provided I know
 |  ASAP. But we really really need to know, because many people will be
 |  gone the following week.
 | 
 |  In the following few days, I'm hoping going to finish off everything
 | I
 |  can in the patch queue, and fix my remaining bugs, and investigate
 |  Dynamic GHCi in particular.
 | 
 |  Again, if you don't think you can make it on the 16th, but still
 |  within the week, we can of discuss it.
 | 
 | 
 |
 |
 |
 | --
 | Regards,
 | Austin - PGP: 4096R/0x91384671
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8 Release Update

[Johan Tibell]

On Mon, Sep 9, 2013 at 1:14 PM, Edward Z. Yang ezy...@mit.edu wrote:
 I think Kazu is saying that when he builds something with profiling
 using cabal-install, it fails because cabal-install tries to build a
 dynamic version too.  We don't want dyanmic/profiled libraries (there's
 no point, you can't load them into GHCi).  Perhaps this is something
 that needs fixing in cabal-install?

 Agreed, sounds like a Cabal install bug.

I don't know what the right fix is. Can someone who understands the
issue submit a pull request to cabal-install?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8 Release Update

[Johan Tibell]

That sounds terrible expensive to do on every `cabal build` and its a
cost most users won't understand (what was broken before?).

On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang ezy...@mit.edu wrote:
 If I am building some Haskell executable using 'cabal build', the
 result should be *statically linked* by default.

 However, subtly, if I am building a Haskell library, I would like to
 be able to load the compiled version into GHCi.

 So it seems to me cabal should produce v, dyn (libs only, not final
 executable) and p ways by default (but not dyn_p).

 Edward

 Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 
 2013:
 Hi,

  Kazu (or someone else), can you please file a ticket on the Cabal bug
  tracker [1] if you think that this a Cabal bug?

 I'm not completely sure yet.

 GHCi 7.8 uses dynamic linking. This is true.

 So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they
 supposed to use dynamic linking? Or, static linking?

 If dynamic linking is used, GHC should provide dynamic libraries for
 profiling.

 If static linking is used, cabal-install should stop using dynamic
 libraries for profiling.

 And of course, I can make a ticket when I'm convinced.

 P.S.

 Since doctest uses GHCi internally, I might misunderstand GHC 7.8
 uses dynamic linking. Anyway, I don't understand what is right yet.

 --Kazu


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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Cabal --enable-tests

[Johan Tibell]

I don't think so. Perhaps we should set one. What's your use case? Perhaps
you could describe it in a new bug report at
https://github.com/haskell/cabal/issues


On Mon, Sep 9, 2013 at 7:29 PM, satvik chauhan mystic.sat...@gmail.comwrote:

 Hi cafe,


 I wanted to ask this as I couldn't find this in cabal documentation.

 Is there any CCP macro set when a package is configured with
 --enable-testing? If not is there a way to do that?

 -Satvik

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released

[Johan Tibell]

I pasted your report into the bug tracker:
https://github.com/haskell/cabal/issues/1478

I don't know if you're on GitHub or not so I could link the report to your user.

On Thu, Sep 5, 2013 at 8:16 AM, Rogan Creswick cresw...@gmail.com wrote:
 I ran into another oddity due to old build artifacts today -- it was easy to
 fix, but very confusing; cabal repl was exiting with unrecognised command:
 repl.

 tl/dr; if you see this, delete the old 'dist' dir and re-run 'cabal
 configure'.

 Here's a snippit of my shell session to explain in more detail:

 $ cabal sandbox init
 ...
  $ cabal --version
 cabal-install version 1.18.0
 using version 1.18.0 of the Cabal library
  $ cabal configure
 Resolving dependencies...
 Configuring pgftransform-0.0.0.1...
  $ cabal repl
 unrecognised command: repl (try --help)
  $ cabal --help
 ...
 Commands:
 ...
   buildCompile all targets or specific targets.
   repl Open an interpreter session for the given target.
   sandbox  Create/modify/delete a sandbox.
  ...

 Note that cabal --version and cabal --help indicated that repl /was/ a valid
 command.

 The issue appears to be that an old dist directory was still hanging around,
 and (I suspect) the compiled setup.hs build program (which would have been
 built with an old Cabal) was causing the actual error.  Deleting the dist
 dir and re-running cabal configure set everything right.

 --Rogan


 On Thu, Sep 5, 2013 at 6:18 AM, Yuri de Wit yde...@gmail.com wrote:

 It is easy enough to recreate the link manually or as easy to run cabal
 install again, but that is not the point here. The point is that it will
 bite the next dozen of unsuspecting users since, at first, they have no idea
 of what is going on.

 In any case, apologies for sending this in this thread as it doesn't seem
 the right forum to discuss it.


 On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso p.giarru...@gmail.com
 wrote:

 On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote:

 Thanks for all the hard work!

 If you see this in OSX (#1009) while installing cabal 1.18:

 Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin
 for
 cabal because the file exists there already but is not managed by cabal.
 You
 can create a symlink for this executable manually if you wish. The
 executable
 file has been installed at
 /Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal

 You will need to manually remove the pre-existing 1.16 links in
 ~/Library/Haskell/bin before installing again.


 Instead of installing again, you can even just recreate the symlink as
 mentioned by the message (if you know how to do that).



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released

[Johan Tibell]

Hideyuki Tanaka was missing from the list of contributors (his patch was
applied through me). His contribution made 'cabal update' faster!


On Wed, Sep 4, 2013 at 2:11 PM, Johan Tibell johan.tib...@gmail.com wrote:

 Hi all,

 On behalf of the cabal maintainers and contributors I'm proud to
 announce the Cabal (and cabal-install) 1.18.0 release. To install run

 cabal update  cabal install Cabal-1.18.0 cabal-install-1.18.0

 With 854 commits since the last release there are two many
 improvements and bug fixes to list them here, but two highlights are:

  * Hermetic builds using sandboxes. This should reduce the number of
 dependency hell and broken package DB problems.

  * GHCi support. It's now much easier to use ghci when developing your
 packages, especially if those packages require preprocessors (e.g.
 hsc2hs).

 Here's how working on a package might look like using the new features:

 # Only once:
 cabal sandbox init
 cabal install --only-dependencies --enable-tests
 # Configure, build, and run tests:
 cabal test  # now implies configure and build
 # Play around with the code in GHCi:
 cabal repl

 Mikhail wrote a bit more about the user visible changes on his blog:

 http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

 For a complete list of changes run

 git log cabal-install-v1.16.0.2..cabal-install-v1.18.0

 in the cabal repo or look at the GitHub compare page:


 https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0

 (only shows the last 250 commits).

 57 people contributed to this release!

503  Mikhail Glushenkov
 99  Johan Tibell
 41  Duncan Coutts
 39  Ian Lynagh
 19  Brent Yorgey
 19  Thomas Tuegel
 18  Ben Millwood
 16  Eyal Lotem
 10  Thomas Dziedzic
  7  Andres Loeh
  6  John Wiegley
  6  Benno Fünfstück
  5  Gregory Collins
  4  Herbert Valerio Riedel
  4  Simon Hengel
  3  Joachim Breitner
  3  Luke Iannini
  3  Bryan Richter
  3  Richard Eisenberg
  3  Tuncer Ayaz
  3  Jens Petersen
  2  Arun Tejasvi Chaganty
  2  Bryan O'Sullivan
  2  Eric Kow
  2  Jookia
  2  Paolo G. Giarrusso
  2  Paolo Capriotti
  1  Sönke Hahn
  1  Yitzchak Gale
  1  Albert Krewinkel
  1  stepcut
  1  Alexander Kjeldaas
  1  Austin Seipp
  1  Bardur Arantsson
  1  Ben Doyle
  1  Ben Gamari
  1  Bram
  1  Carter Tazio Schonwald
  1  Clint Adams
  1  Daniel Wagner
  1  David Lazar
  1  Erik Hesselink
  1  Eugene Sukhodolin
  1  Gabor Greif
  1  Jack Henahan
  1  Jason Dagit
  1  Ken Bateman
  1  Mark Lentczner
  1  Masahiro Yamauchi
  1  Merijn Verstraaten
  1  Michael Thompson
  1  Niklas Hambüchen
  1  Oleksandr Manzyuk
  1  Patrick Premont
  1  Roman Cheplyaka
  1  Sergei Trofimovich
  1  Stephen Blackheath

 -- Johan, on behalf of the cabal maintainers and contributors.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell] ANN: Cabal v1.18.0 released

[Johan Tibell]

Hi all,

On behalf of the cabal maintainers and contributors I'm proud to
announce the Cabal (and cabal-install) 1.18.0 release. To install run

cabal update  cabal install Cabal-1.18.0 cabal-install-1.18.0

With 854 commits since the last release there are two many
improvements and bug fixes to list them here, but two highlights are:

 * Hermetic builds using sandboxes. This should reduce the number of
dependency hell and broken package DB problems.

 * GHCi support. It's now much easier to use ghci when developing your
packages, especially if those packages require preprocessors (e.g.
hsc2hs).

Here's how working on a package might look like using the new features:

# Only once:
cabal sandbox init
cabal install --only-dependencies --enable-tests
# Configure, build, and run tests:
cabal test  # now implies configure and build
# Play around with the code in GHCi:
cabal repl

Mikhail wrote a bit more about the user visible changes on his blog:

http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

For a complete list of changes run

git log cabal-install-v1.16.0.2..cabal-install-v1.18.0

in the cabal repo or look at the GitHub compare page:


https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0

(only shows the last 250 commits).

57 people contributed to this release!

   503  Mikhail Glushenkov
99  Johan Tibell
41  Duncan Coutts
39  Ian Lynagh
19  Brent Yorgey
19  Thomas Tuegel
18  Ben Millwood
16  Eyal Lotem
10  Thomas Dziedzic
 7  Andres Loeh
 6  John Wiegley
 6  Benno Fünfstück
 5  Gregory Collins
 4  Herbert Valerio Riedel
 4  Simon Hengel
 3  Joachim Breitner
 3  Luke Iannini
 3  Bryan Richter
 3  Richard Eisenberg
 3  Tuncer Ayaz
 3  Jens Petersen
 2  Arun Tejasvi Chaganty
 2  Bryan O'Sullivan
 2  Eric Kow
 2  Jookia
 2  Paolo G. Giarrusso
 2  Paolo Capriotti
 1  Sönke Hahn
 1  Yitzchak Gale
 1  Albert Krewinkel
 1  stepcut
 1  Alexander Kjeldaas
 1  Austin Seipp
 1  Bardur Arantsson
 1  Ben Doyle
 1  Ben Gamari
 1  Bram
 1  Carter Tazio Schonwald
 1  Clint Adams
 1  Daniel Wagner
 1  David Lazar
 1  Erik Hesselink
 1  Eugene Sukhodolin
 1  Gabor Greif
 1  Jack Henahan
 1  Jason Dagit
 1  Ken Bateman
 1  Mark Lentczner
 1  Masahiro Yamauchi
 1  Merijn Verstraaten
 1  Michael Thompson
 1  Niklas Hambüchen
 1  Oleksandr Manzyuk
 1  Patrick Premont
 1  Roman Cheplyaka
 1  Sergei Trofimovich
 1  Stephen Blackheath

-- Johan, on behalf of the cabal maintainers and contributors.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell-cafe] ANN: Cabal v1.18.0 released

[Johan Tibell]

Hi all,

On behalf of the cabal maintainers and contributors I'm proud to
announce the Cabal (and cabal-install) 1.18.0 release. To install run

cabal update  cabal install Cabal-1.18.0 cabal-install-1.18.0

With 854 commits since the last release there are two many
improvements and bug fixes to list them here, but two highlights are:

 * Hermetic builds using sandboxes. This should reduce the number of
dependency hell and broken package DB problems.

 * GHCi support. It's now much easier to use ghci when developing your
packages, especially if those packages require preprocessors (e.g.
hsc2hs).

Here's how working on a package might look like using the new features:

# Only once:
cabal sandbox init
cabal install --only-dependencies --enable-tests
# Configure, build, and run tests:
cabal test  # now implies configure and build
# Play around with the code in GHCi:
cabal repl

Mikhail wrote a bit more about the user visible changes on his blog:

http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html

For a complete list of changes run

git log cabal-install-v1.16.0.2..cabal-install-v1.18.0

in the cabal repo or look at the GitHub compare page:


https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0

(only shows the last 250 commits).

57 people contributed to this release!

   503  Mikhail Glushenkov
99  Johan Tibell
41  Duncan Coutts
39  Ian Lynagh
19  Brent Yorgey
19  Thomas Tuegel
18  Ben Millwood
16  Eyal Lotem
10  Thomas Dziedzic
 7  Andres Loeh
 6  John Wiegley
 6  Benno Fünfstück
 5  Gregory Collins
 4  Herbert Valerio Riedel
 4  Simon Hengel
 3  Joachim Breitner
 3  Luke Iannini
 3  Bryan Richter
 3  Richard Eisenberg
 3  Tuncer Ayaz
 3  Jens Petersen
 2  Arun Tejasvi Chaganty
 2  Bryan O'Sullivan
 2  Eric Kow
 2  Jookia
 2  Paolo G. Giarrusso
 2  Paolo Capriotti
 1  Sönke Hahn
 1  Yitzchak Gale
 1  Albert Krewinkel
 1  stepcut
 1  Alexander Kjeldaas
 1  Austin Seipp
 1  Bardur Arantsson
 1  Ben Doyle
 1  Ben Gamari
 1  Bram
 1  Carter Tazio Schonwald
 1  Clint Adams
 1  Daniel Wagner
 1  David Lazar
 1  Erik Hesselink
 1  Eugene Sukhodolin
 1  Gabor Greif
 1  Jack Henahan
 1  Jason Dagit
 1  Ken Bateman
 1  Mark Lentczner
 1  Masahiro Yamauchi
 1  Merijn Verstraaten
 1  Michael Thompson
 1  Niklas Hambüchen
 1  Oleksandr Manzyuk
 1  Patrick Premont
 1  Roman Cheplyaka
 1  Sergei Trofimovich
 1  Stephen Blackheath

-- Johan, on behalf of the cabal maintainers and contributors.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Building recent Cabal/cabal-install

[Johan Tibell]

Hi,

Cabal 1.18 is still in the release candidate stage so it has in fact not
been released yet. We could either bump the dependency on base to 4.8
before the 1.8 release or we could make a Cabal-1.8.0.1 release together
with the GHC release that bumps the dependency.

-- Johan


On Wed, Aug 28, 2013 at 9:08 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:

 Greetings café,

 There are some problems in Haddock to do with Template Haskell that I
 believe are being caused by Cabal. These were apparently addressed in
 1.18 which came out recently. ‘Great!’, I thought.

 My problem is that I'm unsure how to use 1.18. I'm using GHC HEAD (well,
 3 days old now) which is meant to come with Cabal 1.18 (the library) and
 in fact it seems to ship with it. Running ‘cabal --version’ however:

  cabal-install version 1.17.0
  using version 1.17.0 of the Cabal library

 I'm unsure how to get it to use 1.18. I tried to build cabal-install
 from git but that just complains about dependencies not being possible
 to resolve: it depends on HTTP which depends on base 4.7 but 4.7 comes
 with GHC HEAD!

 I am baffled as to how I should go about using 1.18 and would love to
 hear from some people who have this up and running.
 --
 Mateusz K.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Debugging ByteString and Data.Binary.Get memory usage

[Johan Tibell]

A good starting point is to estimate how much space you think the data
should take using e.g.


http://blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html

If you do that, is the actual space usage close to what you expected?


On Thu, Aug 29, 2013 at 5:35 PM, Kyle Hanson hanoo...@gmail.com wrote:

 OK

 I have a bunch of BSON documents that I convert to ByteStrings, put in a
 Map, and write to a socket based on the response. I noticed some high
 memory usage (in the GBs) so I decided to investigate. I simplified my
 problem into a small program that demonstrates clearer what is happening.

 I wrote two versions, one with a Lazy Map and Lazy ByteStrings and one
 with a Strict Map and Strict ByteStrings. Both share the same memory
 behavior (except the lazy BS one is faster)

 Here is the strict version:

 http://lpaste.net/92298

 And here is the lazy version:

 http://lpaste.net/92299

 I wrote this and compared the memory and speed behavior of ByteStrings
 generated by converting it from a BSON document and ByteStrings generated
 more purely.

 The length of the ByteString from a BSON document is 68k and the length of
 the pure BS is 70k.

 This is my weird memory behavior, both BSON and pure methods use the
 same amount of memory after inserting 10k of them (90mb)

 However when I go to lookup a value, the BSON Map explodes the memory to
 over 250mb. Even if I lookup just 1 value. Looking up any number of values
 in the pure BS keeps the memory usage stable (90mb).

 I am hoping someone can help me understand this. I have read some posts
 about Temporary ByteStrings causing memory issues but I don't know how to
 get started debugging.

 --
 Kyle Hanson

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ideas on a fast and tidy CSV library

[Johan Tibell]

As I mentioned, you want to use the Streaming (or Incremental) module.
As the program now stands the call to `decode` causes 1.5 GB of CSV
data to be read as a `Vector (Vector Int)` before any encoding starts.

-- Johan


On Wed, Aug 21, 2013 at 1:09 PM, Justin Paston-Cooper
paston.coo...@gmail.com wrote:
 Dear All,

 I now have some example code. I have put it on: http://pastebin.com/D9MPmyVd
 .

 vectorBinner is simply of type Vector Int - Int. I am inputting a 1.5GB CSV
 on stdin, and would like vectorBinner to run over every single record,
 outputting results as computed, thus running in constant memory. My
 programme instead quickly approaches full memory use. Is there any way to
 work around this?

 Justin


 On 25 July 2013 17:53, Johan Tibell johan.tib...@gmail.com wrote:

 You can use the Incremental or Streaming modules to get more fine
 grained control over when new parsed records are produced.

 On Thu, Jul 25, 2013 at 11:02 AM, Justin Paston-Cooper
 paston.coo...@gmail.com wrote:
  I hadn't yet tried profiling the programme. I actually deleted it a few
  days
  ago. I'm going to try to get something new running, and I will report
  back.
  On a slightly less related track: Is there any way to use cassava so
  that I
  can have pure state and also yield CSV lines while my computation is
  running
  instead of everything at the end as would be with the State monad?
 
 
  On 23 July 2013 22:13, Johan Tibell johan.tib...@gmail.com wrote:
 
  On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari bgamari.f...@gmail.com
  wrote:
   Justin Paston-Cooper paston.coo...@gmail.com writes:
  
   Dear All,
  
   Recently I have been doing a lot of CSV processing. I initially
   tried
   to
   use the Data.Csv (cassava) library provided on Hackage, but I found
   this to
   still be too slow for my needs. In the meantime I have reverted to
   hacking
   something together in C, but I have been left wondering whether a
   tidy
   solution might be possible to implement in Haskell.
  
   Have you tried profiling your cassava implementation? In my
   experience
   I've found it's quite quick. If you have an example of a slow path
   I'm
   sure Johan (cc'd) would like to know about it.
 
  I'm always interested in examples of code that is not running fast
  enough. Send me a reproducible example (preferably as a bug on the
  GitHub bug tracker) and I'll take a look.
 
 



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ideas on a fast and tidy CSV library

[Johan Tibell]

You can use the Incremental or Streaming modules to get more fine
grained control over when new parsed records are produced.

On Thu, Jul 25, 2013 at 11:02 AM, Justin Paston-Cooper
paston.coo...@gmail.com wrote:
 I hadn't yet tried profiling the programme. I actually deleted it a few days
 ago. I'm going to try to get something new running, and I will report back.
 On a slightly less related track: Is there any way to use cassava so that I
 can have pure state and also yield CSV lines while my computation is running
 instead of everything at the end as would be with the State monad?


 On 23 July 2013 22:13, Johan Tibell johan.tib...@gmail.com wrote:

 On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari bgamari.f...@gmail.com
 wrote:
  Justin Paston-Cooper paston.coo...@gmail.com writes:
 
  Dear All,
 
  Recently I have been doing a lot of CSV processing. I initially tried
  to
  use the Data.Csv (cassava) library provided on Hackage, but I found
  this to
  still be too slow for my needs. In the meantime I have reverted to
  hacking
  something together in C, but I have been left wondering whether a tidy
  solution might be possible to implement in Haskell.
 
  Have you tried profiling your cassava implementation? In my experience
  I've found it's quite quick. If you have an example of a slow path I'm
  sure Johan (cc'd) would like to know about it.

 I'm always interested in examples of code that is not running fast
 enough. Send me a reproducible example (preferably as a bug on the
 GitHub bug tracker) and I'll take a look.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Ideas on a fast and tidy CSV library

[Johan Tibell]

On Tue, Jul 23, 2013 at 5:45 PM, Ben Gamari bgamari.f...@gmail.com wrote:
 Justin Paston-Cooper paston.coo...@gmail.com writes:

 Dear All,

 Recently I have been doing a lot of CSV processing. I initially tried to
 use the Data.Csv (cassava) library provided on Hackage, but I found this to
 still be too slow for my needs. In the meantime I have reverted to hacking
 something together in C, but I have been left wondering whether a tidy
 solution might be possible to implement in Haskell.

 Have you tried profiling your cassava implementation? In my experience
 I've found it's quite quick. If you have an example of a slow path I'm
 sure Johan (cc'd) would like to know about it.

I'm always interested in examples of code that is not running fast
enough. Send me a reproducible example (preferably as a bug on the
GitHub bug tracker) and I'll take a look.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Not working examples in GHC API documentation

[Johan Tibell]

I filed a bug a while back:

http://ghc.haskell.org/trac/ghc/ticket/7752

Someone that understands the API needs to fix the doc. :)

On Thu, Jul 18, 2013 at 7:58 PM, John Blackbox
blackbox.dev...@gmail.com wrote:
 Hi!
 Please take a look here: http://www.haskell.org/haskellwiki/GHC/As_a_library
 The examples are not working. Even the simpelst one:

 import GHC

 import GHC.Paths ( libdir )

 import DynFlags ( defaultLogAction )



 main =

 defaultErrorHandler defaultLogAction $ do

   runGhc (Just libdir) $ do

 dflags - getSessionDynFlags

 setSessionDynFlags dflags

 target - guessTarget test_main.hs Nothing

 setTargets [target]

 load LoadAllTargets



 throws:


 $ ghc -package ghc Main.hs

 [1 of 1] Compiling Main ( Main.hs, Main.o )

 Main.hs:6:25:

 Couldn't match type `DynFlags' with `[Char]'

 Expected type: DynFlags.FatalMessager

   Actual type: DynFlags.LogAction

 In the first argument of `defaultErrorHandler', namely

   `defaultLogAction'

 In the expression: defaultErrorHandler defaultLogAction

 In the expression:

   defaultErrorHandler defaultLogAction

   $ do { runGhc (Just libdir)

  $ do { dflags - getSessionDynFlags;

 setSessionDynFlags dflags;

  } }

 Main.hs:7:7:

 Couldn't match expected type `DynFlags.FlushOut'

 with actual type `IO SuccessFlag'

 In a stmt of a 'do' block:

   runGhc (Just libdir)

   $ do { dflags - getSessionDynFlags;

  setSessionDynFlags dflags;

  target - guessTarget test_main.hs Nothing;

  setTargets [target];

   }

 In the second argument of `($)', namely

   `do { runGhc (Just libdir)

 $ do { dflags - getSessionDynFlags;

setSessionDynFlags dflags;

 } }'

 In the expression:

   defaultErrorHandler defaultLogAction

   $ do { runGhc (Just libdir)

  $ do { dflags - getSessionDynFlags;

 setSessionDynFlags dflags;

  } }



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Remove Enum from Float and Double

[Johan Tibell]

Hi Harry,

On Tue, Jun 11, 2013 at 3:51 AM, harry volderm...@hotmail.com wrote:

 There have been several discussions over the years regarding Enum instances
 for Float and Double. The conclusion each time appears to have been that
 there are no instances which are both sane and practical.


Do you have a link to some of those discussions? I have a vague memory of
them but can no longer remember the specifics.


 I would like to propose that these instances be removed from Haskell 2014.
 This may be covered by the various alternative prelude and number class
 proposals, but they are much more ambitious and less likely to make it into
 the standard in the short term.


I don't see much gain. It will break previously working code and the
workaround to the breakage will likely be manually reimplementing
enumFromTo in each instance.

Cheers,
Johan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Remove Enum from Float and Double

[Johan Tibell]

If we truly believe that the instance is dangerous for users (and not
merely for people who don't understand floating point arithmetic on
computers), then we should add a deprecation pragma to the instance and
discourage its use. But what would the deprecation message encourage
instead, for users to write an explicit loop that tests against some
lower/upper bound? It would have the same problem as enumFromTo. I think
the issue here is really that floating point math on computers is hard to
think about.


On Tue, Jun 11, 2013 at 11:18 AM, harry volderm...@hotmail.com wrote:

 Johan Tibell johan.tibell@... writes:

  I don't see much gain. It will break previously working code and the
 workaround to the breakage will likely be manually reimplementing
 enumFromTo
 in each instance.

 I forgot the main point of my post :-)

 The primary motivation for removing these instances is that they cause
 endless confusion for beginners, e.g.

 http://stackoverflow.com/questions/13203471/the-math-behind-1-0999-in-haskell
 ,
 http://stackoverflow.com/questions/9810002/floating-point-list-generator,
 http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats,

 http://stackoverflow.com/questions/10328435/how-to-solve-floating-point-number-getting-wrong-in-list-haskell
 ,
 and many more.

 On the other hand, how much working code is there correctly using there
 instances?


 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Remove Enum from Float and Double

[Johan Tibell]

On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka r...@ro-che.info wrote:

 Does such thing as a deprecation pragma for an instance exist?
 What triggers it?


I don't know. We'll need one if we're going to deprecating core instances.
Just deleting them is not an option (as it gives users with large code
bases no time to migrate).
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Proposal: NoImplicitPreludeImport

[Johan Tibell]

On Tue, May 28, 2013 at 8:23 AM, Ian Lynagh i...@well-typed.com wrote:


 Dear Haskellers,

 I have made a wiki page describing a new proposal,
 NoImplicitPreludeImport, which I intend to propose for Haskell 2014:

 http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport

 What do you think?


-1 for me.

Breaking every single Haskell module for some namespace reorganization
doesn't seem worth it. I don't think alternative Prelused (one of the
justifications) is a good idea to begin with, as programmers will have to
first understand which particular version of e.g. map this module uses,
instead of knowing it's the same one as every other module uses.

Changes like this will likely cause years worth of pain e.g. see the Python
2/Python 3 failure.

The likely practical result of this is that every module will now read:

module M where

#if MIN_VERSION_base(x,y,z)
import Prelude
#else
import Data.Num
import Control.Monad
...
#endif

for the next 3 years or so.

-- Johan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: proposal for trailing comma and semicolon

[Johan Tibell]

On Fri, May 17, 2013 at 9:17 AM, Garrett Mitchener 
garrett.mitche...@gmail.com wrote:

 Anyway, this is a paper cut in the language that has been bugging me for
 a while, and since there's now a call for suggestions for Haskell 2014, I
 thought I'd ask about it.


I've also thought about this issue and I agree with Garrett, allowing that
trailing comma (or semicolon) would help readability*. If it doesn't work
with tuples, perhaps we could at least do it with lists and records?

* It also hurts source control diffs a bit, as adding extra commas will
give diffs that suggest that one additional line was changed.

-- Johan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: [Haskell] ANN: strict-base-types-0.1

[Johan Tibell]

On Wed, May 8, 2013 at 11:01 AM, Bas van Dijk v.dijk@gmail.com wrote:
 Good stuff Simon!

 It would be great if either strict-base-types, strict or a merger of
 the two will find its way into the Haskell Platform. Even better if it
 also merged with strict-concurrency and strict-io so that we have one
 go-to package for strict types and operations.

For what it's worth, I think we need Data.Maybe.Strict,
Data.Tuple.Strict, and Data.Either.Strict in base. Only then will they
be accessible enough that we can start using them in APIs in core
packages. This will also make it easier to provide type class
instances (e.g. Binary) for them without creating odd package
dependencies (or packages that depends on everything under the sub).

-- Johan

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: Simplifying Core pretty-printing via GHC API?

[Johan Tibell]

On Wed, May 1, 2013 at 2:13 PM, Conal Elliott co...@conal.net wrote:

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


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

Re: [Haskell-cafe] GSoC - A Cabal Project

[Johan Tibell]

Sounds like a good idea. Go ahead and apply. :)


On Tue, Apr 30, 2013 at 2:46 AM, Martin Ruderer martin.rude...@gmail.comwrote:

 Hi,

 I am proposing a GSoC project on Cabal. It aims to open up the dependency
 solver
 for debugging purposes.

 The details are here: https://gist.github.com/mr-/7995081f89cff38e9443

 I would really like to hear what you think about it.

 Best regards, Martin

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Johan Tibell]

Hi Adam,

Since we have already had *very* long discussions on this topic, I'm
worried that I might open a can of worms be weighing in here, but the issue
is important enough to me that I will do so regardless.

Instead of endorsing one of the listed proposals directly, I will emphasize
the problem, so we don't lose sight of it. The problem people run into *in
practice* and complain about in blog posts, on Google+, or privately when
we chat about Haskell over beer, is that they would like to write a record
definition like this one:

data Employee = Employee { id :: Int, name :: String }

printId :: Employee - IO ()
printId emp = print $ id emp

but since that doesn't work well in Haskell today due to name collisions,
the best practice today is to instead write something like:

data Employee = Employee { employeeId :: Int, employeeName :: String }

printId :: Employee - IO ()
printId emp = print $ employeeId emp

The downsides of the latter have been discussed elsewhere, but briefly they
are:

 * Overly verbose when there's no ambiguity.
 * Ad-hoc prefix is hard to predict (i.e. sometimes abbreviations of the
data type name are used).

The important requirement, which might seem a bit obvious, is that any
solution to this problem better not be *even more* verbose than the second
code snippet above. If I understand the SORF proposal correctly, you would
write:

data Employee = Employee { id :: Int, name :: String }

printId :: Employee - IO ()
printId emp = print $ emp.id

Is that correct or do you have to replace 'Employee' with 'r { id :: Int }'
in the type signature of 'printId'?

The discussions about an overhauled record system also involve lots of talk
about record sub-typing, extensible records, and other more advanced
features. I'd like to point out that there doesn't seem to be a great
demand for these features. They might be nice-to-haves or might fall
out naturally from a solution to the namespacing problem above, but they
are in fact not needed to solve the common problem people have with the
Haskell record system.

Cheers,
  Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails

[Johan Tibell]

Hi Ben,

On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
 The Repa plugin will also do proper SIMD vectorisation for stream programs, 
 producing the SIMD primops that Geoff recently added. Along the way it will 
 brutally convert all operations on boxed/lifted numeric data to their unboxed 
 equivalents, because I am sick of adding bang patterns to every single 
 function parameter in Repa programs.

How far is this plugin from being usable to implement a

{-# LANGUAGE Strict #-}

pragma for treating a single module as if Haskell was strict?

Cheers,
Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails

[Johan Tibell]

On Thu, Apr 25, 2013 at 10:30 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
 On Thu, 2013-04-25 at 21:15 -0700, Johan Tibell wrote:

 {-# LANGUAGE Strict #-}

 God, I would love this. Obviously the plugin approach could do it, but
 could not GHC itself just _not create thunks_ for things unless told to
 be lazy in the presence of such a pragma?

 [at which point, we need an annotation for laziness, instead of the
 annotation for strictness. We're not using ampersand for anything, are
 we?

 func Int - Thing - WorldPeace
 func a b = ...

 Ah, bikeshed, how we love thee]

We already have ~ that's used to make lazy patterns. :)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stream fusion and span/break/group/init/tails

[Johan Tibell]

On Thu, Apr 25, 2013 at 9:20 PM, Ben Lippmeier b...@ouroborus.net wrote:

 On 26/04/2013, at 2:15 PM, Johan Tibell wrote:

 Hi Ben,

 On Thu, Apr 25, 2013 at 7:46 PM, Ben Lippmeier b...@ouroborus.net wrote:
 The Repa plugin will also do proper SIMD vectorisation for stream programs, 
 producing the SIMD primops that Geoff recently added. Along the way it will 
 brutally convert all operations on boxed/lifted numeric data to their 
 unboxed equivalents, because I am sick of adding bang patterns to every 
 single function parameter in Repa programs.

 How far is this plugin from being usable to implement a

 {-# LANGUAGE Strict #-}

 pragma for treating a single module as if Haskell was strict?

 There is already one that does this, but I haven't used it.

 http://hackage.haskell.org/package/strict-ghc-plugin

 It's one of the demo plugins, though you need to mark individual functions 
 rather than the whole module (which would be straightforward to add).

 The Repa plugin is only supposed to munge functions using the Repa library, 
 rather than the whole module.

I guess what I was really hoping for was a plugin that rigorously
defined what it meant to make the code strict at a source language
level, rather than at a lets make all lets into cases Core level. :)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fwd: GSoC Project Proposal: Markdown support for Haddock

[Johan Tibell]

On Tue, Apr 9, 2013 at 12:40 PM, Joe Nash joen...@blackvine.co.uk wrote:
 I would be interested in discussing this project with a potential mentor if
 one happens to be reading. I'm a second year Computer Science student at the
 University of Nottingham, very interested in doing a haskell.org SoC
 project.

Normally I would volunteer to mentor any project I propose, but my
schedule doesn't allow for it this summer. Perhaps Mark Lentczner is
interested. He did some Haddock work before. I'm happy to provide
input on what I think the feature should be about (in fact, I will
probably write a blog post about it, like I do every year before
GSoC).

-- Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [haskell.org Summer of Code 2013] We're In!

[Johan Tibell]

Thanks for working on this again this year!

On Mon, Apr 8, 2013 at 12:50 PM, Edward Kmett ekm...@gmail.com wrote:
 We (haskell.org) have been officially accepted into the Google Summer of
 Code for 2013. We should show up in the mentoring organization list as soon
 as I get some information we need to finalize the listing.

 Shachaf Ben-Kiki has volunteered to help out as our backup org administrator
 this year.

 If you are thinking about joining up as a mentor or a student this year, now
 would be a good time to start brainstorming about project ideas!

 I'll follow up with more information as soon as the listing goes in.

 In the meantime there is the #haskell-gsoc channel on irc.freenode.net. Feel
 free to pester me (or Shachaf) with questions!

 -Edward Kmett

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock

[Johan Tibell]

Hi all,

Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).

I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:

{-# HADDOCK Markdown #-}

on top of the source file.

Ticket: http://trac.haskell.org/haddock/ticket/244

-- Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock

[Johan Tibell]

On Thu, Apr 4, 2013 at 9:49 AM, Johan Tibell johan.tib...@gmail.com wrote:
 I suggest that we implement an alternative haddock syntax that's a
 superset of Markdown. It's a superset in the sense that we still want
 to support linkifying Haskell identifiers, etc. Modules that want to
 use the new syntax (which will probably be incompatible with the
 current syntax) can set:

 {-# HADDOCK Markdown #-}

Let me briefly argue for why I suggested Markdown instead of the many
other markup languages out there.

Markdown has won. Look at all the big programming sites out there,
from GitHub to StackOverflow, they all use a superset of Markdown. It
did so mostly (in my opinion) because it codified the formatting style
people were already using in emails and because it was pragmatic
enough to include HTML as an escape hatch.

-- Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock

[Johan Tibell]

 Would it be too much to ask that a notation be used which has
 a formal syntax and a formal semantics?

We will document our superset, sure. That's what others did as well.
The point is using Markdown as the shared base.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell] [Haskell-cafe] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

[Johan Tibell]

I had a 5 second look at the PSQueue implementation and here's what I got
so far:

 * fromList should use foldl'.
 * LTree should be spine strict (i.e. strict in the (LTree k p) fields).
 * Winner should be strict in the (LTree k p) field and probably in all
other fields as well.

This is a nice example showing that strict fields is the right default. If
fields need to be lazy there should ideally be a comment explaining why
that is needed (e.g. in the case of finger trees and lists).


On Fri, Mar 29, 2013 at 9:53 AM, Niklas Hambüchen m...@nh2.me wrote:

 Hey Scott,

 I quickly tried your suggestion, plugging in foldr' from Data.Foldable
 and sprinkling a few seqs in some places, but it doesn't help the stack
 overflow.

 On Fri 29 Mar 2013 16:23:55 GMT, Scott Dillard wrote:
  I do not know why it overflows. It's been a while, but isn't the
  answer usually too much laziness? Maybe try changing the foldr in
  fromList to foldr'? I would try it out quickly but do not have ghc
  installed on any computers here.
 
  I am happy start a repo for this library, but there is not much
  history to import so anyone else may do it. I'm not sure how hackage
  upload permissions work... I guess I just change the maintainer field
  in the .cabal file from myself to someone else...? Any volunteers?
 
 
 
 
  On Thu, Mar 28, 2013 at 11:16 PM, Kazu Yamamoto k...@iij.ad.jp
  mailto:k...@iij.ad.jp wrote:
 
  Hi Niklas,
 
   * PSQueue throws a stack space overflow if you try to put in 10
   * Ints
 
  A slightly different implementation is used in GHC:
 
 
  https://github.com/ghc/packages-base/blob/master/GHC/Event/PSQ.hs
 
  Could you test it? If this code also has the same problem, I need to
  fix it.
 
  --Kazu
 
 

 ___
 Haskell mailing list
 Haskell@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] [Haskell] ANN: psqueue-benchmarks - benchmarks of priority queue implementations

[Johan Tibell]

I had a 5 second look at the PSQueue implementation and here's what I got
so far:

 * fromList should use foldl'.
 * LTree should be spine strict (i.e. strict in the (LTree k p) fields).
 * Winner should be strict in the (LTree k p) field and probably in all
other fields as well.

This is a nice example showing that strict fields is the right default. If
fields need to be lazy there should ideally be a comment explaining why
that is needed (e.g. in the case of finger trees and lists).


On Fri, Mar 29, 2013 at 9:53 AM, Niklas Hambüchen m...@nh2.me wrote:

 Hey Scott,

 I quickly tried your suggestion, plugging in foldr' from Data.Foldable
 and sprinkling a few seqs in some places, but it doesn't help the stack
 overflow.

 On Fri 29 Mar 2013 16:23:55 GMT, Scott Dillard wrote:
  I do not know why it overflows. It's been a while, but isn't the
  answer usually too much laziness? Maybe try changing the foldr in
  fromList to foldr'? I would try it out quickly but do not have ghc
  installed on any computers here.
 
  I am happy start a repo for this library, but there is not much
  history to import so anyone else may do it. I'm not sure how hackage
  upload permissions work... I guess I just change the maintainer field
  in the .cabal file from myself to someone else...? Any volunteers?
 
 
 
 
  On Thu, Mar 28, 2013 at 11:16 PM, Kazu Yamamoto k...@iij.ad.jp
  mailto:k...@iij.ad.jp wrote:
 
  Hi Niklas,
 
   * PSQueue throws a stack space overflow if you try to put in 10
   * Ints
 
  A slightly different implementation is used in GHC:
 
 
  https://github.com/ghc/packages-base/blob/master/GHC/Event/PSQ.hs
 
  Could you test it? If this code also has the same problem, I need to
  fix it.
 
  --Kazu
 
 

 ___
 Haskell mailing list
 hask...@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Associated types for number coercion

[Johan Tibell]

On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done chrisd...@gmail.comwrote:

 From the paper Fun with Type Funs, it's said:

  One compelling use of such type functions is to make type
  coercions implicit, especially in arithmetic. Suppose we want to be able
 to
  write add a b to add two numeric values a and b even if one is an Integer
  and the other is a Double (without writing fromIntegral explicitly).

 And then an Add class is defined which can dispatch at the type-level
 to appropriate functions which resolve two types into one, with a
 catch-all case for Num.

 Has anyone put this into a package, for all common arithmetic
 operations? I would use it. Doing arithmetic stuff in Haskell always
 feels labored because of having constantly convert between number
 types.


I prefer the current way (which is interestingly what Go chose as well).
With implicit casts it's easy to shoot yourself in the foot e.g. when doing
bit-twiddling. These two are different

f :: Word8 - Int - Word32
f w8 n = fromIntegral (w8 `shiftL` n)

f' :: Word8 - Int - Word32
f' w8 n = (fromIntegral w8) `shiftL` n
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell] Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013

[Johan Tibell]

[bcc: haskell@haskell.org]

We should make sure that we apply for Google Summer of Code this year as
well. It's been very successful in the previous year, where we have
gotten several projects funded every year.

-- Johan

-- Forwarded message --
From: Carol Smith car...@google.com
Date: Mon, Mar 18, 2013 at 12:00 PM
Subject: Now Accepting Applications for Mentoring Organizations for GSoC
2013
To: Google Summer of Code Announce 
google-summer-of-code-annou...@googlegroups.com


Hi all,

We're pleased to announce that applications for mentoring organizations for
Google Summer of Code 2013 are now being accepted [1]. If you'd like to
apply to be a mentoring organization you can do so via Melange [2]. If you
have questions about how to use Melange, please see our User's Guide [3].

Please note that the application period [4] closes on 29 March at 19:00 UTC
[5]. We will not accept any late applications for any reason.

[1] -
http://google-opensource.blogspot.com/2013/03/mentoring-organization-applications-now.html
[2] - http://www.google-melange.com
[3] - http://en.flossmanuals.net/melange/
[4] - http://www.google-melange.com/gsoc/events/google/gsoc2013
[5] - http://goo.gl/xmQMJ

Cheers,
Carol

-- 
You received this message because you are subscribed to the Google Groups
Google Summer of Code Announce group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-annou...@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-summer-of-code-announce?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell-cafe] Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013

[Johan Tibell]

[bcc: hask...@haskell.org]

We should make sure that we apply for Google Summer of Code this year as
well. It's been very successful in the previous year, where we have
gotten several projects funded every year.

-- Johan

-- Forwarded message --
From: Carol Smith car...@google.com
Date: Mon, Mar 18, 2013 at 12:00 PM
Subject: Now Accepting Applications for Mentoring Organizations for GSoC
2013
To: Google Summer of Code Announce 
google-summer-of-code-annou...@googlegroups.com


Hi all,

We're pleased to announce that applications for mentoring organizations for
Google Summer of Code 2013 are now being accepted [1]. If you'd like to
apply to be a mentoring organization you can do so via Melange [2]. If you
have questions about how to use Melange, please see our User's Guide [3].

Please note that the application period [4] closes on 29 March at 19:00 UTC
[5]. We will not accept any late applications for any reason.

[1] -
http://google-opensource.blogspot.com/2013/03/mentoring-organization-applications-now.html
[2] - http://www.google-melange.com
[3] - http://en.flossmanuals.net/melange/
[4] - http://www.google-melange.com/gsoc/events/google/gsoc2013
[5] - http://goo.gl/xmQMJ

Cheers,
Carol

-- 
You received this message because you are subscribed to the Google Groups
Google Summer of Code Announce group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-annou...@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-summer-of-code-announce?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: base package -- goals

[Johan Tibell]

On Wed, Mar 13, 2013 at 7:04 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:

 Most people won't care and will continue to depend on enough to get
 Prelude.


Let me just put this out here so keep it in the back of our heads: most
people don't care about this whole thing (splitting base) so lets make sure
there's still a base package to import that gives people what they have
before. :) Other than that I'm quite excited about the prospects of
splitting up base a bit.

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package -- goals

[Johan Tibell]

On Mon, Mar 11, 2013 at 4:45 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:

 B Better for internal implementation (eg using containers or bytestring in
 base)


Note that this also means better code for external clients, as we can offer
e.g. a better System.IO that lets people use Handles to read Text and
ByteStrings in a more natural way (i.e. the I/O functions will be in one
place, not spread out throughout N data structure libraries).
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] GSOC application level

[Johan Tibell]

Hi Mateusz,

On Wed, Mar 6, 2013 at 4:58 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:

 Can someone that has been around for a bit longer comment on what level
 of experience with Haskell and underlying concepts is usually expected
 from candidates? Are applications discarded simply based on the
 applicant not having much previous experience in the target area? What
 is the level of the competition for places on the projects?


We don't have a fix bar for things you need to known when you apply.
Rather we try to guess whether the student can accomplish the project
he/she is applying for, based on whatever evidence we have e.g.
contribution to other projects, released libraries on Hackage, and other
forms of community participation. Since we typically have more proposals
than slots we will rank students both based on how impactful we think the
project will be and how likely we think it is that the student will
proceed. Both these qualities map onto a single number that we use to stack
rank proposals.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Concurrency performance problem

[Johan Tibell]

On Mon, Mar 4, 2013 at 11:39 AM, Łukasz Dąbek sznu...@gmail.com wrote:

 Thank you for your help! This solved my performance problem :)

 Anyway, the second question remains. Why performance of single
 threaded calculation is affected by RTS -N parameter. Is GHC doing
 some parallelization behind the scenes?


I believe it's because -N makes GHC use the threaded RTS, which is
different from the non-threaded RTS and has some overheads therefore.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The state of binary (de)serialization

[Johan Tibell]

On Tue, Feb 26, 2013 at 11:17 PM, Vincent Hanquez t...@snarc.org wrote:

 On Mon, Feb 25, 2013 at 11:59:42AM -0800, Johan Tibell wrote:
   - cereal can output a strict bytestring (runPut) or a lazy one
   (runPutLazy), whilst binary only outputs lazy ones (runPut)
  
 
  The lazy one is more general and you can use toStrict (from bytestring)
 to
  get a strict ByteString from a lazy one, without loss of performance.

 Two major problems of lazy bytestrings is that:

 * you can't pass it to a C bindings easily.
 * doing IO with it without rewriting the chunks, can sometimes (depending
   how the lazy bytestring has been produced) result in a serious
 degradation of
   performance calling syscalls on arbitrary and small chunks (e.g.
 socket's 'send').

 Personally, i also like the (obvious) stricter behavior of strict
 bytestring.


My point was rather that all cereal does for you is to concat the lazy
chunks it already has to a strict bytestring before returning them. If you
want that behavior with binary just call concat yourself. The benefit of
not concatenating by default is that it costs O(n) time, which you might
avoid if you can consume the lazy bytestring directly (e.g. through writev).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: base package -- goals

[Johan Tibell]

Hi all,

Let me add the goals I had in mind last time I considered trying to split
base.

 1. I'd like to have text Handles use the Text type and binary Handles use
the ByteString type. Right now we have this somewhat awkward setup where
the I/O APIs are spread out and bundled with pure types. Splitting base
would let us fix this and write a better I/O layer.

 2. The I/O manager currently has a copy of IntMap inside its
implementation because base cannot use containers. Splitting base would let
us get rid of this code duplication.

I'm less interested in having super fine-grained dependencies in my
libraries. More packages usually means more busy-work managing
dependencies. Taken to its extreme you could imagine having base-maybe,
base-bool, and whatnot. I don't think this is an improvement. Splitting
base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let us
get a bunch of benefits without too many downsides.

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] The state of binary (de)serialization

[Johan Tibell]

On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez nico...@incubaid.comwrote:

 - cereal supports chunk-based 'partial' parsing (runGetPartial). It
 looks like support for this is introduced in recent versions of 'binary'
 as well (runGetIncremental)


Yes. Binary now support an incremental interface. We intend to make sure
binary has all the same functionality as cereal. We'd like to move away
from having two packages if possible and since binary has the larger
installed user base we're trying to make that the go-to package.


 - cereal can output a strict bytestring (runPut) or a lazy one
 (runPutLazy), whilst binary only outputs lazy ones (runPut)


The lazy one is more general and you can use toStrict (from bytestring) to
get a strict ByteString from a lazy one, without loss of performance.


 - Next to binary and cereal, there's bytestring's Builder interface for
 serialization, and Simon Meier's blaze-binary prototype


Simon's builder (originally developed in blaze-binary) has been merged into
the bytestring package. In the future binary will just re-export that
builder.


 There are some blog posts and comments out there about merging cereal
 and binary, is this what's the goal/going on (cfr runGetIncremental)?


It's most definitely the goal and it's basically done. The only thing I
don't think we'll adopt from cereal is the instances from container types.


 In my use-case I think using Builder instead of binary/cereal's PutM
 monad shouldn't be a major problem. Is this advisable performance-wise?


You can go ahead and use the builder directly if you like.


 Overall: what's the advised future-proof strategy of handling binary
 (de)serialization?


Use binary or the builder from bytestring whenever you can. Since the
builder in bytestring was recently added you might have to fall back to
blaze-builder if you believe your users can't rely on the latest version of
bytestring.

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: lazy-csv - the fastest and most space-efficient parser for CSV

[Johan Tibell]

On Mon, Feb 25, 2013 at 2:32 PM, Don Stewart don...@gmail.com wrote:

 Cassava is quite new, but has the same goals as lazy-csv.

 Its about a year old now -
 http://blog.johantibell.com/2012/08/a-new-fast-and-easy-to-use-csv-library.html

 I know Johan has been working on the benchmarks of late - it would be very
 good to know how the two compare in features

I whipped together a quick benchmark:
https://github.com/tibbe/cassava/blob/master/benchmarks/Benchmarks.hs

To run, check out the cassava repo on GitHub and run: cabal configure
--enable-benchmarks  cabal build  cabal bench

Here are the results (all the normal caveats for benchmarking applies):

benchmarking positional/decode/presidents/without conversion
mean: 62.85965 us, lb 62.56705 us, ub 63.26101 us, ci 0.950
std dev: 1.751446 us, lb 1.371323 us, ub 2.295576 us, ci 0.950

benchmarking positional/decode/streaming/presidents/without conversion
mean: 93.81925 us, lb 91.14701 us, ub 98.19217 us, ci 0.950
std dev: 17.20842 us, lb 11.58690 us, ub 23.41786 us, ci 0.950

benchmarking comparison/lazy-csv
mean: 133.2609 us, lb 132.4415 us, ub 135.3085 us, ci 0.950
std dev: 6.193178 us, lb 3.123661 us, ub 12.83148 us, ci 0.950

The two first set of numbers are for cassava (in the all-at-once vs
streaming mode). The last set is for lazy-csv.

The feature sets of the two libraries are quite different. Both do basic
CSV parsing (with some extensions).

 * lazy-csv parses CSV data to something akin to [[ByteString]], but with a
heavy focus on error recovery and precise error messages.
 * cassava parses CSV data to [a], where a is a user-defined type that
represents a CSV record. There are options to recover from *type
conversion* errors, but not from malformed CSV. cassava has several parsing
modes: incremental for parsing interleaved with I/O, streaming for lazy
parsing (with or without I/O), and all-at-once parsing for when you want to
hold all the data in memory.

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The state of binary (de)serialization

[Johan Tibell]

On Mon, Feb 25, 2013 at 4:51 PM, Alexander Solla alex.so...@gmail.comwrote:

 On Mon, Feb 25, 2013 at 11:59 AM, Johan Tibell johan.tib...@gmail.comwrote:


 There are some blog posts and comments out there about merging cereal
 and binary, is this what's the goal/going on (cfr runGetIncremental)?


 It's most definitely the goal and it's basically done. The only thing I
 don't think we'll adopt from cereal is the instances from container types.


 Why not?  Those instances are useful.  Without instances defined in
 binary/cereal, pretty much every Happstack (or, better said, every
 ixset/acidstate/safecopy stack) user will have to have orphan instances.


I will have to give a bit more context to answer this one. After the binary
package was created we've realized that it should really have been two
packages:

 * One package for serialization and deserialization of basic types, that
have a well-defined serialization format even outside the package e.g.
little and big endian integers, IEEE floats, etc. This package would
correspond to Data.Binary.Get, Data.Binary.Builder, and Data.Binary.Put.

 * One package that defines a particular binary format useful for
serializing arbitrary Haskell values. This package would correspond to
Data.Binary.

For the latter we need to decide what guarantees we make. For example, is
the format stable between releases? Is the format public (such that other
libraries can parse the output of binary)? Right now these two questions
are left unanswered in both binary and cereal, making those packages less
useful.

Before we answer those questions we don't want to 1) add
more dependencies to binary and 2) define serialization formats that we
might break in the next release.

So perhaps once we've settled these issues we'll include instances for
containers.

Also, cereal has a generic instance.  Will the new binary?


That sounds reasonable. If someone sends a pull request Lennart or I will
review and merge it.

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Race-condition in alternative 'System.Timeout.timeout' implementation

[Johan Tibell]

On Sun, Feb 24, 2013 at 2:31 PM, Herbert Valerio Riedel h...@gnu.org wrote:

 I've been experimenting with an alternative implementation of
 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new
 thread for each invocation.

 Part of my motivation is to see if I can implement a faster version of

 threadWaitReadTimeout :: Int - Fd - IO Bool
 threadWaitReadTimeout to = liftM (maybe False (const True))
. timeout to . threadWaitRead

 and thus exploit GHC's event notification system instead of having to
 reimplement a timeout-manager myself (like popular HTTP server libraries
 such as Snap or Warp do currently).


 The following Haskell program shows a proof-of-concept implementation
 derived directly from 'System.Timeout.timeout' together with a Criterion
 benchmark comparing the performance between the original and the
 alternative 'timeout' function wrapping a 'readMVar' call.



 On a i7-3770 with GHC-7.6.2/Linux/64bit ran with +RTS -A4m -N4, the
 benchmark shows a 15x improvement for the new implementation (below 1
 uS) compared to the original implementation (~13 uS):


Fast timeouts is really important for real world web servers, which
typically need one timeout per connection (e.g. to avoid slowloris DOS
attacks). We should make sure timeouts are as cheap and fast as possible.
This seems like a step in the right direction.

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package

[Johan Tibell]

Hi Joachim.

Glad to see you're making progress on this. Once we're done exploring how
fine-grained we can make the division we might want to pull back a bit and
consider what logical groupings makes sense. For example, even if the float
functionality can be split from the int functionality, I don't think that
makes for a very logical grouping.

In addition, I don't think we want to say that e.g. pure data structures
can't depend on the FFI. While their current implementation might not use
the FFI, what if we want to use it in the future. We'd have to reshuffle
the packages again.

Just my 2 cents.

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package

[Johan Tibell]

On Fri, Feb 22, 2013 at 3:34 PM, Joachim Breitner
m...@joachim-breitner.dewrote:

 right, there is a tension between having just independent APIs and
 having also independent implementations. My main goal is to allow
 packages to specify their imports more precisely, to require less
 changes as not-so-common stuff in base evolves and to make it easier for
 alternative compiler/targets to implement parts of base; this would just
 require providing better grouped APIs.

 But if we want that while retaining the freedom to have an entangled
 implementation, we are back at the large base + specific re-exporting
 packages approach, which wasn’t particularly well received here.


I don't know about entangled implementations. But I'd like to have a base
package (e.g. your base-pure) that has a consistent set of basic data types
e.g. Int, Word, Float, Double, Char, String, ByteString, Text, [a], Maybe,
Either, and so forth. These are logically at the same layer. I think
splitting them according to how they happen to be implemented at the moment
is a misstake. It would give us a illogical and unstable layering in the
long run.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] What magic has the new IO manager done to improve performance ?

[Johan Tibell]

Hi,

On Saturday, February 16, 2013, yi huang wrote:

 I' m curious about the design and trade offs behind the new IO manager. I
 see two changes from the code:

 1. Run IO manager thread on each capability.
 2. Use ONESHOT flag to save a system call.

 Is there other interesting things to know?
 Is it possible to use epoll's ET mode to save even more system calls?


 Andreas and Kazu (CCed) would know more. In addition to the things you
mentioned then parallel I/O manager also uses lock striping and is smarter
bout when it makes blocking system calls.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: base package (Was: GHC 7.8 release?)

[Johan Tibell]

On Thu, Feb 14, 2013 at 6:48 AM, Joachim Breitner
m...@joachim-breitner.dewrote:

 Maybe the proper is to reverse the whole approach: Leave base as it is,
 and then build re-exporting smaller packages (e.g. a base-pure) on top
 of it. The advantage is:
   * No need to rewrite the tightly intertwined base.
   * Libraries still have the option to have tighter dependencies.
   * Base can evolve with lots of breaking changes, as long as they
 do not affect the API by the smaller packages.
   * Development of this collection can happen outside the GHC tree.
   * Alternative implementations for (some of) these packages can be
 created, if the reason why they could not be moved out of base
 is one of implementation, not of API

 How does that sound?


I'm not in favor of this approach as it precludes pushing any data types
down the stack. In particular, we want text and bytestring to be below the
I/O layer, so we can defined Handles that work with those in base itself.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package (Was: GHC 7.8 release?)

[Johan Tibell]

On Thu, Feb 14, 2013 at 8:45 AM, Joachim Breitner
m...@joachim-breitner.dewrote:

 ./Control/Applicative.hs
 ./Control/Arrow.hs
 ./Control/Category.hs
 ./Control/Monad/Fix.hs
 ./Control/Monad.hs
 ./Data/Bits.hs
 ./Data/Bool.hs
 ./Data/Either.hs
 ./Data/Eq.hs
 ./Data/Foldable.hs
 ./Data/Function.hs
 ./Data/Functor.hs
 ./Data/Int.hs
 ./Data/List.hs
 ./Data/Maybe.hs
 ./Data/Monoid.hs
 ./Data/Ord.hs
 ./Data/Ratio.hs
 ./Data/Traversable.hs
 ./Data/Tuple.hs
 ./Data/Typeable.hs
 ./Data/Typeable.hs-boot
 ./Data/Typeable/Internal.hs
 ./Data/Typeable/Internal.hs-boot
 ./dist/build/autogen/Paths_base_pure.hs
 ./GHC/Base.lhs
 ./GHC/Char.hs
 ./GHC/Enum.lhs
 ./GHC/Err.lhs
 ./GHC/Err.lhs-boot
 ./GHC/Exception.lhs
 ./GHC/Fingerprint.hs
 ./GHC/Fingerprint/Type.hs
 ./GHC/Int.hs
 ./GHC/List.lhs
 ./GHC/Num.lhs
 ./GHC/Real.lhs
 ./GHC/Show.lhs
 ./GHC/Word.hs
 ./Prelude.hs (contains just $!)
 ./Unsafe/Coerce.hs


That's great. I'm curious  I was under the impression that it was hard to
split out a pure subset as functions might call 'error' (e.g. due to
incomplete pattern matches) and that would pull in the whole I/O subsystem.
How did you avoid that?

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package (Was: GHC 7.8 release?)

[Johan Tibell]

On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
m...@joachim-breitner.dewrote:

 Hi,

 Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell:
  That's great. I'm curious  I was under the impression that it was hard
  to split out a pure subset as functions might call 'error' (e.g. due
  to incomplete pattern matches) and that would pull in the whole I/O
  subsystem. How did you avoid that?

 as mentioned before: By crippling GHC.Fingerprint. error foo just calls
 raise (ErrorCall foo), which calls raise# (SomeException (ErrorCall
 foo). The problem is that the definition of SomeException pulls in the
 Exception type class, which pulls in Typeable, which pulls in
 GHC.Fingerprint, which uses FFI and IO code to to fingerprinting...


I don't think having FFI far down the stack is a problem. There are lots of
pure data types we'd like in the pure data layer (e.g. bytestring) that
uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc)
doesn't get pulled in there's no real problem in depending on the FFI.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Johan Tibell]

Hi,

I think reducing breakages is not necessarily, and maybe not even
primarily, an issue of releases. It's more about realizing that the cost of
breaking things (e.g. changing library APIs) has gone up as the Haskell
community and ecosystem has grown. We need to be conscious of that and
carefully consider if making a breaking change (e.g. changing a function
instead of adding a new function) is really necessary. Many platforms (e.g.
Java and Python) rarely, if ever, make breaking changes. If you look at
 compiler projects (e.g. LLVM and GCC) you never see intentional breakages,
even in major releases*. Here's a question I think we should be asking
ourselves: why is the major version of base bumped with every release? Is
it really necessary to make breaking changes this often? How about aiming
for having GHC 7.10 be a release where we only add new stuff and improve
old stuff?

-- Johan

* A major GCC release usually signifies that some large change to the code
generator was made.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Johan Tibell]

On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis 
g...@integrable-solutions.net wrote:

 I have some experience with GCC releases -- having served as a GCC
 Release Manager for several years. In fact, the release scheme we currently
 have has gone through several iterations -- usually after many
 existential
 crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
 a research compiler and most research works are done on forgotten
 branches
 that nobody cares about anymore.  Implementing new standards (e.g. moving
 from C++03 to C++11 that has several mandated API and ABI breakage) is a
 royal pain that isn't worth replicating in GHC -- at least if you want
 GHC to remain a research compiler.

 Concerning your question about release number, I would venture that there
 is a certain marketing aspect to it.  I can tell you that we, the
 GCC community,
 are very poor at that -- otherwise, we would have been at version 26
 or something :-)


Thanks for sharing! My perspective is of course as a user. I don't think
I've ever run into a case where the compiler broken a previous work e.g.
C++ program. On the other hand I have to make a release of most of the
libraries I maintain with every GHC release (to bump cabal version
constraints to accept the new base version, if nothing else).

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Fwd: Google Summer of Code 2013

[Johan Tibell]

Hi all,

Summer of code has always been a good way for us to get some important
work, that no one has time to do, done. I encourage everyone to come up
with good summer of code projects so we have a good number when the time
for students to apply comes around. Empirically projects that focus on
existing infrastructure (e.g. Cabal) work well. They limit the scope enough
for students to 1) make something that's impacts lots of people and 2)
doesn't give them too much rope*.

* Building something good from scratch requires lots of experience,
something most students don't have, almost per definition.

-- Johan

-- Forwarded message --
From: Carol Smith car...@google.com
Date: Mon, Feb 11, 2013 at 11:02 AM
Subject: Google Summer of Code 2013
To: Google Summer of Code Announce 
google-summer-of-code-annou...@googlegroups.com


Hi all,

We're pleased to announce that Google Summer of Code will be happening for
its ninth year this year. Please check out the blog post [1] about the
program and read the FAQs [2] and Timeline [3] on Melange for more
information.

[1] -
http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html
[2] -
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page
[3] - http://www.google-melange.com/gsoc/events/google/gsoc2013

Cheers,
Carol

-- 
You received this message because you are subscribed to the Google Groups
Google Summer of Code Announce group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-annou...@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-summer-of-code-announce?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: GHC 7.8 release?

[Johan Tibell]

On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote:

  For a while we've been doing one major release per year, and 1-2 minor
 releases.  We have a big sign at the top of the download page directing
 people to the platform.  We arrived here after various discussions in the
 past - there were always a group of people that wanted stability, and a
 roughly equally vocal group of people who wanted the latest bits.  So we
 settled on one API-breaking change per year as a compromise.

 Since then, the number of packages has ballooned, and there's a new factor
 in the equation: the cost to the ecosystem of an API-breaking release of
 GHC.  All that updating of packages collectively costs the community a lot
 of time, for little benefit.  Lots of package updates contributes to Cabal
 Hell.  The package updates need to happen before the platform picks up the
 GHC release, so that when it goes into the platform, the packages are ready.

 So I think, if anything, there's pressure to have fewer major releases of
 GHC.  However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to
 7.4 was 6 months, 7.4 to 7.6 was 7 months.  We're getting too efficient at
 making releases!


I think we want to decouple GHC major releases (as in, we did lots of
work) from API breaking releases. For example, GCC has lots of major (or
big) releases, but rarely, if ever, break programs.

I'd be delighted to see a release once in a while that made my programs
faster/smaller/buggy without breaking any of them.

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] cabal-dev add-source

[Johan Tibell]

On Fri, Feb 8, 2013 at 9:53 AM, Blake Rain blake.r...@gmail.com wrote:

 You need to call cabal-dev add-source on P1 again to copy over the sdist,
 then do a cabal-dev install.

 See notes under Using a sandbox-local Hackage on
 https://github.com/creswick/cabal-dehttps://github.com/creswick/cabal-dev


With the new cabal sandboxing (due in 1.18) this won't be necessary as we
create a link to the repo, instead of installing a copy. We will rebuild
the linked repo as needed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cabal-dev add-source

[Johan Tibell]

On Fri, Feb 8, 2013 at 10:07 AM, JP Moresmau jpmores...@gmail.com wrote:

 Johan, thanks, that brings me to a point that I wanted to raise. I'm
 playing with cabal-dev because users have asked me to add support for it in
 EclipseFP (so projects could have their own sandbox and have dependencies
 between projects without polluting the main package databases). It is worth
 it, or should I just wait for cabal 1.18 and use the sandboxing facility?
 Or will the two work similarly enough that supporting both will be easy?
 Does the sandboxing in cabal means that tools like cabal-dev are going to
 get deprecated?


I think they will be similar enough that you could easily port the code.
The new cabal sandboxing will work as follows:

cabal sandbox --init
cabal add-source dir

and then you use cabal commands like normal (e.g. configure, build, test).
No installing necessary.

I cannot speak for the cabal-dev developers. We do intend to support a
superset of the cabal-dev functionality eventually. What we're missing now
is ghci support.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cabal-dev add-source

[Johan Tibell]

On Fri, Feb 8, 2013 at 10:24 AM, Ozgun Ataman ozata...@gmail.com wrote:

  Which, thanks to Johan's help yesterday, can still be worked around (for
 now) by starting ghci with:

 ghci -package-conf ./cabal-sandbox/your-package-conf-folder-here/


You can indeed do this. For real ghci support in cabal we need to also pass
-package flags, C libraries, etc to ghci. That's why it's not done yet.

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: GHC 7.8 release?

[Johan Tibell]

On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier b...@ouroborus.net wrote:

 Right now, the latest packages uploaded to Hackage get built with ghc-7.6
 (only), and all the pages say Built on ghc-7.6. By doing this we force
 *all* library developers to run GHC 7.6. I think this sends the clearest
 message about what the real GHC version is.


I don't know how closely users look at the built on line on the package
page. Perhaps they look there, perhaps they don't.

Between Bryan and me we build all of our own packages and all HP packages
on the latest 3 GHC versions:

http://ci.johantibell.com/
https://jenkins.serpentine.com/

That doesn't mean that it would be a bad idea to build all Hackage packages
on using more GHC versions, but that won't happen until the Hackage project
is unstuck (it has been stuck for years!).

-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bang patterns

[Johan Tibell]

On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood hask...@benmachine.co.uk wrote:
 I have two proposals, I suppose:
 - make bang patterns in let altogether invalid

I would prefer it to be valid. It's the syntactically most lightweight
option we have to force some thunks before using the resulting values
in a constructor that we have. Example

let !x = ...
!y = ...
in C x y

The alternative would be

let x = ...
y = ...
in x `seq` y `seq` C x y

which obscures the code much more.

My 2 cents.

-- Johan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] Substantial (1:10??) system dependencies of runtime performance??

[Johan Tibell]

On Sat, Feb 2, 2013 at 5:14 PM, Ozgun Ataman ozata...@gmail.com wrote:
 If you are doing row-by-row transformations, I would recommend giving a try 
 to my csv-conduit or csv-enumerator packages on Hackage. They were designed 
 with constant space operation in mind, which may help you here.

 If you're keeping an accumulator around, however, you may still run into 
 issues with too much laziness.

The cassava package also has a Streaming and an Incremental module for
constant space parsing.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Heads up: planned removal of String instances from HTTP package

[Johan Tibell]

On Tue, Jan 29, 2013 at 2:15 PM, Ganesh Sittampalam gan...@earth.li wrote:
 tl;dr: I'm planning on removing the String instances from the HTTP
 package. This is likely to break code. Obviously it will involve a major
 version bump.

 The basic reason is that this instance is rather broken in itself. A
 String ought to represent Unicode data, but the HTTP wire format is
 bytes, and HTTP makes no attempt to handle encoding.

 This was discussed on the libraries@ list a while back, but I'm happy to
 discuss further if there's a general feeling that this is a bad thing to do:

 http://www.haskell.org/pipermail/libraries/2012-September/018426.html

 I will probably upload the new version in a week or two.

I think it's the right thing to do. Providing a little upgrade guide
should help things to go smoother.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Handling exceptions or gracefully releasing resources

[Johan Tibell]

Hi,

The pattern is essentially the same as in imperative languages; every
allocation should involve a finally clause that deallocates the
resource.

On Tue, Jan 29, 2013 at 2:59 PM, Thiago Negri evoh...@gmail.com wrote:
 Should I put `Control.Exception.finally` on every single line of my
 finalizers?

I'm not sure what you're asking here. If your finally clause tries to
call close, you don't have to catch exceptions raise by close (what
would you do with them anyway).

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mac os x (Intel, 10.6.8) problem compiling yesod-core-1.1.7.1

[Johan Tibell]

Adding Bryan, who wrote this code.

On Mon, Jan 28, 2013 at 1:23 AM, jean-christophe mincke
jeanchristophe.min...@gmail.com wrote:
 Hello

 GHC version : 7.4.2

 When I do a cabal-dev instal yesod-core, I get the following error:

 Loading package blaze-builder-conduit-0.5.0.3 ... linking ... done.
 Loading package hashable-1.2.0.5 ... linking ... ghc:
 lookupSymbol failed in resolveImports
 /Users/V3/windev/Haskell/Z/cabal-dev//lib/HShashable-1.2.0.5.o: unknown
 symbol `_hashable_siphash24_sse2'
 ghc: unable to load package `hashable-1.2.0.5'

 Has anyone encountered the same problem?

 Thank you

 J-C



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Space leaks in function that uses Data.Vector.Mutable

[Johan Tibell]

Hi!

You have to look outside the place function, which is strict enough. I
would look for a call to unsafeWrite that doesn't evaluate it's
argument before writing it into the vector. Perhaps you're doing
something like:

MV.unsafeWrite (i + 1, ...)

Since tuples are lazy the i + 1 will be stored as a thunk. I recommend doing:

data DescriptiveName a = DescriptiveName {-# UNPACK #-} !Int a

and using a

MV.MVector (PrimState m) (DescriptiveName t)

if speed is really of the essence.

Aside: You can't optimize place slightly by:

 * Making it strict in val1, and
 * Making it inline.

The reason you want it to inline* is that's the function is
polymorphic and inlining it at a call site when you know if you're
working in IO and ST will improve performance.

Here's the slightly optimized version:

place :: (PrimMonad m) =
 MV.MVector (PrimState m) (Int, t) - (Int, t) - Int - m ()
place v max@(!val1,_) i = place' i
 where
  place' i = do
let j = i - 1
if j  0
then return ()
else do
  curr@(val2, _) - MV.unsafeRead v j
  if val2  val1
  then do
MV.unsafeWrite v j max
MV.unsafeWrite v i curr
place' j
  else return ()
{-# INLINE place #-}

* It should be enough to write two SPECIALIZE pragmas, one for IO and
one for ST, but GHC doesn't seem to like that for some reason:

/tmp/Test.hs:24:1: Warning:
RULE left-hand side too complicated to desugar
  (place @ (ST s) @ t ($fPrimMonadST @ s ($fMonadST @ s))) `cast` ...

/tmp/Test.hs:25:1: Warning:
RULE left-hand side too complicated to desugar
  (place @ IO @ t $fPrimMonadIO) `cast` ...

Cheers,
Johan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Should ghc -msse imply gcc -msse

[Johan Tibell]

Hi all,

I forgot I once raised this on the GHC bug tracker:
http://hackage.haskell.org/trac/ghc/ticket/7025

Here's what Simon M had to say back then:

The right thing is to put -msse in the cc-options field of your
.cabal file, if that's what you want.

I'm distinctly uneasy about having -msse magically pass through to gcc.

* There are many flags that we do not pass through to gcc, so having
one that we do pass through could be confusing (and lead to lots more
requests for more flags to be passed through)

* What if there is a variant of -msse that gcc supports but we don't?
Wouldn't we have to keep them in sync?

I'm going to close this as wontfix, but please feel free to reopen and
disagree.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Should ghc -msse imply gcc -msse

[Johan Tibell]

On Thu, Jan 17, 2013 at 12:01 PM, Johan Tibell johan.tib...@gmail.com wrote:
 I forgot I once raised this on the GHC bug tracker:
 http://hackage.haskell.org/trac/ghc/ticket/7025

 Here's what Simon M had to say back then:

 The right thing is to put -msse in the cc-options field of your
 .cabal file, if that's what you want.

 I'm distinctly uneasy about having -msse magically pass through to gcc.

 * There are many flags that we do not pass through to gcc, so having
 one that we do pass through could be confusing (and lead to lots more
 requests for more flags to be passed through)

 * What if there is a variant of -msse that gcc supports but we don't?
 Wouldn't we have to keep them in sync?

 I'm going to close this as wontfix, but please feel free to reopen and
 disagree.

One problem with having the user set cc-options in addition to passing
-msse to GHC, is that the user might not realize that he/she needs to
do this. This is bad if you use -fllvm, as your -msse will essentially
just be ignored as the LLVM primitives we use in the LLVM backend
(e.g. for popcnt) won't convert to SSE instructions.

Even worse, LLVM doesn't support a -msse flag, instead you need to use
-mattr=+sse, so the user needs to be aware of this difference and
change his/her flags depending on if we use the native backend or the
LLVM backend.

-- Johan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Should ghc -msse imply gcc -msse

[Johan Tibell]

On Thu, Jan 17, 2013 at 12:29 PM, Simon Marlow marlo...@gmail.com wrote:
 If the intended meaning of -msse is

   Use SSE instructions in Haskell compilations

 then of course we should pass -mattr=+sse to LLVM, because it is the backend
 for Haskell compilations.  But we should not pass it to gcc, unless we're
 using the C backend.

Lets do at least this then.

-- Johan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Johan Tibell]

On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi sanzhi...@gmail.com wrote:
 Have you considered the effect on types like Data.Set that use the
 uniqueness of typeclass instances to maintain invariants? e.g. even when we
 have newtype X = X Y coercing Set X to Set Y can produce a tree with
 the wrong shape for the Ord instance of Y.

I was just going to say that. Changing newtypes changes instances,
which isn't safe in the general case.

-- Johan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Johan Tibell]

On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 Have you considered the effect on types like Data.Set that use the
 uniqueness of typeclass instances to maintain invariants? e.g. even when we
 have newtype X = X Y coercing Set X to Set Y can produce a tree with
 the wrong shape for the Ord instance of Y.



 Good point. I should add this.  The wrapper should only work if the relevant
 data constructors are in scope; rather like GHC’s existing auto-unwrapping
 on foreign calls
 (http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-newtype-io)

I don't follow. Are you saying that adding an import, even if nothing
from that import is used, can effect if the program compiles?

Does that mean if we ever add Data.Map.Internal that exposes the data
constructors to users who know what they're doing (i.e. are willing
to take it upon themselves to maintain the invariants) then code that
used to compile will stop to do so?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Johan Tibell]

On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka r...@ro-che.info wrote:
 * Johan Tibell johan.tib...@gmail.com [2013-01-14 13:32:54-0800]
 On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
 simo...@microsoft.com wrote:
  Have you considered the effect on types like Data.Set that use the
  uniqueness of typeclass instances to maintain invariants? e.g. even when we
  have newtype X = X Y coercing Set X to Set Y can produce a tree with
  the wrong shape for the Ord instance of Y.
 
 
 
  Good point. I should add this.  The wrapper should only work if the 
  relevant
  data constructors are in scope; rather like GHC’s existing auto-unwrapping
  on foreign calls
  (http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-newtype-io)

 I don't follow. Are you saying that adding an import, even if nothing
 from that import is used, can effect if the program compiles?

 Does that mean if we ever add Data.Map.Internal that exposes the data
 constructors to users who know what they're doing (i.e. are willing
 to take it upon themselves to maintain the invariants) then code that
 used to compile will stop to do so?

 Now I don't follow you. Why will it stop compiling?

 If you define wrappers/unwrappers involving Data.Map, then they will
 compile if Data.Map.Internal is imported and will not compile if it isn't.

Let me rephrase: how will Simon's proposed data constructors are in
scope mechanism work? For example, will

let xs :: Map = ...
in map MyNewtype xs

behave differently if the constructors of Map are in scope or not?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users