From eir at cis.upenn.edu  Mon Dec  2 20:00:59 2013
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 2 Dec 2013 15:00:59 -0500
Subject: role signatures in libraries
In-Reply-To: <CAJ727Gh=hOA0oFNsQ7gW2fj_k1Ua5g0yW1YmEDQofG8uF1aT9Q@mail.gmail.com>
References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu>
 <CAJ727Gh=hOA0oFNsQ7gW2fj_k1Ua5g0yW1YmEDQofG8uF1aT9Q@mail.gmail.com>
Message-ID: <B0318AB5-1881-4FCE-B307-C42E48F77093@cis.upenn.edu>

Hi John,

Good questions!

On Nov 27, 2013, at 3:35 PM, John Lato wrote:
> Consider data V a = V Int (ForeignPtr a), a storable vector, where the Int is the number of elements.  We would then want to add 'type role V nominal' as the stored data depends on the Storable instance for the 'a' parameter.  Is this correct?
> 
> 

If you want to be fully safe in the presence of different Storable dictionaries for Age and Int, yes, you should declare `a` to be nominal. However, it's much more likely that Age and Int have the same implementation for Storable, and it might be much more convenient for your users to be able to freely convert between `V Age` and `V Int`. I would say that this is a judgment call -- nominal is safer (always), but representational may be more practical.

Note that this is not an issue of type safety, per se. It's much more an issue of type class coherence across newtypes.

> To me it looks like a next step would be a way to specify that two representationally-equal types share a dictionary, and thus could be considered nominally equal for that dictionary. This would mean if we use newtype MkAge = MkAge Int deriving Storable (via GeneralizedNewtypeDeriving), we could then coerce V Int to V MkAge. We don't currently have a way to do this, correct?
> 
That's correct. Extending the roles mechanism in this direction might be a fruitful future direction, but it's not currently on my docket. I'm happy to advise if someone else wants to take this on!

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131202/55178448/attachment.html>

From acowley at seas.upenn.edu  Mon Dec  2 20:40:52 2013
From: acowley at seas.upenn.edu (Anthony Cowley)
Date: Mon, 2 Dec 2013 15:40:52 -0500
Subject: role signatures in libraries
In-Reply-To: <B0318AB5-1881-4FCE-B307-C42E48F77093@cis.upenn.edu>
References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu>
 <CAJ727Gh=hOA0oFNsQ7gW2fj_k1Ua5g0yW1YmEDQofG8uF1aT9Q@mail.gmail.com>
 <B0318AB5-1881-4FCE-B307-C42E48F77093@cis.upenn.edu>
Message-ID: <CADch-t+V+g3cY5EFHzo=PzK65q7S0T_+n1vu69bgNTafUxvYyw@mail.gmail.com>

On Mon, Dec 2, 2013 at 3:00 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Hi John,
>
> Good questions!
>
> On Nov 27, 2013, at 3:35 PM, John Lato wrote:
>
> Consider data V a = V Int (ForeignPtr a), a storable vector, where the Int
> is the number of elements.  We would then want to add 'type role V nominal'
> as the stored data depends on the Storable instance for the 'a' parameter.
> Is this correct?
>
>
>
> If you want to be fully safe in the presence of different Storable
> dictionaries for Age and Int, yes, you should declare `a` to be nominal.
> However, it's much more likely that Age and Int have the same implementation
> for Storable, and it might be much more convenient for your users to be able
> to freely convert between `V Age` and `V Int`. I would say that this is a
> judgment call -- nominal is safer (always), but representational may be more
> practical.

For the record, I use newtypes to pick out different Storable
instances rather a lot, and would find it awfully inconvenient if
library authors started assuming otherwise.

Anthony

From jwlato at gmail.com  Tue Dec  3 00:04:14 2013
From: jwlato at gmail.com (John Lato)
Date: Mon, 2 Dec 2013 16:04:14 -0800
Subject: role signatures in libraries
In-Reply-To: <B0318AB5-1881-4FCE-B307-C42E48F77093@cis.upenn.edu>
References: <871C45BC-6380-4809-A812-C7E3B82AA69E@cis.upenn.edu>
 <CAJ727Gh=hOA0oFNsQ7gW2fj_k1Ua5g0yW1YmEDQofG8uF1aT9Q@mail.gmail.com>
 <B0318AB5-1881-4FCE-B307-C42E48F77093@cis.upenn.edu>
Message-ID: <CAJ727Ghn_bXEyeYZNbGFA0b0Ka4fdSOP3m_ZsNLy00eqmBg0pQ@mail.gmail.com>

Hi Richard,

Thanks for your response.


On Mon, Dec 2, 2013 at 12:00 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> Hi John,
>
> Good questions!
>
> On Nov 27, 2013, at 3:35 PM, John Lato wrote:
>
> Consider data V a = V Int (ForeignPtr a), a storable vector, where the Int
> is the number of elements.  We would then want to add 'type role V nominal'
> as the stored data depends on the Storable instance for the 'a' parameter.
> Is this correct?
>
>
> If you want to be fully safe in the presence of different Storable
> dictionaries for Age and Int, yes, you should declare `a` to be nominal.
> However, it's much more likely that Age and Int have the same
> implementation for Storable, and it might be much more convenient for your
> users to be able to freely convert between `V Age` and `V Int`. I would say
> that this is a judgment call -- nominal is safer (always), but
> representational may be more practical.
>

Although I can't think of any case where I've changed a Storable instance
across newtypes, Anthony makes use of this feature and others must also.  I
think the best thing to do is to make the best use of roles as we currently
have them, for the most safety we can get.  A no-cost conversion can always
be achieved by unsafeCoerce after all.


>
> Note that this is not an issue of type safety, per se. It's much more an
> issue of type class coherence across newtypes.
>

>
> To me it looks like a next step would be a way to specify that two
> representationally-equal types share a dictionary, and thus could be
> considered nominally equal for that dictionary. This would mean if we use
> newtype MkAge = MkAge Int deriving Storable (via
> GeneralizedNewtypeDeriving), we could then coerce V Int to V MkAge. We
> don't currently have a way to do this, correct?
>
> That's correct. Extending the roles mechanism in this direction might be a
> fruitful future direction, but it's not currently on my docket. I'm happy
> to advise if someone else wants to take this on!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131202/357fe711/attachment.html>

From tkn.akio at gmail.com  Wed Dec  4 10:33:31 2013
From: tkn.akio at gmail.com (Akio Takano)
Date: Wed, 4 Dec 2013 19:33:31 +0900
Subject: Proposal: add fusion RULES for Data.Map.mapMaybe
In-Reply-To: <CAOGQyFs2AD42UtxYhOThRJJYYknPcgtMb9gqWzv_-oWiT=JXcQ@mail.gmail.com>
References: <CAOGQyFs2AD42UtxYhOThRJJYYknPcgtMb9gqWzv_-oWiT=JXcQ@mail.gmail.com>
Message-ID: <CAOGQyFsyZQZcPu48PdDOtrDC7j_0gJeS1nkpk5pKQidp=QEdGw@mail.gmail.com>

The proposal received support from two people, and got no objection, so I
created a ticket for it on the GHC trac.

https://ghc.haskell.org/trac/ghc/ticket/8595

Thank you,
Takano Akio

On Wed, Nov 20, 2013 at 4:40 PM, Akio Takano <tkn.akio at gmail.com> wrote:

> Hi,
>
> Currently mapMaybe does not fuse at all. The attached patch implements
> necessary rules for fold/build fusion in both sides (the result and the
> second argument) to happen. When fusion does not happen, the function
> should behave exactly the same as before.
>
> I ran some benchmarks, testing cases where fusion does and does not happen:
>
>
> http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/out.html
>
> The benchmark code is:
>
> https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs
>
> Discussion period: 2 weeks.
>
> Thank you,
> Takano Akio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131204/09e1532c/attachment.html>

From selinger at mathstat.dal.ca  Sat Dec  7 03:31:51 2013
From: selinger at mathstat.dal.ca (Peter Selinger)
Date: Fri, 6 Dec 2013 23:31:51 -0400 (AST)
Subject: cabal: question on compiling build prerequisites
Message-ID: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>

This may be a silly question, but I can't seem to find the answer in
the documentation.

I would like to create a Cabal package where some of the source files
use a custom pre-processor. The pre-processor is itself a Haskell
program, let's say MyPreProc.hs in the package's root directory.

I figured out how to activate the preprocessor, for example,

cabal build --ghc-options="-F -pgmF ./MyPreProc"

I also figured out how to achieve the same effect using hooks.

However, there is one problem: how can I tell cabal to actually
compile MyPreProc.hs before any of the commands using the preprocessor
are run? The package's Setup.hs file is automatically compiled during
"cabal configure". I would like MyPreProc.hs to be compiled at the
same time as well - or at least some time before the proprocessor
needs to be used.

The .cabal file contains all kinds of related variables, such as
"build-depends" (but only packages can be listed here, not programs to
be compiled), "other-modules" (but these modules would already require
the pre-processor, so the pre-processor should be compiled first),
"build-tools" (but this only refers to external programs).

My current solution is to make the pre-processor a shell script,
rather than a Haskell program. But this is ugly and not portable
(won't work in Windows, for example). 

To clarify: my custom preprocessor is local to this package. It has no
independent value, so it would not make sense to publish it as a
separate package just so that I can add it to build-depends.

Is there a known solution to this problem? 

Thanks, -- Peter

From lemming at henning-thielemann.de  Sat Dec  7 11:52:51 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 07 Dec 2013 12:52:51 +0100 (CET)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
Message-ID: <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>


On Fri, 6 Dec 2013, Peter Selinger wrote:

> My current solution is to make the pre-processor a shell script,
> rather than a Haskell program. But this is ugly and not portable
> (won't work in Windows, for example).
>
> To clarify: my custom preprocessor is local to this package. It has no
> independent value, so it would not make sense to publish it as a
> separate package just so that I can add it to build-depends.
>
> Is there a known solution to this problem?

I have not tried this solution but I would guess that it is a good idea to 
put the preprocessor in a separate package anyway, since it might have its 
own build-depends.

From selinger at mathstat.dal.ca  Sat Dec  7 14:17:58 2013
From: selinger at mathstat.dal.ca (Peter Selinger)
Date: Sat, 7 Dec 2013 10:17:58 -0400 (AST)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
Message-ID: <20131207141758.3FF228C017E@chase.mathstat.dal.ca>

Thanks for your reply!

The preprocessor is essentially a 20-line Haskell program depending on
Prelude. It's similar to the kind of ad-hoc programs that one might
use within the "test" and "benchmark" targets.  So putting it in a
separate package would be overkill, I think.

I wonder if I can somehow run the compiler from a post-configure
hook. Hm. Looks like I would have to call
Distribution.Simple.Build.buildExe with some magic arguments, to
invoke the compiler. Maybe I will keep experimenting. If there's a
better solution, please let me know! 

Thanks, -- Peter

Henning Thielemann wrote:
> 
> 
> On Fri, 6 Dec 2013, Peter Selinger wrote:
> 
> > My current solution is to make the pre-processor a shell script,
> > rather than a Haskell program. But this is ugly and not portable
> > (won't work in Windows, for example).
> >
> > To clarify: my custom preprocessor is local to this package. It has no
> > independent value, so it would not make sense to publish it as a
> > separate package just so that I can add it to build-depends.
> >
> > Is there a known solution to this problem?
> 
> I have not tried this solution but I would guess that it is a good idea to 
> put the preprocessor in a separate package anyway, since it might have its 
> own build-depends.
> 


From lemming at henning-thielemann.de  Sat Dec  7 15:05:04 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 07 Dec 2013 16:05:04 +0100 (CET)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <20131207141758.3FF228C017E@chase.mathstat.dal.ca>
References: <20131207141758.3FF228C017E@chase.mathstat.dal.ca>
Message-ID: <alpine.DEB.2.00.1312071600100.20239@anubis.informatik.uni-halle.de>


On Sat, 7 Dec 2013, Peter Selinger wrote:

> The preprocessor is essentially a 20-line Haskell program depending on
> Prelude. It's similar to the kind of ad-hoc programs that one might
> use within the "test" and "benchmark" targets.  So putting it in a
> separate package would be overkill, I think.

Maybe it can be done without a preprocessor? In this case the discussion 
would better fit to haskell-cafe. For Cabal discussions there is also
   http://www.haskell.org/mailman/listinfo/cabal-devel

From jimenezrick at gmail.com  Sat Dec  7 19:20:28 2013
From: jimenezrick at gmail.com (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=)
Date: Sat, 7 Dec 2013 19:20:28 +0000
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
Message-ID: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>

Hi,

Please review this pull request:
https://github.com/jimenezrick/unix/compare/master...file-utils.patch

If you find interesting this patch, then:
git pull https://github.com/jimenezrick/unix.git file-utils

/Ricardo

From ben.franksen at online.de  Sun Dec  8 01:06:26 2013
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 08 Dec 2013 02:06:26 +0100
Subject: Proposal: add $> to Data.Functor
Message-ID: <l80gm4$hgj$1@ger.gmane.org>

Data.Functor has <$> and <$, but not $>, which should be a flipped version 
of <$, analogous to <*>, <*, and *> in Control.Applicative. I was astonished 
to see that Data.Functor doesn't have it so I had to write it myself. Then I 
looked on hackage and found it defined in comonad package (also re-exported 
from semigroupoids). One (seemingly unmaintained, last version Apr 2012) 
package named iterIO has it, too.

infixl 4 $>
-- | Replace the contents of a functor uniformly with a constant value.
($>) :: Functor f => f b -> a -> f a
($>) = flip (<$)

I propose to add this to Data.Functor; mostly because I think users expect 
it there (again by analogy with Applicative), even though it is trivial to 
write (but then writing <$ is trivial, too).

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams



From hvr at gnu.org  Sun Dec  8 08:17:06 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 08 Dec 2013 09:17:06 +0100
Subject: Proposal: add $> to Data.Functor
In-Reply-To: <l80gm4$hgj$1@ger.gmane.org> (Ben Franksen's message of "Sun, 08
 Dec 2013 02:06:26 +0100")
References: <l80gm4$hgj$1@ger.gmane.org>
Message-ID: <87txeju58d.fsf@gnu.org>

On 2013-12-08 at 02:06:26 +0100, Ben Franksen wrote:
> Data.Functor has <$> and <$, but not $>, which should be a flipped version 
> of <$, analogous to <*>, <*, and *> in Control.Applicative. I was astonished 
> to see that Data.Functor doesn't have it so I had to write it myself. Then I 
> looked on hackage and found it defined in comonad package (also re-exported 
> from semigroupoids). One (seemingly unmaintained, last version Apr 2012) 
> package named iterIO has it, too.
>
> infixl 4 $>
> -- | Replace the contents of a functor uniformly with a constant value.
> ($>) :: Functor f => f b -> a -> f a
> ($>) = flip (<$)
>
> I propose to add this to Data.Functor; mostly because I think users expect 
> it there (again by analogy with Applicative), even though it is trivial to 
> write (but then writing <$ is trivial, too).

fyi, this has been suggested a few months ago as part of

  http://comments.gmane.org/gmane.comp.lang.haskell.libraries/18952

and as a matter of fact has been already implemented in base-4.7.0.0:

  https://github.com/ghc/packages-base/blob/master/Data/Functor.hs#L36-L40

Cheers,
  hvr

From rhymoid at gmail.com  Sun Dec  8 17:22:32 2013
From: rhymoid at gmail.com (Stijn van Drongelen)
Date: Sun, 8 Dec 2013 18:22:32 +0100
Subject: Proposal: add $> to Data.Functor
In-Reply-To: <87txeju58d.fsf@gnu.org>
References: <l80gm4$hgj$1@ger.gmane.org> <87txeju58d.fsf@gnu.org>
Message-ID: <CAGg6Gc6wxfDZXw6-e3wKQu39crqgBb6J2Md21t4q9z8thdrjVQ@mail.gmail.com>

> Data.Functor has <$> and <$, but not $>, which should be a flipped version
> of <$, analogous to <*>, <*, and *> in Control.Applicative.

Whoa there, it's not at all analogous. Your wording is almost suggesting
that <* is a flipped *>, but beyond that, they are uncomparable to begin
with.

Applicative functors:

    (<*>) :: Applicative f => f (a -> b) -> f a -> f b
    (<*)  :: Applicative f => f a -> f b -> f a
    (*>)  :: Applicative f => f a -> f b -> f b

Removing the `f` in the first position, you'd get an honest analogue for
any functor:

    (<$>) :: Functor f => (a -> b) -> f a -> f b
    (<$)  :: Functor f => a -> f b -> f a
    ($>)  :: Functor f => a -> f b -> f b

Here, I don't see how ($>) could be anything else than `const id`.

Or am I missing something here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131208/dae65da0/attachment.html>

From danburton.email at gmail.com  Sun Dec  8 19:12:50 2013
From: danburton.email at gmail.com (Dan Burton)
Date: Sun, 8 Dec 2013 11:12:50 -0800
Subject: Proposal: add $> to Data.Functor
In-Reply-To: <CAGg6Gc6wxfDZXw6-e3wKQu39crqgBb6J2Md21t4q9z8thdrjVQ@mail.gmail.com>
References: <l80gm4$hgj$1@ger.gmane.org> <87txeju58d.fsf@gnu.org>
 <CAGg6Gc6wxfDZXw6-e3wKQu39crqgBb6J2Md21t4q9z8thdrjVQ@mail.gmail.com>
Message-ID: <CALSygwcXpmri1Di+8uKjR4Ax8ng3dBeY5KCrFC-wg8gqL9pVew@mail.gmail.com>

($>) is analogous to (*>) not by dropping the f in the first position, but
the f in the second, as proposed.

(*>) :: Applicative f => f a -> f b -> f b
($>) :: Functor f     => f a ->   b -> f b

It is unfortunate that (*>) is not equivalent to (flip (<*)), but it is a
special case where breaking the "flipped characters" convention is useful
for the sake of Applicative's convention to gather effects from left to
right. It is nice that ($>) adheres to the flipped characters convention as
well as being analogous to (*>).

-- Dan Burton


On Sun, Dec 8, 2013 at 9:22 AM, Stijn van Drongelen <rhymoid at gmail.com>wrote:

> > Data.Functor has <$> and <$, but not $>, which should be a flipped
> version
> > of <$, analogous to <*>, <*, and *> in Control.Applicative.
>
> Whoa there, it's not at all analogous. Your wording is almost suggesting
> that <* is a flipped *>, but beyond that, they are uncomparable to begin
> with.
>
> Applicative functors:
>
>     (<*>) :: Applicative f => f (a -> b) -> f a -> f b
>     (<*)  :: Applicative f => f a -> f b -> f a
>     (*>)  :: Applicative f => f a -> f b -> f b
>
> Removing the `f` in the first position, you'd get an honest analogue for
> any functor:
>
>     (<$>) :: Functor f => (a -> b) -> f a -> f b
>     (<$)  :: Functor f => a -> f b -> f a
>     ($>)  :: Functor f => a -> f b -> f b
>
> Here, I don't see how ($>) could be anything else than `const id`.
>
> Or am I missing something here?
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131208/53e612c2/attachment.html>

From johnw at fpcomplete.com  Sun Dec  8 20:57:17 2013
From: johnw at fpcomplete.com (John Wiegley)
Date: Sun, 08 Dec 2013 14:57:17 -0600
Subject: Proposal: add $> to Data.Functor
In-Reply-To: <l80gm4$hgj$1@ger.gmane.org> (Ben Franksen's message of "Sun, 08
 Dec 2013 02:06:26 +0100")
References: <l80gm4$hgj$1@ger.gmane.org>
Message-ID: <m2mwkb6oya.fsf@newartisans.com>

>>>>> Ben Franksen <ben.franksen at online.de> writes:

> I propose to add this to Data.Functor; mostly because I think users expect
> it there (again by analogy with Applicative), even though it is trivial to
> write (but then writing <$ is trivial, too).

+1

John

From ben.franksen at online.de  Sun Dec  8 21:05:04 2013
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 08 Dec 2013 22:05:04 +0100
Subject: Proposal: add $> to Data.Functor
References: <l80gm4$hgj$1@ger.gmane.org> <87txeju58d.fsf@gnu.org>
Message-ID: <l82mtj$628$1@ger.gmane.org>

Herbert Valerio Riedel wrote:
> On 2013-12-08 at 02:06:26 +0100, Ben Franksen wrote:
>> Data.Functor has <$> and <$, but not $>, which should be a flipped
>> version of <$, analogous to <*>, <*, and *> in Control.Applicative. I was
>> astonished to see that Data.Functor doesn't have it so I had to write it
>> myself. Then I looked on hackage and found it defined in comonad package
>> (also re-exported from semigroupoids). One (seemingly unmaintained, last
>> version Apr 2012) package named iterIO has it, too.
>>
>> infixl 4 $>
>> -- | Replace the contents of a functor uniformly with a constant value.
>> ($>) :: Functor f => f b -> a -> f a
>> ($>) = flip (<$)
>>
>> I propose to add this to Data.Functor; mostly because I think users
>> expect it there (again by analogy with Applicative), even though it is
>> trivial to write (but then writing <$ is trivial, too).
> 
> fyi, this has been suggested a few months ago as part of
> 
>   http://comments.gmane.org/gmane.comp.lang.haskell.libraries/18952
> 
> and as a matter of fact has been already implemented in base-4.7.0.0:
> 
>   https://github.com/ghc/packages-base/blob/master/Data/Functor.hs#L36-L40

Thanks, I'm glad the proposal has been obsoleted in this way. Count it as a 
+1 after the fact ;-)

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams



From svenpanne at gmail.com  Mon Dec  9 09:29:17 2013
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 9 Dec 2013 10:29:17 +0100
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
Message-ID: <CANBN=mv_-eM88OEsS_E1yUwyB8rkcmvu+MzkN4UPW_PiJ2FQZw@mail.gmail.com>

2013/12/7 Henning Thielemann <lemming at henning-thielemann.de>:
> I have not tried this solution but I would guess that it is a good idea to
> put the preprocessor in a separate package anyway, since it might have its
> own build-depends.

I thought about a similar scenario recently, and I would like to hear
if there is a clean cabal solution for this, too. Ripping out a helper
program which has only a single use case (support for the "real"
package) and which totally has to stay in sync with that "real"
package would not be very nice. It would just be an artifact of a
(missing?) cabal feature.

Note that e.g. Template Haskell is not a solution for all needs
(portability, XML=>Haskell translations, etc.), so support for some
preprocessing step would be nice.

From lemming at henning-thielemann.de  Mon Dec  9 10:00:49 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 09 Dec 2013 11:00:49 +0100 (CET)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <CANBN=mv_-eM88OEsS_E1yUwyB8rkcmvu+MzkN4UPW_PiJ2FQZw@mail.gmail.com>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
 <CANBN=mv_-eM88OEsS_E1yUwyB8rkcmvu+MzkN4UPW_PiJ2FQZw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1312091058390.23694@anubis.informatik.uni-halle.de>


On Mon, 9 Dec 2013, Sven Panne wrote:

> I thought about a similar scenario recently, and I would like to hear
> if there is a clean cabal solution for this, too. Ripping out a helper
> program which has only a single use case (support for the "real"
> package) and which totally has to stay in sync with that "real"
> package would not be very nice. It would just be an artifact of a
> (missing?) cabal feature.

The question is, how far should this feature reach? What if the 
preprocessor needs a preprocessor itself? E.g. a preprocessor might be 
built using a parser generator, then you need this parser generator as 
build-tool for the preprocessor build-tool.

From spam at scientician.net  Mon Dec  9 10:27:33 2013
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 09 Dec 2013 11:27:33 +0100
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <alpine.DEB.2.00.1312091058390.23694@anubis.informatik.uni-halle.de>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
 <CANBN=mv_-eM88OEsS_E1yUwyB8rkcmvu+MzkN4UPW_PiJ2FQZw@mail.gmail.com>
 <alpine.DEB.2.00.1312091058390.23694@anubis.informatik.uni-halle.de>
Message-ID: <l845ua$kve$1@ger.gmane.org>

On 2013-12-09 11:00, Henning Thielemann wrote:
> 
> On Mon, 9 Dec 2013, Sven Panne wrote:
> 
>> I thought about a similar scenario recently, and I would like to hear
>> if there is a clean cabal solution for this, too. Ripping out a helper
>> program which has only a single use case (support for the "real"
>> package) and which totally has to stay in sync with that "real"
>> package would not be very nice. It would just be an artifact of a
>> (missing?) cabal feature.
> 
> The question is, how far should this feature reach? What if the
> preprocessor needs a preprocessor itself? E.g. a preprocessor might be
> built using a parser generator, then you need this parser generator as
> build-tool for the preprocessor build-tool.

This just means that the build-tool definition should allow for
recursion, I think. In fact, at least one build system that I know of
supports this in a very general way via recursive project definitions.

(The tool is the somewhat inaccurately named Simple Build Tool/SBT, but
the non-simple nature of it doesn't have anything in particular to do
with this feature.)

Regards,


From Christian.Maeder at dfki.de  Mon Dec  9 14:49:28 2013
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Mon, 09 Dec 2013 15:49:28 +0100
Subject: text, warp and blaze-builder
Message-ID: <52A5D878.1030807@dfki.de>

Hi,

with the new version 1.0.0.0 of text I have a problem to use warp
that indirectly (via blaze-builder) relies on text-0.11.3.1

I do:

import qualified Data.Text as T

and get:

     Couldn't match type `text-0.11.3.1:Data.Text.Internal.Text'
                   with `T.Text'
     Expected type: [T.Text]
       Actual type: [text-0.11.3.1:Data.Text.Internal.Text]


How is this best fixed?

Cheers Christian

Part of "ghc-pkg list" shows:

    text-0.11.3.1
    text-1.0.0.0

From johan.tibell at gmail.com  Mon Dec  9 15:19:27 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 9 Dec 2013 16:19:27 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <52A5D878.1030807@dfki.de>
References: <52A5D878.1030807@dfki.de>
Message-ID: <CAK-tuPbGJvU7YxLQDG=k3x2gD3iBGW-rPXHZAu5hwKVoregf6g@mail.gmail.com>

On Mon, Dec 9, 2013 at 3:49 PM, Christian Maeder
<Christian.Maeder at dfki.de>wrote:

>     Couldn't match type `text-0.11.3.1:Data.Text.Internal.Text'
>                   with `T.Text'
>     Expected type: [T.Text]
>       Actual type: [text-0.11.3.1:Data.Text.Internal.Text]
>

You typically get these errors when you try to use two versions of a
package at the same time. Are you building with cabal? If so it should have
warned you about that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131209/6cbbb833/attachment.html>

From Christian.Maeder at dfki.de  Mon Dec  9 16:20:41 2013
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Mon, 09 Dec 2013 17:20:41 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <CAK-tuPbGJvU7YxLQDG=k3x2gD3iBGW-rPXHZAu5hwKVoregf6g@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <CAK-tuPbGJvU7YxLQDG=k3x2gD3iBGW-rPXHZAu5hwKVoregf6g@mail.gmail.com>
Message-ID: <52A5EDD9.7080506@dfki.de>

Am 09.12.2013 16:19, schrieb Johan Tibell:
> On Mon, Dec 9, 2013 at 3:49 PM, Christian Maeder
> <Christian.Maeder at dfki.de <mailto:Christian.Maeder at dfki.de>> wrote:
>
>          Couldn't match type `text-0.11.3.1:Data.Text.__Internal.Text'
>                        with `T.Text'
>          Expected type: [T.Text]
>            Actual type: [text-0.11.3.1:Data.Text.__Internal.Text]
>
>
> You typically get these errors when you try to use two versions of a
> package at the same time. Are you building with cabal? If so it should
> have warned you about that.

no, I just call "ghc --make ..."

When I add "-hide-package text-1.0.0.0" to the command line, then 
compilation goes through, but linking fails.

Obviously, having two versions is bad. Maybe I should install the old 
text version explicitly first and reinstall all other packages.

Or I wait until warp can work with text-1.0.0.0, too.

C.

/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): 
In function `_hs_text_memcpy':
cbits.c:(.text+0x0): multiple definition of `_hs_text_memcpy'
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x0): 
first defined here
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): 
In function `_hs_text_memcmp':
cbits.c:(.text+0x30): multiple definition of `_hs_text_memcmp'
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x30): 
first defined here
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): 
In function `_hs_text_decode_latin1':
cbits.c:(.text+0x60): multiple definition of `_hs_text_decode_latin1'
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x60): 
first defined here
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-1.0.0.0/libHStext-1.0.0.0.a(cbits.o): 
In function `_hs_text_decode_utf8':
cbits.c:(.text+0x2b0): multiple definition of `_hs_text_decode_utf8'
/home/linux-bkb/ghc/ghc-7.6.3/lib/i386-linux-ghc-7.6.3/text-0.11.3.1/libHStext-0.11.3.1.a(cbits.o):cbits.c:(.text+0x110): 
first defined here
collect2: error: ld returned 1 exit status


From lemming at henning-thielemann.de  Mon Dec  9 16:25:06 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 09 Dec 2013 17:25:06 +0100 (CET)
Subject: text, warp and blaze-builder
In-Reply-To: <52A5EDD9.7080506@dfki.de>
References: <52A5D878.1030807@dfki.de>
 <CAK-tuPbGJvU7YxLQDG=k3x2gD3iBGW-rPXHZAu5hwKVoregf6g@mail.gmail.com>
 <52A5EDD9.7080506@dfki.de>
Message-ID: <alpine.DEB.2.00.1312091723180.16170@anubis.informatik.uni-halle.de>


On Mon, 9 Dec 2013, Christian Maeder wrote:

> Am 09.12.2013 16:19, schrieb Johan Tibell:

>> You typically get these errors when you try to use two versions of a
>> package at the same time. Are you building with cabal? If so it should
>> have warned you about that.
>
> no, I just call "ghc --make ..."
>
> When I add "-hide-package text-1.0.0.0" to the command line, then compilation 
> goes through, but linking fails.
>
> Obviously, having two versions is bad. Maybe I should install the old text 
> version explicitly first and reinstall all other packages.

Cabal assists with that problem. You may run

   cabal install --reinstall --constraint="text==1.0.0.0"

From nominolo at googlemail.com  Mon Dec  9 17:49:36 2013
From: nominolo at googlemail.com (Thomas Schilling)
Date: Mon, 9 Dec 2013 18:49:36 +0100
Subject: Performance bug in HTTP library affecting "cabal update"
Message-ID: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>

Hi Ganesh and Mark,

I just sent a pull request to the HTTP library [1] that dramatically
improves the performance of "cabal update" (80s -> 8s on my machine).
It would be nice if we could make a new release soon and compile the
next Platform's "cabal-install" against it.

Mark, any concerns?

[1]: https://github.com/haskell/HTTP/pull/48

From chrisdone at gmail.com  Mon Dec  9 18:08:27 2013
From: chrisdone at gmail.com (Christopher Done)
Date: Mon, 9 Dec 2013 19:08:27 +0100
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
Message-ID: <CAAJHNPAvg2cLzRfaH-eZLU_ysQwxFRTAYUZVLiaw3k27sDuMMw@mail.gmail.com>

Woo! cabal update is always so slow for me.


On 9 December 2013 18:49, Thomas Schilling <nominolo at googlemail.com> wrote:

> Hi Ganesh and Mark,
>
> I just sent a pull request to the HTTP library [1] that dramatically
> improves the performance of "cabal update" (80s -> 8s on my machine).
> It would be nice if we could make a new release soon and compile the
> next Platform's "cabal-install" against it.
>
> Mark, any concerns?
>
> [1]: https://github.com/haskell/HTTP/pull/48
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131209/45b5a383/attachment.html>

From lemming at henning-thielemann.de  Mon Dec  9 18:14:59 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 09 Dec 2013 19:14:59 +0100 (CET)
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <CAAJHNPAvg2cLzRfaH-eZLU_ysQwxFRTAYUZVLiaw3k27sDuMMw@mail.gmail.com>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
 <CAAJHNPAvg2cLzRfaH-eZLU_ysQwxFRTAYUZVLiaw3k27sDuMMw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1312091912120.16170@anubis.informatik.uni-halle.de>


On Mon, 9 Dec 2013, Christopher Done wrote:

> Woo! cabal update is always so slow for me.

Me too. And it takes a lot of space. Is there a reason why the unpacked 
00-index.tar is stored? It requires currently 110MB, while the gzipped 
version requires only 6MB. Sorry, offtopic.

From ekmett at gmail.com  Mon Dec  9 19:29:53 2013
From: ekmett at gmail.com (Edward A Kmett)
Date: Mon, 9 Dec 2013 14:29:53 -0500
Subject: text, warp and blaze-builder
In-Reply-To: <52A5D878.1030807@dfki.de>
References: <52A5D878.1030807@dfki.de>
Message-ID: <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>

At last check blaze-builder hadn't updated its text dependency though stuff built on top of it has. I opened an issue with the repo about it as this is currently blocking the updated release of trifecta.

Sent from my iPhone

> On Dec 9, 2013, at 9:49 AM, Christian Maeder <Christian.Maeder at dfki.de> wrote:
> 
> Hi,
> 
> with the new version 1.0.0.0 of text I have a problem to use warp
> that indirectly (via blaze-builder) relies on text-0.11.3.1
> 
> I do:
> 
> import qualified Data.Text as T
> 
> and get:
> 
>    Couldn't match type `text-0.11.3.1:Data.Text.Internal.Text'
>                  with `T.Text'
>    Expected type: [T.Text]
>      Actual type: [text-0.11.3.1:Data.Text.Internal.Text]
> 
> 
> How is this best fixed?
> 
> Cheers Christian
> 
> Part of "ghc-pkg list" shows:
> 
>   text-0.11.3.1
>   text-1.0.0.0
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From the.dead.shall.rise at gmail.com  Mon Dec  9 19:53:48 2013
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 9 Dec 2013 20:53:48 +0100
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
Message-ID: <CA+tcxkC05Fvb2KdFWdYxOuNchEDhpZnKZ3_Zde3AtWBkWXwa9Q@mail.gmail.com>

On Mon, Dec 9, 2013 at 6:49 PM, Thomas Schilling
<nominolo at googlemail.com> wrote:
> Hi Ganesh and Mark,
>
> I just sent a pull request to the HTTP library [1] that dramatically
> improves the performance of "cabal update" (80s -> 8s on my machine).
> It would be nice if we could make a new release soon and compile the
> next Platform's "cabal-install" against it.

+1, this would be nice. Thank you for fixing this, Thomas.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From ganesh at earth.li  Mon Dec  9 20:13:47 2013
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Mon, 09 Dec 2013 20:13:47 +0000
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
Message-ID: <52A6247B.40700@earth.li>

On 09/12/2013 17:49, Thomas Schilling wrote:

> I just sent a pull request to the HTTP library [1] that dramatically
> improves the performance of "cabal update" (80s -> 8s on my machine).
> It would be nice if we could make a new release soon and compile the
> next Platform's "cabal-install" against it.
> 
> Mark, any concerns?

Nice catch! I've uploaded 4000.2.10 with your fix (and no other changes
from 4000.2.9, which itself only has dependency changes since 4000.2.8).

I'm fine with this going into the upcoming HP release, but I don't have
a strong opinion either way myself.

It is a code change perhaps quite late in the day, albeit a small one
with significant benefits; it's not fixing an out and out regression but
on the other hand the problem is likely getting worse over time as the
hackage index gets larger.

Cheers,

Ganesh

From nominolo at googlemail.com  Mon Dec  9 20:27:07 2013
From: nominolo at googlemail.com (Thomas Schilling)
Date: Mon, 9 Dec 2013 21:27:07 +0100
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <52A6247B.40700@earth.li>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
 <52A6247B.40700@earth.li>
Message-ID: <CAOJG3uBBED20L7zY3iYHTN2xFn29wFdCdaZ7C=dqPMFDioe7Nw@mail.gmail.com>

Thanks for the quick response and the new release, Ganesh.

On 9 December 2013 21:13, Ganesh Sittampalam <ganesh at earth.li> wrote:
> On 09/12/2013 17:49, Thomas Schilling wrote:
>
>> I just sent a pull request to the HTTP library [1] that dramatically
>> improves the performance of "cabal update" (80s -> 8s on my machine).
>> It would be nice if we could make a new release soon and compile the
>> next Platform's "cabal-install" against it.
>>
>> Mark, any concerns?
>
> Nice catch! I've uploaded 4000.2.10 with your fix (and no other changes
> from 4000.2.9, which itself only has dependency changes since 4000.2.8).
>
> I'm fine with this going into the upcoming HP release, but I don't have
> a strong opinion either way myself.
>
> It is a code change perhaps quite late in the day, albeit a small one
> with significant benefits; it's not fixing an out and out regression but
> on the other hand the problem is likely getting worse over time as the
> hackage index gets larger.
>
> Cheers,
>
> Ganesh

From bos at serpentine.com  Mon Dec  9 20:28:32 2013
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon, 9 Dec 2013 12:28:32 -0800
Subject: text, warp and blaze-builder
In-Reply-To: <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
Message-ID: <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>

On Mon, Dec 9, 2013 at 11:29 AM, Edward A Kmett <ekmett at gmail.com> wrote:

> At last check blaze-builder hadn't updated its text dependency though
> stuff built on top of it has. I opened an issue with the repo about it as
> this is currently blocking the updated release of trifecta.
>

There will be a 1.1 release of text in a matter of weeks, which leaves the
public API unchanged, but exposes all the hitherto hidden internal modules.

Everyone who removes their upper bounds on the version of text gets a pony.
Everyone who widens their upper bounds to allow 1.1 gets a photo of a pony.
Everyone who widens, but only to 1.0, gets some postprocessed pony food.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131209/ceb333de/attachment.html>

From hesselink at gmail.com  Mon Dec  9 20:38:28 2013
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 9 Dec 2013 21:38:28 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
Message-ID: <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>

On Mon, Dec 9, 2013 at 9:28 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> There will be a 1.1 release of text in a matter of weeks, which leaves the
> public API unchanged, but exposes all the hitherto hidden internal modules.

Why make this a major bump? If it only exposes new things, it should
only have to be a minor bump, right?

Also, I've already said this elsewhere before, but all package
breakages I've had in the past year have been due to missing upper
bounds, also on stable things like 'text' or 'base'. Removing an upper
bound saves one developer work at the expense of many users. Friends
don't let friends remove upper bounds.

Erik

From lemming at henning-thielemann.de  Mon Dec  9 21:02:32 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 09 Dec 2013 22:02:32 +0100 (CET)
Subject: text, warp and blaze-builder
In-Reply-To: <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1312092201170.16170@anubis.informatik.uni-halle.de>


On Mon, 9 Dec 2013, Erik Hesselink wrote:

> Also, I've already said this elsewhere before, but all package
> breakages I've had in the past year have been due to missing upper
> bounds, also on stable things like 'text' or 'base'. Removing an upper
> bound saves one developer work at the expense of many users. Friends
> don't let friends remove upper bounds.

full ack

From voldermort at hotmail.com  Tue Dec 10 08:20:19 2013
From: voldermort at hotmail.com (harry)
Date: Tue, 10 Dec 2013 00:20:19 -0800 (PST)
Subject: text, warp and blaze-builder
In-Reply-To: <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
Message-ID: <1386663619749-5740929.post@n5.nabble.com>

Erik Hesselink wrote
> Why make this a major bump? If it only exposes new things, it should
> only have to be a minor bump, right?

I just had a build break because a module I was importing exposed a new
function that clashed with an existing function from a different module.
Should potential build-breakers be a minor bump?



--
View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5740929.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From nicolas.wu at gmail.com  Tue Dec 10 08:25:51 2013
From: nicolas.wu at gmail.com (Nicolas Wu)
Date: Tue, 10 Dec 2013 08:25:51 +0000
Subject: Performance bug in HTTP library affecting "cabal update"
In-Reply-To: <52A6247B.40700@earth.li>
References: <CAOJG3uC3zRTh5+DZxWMuFqVfN0zkKDkicHvfjpqg9qJUJAGfFA@mail.gmail.com>
 <52A6247B.40700@earth.li>
Message-ID: <CAFBp9RnK-7Z9+jA_N+5oo7C0h93Tso2-DC5hJ-YX0TS7BXxPCw@mail.gmail.com>

On Mon, Dec 9, 2013 at 8:13 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:
> Nice catch! I've uploaded 4000.2.10 with your fix (and no other changes
> from 4000.2.9, which itself only has dependency changes since 4000.2.8).
>
> I'm fine with this going into the upcoming HP release, but I don't have
> a strong opinion either way myself.
>
> It is a code change perhaps quite late in the day, albeit a small one
> with significant benefits; it's not fixing an out and out regression but
> on the other hand the problem is likely getting worse over time as the
> hackage index gets larger.

Nice catch indeed! The fix seems straight-forward and has pretty
important consequences. I think it would be worth pushing this into
the HP release if we can.

From svenpanne at gmail.com  Tue Dec 10 09:05:12 2013
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 10 Dec 2013 10:05:12 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <1386663619749-5740929.post@n5.nabble.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
Message-ID: <CANBN=mvqg7meSYQ9DTwyV-72jHAM5e514Ze0H=BfiOCJ5KJ28Q@mail.gmail.com>

2013/12/10 harry <voldermort at hotmail.com>:
> I just had a build break because a module I was importing exposed a new
> function that clashed with an existing function from a different module.
> Should potential build-breakers be a minor bump?

In this case, yes:
http://www.haskell.org/haskellwiki/Package_versioning_policy#Version_numbers

I think the rational is: If you carefully and explictly import only
the things you need, the new version won't break your build. Importing
whole modules can of course break your build when new entities have
been added to the imported module, but this could be avoided by being
less lazy and more explicit. ;-) Changing e.g. a signature or removing
stuff OTOH will break some builds in ways which can't be anticipated.

From Christian.Maeder at dfki.de  Tue Dec 10 10:16:35 2013
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Tue, 10 Dec 2013 11:16:35 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <52A5D878.1030807@dfki.de>
References: <52A5D878.1030807@dfki.de>
Message-ID: <52A6EA03.4020302@dfki.de>

With the new blaze-builder-0.3.3.2 version all works fine (after a 
complete reinstallation).

Thanks Christian

Am 09.12.2013 15:49, schrieb Christian Maeder:
> Hi,
>
> with the new version 1.0.0.0 of text I have a problem to use warp
> that indirectly (via blaze-builder) relies on text-0.11.3.1
>
> I do:
>
> import qualified Data.Text as T
>
> and get:
>
>      Couldn't match type `text-0.11.3.1:Data.Text.Internal.Text'
>                    with `T.Text'
>      Expected type: [T.Text]
>        Actual type: [text-0.11.3.1:Data.Text.Internal.Text]
>
>
> How is this best fixed?
>
> Cheers Christian
>
> Part of "ghc-pkg list" shows:
>
>     text-0.11.3.1
>     text-1.0.0.0

From voldermort at hotmail.com  Tue Dec 10 12:44:37 2013
From: voldermort at hotmail.com (harry)
Date: Tue, 10 Dec 2013 04:44:37 -0800 (PST)
Subject: cabal-install and local path disclosure
Message-ID: <1386679477345-5740940.post@n5.nabble.com>

When compiling cabal-install, some paths on my system are hard-coded in the
executable. Is it possible to avoid this?

My use case is a CI server that's compiling cabal-install, then deploying it
to less privileged servers which shouldn't know anything about the CI
server.



--
View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-and-local-path-disclosure-tp5740940.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From roma at ro-che.info  Tue Dec 10 13:08:42 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 10 Dec 2013 15:08:42 +0200
Subject: cabal-install and local path disclosure
In-Reply-To: <1386679477345-5740940.post@n5.nabble.com>
References: <1386679477345-5740940.post@n5.nabble.com>
Message-ID: <20131210130842.GA14164@sniper>

* harry <voldermort at hotmail.com> [2013-12-10 04:44:37-0800]
> When compiling cabal-install, some paths on my system are hard-coded in the
> executable. Is it possible to avoid this?
> 
> My use case is a CI server that's compiling cabal-install, then deploying it
> to less privileged servers which shouldn't know anything about the CI
> server.

Hi harry,

This mailing list is for discussions about the core Haskell libraries.

You should file an issue at the cabal's issue tracker instead:
https://github.com/haskell/cabal/issues

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131210/b02c12cc/attachment.sig>

From voldermort at hotmail.com  Tue Dec 10 14:36:50 2013
From: voldermort at hotmail.com (harry)
Date: Tue, 10 Dec 2013 06:36:50 -0800 (PST)
Subject: text, warp and blaze-builder
In-Reply-To: <CANBN=mvqg7meSYQ9DTwyV-72jHAM5e514Ze0H=BfiOCJ5KJ28Q@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
 <CANBN=mvqg7meSYQ9DTwyV-72jHAM5e514Ze0H=BfiOCJ5KJ28Q@mail.gmail.com>
Message-ID: <1386686210296-5740946.post@n5.nabble.com>

Sven Panne-2 wrote
> I think the rational is: If you carefully and explictly import only
> the things you need, the new version won't break your build. Importing
> whole modules can of course break your build when new entities have
> been added to the imported module, but this could be avoided by being
> less lazy and more explicit. ;-) Changing e.g. a signature or removing
> stuff OTOH will break some builds in ways which can't be anticipated.

Fixing that took considerably less time than what I would have spent on
making all my imports explicit. Laziness wins again :)



--
View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5740946.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From hesselink at gmail.com  Tue Dec 10 14:51:29 2013
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 10 Dec 2013 15:51:29 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <1386686210296-5740946.post@n5.nabble.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
 <CANBN=mvqg7meSYQ9DTwyV-72jHAM5e514Ze0H=BfiOCJ5KJ28Q@mail.gmail.com>
 <1386686210296-5740946.post@n5.nabble.com>
Message-ID: <CAPeieQEsuribstpUpC7kJCk17msjTvOpCNS9VyZnTVpZ19emiw@mail.gmail.com>

On Tue, Dec 10, 2013 at 3:36 PM, harry <voldermort at hotmail.com> wrote:
> Sven Panne-2 wrote
>> I think the rational is: If you carefully and explictly import only
>> the things you need, the new version won't break your build. Importing
>> whole modules can of course break your build when new entities have
>> been added to the imported module, but this could be avoided by being
>> less lazy and more explicit. ;-) Changing e.g. a signature or removing
>> stuff OTOH will break some builds in ways which can't be anticipated.
>
> Fixing that took considerably less time than what I would have spent on
> making all my imports explicit. Laziness wins again :)

True :) Although I have noticed that when you use explicit or
qualified imports, the code is much more easily readable for others,
since it's always clear where an identifier comes from. That might be
a reason to use this style  for some code. I've often developed
without explicit imports, and added them when 'done'. Then later, when
altering the code, I can remove the explicitness again while
developing, adding it back at the end. That flow could use some tool
support, though.

Erik

From ekmett at gmail.com  Tue Dec 10 16:13:31 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 10 Dec 2013 11:13:31 -0500
Subject: text, warp and blaze-builder
In-Reply-To: <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
Message-ID: <F586C387-9EC3-4B16-AA8A-FD5AD51941AD@gmail.com>

I have a big yard, but I don't think it'd be enough to house and feed a pony. 

I may have to content myself with a photo. :) 

A middle ground that has worked for me is that between my own packages I just use the first digit of the major version. If the bulk of the API is unlikely to break in the 1.x regime, putting a bound of text < 2 would permit large breaking changes to be signaled in the future, while still removing most of the headaches of day to day version bumps forced on you by the pvp.

-Edward

> On Dec 9, 2013, at 3:28 PM, "Bryan O'Sullivan" <bos at serpentine.com> wrote:
> 
> 
>> On Mon, Dec 9, 2013 at 11:29 AM, Edward A Kmett <ekmett at gmail.com> wrote:
>> At last check blaze-builder hadn't updated its text dependency though stuff built on top of it has. I opened an issue with the repo about it as this is currently blocking the updated release of trifecta.
> 
> There will be a 1.1 release of text in a matter of weeks, which leaves the public API unchanged, but exposes all the hitherto hidden internal modules.
> 
> Everyone who removes their upper bounds on the version of text gets a pony. Everyone who widens their upper bounds to allow 1.1 gets a photo of a pony. Everyone who widens, but only to 1.0, gets some postprocessed pony food.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131210/0f2d206c/attachment.html>

From ekmett at gmail.com  Tue Dec 10 16:16:46 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 10 Dec 2013 11:16:46 -0500
Subject: text, warp and blaze-builder
In-Reply-To: <1386663619749-5740929.post@n5.nabble.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
Message-ID: <0018634B-3AF2-41C7-B16E-A08D2A725FC0@gmail.com>

The idea is that exposing a new function can be defended against by the user by using qualified imports. If you don't use qualified imports then minor version changes CAN break your code, even bough they rarely will.

If a something new is exposed in a module users were already importing like that it should be a minor bump so that users can defend themselves if they are sufficiently paranoid.

-Edward

> On Dec 10, 2013, at 3:20 AM, harry <voldermort at hotmail.com> wrote:
> 
> Erik Hesselink wrote
>> Why make this a major bump? If it only exposes new things, it should
>> only have to be a minor bump, right?
> 
> I just had a build break because a module I was importing exposed a new
> function that clashed with an existing function from a different module.
> Should potential build-breakers be a minor bump?
> 
> 
> 
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5740929.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From rwbarton at gmail.com  Tue Dec 10 16:51:38 2013
From: rwbarton at gmail.com (Reid Barton)
Date: Tue, 10 Dec 2013 11:51:38 -0500
Subject: text, warp and blaze-builder
In-Reply-To: <0018634B-3AF2-41C7-B16E-A08D2A725FC0@gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
 <0018634B-3AF2-41C7-B16E-A08D2A725FC0@gmail.com>
Message-ID: <CADmwj45911c_wha_Ur-eSz+w9dKV9bQgi4_S4szpaeEp8iLj1w@mail.gmail.com>

Just to keep the discussion on point, in this case bos is exposing
additional modules, rather than exporting additional functions from
existing modules, right? The danger is that a user of text is currently
also using another package's, say, Data.Text.Util module.

Users can also defend themselves against this kind of change, by using
package-qualified imports, though I don't think I've ever seen anyone do so
preemptively (only in cases where there is a real existing conflict, like
between mtl and monads-tf).

Regards,
Reid


On Tue, Dec 10, 2013 at 11:16 AM, Edward Kmett <ekmett at gmail.com> wrote:

> The idea is that exposing a new function can be defended against by the
> user by using qualified imports. If you don't use qualified imports then
> minor version changes CAN break your code, even bough they rarely will.
>
> If a something new is exposed in a module users were already importing
> like that it should be a minor bump so that users can defend themselves if
> they are sufficiently paranoid.
>
> -Edward
>
> > On Dec 10, 2013, at 3:20 AM, harry <voldermort at hotmail.com> wrote:
> >
> > Erik Hesselink wrote
> >> Why make this a major bump? If it only exposes new things, it should
> >> only have to be a minor bump, right?
> >
> > I just had a build break because a module I was importing exposed a new
> > function that clashed with an existing function from a different module.
> > Should potential build-breakers be a minor bump?
> >
> >
> >
> > --
> > View this message in context:
> http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5740929.html
> > Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131210/a69aac1a/attachment.html>

From johan.tibell at gmail.com  Tue Dec 10 18:04:46 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 10 Dec 2013 19:04:46 +0100
Subject: text, warp and blaze-builder
In-Reply-To: <CADmwj45911c_wha_Ur-eSz+w9dKV9bQgi4_S4szpaeEp8iLj1w@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
 <0018634B-3AF2-41C7-B16E-A08D2A725FC0@gmail.com>
 <CADmwj45911c_wha_Ur-eSz+w9dKV9bQgi4_S4szpaeEp8iLj1w@mail.gmail.com>
Message-ID: <CAK-tuPY3RoQbwrQNj2bxsbk4AzqHA82=kR7QuFj5Wa_pHEsaAg@mail.gmail.com>

This is all true. I think for the HP we decided that the odds were low
enough that we don't require a major version bump in the case of adding new
modules.


On Tue, Dec 10, 2013 at 5:51 PM, Reid Barton <rwbarton at gmail.com> wrote:

> Just to keep the discussion on point, in this case bos is exposing
> additional modules, rather than exporting additional functions from
> existing modules, right? The danger is that a user of text is currently
> also using another package's, say, Data.Text.Util module.
>
> Users can also defend themselves against this kind of change, by using
> package-qualified imports, though I don't think I've ever seen anyone do so
> preemptively (only in cases where there is a real existing conflict, like
> between mtl and monads-tf).
>
> Regards,
> Reid
>
>
>
> On Tue, Dec 10, 2013 at 11:16 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> The idea is that exposing a new function can be defended against by the
>> user by using qualified imports. If you don't use qualified imports then
>> minor version changes CAN break your code, even bough they rarely will.
>>
>> If a something new is exposed in a module users were already importing
>> like that it should be a minor bump so that users can defend themselves if
>> they are sufficiently paranoid.
>>
>> -Edward
>>
>> > On Dec 10, 2013, at 3:20 AM, harry <voldermort at hotmail.com> wrote:
>> >
>> > Erik Hesselink wrote
>> >> Why make this a major bump? If it only exposes new things, it should
>> >> only have to be a minor bump, right?
>> >
>> > I just had a build break because a module I was importing exposed a new
>> > function that clashed with an existing function from a different module.
>> > Should potential build-breakers be a minor bump?
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://haskell.1045720.n5.nabble.com/text-warp-and-blaze-builder-tp5740884p5740929.html
>> > Sent from the Haskell - Libraries mailing list archive at Nabble.com.
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131210/46858e5b/attachment-0001.html>

From the.dead.shall.rise at gmail.com  Wed Dec 11 12:37:34 2013
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Wed, 11 Dec 2013 12:37:34 +0000 (UTC)
Subject: cabal: question on compiling build prerequisites
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
Message-ID: <loom.20131211T133509-155@post.gmane.org>

Hi Peter,

Peter Selinger <selinger <at> mathstat.dal.ca> writes:

> The .cabal file contains all kinds of related variables, such as
> "build-depends" (but only packages can be listed here, not programs to
> be compiled), "other-modules" (but these modules would already require
> the pre-processor, so the pre-processor should be compiled first),
> "build-tools" (but this only refers to external programs).

According to Duncan Coutts [1], 'build-tools' should also work for internal
executables.

[1] https://github.com/haskell/cabal/issues/1541#issuecomment-30155513


From nominolo at googlemail.com  Wed Dec 11 16:00:10 2013
From: nominolo at googlemail.com (Thomas Schilling)
Date: Wed, 11 Dec 2013 17:00:10 +0100
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
Message-ID: <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>

Also, adding a function should bump the third component, not the fourth.

On 11 December 2013 16:57, Thomas Schilling <nominolo at googlemail.com> wrote:
> There's a typo in line:
>
> +#ifndef HAVE_FDAYASYNC
>
> I assume it should read HAVE_FDATASYNC
>
> Did you try to compile this on a system that has fdatasync?
>
> On 7 December 2013 20:20, Ricardo Catalinas Jim?nez
> <jimenezrick at gmail.com> wrote:
>> Hi,
>>
>> Please review this pull request:
>> https://github.com/jimenezrick/unix/compare/master...file-utils.patch
>>
>> If you find interesting this patch, then:
>> git pull https://github.com/jimenezrick/unix.git file-utils
>>
>> /Ricardo
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries

From jimenezrick at gmail.com  Wed Dec 11 22:55:08 2013
From: jimenezrick at gmail.com (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=)
Date: Wed, 11 Dec 2013 22:55:08 +0000
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
Message-ID: <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>

Shame on me! Wrong copy&paste from fsync to fdatasync... Fixed and
tested on Linux. Changelog corrected and commits squashed.

Review:
https://github.com/jimenezrick/unix/compare/master...file-utils
/Ricardo


On Wed, Dec 11, 2013 at 4:00 PM, Thomas Schilling
<nominolo at googlemail.com> wrote:
> Also, adding a function should bump the third component, not the fourth.
>
> On 11 December 2013 16:57, Thomas Schilling <nominolo at googlemail.com> wrote:
>> There's a typo in line:
>>
>> +#ifndef HAVE_FDAYASYNC
>>
>> I assume it should read HAVE_FDATASYNC
>>
>> Did you try to compile this on a system that has fdatasync?
>>
>> On 7 December 2013 20:20, Ricardo Catalinas Jim?nez
>> <jimenezrick at gmail.com> wrote:
>>> Hi,
>>>
>>> Please review this pull request:
>>> https://github.com/jimenezrick/unix/compare/master...file-utils.patch
>>>
>>> If you find interesting this patch, then:
>>> git pull https://github.com/jimenezrick/unix.git file-utils
>>>
>>> /Ricardo
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries

From svenpanne at gmail.com  Thu Dec 12 10:47:15 2013
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 12 Dec 2013 11:47:15 +0100
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <loom.20131211T133509-155@post.gmane.org>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <loom.20131211T133509-155@post.gmane.org>
Message-ID: <CANBN=muGVcppsh6-6M0KXaGxowvf-RiT=0vXjPezTjTZyjyOTw@mail.gmail.com>

2013/12/11 Mikhail Glushenkov <the.dead.shall.rise at gmail.com>:
> According to Duncan Coutts [1], 'build-tools' should also work for internal
> executables.

Is there a Haskell package on Hackage which is successfully using it
this way? I'm just curious to see the details...

From the.dead.shall.rise at gmail.com  Thu Dec 12 16:35:01 2013
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 12 Dec 2013 17:35:01 +0100
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <CANBN=muGVcppsh6-6M0KXaGxowvf-RiT=0vXjPezTjTZyjyOTw@mail.gmail.com>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <loom.20131211T133509-155@post.gmane.org>
 <CANBN=muGVcppsh6-6M0KXaGxowvf-RiT=0vXjPezTjTZyjyOTw@mail.gmail.com>
Message-ID: <CA+tcxkD8RLzi-eLO_Qi9_j-FUo5Gw0owHhCW5xh5jmNHFT2JWQ@mail.gmail.com>

Hi Sven,

On Thu, Dec 12, 2013 at 11:47 AM, Sven Panne <svenpanne at gmail.com> wrote:
> 2013/12/11 Mikhail Glushenkov <the.dead.shall.rise at gmail.com>:
>> According to Duncan Coutts [1], 'build-tools' should also work for internal
>> executables.
>
> Is there a Haskell package on Hackage which is successfully using it
> this way? I'm just curious to see the details...

I've created a small example: https://gist.github.com/23Skidoo/7930870

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

From lemming at henning-thielemann.de  Thu Dec 12 20:01:08 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 12 Dec 2013 21:01:08 +0100 (CET)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <CA+tcxkD8RLzi-eLO_Qi9_j-FUo5Gw0owHhCW5xh5jmNHFT2JWQ@mail.gmail.com>
References: <20131207033151.08D0B8C017C@chase.mathstat.dal.ca>
 <loom.20131211T133509-155@post.gmane.org>
 <CANBN=muGVcppsh6-6M0KXaGxowvf-RiT=0vXjPezTjTZyjyOTw@mail.gmail.com>
 <CA+tcxkD8RLzi-eLO_Qi9_j-FUo5Gw0owHhCW5xh5jmNHFT2JWQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1312122053550.2013@anubis.informatik.uni-halle.de>


On Thu, 12 Dec 2013, Mikhail Glushenkov wrote:

> Hi Sven,
>
> On Thu, Dec 12, 2013 at 11:47 AM, Sven Panne <svenpanne at gmail.com> wrote:
>> 2013/12/11 Mikhail Glushenkov <the.dead.shall.rise at gmail.com>:
>>> According to Duncan Coutts [1], 'build-tools' should also work for internal
>>> executables.
>>
>> Is there a Haskell package on Hackage which is successfully using it
>> this way? I'm just curious to see the details...
>
> I've created a small example: https://gist.github.com/23Skidoo/7930870

I have added a reference to:
   http://www.haskell.org/haskellwiki/Cabal/Developer-FAQ#Custom_preprocessors

From lemming at henning-thielemann.de  Thu Dec 12 20:30:18 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 12 Dec 2013 21:30:18 +0100 (CET)
Subject: import style (was: text, warp and blaze-builder)
In-Reply-To: <CAPeieQEsuribstpUpC7kJCk17msjTvOpCNS9VyZnTVpZ19emiw@mail.gmail.com>
References: <52A5D878.1030807@dfki.de>
 <6FC72031-2091-440C-A0F6-2D9C60E1138E@gmail.com>
 <CACw0ni+hm9yxAo-z+Or_vBWy3BvhFyzpVhr1kQ6-EAZmUzwKKA@mail.gmail.com>
 <CAPeieQFt+XhKgV8_04azAHZD7HDE3SpS84S0yqmqQutRBAYE8A@mail.gmail.com>
 <1386663619749-5740929.post@n5.nabble.com>
 <CANBN=mvqg7meSYQ9DTwyV-72jHAM5e514Ze0H=BfiOCJ5KJ28Q@mail.gmail.com>
 <1386686210296-5740946.post@n5.nabble.com>
 <CAPeieQEsuribstpUpC7kJCk17msjTvOpCNS9VyZnTVpZ19emiw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1312122124030.2013@anubis.informatik.uni-halle.de>


On Tue, 10 Dec 2013, Erik Hesselink wrote:

> On Tue, Dec 10, 2013 at 3:36 PM, harry <voldermort at hotmail.com> wrote:
>> Sven Panne-2 wrote
>>> I think the rational is: If you carefully and explictly import only
>>> the things you need, the new version won't break your build. Importing
>>> whole modules can of course break your build when new entities have
>>> been added to the imported module, but this could be avoided by being
>>> less lazy and more explicit. ;-) Changing e.g. a signature or removing
>>> stuff OTOH will break some builds in ways which can't be anticipated.
>>
>> Fixing that took considerably less time than what I would have spent on
>> making all my imports explicit. Laziness wins again :)
>
> True :) Although I have noticed that when you use explicit or
> qualified imports, the code is much more easily readable for others,
> since it's always clear where an identifier comes from. That might be
> a reason to use this style  for some code. I've often developed
> without explicit imports, and added them when 'done'. Then later, when
> altering the code, I can remove the explicitness again while
> developing, adding it back at the end. That flow could use some tool
> support, though.

The decision whether to use qualification or not, cannot be done when 
importing, it must be done when exporting. If you define writeChan, then 
it is certainly not intended to use it as Chan.writeChan. Vice versa, if 
module Chan exports "write" then it calls for name clashes if you import 
that implicitly and unqualified. For that reason I use qualified style 
whereever possible (i.e. except for infix operators) and define names such 
that they make sense together with the qualification. This way I need 
neither interim solutions nor tool support.

From jimenezrick at gmail.com  Thu Dec 12 21:33:33 2013
From: jimenezrick at gmail.com (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=)
Date: Thu, 12 Dec 2013 21:33:33 +0000
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
Message-ID: <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>

If anyone else doesn't have any other objection, how should I proceed?
Should I open a ticket in ghc's Trac asking for integration of this
patch?

Regards,
/Ricardo


On Wed, Dec 11, 2013 at 10:55 PM, Ricardo Catalinas Jim?nez
<jimenezrick at gmail.com> wrote:
> Shame on me! Wrong copy&paste from fsync to fdatasync... Fixed and
> tested on Linux. Changelog corrected and commits squashed.
>
> Review:
> https://github.com/jimenezrick/unix/compare/master...file-utils
> /Ricardo
>
>
> On Wed, Dec 11, 2013 at 4:00 PM, Thomas Schilling
> <nominolo at googlemail.com> wrote:
>> Also, adding a function should bump the third component, not the fourth.
>>
>> On 11 December 2013 16:57, Thomas Schilling <nominolo at googlemail.com> wrote:
>>> There's a typo in line:
>>>
>>> +#ifndef HAVE_FDAYASYNC
>>>
>>> I assume it should read HAVE_FDATASYNC
>>>
>>> Did you try to compile this on a system that has fdatasync?
>>>
>>> On 7 December 2013 20:20, Ricardo Catalinas Jim?nez
>>> <jimenezrick at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Please review this pull request:
>>>> https://github.com/jimenezrick/unix/compare/master...file-utils.patch
>>>>
>>>> If you find interesting this patch, then:
>>>> git pull https://github.com/jimenezrick/unix.git file-utils
>>>>
>>>> /Ricardo
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries

From sol at typeful.net  Sat Dec 14 10:56:11 2013
From: sol at typeful.net (Simon Hengel)
Date: Sat, 14 Dec 2013 11:56:11 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
Message-ID: <20131214105611.GA2849@x200>

Hi!
I propose to add

    die :: String -> IO ()
    die err = hPutStrLn stderr err >> exitFailure

to System.Exit.

Reasoning:

(1) It's a frequently required functionality.  Almost every command-line
    program has code similar to this.

(2) The definition is relatively short, but in addition to the
    definition, you need two import statements.

(3) It's frequently done wrong (e.g. writing to stdout instead of
    stderr, or not using exitFailure, or both).
    
I haven't done any extensive research on Hackage, but I quickly looked
at Haddock.  Here we have a definition of die [1], but we also print to
stdout at a couple of place and then call exitFailure [2].

Personally, I think it should be re-exported from Prelude.  But this may
be controversial.  So let's have two separate votes:

Add System.Exit.die:            +1
Re-export it from Prelude:      +1

(discussion until December, 28th)

Cheers,
Simon

[1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
[2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87

From sol at typeful.net  Sat Dec 14 10:59:16 2013
From: sol at typeful.net (Simon Hengel)
Date: Sat, 14 Dec 2013 11:59:16 +0100
Subject: Proposal: Add die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200>
References: <20131214105611.GA2849@x200>
Message-ID: <20131214105916.GB2849@x200>

On Sat, Dec 14, 2013 at 11:56:11AM +0100, Simon Hengel wrote:
> I propose to add
> 
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
> 
> to System.Exit.

An alternative implementation would be:

    die :: String -> IO ()
    die err = do
      name <- getProgramName
      hPutStrLn stderr (name ++ ": " ++ err) >> exitFailure

(not sure what's preferable)

Cheers.

From noteed at gmail.com  Sat Dec 14 11:09:20 2013
From: noteed at gmail.com (Vo Minh Thu)
Date: Sat, 14 Dec 2013 12:09:20 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200>
References: <20131214105611.GA2849@x200>
Message-ID: <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>

2013/12/14 Simon Hengel <sol at typeful.net>:
> Hi!
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.
>
> Reasoning:
>
> (1) It's a frequently required functionality.  Almost every command-line
>     program has code similar to this.
>
> (2) The definition is relatively short, but in addition to the
>     definition, you need two import statements.
>
> (3) It's frequently done wrong (e.g. writing to stdout instead of
>     stderr, or not using exitFailure, or both).
>
> I haven't done any extensive research on Hackage, but I quickly looked
> at Haddock.  Here we have a definition of die [1], but we also print to
> stdout at a couple of place and then call exitFailure [2].
>
> Personally, I think it should be re-exported from Prelude.  But this may
> be controversial.  So let's have two separate votes:

Isn't your `die` function a special case of `error :: String -> a`,
which is in the Prelude ?

I think variants of what you propose are often used: different exit
codes, not exiting and flushing stderr, displaying an arbitrary `Show
a` instead of `String`, using `Text`, and so on.

Actually I think some (all ?) `IO` things from the Prelude should not
be in the Prelude. For instance I may want to use the `bytestring`
`readFile`.

- 1 (for both)

Thu

From roma at ro-che.info  Sat Dec 14 11:19:26 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 14 Dec 2013 13:19:26 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200>
References: <20131214105611.GA2849@x200>
Message-ID: <20131214111926.GA20495@sniper>

I agree that this function would be useful for quick&dirty prototyping.

However, I'm not sure we should encourage its use. What looks to me like
a superior approach is to throw proper exceptions.

Here's an example in my own code:
https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L31

The main advantage of this is that it's much easier to turn the 'main'
code into library code, which is not supposed to write to stderr
anymore. Exceptions carry important semantic information about what
actually happened, and can be caught and handled if needed. (The
ExitCode exception can also be caught, but it doesn't tell us anything,
and the output would have already gone to stderr.)

As a bonus, this approach forces you to separate (in code) message
strings from places where you die, which in my experience leads to much
cleaner code.

There's a caveat that the standard doesn't specify what happens to
uncaught exceptions, so we have to rely on the runtime doing the right
thing for us. Well, GHC's one does.

Roman

* Simon Hengel <sol at typeful.net> [2013-12-14 11:56:11+0100]
> Hi!
> I propose to add
> 
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
> 
> to System.Exit.
> 
> Reasoning:
> 
> (1) It's a frequently required functionality.  Almost every command-line
>     program has code similar to this.
> 
> (2) The definition is relatively short, but in addition to the
>     definition, you need two import statements.
> 
> (3) It's frequently done wrong (e.g. writing to stdout instead of
>     stderr, or not using exitFailure, or both).
>     
> I haven't done any extensive research on Hackage, but I quickly looked
> at Haddock.  Here we have a definition of die [1], but we also print to
> stdout at a couple of place and then call exitFailure [2].
> 
> Personally, I think it should be re-exported from Prelude.  But this may
> be controversial.  So let's have two separate votes:
> 
> Add System.Exit.die:            +1
> Re-export it from Prelude:      +1
> 
> (discussion until December, 28th)
> 
> Cheers,
> Simon
> 
> [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
> [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131214/b365d7b8/attachment.sig>

From roma at ro-che.info  Sat Dec 14 11:21:55 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 14 Dec 2013 13:21:55 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
References: <20131214105611.GA2849@x200>
 <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
Message-ID: <20131214112155.GB20495@sniper>

* Vo Minh Thu <noteed at gmail.com> [2013-12-14 12:09:20+0100]
> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

There are two differences:

* die throws an exception in the IO monad (i.e. it uses `throwIO`,
  whereas `error` uses `throw`).
* error adds "*** Exception: " to the message

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131214/371cf5fb/attachment.sig>

From sol at typeful.net  Sat Dec 14 11:33:16 2013
From: sol at typeful.net (Simon Hengel)
Date: Sat, 14 Dec 2013 12:33:16 +0100
Subject: Proposal: Add die to System.Exit (and/or Prelude)
In-Reply-To: <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
References: <20131214105611.GA2849@x200>
 <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
Message-ID: <20131214113316.GA13215@x200>

On Sat, Dec 14, 2013 at 12:09:20PM +0100, Vo Minh Thu wrote:
> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

No, it's not.  I'm not going into the details of imprecise exceptions
(and GHC's interpretation of them + all the bugs that various versions
of GHC have when it comes to that topic), but `error` indicates a
programmer error and should not be part of a valid path in your program.
In contrast, `die` is meant to be used when a user e.g. passes wrong
input to a program (which is a user error, not a programmer error).

> I think variants of what you propose are often used: different exit
> codes, not exiting and flushing stderr

You can just use hPutStrLn here, stderr is unbuffered by default.

> displaying an arbitrary `Show a` instead of `String`

Yes, that is actually a good point.  But

    die (show x)

is still much more concise than using hPrint + exitFailure.

> using `Text`

Valid point.  Still, I think for the particular case of error messages
it's ok to stick with String.

Cheers.

From lemming at henning-thielemann.de  Sat Dec 14 11:38:13 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 14 Dec 2013 12:38:13 +0100 (CET)
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200>
References: <20131214105611.GA2849@x200>
Message-ID: <alpine.DEB.2.00.1312141228430.15414@anubis.informatik.uni-halle.de>


On Sat, 14 Dec 2013, Simon Hengel wrote:

> Hi!
> I propose to add
>
>    die :: String -> IO ()
>    die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.

I have written this definition several times and called it exitFailureMsg. 
I used it only for the argument handling in shell programs. I agree with 
Roman that the proper way are exceptions. However, the implicit nature of 
IO exceptions is the wrong way, too. This is confirmed by Roman's 
observation that it is not clear how uncaught IO exceptions are handled. 
In an explicit ErrorT way you cannot accidentally ignore exceptions.

Thus, I think neither 'die'/exit nor IO exceptions are the right way to 
go. Consequently I hesitate to add further steps in wrong directions to 
'base'. Maybe it would be better to add an exception handler containing 
"hPutStrLn stderr" to ErrorT module.


> Add System.Exit.die:

0

> Re-export it from Prelude:

-1

From sol at typeful.net  Sat Dec 14 11:54:17 2013
From: sol at typeful.net (Simon Hengel)
Date: Sat, 14 Dec 2013 12:54:17 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214111926.GA20495@sniper>
References: <20131214105611.GA2849@x200>
 <20131214111926.GA20495@sniper>
Message-ID: <20131214115417.GB13215@x200>

> I agree that this function would be useful for quick&dirty prototyping.
> 
> However, I'm not sure we should encourage its use. What looks to me like
> a superior approach is to throw proper exceptions.
> 
> Here's an example in my own code:
> https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L31
> 
> The main advantage of this is that it's much easier to turn the 'main'
> code into library code, which is not supposed to write to stderr
> anymore. Exceptions carry important semantic information about what
> actually happened, and can be caught and handled if needed. (The
> ExitCode exception can also be caught, but it doesn't tell us anything,
> and the output would have already gone to stderr.)
> 
> As a bonus, this approach forces you to separate (in code) message
> strings from places where you die, which in my experience leads to much
> cleaner code.
> 
> There's a caveat that the standard doesn't specify what happens to
> uncaught exceptions, so we have to rely on the runtime doing the right
> thing for us. Well, GHC's one does.

For my own code, I actually prefer to stick with Maybe/Either instead of
exceptions when ever possible.  I'd use `die` only in a top-level
wrapper, e.g. like so:

    import Acme.Omitted

    main :: IO ()
    main = getContents >>= either die run . parseInput

    run :: UserInput -> IO ()
    run = (...)

    parseInput :: String -> Either String UserInput
    parseInput = (...)

Cheers.

From mail at nh2.me  Sat Dec 14 12:49:59 2013
From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=)
Date: Sat, 14 Dec 2013 12:49:59 +0000
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214115417.GB13215@x200>
References: <20131214105611.GA2849@x200> <20131214111926.GA20495@sniper>
 <20131214115417.GB13215@x200>
Message-ID: <52AC53F7.20109@nh2.me>

I also think that people should generally use exceptions which I can
catch by names (as opposed to error), especially in libraries, but in
simple top-level cases as you described, your `die` makes a lot of sense
to me. "Easy things should be easy", and removing another case for
`error` sounds like a good thing.

  Add System.Exit.die:     +1

I'd prefer your simple, first version though, since `getProgramName`
might not always print the thing you would like. Glad to be convinced
otherwise though (how do unix tools do this? Is it hardcoded or do they
check their program name)?

  Re-export it from Prelude:  -1

(At least for now, let's have it around firstr.)


On 14/12/13 11:54, Simon Hengel wrote:
>> I agree that this function would be useful for quick&dirty prototyping.
>>
>> However, I'm not sure we should encourage its use. What looks to me like
>> a superior approach is to throw proper exceptions.
>>
>> Here's an example in my own code:
>> https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L31
>>
>> The main advantage of this is that it's much easier to turn the 'main'
>> code into library code, which is not supposed to write to stderr
>> anymore. Exceptions carry important semantic information about what
>> actually happened, and can be caught and handled if needed. (The
>> ExitCode exception can also be caught, but it doesn't tell us anything,
>> and the output would have already gone to stderr.)
>>
>> As a bonus, this approach forces you to separate (in code) message
>> strings from places where you die, which in my experience leads to much
>> cleaner code.
>>
>> There's a caveat that the standard doesn't specify what happens to
>> uncaught exceptions, so we have to rely on the runtime doing the right
>> thing for us. Well, GHC's one does.
> 
> For my own code, I actually prefer to stick with Maybe/Either instead of
> exceptions when ever possible.  I'd use `die` only in a top-level
> wrapper, e.g. like so:
> 
>     import Acme.Omitted
> 
>     main :: IO ()
>     main = getContents >>= either die run . parseInput
> 
>     run :: UserInput -> IO ()
>     run = (...)
> 
>     parseInput :: String -> Either String UserInput
>     parseInput = (...)
> 
> Cheers.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 

From ivan.miljenovic at gmail.com  Sat Dec 14 13:24:48 2013
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 15 Dec 2013 00:24:48 +1100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214111926.GA20495@sniper>
References: <20131214105611.GA2849@x200>
	<20131214111926.GA20495@sniper>
Message-ID: <CA+u6gbyH9=K=Sfx7j9aDP_udG+TWQj9BvmJnY3T1ScijiNM0nQ@mail.gmail.com>

On 14 December 2013 22:19, Roman Cheplyaka <roma at ro-che.info> wrote:
> I agree that this function would be useful for quick&dirty prototyping.
>
> However, I'm not sure we should encourage its use. What looks to me like
> a superior approach is to throw proper exceptions.

I've written something similar to this die function specifically to
deal with these exceptions (or to exit early out of main if I know
nothing more can proceed) rather than relying upon GHC to deal with
them.

That said, I'm not sure if it's worth adding; +0.5 to having it in System.Exit.

>
> Here's an example in my own code:
> https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L31
>
> The main advantage of this is that it's much easier to turn the 'main'
> code into library code, which is not supposed to write to stderr
> anymore. Exceptions carry important semantic information about what
> actually happened, and can be caught and handled if needed. (The
> ExitCode exception can also be caught, but it doesn't tell us anything,
> and the output would have already gone to stderr.)
>
> As a bonus, this approach forces you to separate (in code) message
> strings from places where you die, which in my experience leads to much
> cleaner code.
>
> There's a caveat that the standard doesn't specify what happens to
> uncaught exceptions, so we have to rely on the runtime doing the right
> thing for us. Well, GHC's one does.
>
> Roman
>
> * Simon Hengel <sol at typeful.net> [2013-12-14 11:56:11+0100]
>> Hi!
>> I propose to add
>>
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>>
>> to System.Exit.
>>
>> Reasoning:
>>
>> (1) It's a frequently required functionality.  Almost every command-line
>>     program has code similar to this.
>>
>> (2) The definition is relatively short, but in addition to the
>>     definition, you need two import statements.
>>
>> (3) It's frequently done wrong (e.g. writing to stdout instead of
>>     stderr, or not using exitFailure, or both).
>>
>> I haven't done any extensive research on Hackage, but I quickly looked
>> at Haddock.  Here we have a definition of die [1], but we also print to
>> stdout at a couple of place and then call exitFailure [2].
>>
>> Personally, I think it should be re-exported from Prelude.  But this may
>> be controversial.  So let's have two separate votes:
>>
>> Add System.Exit.die:            +1
>> Re-export it from Prelude:      +1
>>
>> (discussion until December, 28th)
>>
>> Cheers,
>> Simon
>>
>> [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
>> [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From selinger at mathstat.dal.ca  Sat Dec 14 18:09:57 2013
From: selinger at mathstat.dal.ca (Peter Selinger)
Date: Sat, 14 Dec 2013 14:09:57 -0400 (AST)
Subject: cabal: question on compiling build prerequisites
In-Reply-To: <alpine.DEB.2.00.1312071249531.20239@anubis.informatik.uni-halle.de>
Message-ID: <20131214180957.C738E8C017C@chase.mathstat.dal.ca>

Henning Thielemann wrote:
> 
> On Fri, 6 Dec 2013, Peter Selinger wrote:
> 
> > My current solution is to make the pre-processor a shell script,
> > rather than a Haskell program. But this is ugly and not portable
> > (won't work in Windows, for example).
> >
> > To clarify: my custom preprocessor is local to this package. It has no
> > independent value, so it would not make sense to publish it as a
> > separate package just so that I can add it to build-depends.
> >
> > Is there a known solution to this problem?
> 
> I have not tried this solution but I would guess that it is a good idea to 
> put the preprocessor in a separate package anyway, since it might have its 
> own build-depends.

I'd like to report on how I resolved these issues in the end. In a
way, I followed your suggestion after all. But rather than putting
just the preprocessor in a separate package, I put my entire build
system in a separate package. Actually, this turned out rather nicely,
because now other packages can use it too.

The build system in question is now the package superdoc:
http://hackage.haskell.org/package/superdoc

Its purpose is to extend Haddock's markup language with new markup:
for example, superscripts, boldface, images, and Unicode. It's
implemented as a bunch of UserHooks for a Setup.hs script and a
preprocessor.

What makes this particular use of a preprocessor interesting is that
the preprocessor is only used for building documentation, not for
building the actual code. Because it is now in a separate package,
other packages can use it transparently (the preprocessor will already
be installed). An example of a package using superdoc is newsynth:
http://hackage.haskell.org/package/newsynth.

The only slight complication is bootstrapping: Superdoc's own
documentation uses Superdoc markup. This creates a chicken-and-egg
situation, where the preprocessor may not yet be installed by the time
it needs to be used. It cannot be resolved with "build-tools" or
similar settings, because the library is a prerequisite of the
preprocessor, and the preprocessor is a prerequisite of the
documentation of the library (but not the library itself). 

To resolve this, I bit the bullet and used shell scripts as wrappers
for invoking the preprocessor via runhaskell. I provided both .sh and
.bat versions of the shell script (as well as code to decide which one
to run), so hopefully this is now fully portable. Tested under Linux
and Windows.

Thanks for all your feedback and suggestions! -- Peter

From hvr at gnu.org  Sat Dec 14 18:56:53 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sat, 14 Dec 2013 19:56:53 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
 (Vo Minh Thu's message of "Sat, 14 Dec 2013 12:09:20 +0100")
References: <20131214105611.GA2849@x200>
 <CAOHoMs=4+0nPVhRcmEkG3Yq3tBb1OJ=wmZ4osDNu3VZhHXUh9Q@mail.gmail.com>
Message-ID: <87vbyrp8ga.fsf@gnu.org>

On 2013-12-14 at 12:09:20 +0100, Vo Minh Thu wrote:

[...]

>> I propose to add
>>
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>>
>> to System.Exit.

[...]

> Isn't your `die` function a special case of `error :: String -> a`,
> which is in the Prelude ?

Imho, it'd be more comparable to the effect of `fail :: Monad m =>
String -> m a` for 'm == IO' (which throws an 'userError' exception).

E.g.:

  $ cat > foo.hs <<EOF
  main = fail "I'm outta here"
  EOF
  
  $ ghc --make foo.hs
  
  $ ./foo.hs
  
  foo: user error (I'm outta here)



From jwlato at gmail.com  Sun Dec 15 23:50:08 2013
From: jwlato at gmail.com (John Lato)
Date: Sun, 15 Dec 2013 15:50:08 -0800
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200>
References: <20131214105611.GA2849@x200>
Message-ID: <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>

+1 to adding 'die' to System.Exit
-1 to adding to Prelude

I've pretty much only wanted this in command-line type programs, but as the
proposal notes, it's very frequently required in that situation.

John L.


On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <sol at typeful.net> wrote:

> Hi!
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.
>
> Reasoning:
>
> (1) It's a frequently required functionality.  Almost every command-line
>     program has code similar to this.
>
> (2) The definition is relatively short, but in addition to the
>     definition, you need two import statements.
>
> (3) It's frequently done wrong (e.g. writing to stdout instead of
>     stderr, or not using exitFailure, or both).
>
> I haven't done any extensive research on Hackage, but I quickly looked
> at Haddock.  Here we have a definition of die [1], but we also print to
> stdout at a couple of place and then call exitFailure [2].
>
> Personally, I think it should be re-exported from Prelude.  But this may
> be controversial.  So let's have two separate votes:
>
> Add System.Exit.die:            +1
> Re-export it from Prelude:      +1
>
> (discussion until December, 28th)
>
> Cheers,
> Simon
>
> [1]
> https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
> [2]
> https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131215/ff5b068d/attachment.html>

From amindfv at gmail.com  Mon Dec 16 00:40:29 2013
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 15 Dec 2013 19:40:29 -0500
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
Message-ID: <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>

+1 adding to System.Exit
-0.5 adding to Prelude

Tom


El Dec 15, 2013, a las 18:50, John Lato <jwlato at gmail.com> escribi?:

> +1 to adding 'die' to System.Exit
> -1 to adding to Prelude
> 
> I've pretty much only wanted this in command-line type programs, but as the proposal notes, it's very frequently required in that situation.
> 
> John L.
> 
> 
> On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <sol at typeful.net> wrote:
>> Hi!
>> I propose to add
>> 
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>> 
>> to System.Exit.
>> 
>> Reasoning:
>> 
>> (1) It's a frequently required functionality.  Almost every command-line
>>     program has code similar to this.
>> 
>> (2) The definition is relatively short, but in addition to the
>>     definition, you need two import statements.
>> 
>> (3) It's frequently done wrong (e.g. writing to stdout instead of
>>     stderr, or not using exitFailure, or both).
>> 
>> I haven't done any extensive research on Hackage, but I quickly looked
>> at Haddock.  Here we have a definition of die [1], but we also print to
>> stdout at a couple of place and then call exitFailure [2].
>> 
>> Personally, I think it should be re-exported from Prelude.  But this may
>> be controversial.  So let's have two separate votes:
>> 
>> Add System.Exit.die:            +1
>> Re-export it from Prelude:      +1
>> 
>> (discussion until December, 28th)
>> 
>> Cheers,
>> Simon
>> 
>> [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
>> [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131215/11c681a3/attachment.html>

From ekmett at gmail.com  Mon Dec 16 01:09:24 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 15 Dec 2013 20:09:24 -0500
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
 <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
Message-ID: <CAJumaK-YwbrZgj66mhRnRFEMXcVXtTo6D8_mUprWRrxE79A+cQ@mail.gmail.com>

I'm neutral on adding or removing it to System.Exit in the first place.

On one hand it incurs the extra clutter of another name for a simple
composition, but on the other it is exiled to a fairly appropriate place
and I can see that there is a worldview in which would be the right way to
deal with exceptional situations that have no recovery mechanism.

That said, I'm pretty strongly -1 on adding it to the Prelude.

-Edward


On Sun, Dec 15, 2013 at 7:40 PM, <amindfv at gmail.com> wrote:

> +1 adding to System.Exit
> -0.5 adding to Prelude
>
> Tom
>
>
> El Dec 15, 2013, a las 18:50, John Lato <jwlato at gmail.com> escribi?:
>
> +1 to adding 'die' to System.Exit
> -1 to adding to Prelude
>
> I've pretty much only wanted this in command-line type programs, but as
> the proposal notes, it's very frequently required in that situation.
>
> John L.
>
>
> On Sat, Dec 14, 2013 at 2:56 AM, Simon Hengel <sol at typeful.net> wrote:
>
>> Hi!
>> I propose to add
>>
>>     die :: String -> IO ()
>>     die err = hPutStrLn stderr err >> exitFailure
>>
>> to System.Exit.
>>
>> Reasoning:
>>
>> (1) It's a frequently required functionality.  Almost every command-line
>>     program has code similar to this.
>>
>> (2) The definition is relatively short, but in addition to the
>>     definition, you need two import statements.
>>
>> (3) It's frequently done wrong (e.g. writing to stdout instead of
>>     stderr, or not using exitFailure, or both).
>>
>> I haven't done any extensive research on Hackage, but I quickly looked
>> at Haddock.  Here we have a definition of die [1], but we also print to
>> stdout at a couple of place and then call exitFailure [2].
>>
>> Personally, I think it should be re-exported from Prelude.  But this may
>> be controversial.  So let's have two separate votes:
>>
>> Add System.Exit.die:            +1
>> Re-export it from Prelude:      +1
>>
>> (discussion until December, 28th)
>>
>> Cheers,
>> Simon
>>
>> [1]
>> https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429e/src/Haddock/Utils.hs#L303
>> [2]
>> https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c538933/src/Haddock.hs#L87
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131215/2134b3fe/attachment.html>

From qdunkan at gmail.com  Mon Dec 16 01:54:14 2013
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 15 Dec 2013 17:54:14 -0800
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
 <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
Message-ID: <CACbaDy6KxYVwncyN6fEpqg_W0e6m0QGDTYzxs9jds6nw-y+NiA@mail.gmail.com>

I always thought it was kind of bizarre how other languages (even
wordy old java) have "exit :: Int -> IO ()", but haskell has
"System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
 Yes it's higher level to say "success" and "failure" than "0" and
">0", but wow that's a lot of bureaucracy for something trivial.  And
it still lets you write (ExitFailure 0).

Anyway, +1 for System.Exit, -1 for Prelude, because I sometimes define
my own 'die'.

From roma at ro-che.info  Mon Dec 16 02:16:45 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 16 Dec 2013 04:16:45 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CACbaDy6KxYVwncyN6fEpqg_W0e6m0QGDTYzxs9jds6nw-y+NiA@mail.gmail.com>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
 <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
 <CACbaDy6KxYVwncyN6fEpqg_W0e6m0QGDTYzxs9jds6nw-y+NiA@mail.gmail.com>
Message-ID: <20131216021645.GA15427@sniper>

* Evan Laforge <qdunkan at gmail.com> [2013-12-15 17:54:14-0800]
> I always thought it was kind of bizarre how other languages (even
> wordy old java) have "exit :: Int -> IO ()", but haskell has
> "System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
>  Yes it's higher level to say "success" and "failure" than "0" and
> ">0", but wow that's a lot of bureaucracy for something trivial.  And
> it still lets you write (ExitFailure 0).

System.Exit.exitFailure :: IO a has existed for a long time, FWIW.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/75a7d1dc/attachment-0001.sig>

From qdunkan at gmail.com  Mon Dec 16 06:51:10 2013
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 15 Dec 2013 22:51:10 -0800
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131216021645.GA15427@sniper>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
 <EB1209A5-6F62-4765-8D73-CE9052DE6EEB@gmail.com>
 <CACbaDy6KxYVwncyN6fEpqg_W0e6m0QGDTYzxs9jds6nw-y+NiA@mail.gmail.com>
 <20131216021645.GA15427@sniper>
Message-ID: <CACbaDy7xw5Ne49_TJMCCik+iDA410-zdF93c2REUU1iNkhbMyg@mail.gmail.com>

On Sun, Dec 15, 2013 at 6:16 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
> * Evan Laforge <qdunkan at gmail.com> [2013-12-15 17:54:14-0800]
>> I always thought it was kind of bizarre how other languages (even
>> wordy old java) have "exit :: Int -> IO ()", but haskell has
>> "System.Exit.exitSuccess" and "System.Exit.exitWith (ExitFailure 42)".
>>  Yes it's higher level to say "success" and "failure" than "0" and
>> ">0", but wow that's a lot of bureaucracy for something trivial.  And
>> it still lets you write (ExitFailure 0).
>
> System.Exit.exitFailure :: IO a has existed for a long time, FWIW.

Yeah, that's what I was saying.  One module, one type, two
constructors, and three functions, just to do what everyone else does
with one 'exit' function.  It's the windows vista shutdown menu of
exit functions.  It's almost as if haskell doesn't want to let us out.

Um.  Anyway.  Ignore me and carry on.

From hvr at gnu.org  Mon Dec 16 09:53:21 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 16 Dec 2013 10:53:21 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214105611.GA2849@x200> (Simon Hengel's message of "Sat, 14
 Dec 2013 11:56:11 +0100")
References: <20131214105611.GA2849@x200>
Message-ID: <87y53lxgtq.fsf@gnu.org>

Hello Simon,

On 2013-12-14 at 11:56:11 +0100, Simon Hengel wrote:
> I propose to add
>
>     die :: String -> IO ()
>     die err = hPutStrLn stderr err >> exitFailure
>
> to System.Exit.

Why not simply use the existing `fail :: String -> IO a` method instead?

The differences & similiarities I see wrt `fail`:

 - `die` throws an `ExitCode` exception, whereas `fail` throws an
   `IOError` exception

 - Both result in the message written to stderr and a non-zero exit code

 - As both use exceptions, `die` does guarantee termination (as it can
   be caught)

 - `die` writes to stderr at invocation time, whereas `fail` attaches
   the message to the exception, which is then output by the top
   exception handler.

   Due to that, catching a `die`-caused exception will print the
   termination message even though the process-exit was
   cancelled. Whereas attaching the message to the exception allows for
   more flexibility as well as for atomicity wrt message-output and
   termination.
   
 - `fail` is available from Prelude (and part of Haskell98/2010),
   whereas `System.Exit.die` would require an import of "System.Exit"
   (with the small risk of breaking code that expects only
   Haskell2010-known entities exported by "System.Exit")

Therefore I'm not convinced (yet), that the suggested `die`
implementation has sensible semantics in the context of exceptions, and
that it offers enough benefits over the already existing `fail` method.

Cheers,
  hvr

From dluposchainsky at googlemail.com  Mon Dec 16 09:59:02 2013
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Mon, 16 Dec 2013 10:59:02 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
References: <20131214105611.GA2849@x200>
 <CAJ727GjjUHNcf3wtFEtDxE=3tOzyOWZex_sgAF2TBk7KvyR1ig@mail.gmail.com>
Message-ID: <52AECEE6.7000200@gmail.com>

On 16.12.2013 00:50, John Lato wrote:
> +1 to adding 'die' to System.Exit
> -1 to adding to Prelude

Dito. Prelude should shrink rather than grow, especially with respect to
ad-hoc functions.

David


From roma at ro-che.info  Mon Dec 16 11:15:27 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 16 Dec 2013 13:15:27 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <87y53lxgtq.fsf@gnu.org>
References: <20131214105611.GA2849@x200>
 <87y53lxgtq.fsf@gnu.org>
Message-ID: <20131216111527.GA21117@sniper>

* Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
> Why not simply use the existing `fail :: String -> IO a` method instead?

The purpose of 'fail' is to handle monadic pattern-match failures.
I consider explicit use of 'fail' in user code a hack.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/5e6ae3e2/attachment.sig>

From ivan.miljenovic at gmail.com  Mon Dec 16 13:00:16 2013
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 17 Dec 2013 00:00:16 +1100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131216111527.GA21117@sniper>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
Message-ID: <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>

On 16 December 2013 22:15, Roman Cheplyaka <roma at ro-che.info> wrote:
> * Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
>> Why not simply use the existing `fail :: String -> IO a` method instead?
>
> The purpose of 'fail' is to handle monadic pattern-match failures.
> I consider explicit use of 'fail' in user code a hack.

Or for use with parser-combinator libraries (though I suppose this
could be seen as a pattern-match failure...)?

>
> Roman
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From roma at ro-che.info  Mon Dec 16 13:12:29 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 16 Dec 2013 15:12:29 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
Message-ID: <20131216131229.GB28061@sniper>

* Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> [2013-12-17 00:00:16+1100]
> On 16 December 2013 22:15, Roman Cheplyaka <roma at ro-che.info> wrote:
> > * Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
> >> Why not simply use the existing `fail :: String -> IO a` method instead?
> >
> > The purpose of 'fail' is to handle monadic pattern-match failures.
> > I consider explicit use of 'fail' in user code a hack.
> 
> Or for use with parser-combinator libraries (though I suppose this
> could be seen as a pattern-match failure...)?

I'd consider that an abuse, too. E.g. Parsec provides a parserFail
function that you can call instead.

I treat 'fail' as a semi-private method of the Monad class. I may
override it, but I should never call it. It only exists for the
compiler.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/9e67ceae/attachment.sig>

From andreas.abel at ifi.lmu.de  Mon Dec 16 13:54:53 2013
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 16 Dec 2013 14:54:53 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131216131229.GB28061@sniper>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper>
Message-ID: <52AF062D.3030403@ifi.lmu.de>

On 16.12.2013 14:12, Roman Cheplyaka wrote:
>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>>> I consider explicit use of 'fail' in user code a hack.
>
> I treat 'fail' as a semi-private method of the Monad class. I may
> override it, but I should never call it. It only exists for the
> compiler.

This is useful information.  Please add it to the documentation.  That 
would definitely help newcomers to get some orientation in the design 
space of exceptions...

 
http://hackage.haskell.org/package/base-4.6.0.1/docs/Control-Monad.html#t:Monad

   fail :: String -> m a

   Fail with a message. This operation is not part of the mathematical 
  definition of a monad, but is invoked on pattern-match failure in a do 
expression.

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

From andreas.abel at ifi.lmu.de  Mon Dec 16 13:57:30 2013
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 16 Dec 2013 14:57:30 +0100
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131214115417.GB13215@x200>
References: <20131214105611.GA2849@x200> <20131214111926.GA20495@sniper>
 <20131214115417.GB13215@x200>
Message-ID: <52AF06CA.3060306@ifi.lmu.de>

On 14.12.2013 12:54, Simon Hengel wrote:
>      main :: IO ()
>      main = getContents >>= either die run . parseInput

Funny way to write a pipeline.  Its neither left-to-right, which would be

   getContents >>= (parseInput >>> either die run)

nor right-to-left:

   either die run . parseInput =<< getContents

A case for hlint.
So much for my smart-ass comments.

About "(to) die or not (to) die" I am rather agnostic.
-1 for adding it to the Prelude.

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

From malcolm.wallace at me.com  Mon Dec 16 14:17:49 2013
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 16 Dec 2013 14:17:49 +0000
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <20131216131229.GB28061@sniper>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper>
Message-ID: <B4F0D746-78BC-4EF5-956E-00C2C293B59E@me.com>


On 16 Dec 2013, at 13:12, Roman Cheplyaka wrote:

> * Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> [2013-12-17 00:00:16+1100]
>> On 16 December 2013 22:15, Roman Cheplyaka <roma at ro-che.info> wrote:
>>> * Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
>>>> Why not simply use the existing `fail :: String -> IO a` method instead?
>>> 
>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>>> I consider explicit use of 'fail' in user code a hack.
>> 
>> Or for use with parser-combinator libraries (though I suppose this
>> could be seen as a pattern-match failure...)?
> 
> I'd consider that an abuse, too. E.g. Parsec provides a parserFail
> function that you can call instead.

I respectfully disagree.  Whilst it was probably a mistake originally to include "fail" as a method of the Monad class, it has always been a useful additional method.  Personally, I would have it in a separate class (called MonadFail, or similar).  But wherever it lives, we would always have had it.

I see no good reason to distinguish between runtime pattern-match failure, and a direct user call of "fail".  It is quite common to write parsers using pattern-matching, and why should one kind of backtracking be privileged over another?  Their effects are of exactly the same kind.

e.g.

    keyword = ( do "let" <- word -- fails if the string does not match
                   b <- binding
                   return (LET b) )
               `onFail`
              ( do "case" <- word
                   exp   <- expression
                   "of"  <- word `onFail` fail "missing keyword 'of'"
                   alts  <- many1 alternative
                   return (CASE exp alts) )

etc.


From lemming at henning-thielemann.de  Mon Dec 16 14:09:08 2013
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 16 Dec 2013 15:09:08 +0100 (CET)
Subject: direction of pipelines (Was: Proposal: die to System.Exit (and/or
 Prelude))
In-Reply-To: <52AF06CA.3060306@ifi.lmu.de>
References: <20131214105611.GA2849@x200> <20131214111926.GA20495@sniper>
 <20131214115417.GB13215@x200> <52AF06CA.3060306@ifi.lmu.de>
Message-ID: <alpine.DEB.2.00.1312161506470.3651@anubis.informatik.uni-halle.de>


On Mon, 16 Dec 2013, Andreas Abel wrote:

> On 14.12.2013 12:54, Simon Hengel wrote:
>>      main :: IO ()
>>      main = getContents >>= either die run . parseInput
>
> Funny way to write a pipeline.  Its neither left-to-right, which would be
>
>  getContents >>= (parseInput >>> either die run)
>
> nor right-to-left:
>
>  either die run . parseInput =<< getContents
>
> A case for hlint.


http://www.haskell.org/haskellwiki/Direction_of_data_flow

From roma at ro-che.info  Mon Dec 16 14:45:38 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 16 Dec 2013 16:45:38 +0200
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <B4F0D746-78BC-4EF5-956E-00C2C293B59E@me.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper>
 <B4F0D746-78BC-4EF5-956E-00C2C293B59E@me.com>
Message-ID: <20131216144538.GA1938@sniper>

* Malcolm Wallace <malcolm.wallace at me.com> [2013-12-16 14:17:49+0000]
> I see no good reason to distinguish between runtime pattern-match
> failure, and a direct user call of "fail".

One reason to distinguish them is that there's no good reason for fail
to have type String -> m a. Perhaps a better type would be
PatternFailureInfo -> m a, where PatternFailureInfo would include the
SrcLoc of where the failure happened, the pattern itself, maybe
something else.

So, it is possible to use fail in parsers, but only because it
incidentally has such a loose type. That's why it looks like a hack to
me.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/5c5ae88d/attachment.sig>

From hvr at gnu.org  Mon Dec 16 16:50:23 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 16 Dec 2013 17:50:23 +0100
Subject: Warn against using 'fail' directly in user-code (was: Proposal: die
 to System.Exit (and/or Prelude))
In-Reply-To: <52AF062D.3030403@ifi.lmu.de> (Andreas Abel's message of "Mon, 16
 Dec 2013 14:54:53 +0100")
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
Message-ID: <87ob4gyc34.fsf_-_@gnu.org>

On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
> On 16.12.2013 14:12, Roman Cheplyaka wrote:
>>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>>>> I consider explicit use of 'fail' in user code a hack.
>>
>> I treat 'fail' as a semi-private method of the Monad class. I may
>> override it, but I should never call it. It only exists for the
>> compiler.
>
> This is useful information.  Please add it to the documentation.  That
> would definitely help newcomers to get some orientation in the design
> space of exceptions...

[...]

If this is really the intent of `fail`, shouldn't we then also attach a

  {-# WARNING fail "Monad(fail) is not supposed to be called directly" #-}

to the `fail` method definition to help catch illegal uses of `fail` in
user code?

(Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
if there's consensus, we could add that for GHC 7.8)

Cheers,
  hvr

From mail at nh2.me  Mon Dec 16 17:37:54 2013
From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=)
Date: Mon, 16 Dec 2013 17:37:54 +0000
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <87ob4gyc34.fsf_-_@gnu.org>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org>
Message-ID: <52AF3A72.5080602@nh2.me>

> (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
> libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
> if there's consensus, we could add that for GHC 7.8)

That sounds great!

And as far as I remember, we will have MonadFail, as Malcolm mentioned,
soon.

On 16/12/13 13:54, Andreas Abel wrote
>   fail :: String -> m a
>
>   Fail with a message. This operation is not part of the mathematical
>  definition of a monad, but is invoked on pattern-match failure in a do
> expression.

This seems to go well with your change.

From ekmett at gmail.com  Mon Dec 16 19:52:45 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Dec 2013 14:52:45 -0500
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <B4F0D746-78BC-4EF5-956E-00C2C293B59E@me.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper>
 <B4F0D746-78BC-4EF5-956E-00C2C293B59E@me.com>
Message-ID: <CAJumaK9P4SQyfOymfJHFz_czsgf91GyH6Hw9Zda5jE4r+=igxA@mail.gmail.com>

At ICFP, Simon mentioned a willingness to revisit the placement of fail in
Monad for GHC, offering to defer to the core libraries committee on the
issue.

I'm somewhat loathe to do anything about this for 7.10, as I'd like to
focus on changes that can be made without requiring #ifdef's in user code
for the next major release, and just focus on making progress on things
that are near universally accepted to be good ideas, and which can be
"defended against" without CPP. e.g. finally bringing in Applicative as a
superclass of Monad.

That said, for say, 7.12 a well-reasoned proposal for what to do with fail
would have a very high likelihood of getting through! (for example, exiling
it to a MonadFail class or to the existing MonadPlus) Especially as if the
split-base proposal goes through for 7.12 a lot of breaking changes would
already be in the air.

-Edward


On Mon, Dec 16, 2013 at 9:17 AM, Malcolm Wallace <malcolm.wallace at me.com>wrote:

>
> On 16 Dec 2013, at 13:12, Roman Cheplyaka wrote:
>
> > * Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> [2013-12-17
> 00:00:16+1100]
> >> On 16 December 2013 22:15, Roman Cheplyaka <roma at ro-che.info> wrote:
> >>> * Herbert Valerio Riedel <hvr at gnu.org> [2013-12-16 10:53:21+0100]
> >>>> Why not simply use the existing `fail :: String -> IO a` method
> instead?
> >>>
> >>> The purpose of 'fail' is to handle monadic pattern-match failures.
> >>> I consider explicit use of 'fail' in user code a hack.
> >>
> >> Or for use with parser-combinator libraries (though I suppose this
> >> could be seen as a pattern-match failure...)?
> >
> > I'd consider that an abuse, too. E.g. Parsec provides a parserFail
> > function that you can call instead.
>
> I respectfully disagree.  Whilst it was probably a mistake originally to
> include "fail" as a method of the Monad class, it has always been a useful
> additional method.  Personally, I would have it in a separate class (called
> MonadFail, or similar).  But wherever it lives, we would always have had it.
>
> I see no good reason to distinguish between runtime pattern-match failure,
> and a direct user call of "fail".  It is quite common to write parsers
> using pattern-matching, and why should one kind of backtracking be
> privileged over another?  Their effects are of exactly the same kind.
>
> e.g.
>
>     keyword = ( do "let" <- word -- fails if the string does not match
>                    b <- binding
>                    return (LET b) )
>                `onFail`
>               ( do "case" <- word
>                    exp   <- expression
>                    "of"  <- word `onFail` fail "missing keyword 'of'"
>                    alts  <- many1 alternative
>                    return (CASE exp alts) )
>
> etc.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/c408df6e/attachment-0001.html>

From andreas.abel at ifi.lmu.de  Mon Dec 16 20:08:32 2013
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 16 Dec 2013 21:08:32 +0100
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <52AF3A72.5080602@nh2.me>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52AF3A72.5080602@nh2.me>
Message-ID: <52AF5DC0.7050108@ifi.lmu.de>

On 16.12.2013 18:37, Niklas Hamb?chen wrote:
>> (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
>> libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
>> if there's consensus, we could add that for GHC 7.8)
>
> That sounds great!
>
> And as far as I remember, we will have MonadFail, as Malcolm mentioned,
> soon.
>
> On 16/12/13 13:54, Andreas Abel wrote
>>    fail :: String -> m a
>>
>>    Fail with a message. This operation is not part of the mathematical
>>   definition of a monad, but is invoked on pattern-match failure in a do
>> expression.
>
> This seems to go well with your change.

Above I was just quoting the current documentation.  It should be 
formulated sharper, to say explicitly "do not use `fail' to throw your 
own errors!"



-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

From rhymoid at gmail.com  Mon Dec 16 21:15:17 2013
From: rhymoid at gmail.com (Stijn van Drongelen)
Date: Mon, 16 Dec 2013 22:15:17 +0100
Subject: Warn against using 'fail' directly in user-code (was: Proposal:
 die to System.Exit (and/or Prelude))
In-Reply-To: <87ob4gyc34.fsf_-_@gnu.org>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org>
Message-ID: <CAGg6Gc7pC6W0c=ReBST3qwgwAJW6PEmSN2Q2FkFi9R0QTcEoGQ@mail.gmail.com>

On Mon, Dec 16, 2013 at 5:50 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
> > On 16.12.2013 14:12, Roman Cheplyaka wrote:
> >>>> The purpose of 'fail' is to handle monadic pattern-match failures.
> >>>> I consider explicit use of 'fail' in user code a hack.
> >>
> >> I treat 'fail' as a semi-private method of the Monad class. I may
> >> override it, but I should never call it. It only exists for the
> >> compiler.
> >
> > This is useful information.  Please add it to the documentation.  That
> > would definitely help newcomers to get some orientation in the design
> > space of exceptions...
>
> [...]
>
> If this is really the intent of `fail`, shouldn't we then also attach a
>
>   {-# WARNING fail "Monad(fail) is not supposed to be called directly" #-}
>
> to the `fail` method definition to help catch illegal uses of `fail` in
> user code?
>
> (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
> libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
> if there's consensus, we could add that for GHC 7.8)
>
> Cheers,
>   hvr
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

+1!

I think `fail` is a huge wart anyway.

I'm still partial to the Haskell 1.4 solution to this problem, where the
translation of refutable patterns in do-notation would involve `mzero`
rather than `fail "Here, have some debugging info."`.

:),
Stijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/03294eb2/attachment.html>

From dluposchainsky at googlemail.com  Mon Dec 16 22:26:39 2013
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Mon, 16 Dec 2013 23:26:39 +0100
Subject: Removing MonadFail from Monad
Message-ID: <52AF7E1F.4000606@gmail.com>

Hey everyone,

I feel like there are a couple of elephants in the room that are sort of
important but nobody really addresses them directly. One of them was
what became the AMP, and `fail` is another one.
I resurrected and refurbished this proposal from a 6 month old Gist
because there seemed to be some interest/talk going on in the form of
side remarks in other discussions here. The sun shines, let's make some hay!

The proposal text can be found at the end of this text (for the mailman
archives), or in pretty HTML here:
https://github.com/quchen/articles/blob/master/monad_fail.md


Although this will technically a language-level change, the impact will
mainly be a library and fail-safety detail. For this reason I think this
mailing list is more suitable than other more specialized lists.


Greetings,
David/quchen


PS: I would have chosen Fail Removal Proposal so we have a new buzzword,
but unfortunately it does not abbreviate well. Call it the "fail of
Haskell issue"? ;-)







Removing `fail` from `Monad`
============================



The problem
-----------


Currently, the `<-` symbol is desugared as follows:

```haskell
do pat <- computation     >>>     let f pat = more
   more                   >>>         f _   = fail "..."
                          >>>     in  computation >>= f
```

The problem with this is that `fail` cannot be sensibly implemented for
many monads, for example `State`, `IO`, `Reader`. In those cases it
defaults to `error`, i.e. the monad has a built-in crash.



`MonadFail` class
-----------------

To fix this, introduce a new typeclass:

```haskell
class Monad m => MonadFail m where
      fail :: String -> m a
```

Desugaring is then changed to the following:

```haskell
-- Explicitly irrefutable pattern: do not add MonadFail constraint
do ~pat <- computation     >>>     let f pat = more
   more                    >>>     in  computation >>= f

-- Only one data constructor: do not add MonadFail constraint
do (Only x) <- computation     >>>     let f (Only x) = more
   more                        >>>     in  computation >>= f

-- Otherwise: add MonadFail constraint
do pat <- computation     >>>     let f pat = more
   more                   >>>         f _   = fail "..."
                          >>>     in  computation >>= f
```



Discussion
----------

- Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail`
class should be created. A parser might fail with an error message
involving positional information, and for STM failure is undefined
although it is `MonadPlus`.

- The case of one data constructor should emit a warning if the data
type is defined via `data`: adding another data constructor can make
patterns in unrelated modules refutable.

- Some monads use the pattern matching to force evaluation of the
binding, for example lazy/strict `StateT`. I'm not sure what exactly the
consequences of the above are here; I suspect a strictness annotation or
`(>>=)` instead of `do` notation might be sufficient.

- Getting the change to work should be boring but painless: all Monad
instance declarations involving `fail` will break because the function
is removed, and many monadic computations have to be annotated using `~`
because they were written under the assumption that `fail` is never
called. In both these cases compilation errors/warnings carry sufficient
information to fix the source code easily.

- Backwards compatibility with many old modules will be broken; I don't
see a way around this.



Other things to consider
------------------------

- Rename `fail`? It's quite a generic name that would be nice to have in
APIs. `failM`? `mfail`?

- Remove the `String` argument? (May hurt error reporting on pattern
mismatch ..?)

- How sensitive would existing code be to subtle changes in the
strictness behaviour of `do` notation pattern matching?



Applying the change
-------------------

Like the AMP,

1. Implement ad-hoc warnings that code will receive a `MonadFail`
constraint in a future version. "Either make the patterns irrefutable,
or keep in mind that the next compiler version will require a
`MonadFail` instance". Since `MonadFail` does not clash with an existing
name, it could be introduced to `Control.Monad` right away.

2. Do the switch.

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Dec 16 22:54:13 2013
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 16 Dec 2013 22:54:13 +0000
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF7E1F.4000606@gmail.com>
References: <52AF7E1F.4000606@gmail.com>
Message-ID: <20131216225413.GE8534@weber>

On Mon, Dec 16, 2013 at 11:26:39PM +0100, David Luposchainsky wrote:
> I feel like there are a couple of elephants in the room that are sort of
> important but nobody really addresses them directly. One of them was
> what became the AMP, and `fail` is another one.

Is it written up somewhere why pattern match failure in 'do' is a 'fail' but
pattern match failure elsewhere is just pattern match failure?

Malcolm Wallace mentioned that it convenient when writing parsers, and his
example is indeed neat, but is has someone done a more substantial
investigation the benefits of this special case?

Tom


From dluposchainsky at googlemail.com  Mon Dec 16 22:57:19 2013
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Mon, 16 Dec 2013 23:57:19 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF8112.80004@chalmers.se>
References: <52AF7E1F.4000606@gmail.com> <52AF8112.80004@chalmers.se>
Message-ID: <52AF854F.4070900@gmail.com>

Hey Andreas,

On 16.12.2013 23:39, Andreas Abel wrote:
> "Only one data constructor" should be understood hereditarily; the
> description is not entirely accurate:
> 
> -- Only one data constructor: do not add MonadFail constraint
> do (Only x) <- computation     >>>     let f (Only x) = more
>    more                        >>>     in  computation >>= f
> 
> (Only x) should be pat such that every constructor in pat is an
> "only-one" constructor.

Do you mean in case patterns of nested "Only" types appear, like
`Only (Only' x)`? I hadn't thought of that, good point.


>> - The case of one data constructor should emit a warning if the data
>> type is defined via `data`: adding another data constructor can make
>> patterns in unrelated modules refutable.
> 
> I don't understand the restriction "is defined via data" since I am not
> aware of defining constructors outside of data or with something other
> than the data keyword.  Please clarify.

I meant "data and not newtype". If "Only" is a newtype data constructor,
the pattern is irrefutable by design, is it not?


Greetings,
David/quchen

From roma at ro-che.info  Mon Dec 16 23:32:56 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 17 Dec 2013 01:32:56 +0200
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF854F.4070900@gmail.com>
References: <52AF7E1F.4000606@gmail.com> <52AF8112.80004@chalmers.se>
 <52AF854F.4070900@gmail.com>
Message-ID: <20131216233256.GA6089@sniper>

* David Luposchainsky <dluposchainsky at googlemail.com> [2013-12-16 23:57:19+0100]
> > I don't understand the restriction "is defined via data" since I am not
> > aware of defining constructors outside of data or with something other
> > than the data keyword.  Please clarify.
> 
> I meant "data and not newtype". If "Only" is a newtype data constructor,
> the pattern is irrefutable by design, is it not?

One notable case of one-constructor types defined not via data is
tuples. You certainly don't want warnings for that!

Regarding newtypes vs data, I'm not so sure it should make a difference.
It's customary to make one-field types newtypes, and then, if one
realizes that more fields are needed, turn them into proper data types.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131217/2322b653/attachment.sig>

From allbery.b at gmail.com  Mon Dec 16 23:33:55 2013
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 16 Dec 2013 18:33:55 -0500
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF7E1F.4000606@gmail.com>
References: <52AF7E1F.4000606@gmail.com>
Message-ID: <CAKFCL4VrpKp=WtOrxM79HytZxNhs+=Kz_VZphA8g_84vB9YBgg@mail.gmail.com>

On Mon, Dec 16, 2013 at 5:26 PM, David Luposchainsky <
dluposchainsky at googlemail.com> wrote:

> I feel like there are a couple of elephants in the room that are sort of
> important but nobody really addresses them directly. One of them was
> what became the AMP, and `fail` is another one.
>

AMP is done, except insofar as ghc 7.8 has not been released yet.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/d7a96eba/attachment-0001.html>

From dluposchainsky at googlemail.com  Mon Dec 16 23:39:05 2013
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 17 Dec 2013 00:39:05 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <CAKFCL4VrpKp=WtOrxM79HytZxNhs+=Kz_VZphA8g_84vB9YBgg@mail.gmail.com>
References: <52AF7E1F.4000606@gmail.com>
 <CAKFCL4VrpKp=WtOrxM79HytZxNhs+=Kz_VZphA8g_84vB9YBgg@mail.gmail.com>
Message-ID: <52AF8F19.9020309@gmail.com>

On 17.12.2013 00:33, Brandon Allbery wrote:
> AMP is done, except insofar as ghc 7.8 has not been released yet.

I heard about that, yes ;-)

(Before I proposed the AMP I had a similar feeling as a few hours ago,
that's why I mentioned it.)

David

From jwlato at gmail.com  Tue Dec 17 00:47:42 2013
From: jwlato at gmail.com (John Lato)
Date: Mon, 16 Dec 2013 16:47:42 -0800
Subject: Removing MonadFail from Monad
In-Reply-To: <20131216225413.GE8534@weber>
References: <52AF7E1F.4000606@gmail.com>
	<20131216225413.GE8534@weber>
Message-ID: <CAJ727Gi3jn4i0JcwgCcfERO3mXbQGE44p8L5cqkNVshP0AnxdA@mail.gmail.com>

On Mon, Dec 16, 2013 at 2:54 PM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Mon, Dec 16, 2013 at 11:26:39PM +0100, David Luposchainsky wrote:
> > I feel like there are a couple of elephants in the room that are sort of
> > important but nobody really addresses them directly. One of them was
> > what became the AMP, and `fail` is another one.
>
> Is it written up somewhere why pattern match failure in 'do' is a 'fail'
> but
> pattern match failure elsewhere is just pattern match failure?
>
> Malcolm Wallace mentioned that it convenient when writing parsers, and his
> example is indeed neat, but is has someone done a more substantial
> investigation the benefits of this special case?


AFAIK, it was done this way for list comprehensions.  Currently, you can
write e.g.

> rights = [x | Right x <- listOfEithers]

and it works properly. The list comprehension is desugared to

> do { Right x <- listOfEithers; return x }

which becomes

> do { listOfEithers >>= \l -> case l of { Right x -> return x; _ -> fail
"location" }}

since the Monad instance for lists defines fail = const [], everything
works out.  The nearly-equivalent code,

> listOfEithers >>= \(Right x) -> return x

indeed results in a PatternMatchFail exception.  The difference is that in
the former case, the fail method is called in lieu of the remainder of the
do-expression, whereas the lambda pattern match failure calls throw.
Throwing an exception wouldn't work for this because they can't be caught
outside IO.

(I think this applies to generalized monad comprehensions as well, although
I've never tried that)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131216/f3e97d30/attachment.html>

From vogt.adam at gmail.com  Tue Dec 17 00:50:33 2013
From: vogt.adam at gmail.com (adam vogt)
Date: Mon, 16 Dec 2013 19:50:33 -0500
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF7E1F.4000606@gmail.com>
References: <52AF7E1F.4000606@gmail.com>
Message-ID: <CAHfjoWk7NpA2=vZKRkzyvSyeEDB364aVdcNSb-kmWT3Vst1FNg@mail.gmail.com>

On Mon, Dec 16, 2013 at 5:26 PM, David Luposchainsky
<dluposchainsky at googlemail.com> wrote:
> Desugaring is then changed to the following:
>
> ```haskell
> -- Explicitly irrefutable pattern: do not add MonadFail constraint
> do ~pat <- computation     >>>     let f pat = more
>    more                    >>>     in  computation >>= f
>
> -- Only one data constructor: do not add MonadFail constraint
> do (Only x) <- computation     >>>     let f (Only x) = more
>    more                        >>>     in  computation >>= f
>
> -- Otherwise: add MonadFail constraint
> do pat <- computation     >>>     let f pat = more
>    more                   >>>         f _   = fail "..."
>                           >>>     in  computation >>= f
> ```

Hello David,

GHC can already do this for you. Only `f' below has no MonadFail in
the inferred type:

{-# LANGUAGE RebindableSyntax #-}
import Prelude hiding (fail)
class MonadFail m where fail :: String -> m a
f x = do x <- x; x
g x = do Just y <- return Nothing; x
h x = do (a, Just b) <- x; a

A specification for "pattern can fail given input that is fully
defined" outside of ghc might be
<http://hackage.haskell.org/package/applicative-quoters-0.1.0.8/docs/src/Control-Applicative-QQ-ADo.html#failingPattern>.
Otherwise I suppose section "3.17.2" of the 2010 report covers this
case.

Regards,
Adam

From andreas.abel at ifi.lmu.de  Tue Dec 17 09:38:48 2013
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 17 Dec 2013 10:38:48 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF854F.4070900@gmail.com>
References: <52AF7E1F.4000606@gmail.com> <52AF8112.80004@chalmers.se>
 <52AF854F.4070900@gmail.com>
Message-ID: <52B01BA8.6040204@ifi.lmu.de>

On 16.12.2013 23:57, David Luposchainsky wrote:
> On 16.12.2013 23:39, Andreas Abel wrote:
>> "Only one data constructor" should be understood hereditarily; the
>> description is not entirely accurate:
>>
>> -- Only one data constructor: do not add MonadFail constraint
>> do (Only x) <- computation     >>>     let f (Only x) = more
>>     more                        >>>     in  computation >>= f
>>
>> (Only x) should be pat such that every constructor in pat is an
>> "only-one" constructor.
>
> Do you mean in case patterns of nested "Only" types appear, like
> `Only (Only' x)`? I hadn't thought of that, good point.

Yes; its easy to give a grammar for "only-one" patterns:

   p ::= x              (variable)
       | C p1 ... pn    (C is the only constructor of its data/newtype)

>>> - The case of one data constructor should emit a warning if the data
>>> type is defined via `data`: adding another data constructor can make
>>> patterns in unrelated modules refutable.
>>
>> I don't understand the restriction "is defined via data" since I am not
>> aware of defining constructors outside of data or with something other
>> than the data keyword.  Please clarify.
>
> I meant "data and not newtype". If "Only" is a newtype data constructor,
> the pattern is irrefutable by design, is it not?

Of course, I tend to forget about newtype --- in my mind this is just a 
data with a single-field single constructor.  I never understood why 
there is a separate "newtype" syntax when the automatic inference of 
"being a newtype" is so trivial.  There may be some obscure reason like 
relying on a specific internal memory layout of data types in foreign 
function interfacing or so...

Cheers,
Andreas

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

From andreas.abel at ifi.lmu.de  Tue Dec 17 09:53:21 2013
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 17 Dec 2013 10:53:21 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <20131216233256.GA6089@sniper>
References: <52AF7E1F.4000606@gmail.com> <52AF8112.80004@chalmers.se>
 <52AF854F.4070900@gmail.com> <20131216233256.GA6089@sniper>
Message-ID: <52B01F11.7070002@ifi.lmu.de>

On 17.12.2013 00:32, Roman Cheplyaka wrote:
> * David Luposchainsky <dluposchainsky at googlemail.com> [2013-12-16 23:57:19+0100]
>>> I don't understand the restriction "is defined via data" since I am not
>>> aware of defining constructors outside of data or with something other
>>> than the data keyword.  Please clarify.
>>
>> I meant "data and not newtype". If "Only" is a newtype data constructor,
>> the pattern is irrefutable by design, is it not?
>
> One notable case of one-constructor types defined not via data is
> tuples. You certainly don't want warnings for that!

Should not tuple types be understood as

   data (,) a b = (,) a b
   data (,,) a b c = (,,) a b c

making them one-constructor types?!

> Regarding newtypes vs data, I'm not so sure it should make a difference.
> It's customary to make one-field types newtypes, and then, if one
> realizes that more fields are needed, turn them into proper data types.

I agree.  What operational semantics is concerned (this mean the 
execution model of Haskell in the programmer's mind),

   newtype = data

Cheers,
Andreas

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.


From roma at ro-che.info  Tue Dec 17 10:06:03 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 17 Dec 2013 12:06:03 +0200
Subject: Removing MonadFail from Monad
In-Reply-To: <52B01F11.7070002@ifi.lmu.de>
References: <52AF7E1F.4000606@gmail.com> <52AF8112.80004@chalmers.se>
 <52AF854F.4070900@gmail.com> <20131216233256.GA6089@sniper>
 <52B01F11.7070002@ifi.lmu.de>
Message-ID: <20131217100603.GA10092@sniper>

* Andreas Abel <andreas.abel at ifi.lmu.de> [2013-12-17 10:53:21+0100]
> On 17.12.2013 00:32, Roman Cheplyaka wrote:
> >* David Luposchainsky <dluposchainsky at googlemail.com> [2013-12-16 23:57:19+0100]
> >>>I don't understand the restriction "is defined via data" since I am not
> >>>aware of defining constructors outside of data or with something other
> >>>than the data keyword.  Please clarify.
> >>
> >>I meant "data and not newtype". If "Only" is a newtype data constructor,
> >>the pattern is irrefutable by design, is it not?
> >
> >One notable case of one-constructor types defined not via data is
> >tuples. You certainly don't want warnings for that!
> 
> Should not tuple types be understood as
> 
>   data (,) a b = (,) a b
>   data (,,) a b c = (,,) a b c
> 
> making them one-constructor types?!

You may think of it this way. But for the purposes of this proposal,
tuples shouldn't be treated like data types, because there's no
possibility they will every be extended with more constructors.

> >Regarding newtypes vs data, I'm not so sure it should make a difference.
> >It's customary to make one-field types newtypes, and then, if one
> >realizes that more fields are needed, turn them into proper data types.
> 
> I agree.  What operational semantics is concerned (this mean the
> execution model of Haskell in the programmer's mind),
> 
>   newtype = data

Not really. There's a semantic difference (both in operational and
denotational semantics) ? see http://www.haskell.org/haskellwiki/Newtype

Not that this is relevant for this discussion.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131217/1864a464/attachment.sig>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Dec 17 13:09:27 2013
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 17 Dec 2013 13:09:27 +0000
Subject: Removing MonadFail from Monad
In-Reply-To: <CAJ727Gi3jn4i0JcwgCcfERO3mXbQGE44p8L5cqkNVshP0AnxdA@mail.gmail.com>
References: <52AF7E1F.4000606@gmail.com> <20131216225413.GE8534@weber>
 <CAJ727Gi3jn4i0JcwgCcfERO3mXbQGE44p8L5cqkNVshP0AnxdA@mail.gmail.com>
Message-ID: <20131217130927.GL8534@weber>

On Mon, Dec 16, 2013 at 04:47:42PM -0800, John Lato wrote:
> On Mon, Dec 16, 2013 at 2:54 PM, Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> 
> > On Mon, Dec 16, 2013 at 11:26:39PM +0100, David Luposchainsky wrote:
> > > I feel like there are a couple of elephants in the room that are sort of
> > > important but nobody really addresses them directly. One of them was
> > > what became the AMP, and `fail` is another one.
> >
> > Is it written up somewhere why pattern match failure in 'do' is a 'fail'
> > but
> > pattern match failure elsewhere is just pattern match failure?
> >
> > Malcolm Wallace mentioned that it convenient when writing parsers, and his
> > example is indeed neat, but is has someone done a more substantial
> > investigation the benefits of this special case?
> 
> AFAIK, it was done this way for list comprehensions.  Currently, you can
> write e.g.
> 
> > rights = [x | Right x <- listOfEithers]
> 
> and it works properly.
[...]

Sure, but that then just raises the question "why was this special case
added for list comprehensions"?

To put it another way, if the original implementation of comprehensions and
do had treated pattern match failure just as pattern match failure, would a
proposal to switch to a 'fail' semantics stand a chance of being accepted? 
I'm not so sure.  Admittedly it allows for some neat code, but it really is
a very special case.

Tom

From dluposchainsky at googlemail.com  Tue Dec 17 13:18:25 2013
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 17 Dec 2013 14:18:25 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <20131217130927.GL8534@weber>
References: <52AF7E1F.4000606@gmail.com> <20131216225413.GE8534@weber>
 <CAJ727Gi3jn4i0JcwgCcfERO3mXbQGE44p8L5cqkNVshP0AnxdA@mail.gmail.com>
 <20131217130927.GL8534@weber>
Message-ID: <52B04F21.4070407@gmail.com>

On 17.12.2013 14:09, Tom Ellis wrote:

>> AFAIK, it was done this way for list comprehensions.  Currently, you can
>> write e.g.
>>
>>> rights = [x | Right x <- listOfEithers]
>>
>> and it works properly.
> 
> Sure, but that then just raises the question "why was this special case
> added for list comprehensions"?

List comprehensions are special.

- They have their own semantics in the report. Desugaring them to `do`
notation is a possible implementation, but I think GHC doesn't do that
for performance reasons (-XMonadComprehensions changes this).

- List comprehensions can always rely on the empty list to exist, there
is no analogon to this in an arbitrary monad. Translations to `do`
notation should leave semantics invariant.

David

From nad at cse.gu.se  Tue Dec 17 16:09:08 2013
From: nad at cse.gu.se (Nils Anders Danielsson)
Date: Tue, 17 Dec 2013 17:09:08 +0100
Subject: Removing MonadFail from Monad
In-Reply-To: <52AF7E1F.4000606@gmail.com>
References: <52AF7E1F.4000606@gmail.com>
Message-ID: <52B07724.3040003@cse.gu.se>

On 2013-12-16 23:26, David Luposchainsky wrote:
> -- Explicitly irrefutable pattern: do not add MonadFail constraint
> do ~pat <- computation     >>>     let f pat = more
>    more                    >>>     in  computation >>= f

Why not "f ~pat = more"?

-- 
/NAD

From dan.doel at gmail.com  Tue Dec 17 17:26:45 2013
From: dan.doel at gmail.com (Dan Doel)
Date: Tue, 17 Dec 2013 12:26:45 -0500
Subject: Removing MonadFail from Monad
In-Reply-To: <52B04F21.4070407@gmail.com>
References: <52AF7E1F.4000606@gmail.com> <20131216225413.GE8534@weber>
 <CAJ727Gi3jn4i0JcwgCcfERO3mXbQGE44p8L5cqkNVshP0AnxdA@mail.gmail.com>
 <20131217130927.GL8534@weber> <52B04F21.4070407@gmail.com>
Message-ID: <CAHEA9tNTRHxR4BfH=LMe8A+ojYyahNEZLxCQKu7gBpd19G7mwg@mail.gmail.com>

On Tue, Dec 17, 2013 at 8:18 AM, David Luposchainsky
<dluposchainsky at googlemail.com> wrote:
> List comprehensions are special.
>
> - They have their own semantics in the report. Desugaring them to `do`
> notation is a possible implementation, but I think GHC doesn't do that
> for performance reasons (-XMonadComprehensions changes this).

List comprehensions weren't special (i.e. specific to lists) in
Haskell 1.4. They worked like monad comprehensions. Then they were
changed to only work with lists in Haskell98 (and that is still the
way the standard is), which is why you need to enable an extension to
get monad comprehensions now (that it has been re-implemented).

And comprehensions, of course, have failure as a built-in notion, due
to guards. This was handled by MonadZero, as was pattern match
failure.

There was also a definition of unfailable patterns. A pattern was
unfailable if it could not be refuted except possibly by partially
defined values, as I recall. This makes irrefutable patterns trivially
unfailable, if you wish to force the issue. And GHC pretty clearly
still implements things this way, as seen in adam vogt's mail.

-- Dan

From tkn.akio at gmail.com  Wed Dec 18 07:15:57 2013
From: tkn.akio at gmail.com (Akio Takano)
Date: Wed, 18 Dec 2013 16:15:57 +0900
Subject: Proposal: die to System.Exit (and/or Prelude)
In-Reply-To: <87y53lxgtq.fsf@gnu.org>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
Message-ID: <CAOGQyFtvDtJvLw1aTTC9yRdk_CaV6FYrh=VQwOwCJ3Y4HdxXvQ@mail.gmail.com>

Hi,

On Mon, Dec 16, 2013 at 6:53 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

>
> Why not simply use the existing `fail :: String -> IO a` method instead?
>
> The differences & similiarities I see wrt `fail`:
>
>  - `die` throws an `ExitCode` exception, whereas `fail` throws an
>    `IOError` exception
>
>  - Both result in the message written to stderr and a non-zero exit code
>

One problem with 'fail' is that the error message is surrounded by "user
error (" and ")". This is ok for debugging, but it can be confusing for the
end user.

Add System.Exit.die:            +1
Re-export it from Prelude:      +0

Takano Akio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131218/e71b59ce/attachment.html>

From johan.tibell at gmail.com  Thu Dec 19 19:01:01 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 19 Dec 2013 20:01:01 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <878uw5d95l.fsf@gnu.org>
References: <CAK-tuPbmZG3uUU_AqpfqzriA-p+xdH1ZAx-_0vvsdHeEg+r_Ug@mail.gmail.com>
 <52988669.4070706@gmail.com>
 <CAK-tuPbBk_sgNp=V106=FOE89t18+LaE6_22zrcsMMZcCqqktA@mail.gmail.com>
 <5298A9B2.9080607@gmail.com>
 <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
Message-ID: <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>

We've reached the end of the discussion period. Most seemed in favor. Those
who suggested adding a new type class for these kind of functors, do you
feel OK not doing that (and use Monad =>) with the argument that this
distinction is probably too fine grained and having a separate class (which
people need to implement) would probably be more of a pain than it's worth?

-- Johan



On Sat, Nov 30, 2013 at 7:41 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2013-11-30 at 12:05:06 +0100, Roman Cheplyaka wrote:
> > * Nicolas Trangez <nicolas at incubaid.com> [2013-11-30 02:11:02+0100]
> >> I'm without a doubt overlooking something, but couldn't this be (otoh)
> >>
> >>     fmap' :: Functor f => (a -> b) -> f a -> f b
> >>     fmap' f = fmap (strictify f)
> >>       where
> >>         strictify s = (($!) id) . s
>
> > No. Evaluation of your 'strictify' function will be delayed for the very
> > same reason that evaluation of 'f' is delayed in the first place.
> >
> > It doesn't matter what 'strictify' *does* if it's not even evaluated.
>
> jfyi, if compiled with
>
>   ghc -O2 -dsuppress-all -dsuppress-uniques -ddump-simpl
>
> it can be seen that fmap' is really almost the same as a plain fmap,
> except for an left-over eta-expansion which ghc doesn't optimize away:
>
> fmap' = \ @ a @ b @ f $dFunctor f1 -> fmap $dFunctor (\ x -> f1 x)
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131219/c9982962/attachment.html>

From daniel.trstenjak at gmail.com  Fri Dec 20 08:15:54 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Fri, 20 Dec 2013 09:15:54 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
References: <52988669.4070706@gmail.com>
 <CAK-tuPbBk_sgNp=V106=FOE89t18+LaE6_22zrcsMMZcCqqktA@mail.gmail.com>
 <5298A9B2.9080607@gmail.com>
 <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
Message-ID: <20131220081554.GA2035@machine>


On Thu, Dec 19, 2013 at 08:01:01PM +0100, Johan Tibell wrote:
> We've reached the end of the discussion period. Most seemed in favor.
> Those who suggested adding a new type class for these kind of functors, do
> you feel OK not doing that (and use Monad =>) with the argument that this
> distinction is probably too fine grained and having a separate class
> (which people need to implement) would probably be more of a pain than
> it's worth?
> -- Johan

There are '$' and '$!', so it's just pity that '<$>' and '<$!>' would
break this naming consistency, because '<$!>' wouldn't be the strict
version of '<$>'.


Greetings,
Daniel

From johnw at fpcomplete.com  Fri Dec 20 09:22:26 2013
From: johnw at fpcomplete.com (John Wiegley)
Date: Fri, 20 Dec 2013 03:22:26 -0600
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <20131220081554.GA2035@machine> (Daniel Trstenjak's message of
 "Fri, 20 Dec 2013 09:15:54 +0100")
References: <52988669.4070706@gmail.com>
 <CAK-tuPbBk_sgNp=V106=FOE89t18+LaE6_22zrcsMMZcCqqktA@mail.gmail.com>
 <5298A9B2.9080607@gmail.com>
 <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
 <20131220081554.GA2035@machine>
Message-ID: <m2pporho6l.fsf@newartisans.com>

>>>>> Daniel Trstenjak <daniel.trstenjak at gmail.com> writes:

> There are '$' and '$!', so it's just pity that '<$>' and '<$!>' would break
> this naming consistency, because '<$!>' wouldn't be the strict version of
> '<$>'.

I agree with Daniel.

John

From johan.tibell at gmail.com  Fri Dec 20 09:50:24 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 20 Dec 2013 10:50:24 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <m2pporho6l.fsf@newartisans.com>
References: <52988669.4070706@gmail.com>
 <CAK-tuPbBk_sgNp=V106=FOE89t18+LaE6_22zrcsMMZcCqqktA@mail.gmail.com>
 <5298A9B2.9080607@gmail.com>
 <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
 <20131220081554.GA2035@machine> <m2pporho6l.fsf@newartisans.com>
Message-ID: <CAK-tuPYY2o0SehLVC19BRgkq=ierpT+S9F6FRG1VpaHezXGtVA@mail.gmail.com>

On Fri, Dec 20, 2013 at 10:22 AM, John Wiegley <johnw at fpcomplete.com> wrote:

> >>>>> Daniel Trstenjak <daniel.trstenjak at gmail.com> writes:
>
> > There are '$' and '$!', so it's just pity that '<$>' and '<$!>' would
> break
> > this naming consistency, because '<$!>' wouldn't be the strict version of
> > '<$>'.
>
> I agree with Daniel.
>

What would be the strict version of <$>?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131220/61a5565c/attachment.html>

From daniel.trstenjak at gmail.com  Fri Dec 20 10:57:59 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Fri, 20 Dec 2013 11:57:59 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <CAK-tuPYY2o0SehLVC19BRgkq=ierpT+S9F6FRG1VpaHezXGtVA@mail.gmail.com>
References: <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
 <20131220081554.GA2035@machine> <m2pporho6l.fsf@newartisans.com>
 <CAK-tuPYY2o0SehLVC19BRgkq=ierpT+S9F6FRG1VpaHezXGtVA@mail.gmail.com>
Message-ID: <20131220105759.GA11461@machine>


On Fri, Dec 20, 2013 at 10:50:24AM +0100, Johan Tibell wrote:
> What would be the strict version of <$>??

In my case, it's more about the intuition of the name '<$!>' and less
about the possibility of a strict version of '<$>'.


Greetings,
Daniel

From johan.tibell at gmail.com  Fri Dec 20 11:00:23 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 20 Dec 2013 12:00:23 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <20131220105759.GA11461@machine>
References: <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
 <20131220081554.GA2035@machine> <m2pporho6l.fsf@newartisans.com>
 <CAK-tuPYY2o0SehLVC19BRgkq=ierpT+S9F6FRG1VpaHezXGtVA@mail.gmail.com>
 <20131220105759.GA11461@machine>
Message-ID: <CAK-tuPZEnj3B0CAMKEKgjuNHUyKVLvQ0CbjsPZcJdJxR7y3Xqg@mail.gmail.com>

On Fri, Dec 20, 2013 at 11:57 AM, Daniel Trstenjak <
daniel.trstenjak at gmail.com> wrote:

>
> On Fri, Dec 20, 2013 at 10:50:24AM +0100, Johan Tibell wrote:
> > What would be the strict version of <$>?
>
> In my case, it's more about the intuition of the name '<$!>' and less
> about the possibility of a strict version of '<$>'.
>

What's unintuitive about the definition of <$!> above? It's seems like the
only sensible one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131220/6c9b2acd/attachment.html>

From ganesh at earth.li  Fri Dec 20 17:27:48 2013
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Fri, 20 Dec 2013 17:27:48 +0000
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <87ob4gyc34.fsf_-_@gnu.org>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org>
Message-ID: <52B47E14.9060507@earth.li>

On 16/12/2013 16:50, Herbert Valerio Riedel wrote:
> On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
>> On 16.12.2013 14:12, Roman Cheplyaka wrote:
>>>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>>>>> I consider explicit use of 'fail' in user code a hack.
>>>
>>> I treat 'fail' as a semi-private method of the Monad class. I may
>>> override it, but I should never call it. It only exists for the
>>> compiler.
>>
>> This is useful information.  Please add it to the documentation.  That
>> would definitely help newcomers to get some orientation in the design
>> space of exceptions...
> 
> [...]
> 
> If this is really the intent of `fail`, shouldn't we then also attach a
> 
>   {-# WARNING fail "Monad(fail) is not supposed to be called directly" #-}
> 
> to the `fail` method definition to help catch illegal uses of `fail` in
> user code?
> 
> (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
> libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
> if there's consensus, we could add that for GHC 7.8)

I'm not sure I follow the logic of this. If it does continue to exist,
what are the arguments against using it explicitly?

Cheers,

Ganesh


From rhymoid at gmail.com  Fri Dec 20 23:14:19 2013
From: rhymoid at gmail.com (Stijn van Drongelen)
Date: Sat, 21 Dec 2013 00:14:19 +0100
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <52B47E14.9060507@earth.li>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52B47E14.9060507@earth.li>
Message-ID: <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>

On Fri, Dec 20, 2013 at 6:27 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:

> On 16/12/2013 16:50, Herbert Valerio Riedel wrote:
> > On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
> >> On 16.12.2013 14:12, Roman Cheplyaka wrote:
> >>>>> The purpose of 'fail' is to handle monadic pattern-match failures.
> >>>>> I consider explicit use of 'fail' in user code a hack.
> >>>
> >>> I treat 'fail' as a semi-private method of the Monad class. I may
> >>> override it, but I should never call it. It only exists for the
> >>> compiler.
> >>
> >> This is useful information.  Please add it to the documentation.  That
> >> would definitely help newcomers to get some orientation in the design
> >> space of exceptions...
> >
> > [...]
> >
> > If this is really the intent of `fail`, shouldn't we then also attach a
> >
> >   {-# WARNING fail "Monad(fail) is not supposed to be called directly"
> #-}
> >
> > to the `fail` method definition to help catch illegal uses of `fail` in
> > user code?
> >
> > (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
> > libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
> > if there's consensus, we could add that for GHC 7.8)
>
> I'm not sure I follow the logic of this. If it does continue to exist,
> what are the arguments against using it explicitly?
>
> Cheers,
>
> Ganesh
>

Some monads have no sensible implementation for fail, so therefore, `fail`
can't be bound by any laws besides what's in the type. So when you're
writing common functions involving error handling, the type of `fail` gives
you some requirements on how to use it, but you get no promise that it does
something useful (note: `fail = error` is not useful).

However, when you use something like MonadError, you're guaranteed (by the
type) that you can use throwError, and promised (by those who create
instances for MonadError) that it will have a useful meaning.

(And this is just one of the reasons.)

Regards,
Stijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131221/7366e89d/attachment.html>

From ekmett at gmail.com  Sat Dec 21 00:58:53 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 20 Dec 2013 19:58:53 -0500
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52B47E14.9060507@earth.li>
 <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
Message-ID: <CAJumaK_pJ5t1+Uj7P_wYYD2c6MH82LHPbR=oGiXOwQoBoHANAg@mail.gmail.com>

I'm personally -1 on making explicit calls to fail into a warning.

That said I'd be more than happy to consider where we should put it if we
wanted to move it to another class on a sufficiently long time horizon to
moderate the community impact of that change.

-Edward


On Fri, Dec 20, 2013 at 6:14 PM, Stijn van Drongelen <rhymoid at gmail.com>wrote:

> On Fri, Dec 20, 2013 at 6:27 PM, Ganesh Sittampalam <ganesh at earth.li>wrote:
>
>> On 16/12/2013 16:50, Herbert Valerio Riedel wrote:
>> > On 2013-12-16 at 14:54:53 +0100, Andreas Abel wrote:
>> >> On 16.12.2013 14:12, Roman Cheplyaka wrote:
>> >>>>> The purpose of 'fail' is to handle monadic pattern-match failures.
>> >>>>> I consider explicit use of 'fail' in user code a hack.
>> >>>
>> >>> I treat 'fail' as a semi-private method of the Monad class. I may
>> >>> override it, but I should never call it. It only exists for the
>> >>> compiler.
>> >>
>> >> This is useful information.  Please add it to the documentation.  That
>> >> would definitely help newcomers to get some orientation in the design
>> >> space of exceptions...
>> >
>> > [...]
>> >
>> > If this is really the intent of `fail`, shouldn't we then also attach a
>> >
>> >   {-# WARNING fail "Monad(fail) is not supposed to be called directly"
>> #-}
>> >
>> > to the `fail` method definition to help catch illegal uses of `fail` in
>> > user code?
>> >
>> > (Fwiw, I've tested attaching such a warning to `fail` in GHC HEAD's
>> > libraries/base/GHC/Base.lhs and it seems to work just fine so far... so
>> > if there's consensus, we could add that for GHC 7.8)
>>
>> I'm not sure I follow the logic of this. If it does continue to exist,
>> what are the arguments against using it explicitly?
>>
>> Cheers,
>>
>> Ganesh
>>
>
> Some monads have no sensible implementation for fail, so therefore, `fail`
> can't be bound by any laws besides what's in the type. So when you're
> writing common functions involving error handling, the type of `fail` gives
> you some requirements on how to use it, but you get no promise that it does
> something useful (note: `fail = error` is not useful).
>
> However, when you use something like MonadError, you're guaranteed (by the
> type) that you can use throwError, and promised (by those who create
> instances for MonadError) that it will have a useful meaning.
>
> (And this is just one of the reasons.)
>
> Regards,
> Stijn
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131220/9dbe9615/attachment.html>

From dagitj at gmail.com  Sat Dec 21 02:08:44 2013
From: dagitj at gmail.com (Jason Dagit)
Date: Fri, 20 Dec 2013 18:08:44 -0800
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <CAJumaK_pJ5t1+Uj7P_wYYD2c6MH82LHPbR=oGiXOwQoBoHANAg@mail.gmail.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52B47E14.9060507@earth.li>
 <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
 <CAJumaK_pJ5t1+Uj7P_wYYD2c6MH82LHPbR=oGiXOwQoBoHANAg@mail.gmail.com>
Message-ID: <CAJ-DSywAVxDVMsbxhyo_9fS75K5mXiZqQQoxwSsKmGi9GqA_Pw@mail.gmail.com>

On Fri, Dec 20, 2013 at 4:58 PM, Edward Kmett <ekmett at gmail.com> wrote:

> I'm personally -1 on making explicit calls to fail into a warning.
>

I think it really depends on how the warning is enabled. I don't think it
should be part of -Wall, but I could see it being there for people that
want such things. And if you're going that route, shouldn't it be part of
hlint instead of ghc?

So, I think I just convinced myself that I'm -1 on this too :)

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131220/2707628b/attachment.html>

From ganesh at earth.li  Sat Dec 21 10:13:07 2013
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Sat, 21 Dec 2013 10:13:07 +0000
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52B47E14.9060507@earth.li>
 <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
Message-ID: <52B569B3.6010407@earth.li>

On 20/12/2013 23:14, Stijn van Drongelen wrote:

> Some monads have no sensible implementation for fail, so therefore,
> `fail` can't be bound by any laws besides what's in the type. So when
> you're writing common functions involving error handling, the type of
> `fail` gives you some requirements on how to use it, but you get no
> promise that it does something useful (note: `fail = error` is not useful).
> 
> However, when you use something like MonadError, you're guaranteed (by
> the type) that you can use throwError, and promised (by those who create
> instances for MonadError) that it will have a useful meaning.
> 
> (And this is just one of the reasons.)

But as long as it used for pattern match failures, those problems will
exist anyway - is using it explicitly any worse than writing incomplete
patterns in a do block?

Ganesh



From rhymoid at gmail.com  Sat Dec 21 10:29:21 2013
From: rhymoid at gmail.com (Stijn van Drongelen)
Date: Sat, 21 Dec 2013 11:29:21 +0100
Subject: Warn against using 'fail' directly in user-code
In-Reply-To: <52B569B3.6010407@earth.li>
References: <20131214105611.GA2849@x200> <87y53lxgtq.fsf@gnu.org>
 <20131216111527.GA21117@sniper>
 <CA+u6gbyU2ZQEbhxZA5iaZ_SLenXywqQPrb+QyNjtmi1dPhEp7A@mail.gmail.com>
 <20131216131229.GB28061@sniper> <52AF062D.3030403@ifi.lmu.de>
 <87ob4gyc34.fsf_-_@gnu.org> <52B47E14.9060507@earth.li>
 <CAGg6Gc50GFWTTRyunLSi-Md89a0EX5yXD6A=TSkRwF6B+60urQ@mail.gmail.com>
 <52B569B3.6010407@earth.li>
Message-ID: <CAGg6Gc7ypEyUoJ+fm3ywu2NCsQw=ZegD9hH6zRmORB+LCbkzZQ@mail.gmail.com>

On Dec 21, 2013 11:13 AM, "Ganesh Sittampalam" <ganesh at earth.li> wrote:
>
> On 20/12/2013 23:14, Stijn van Drongelen wrote:
>
> > Some monads have no sensible implementation for fail, so therefore,
> > `fail` can't be bound by any laws besides what's in the type. So when
> > you're writing common functions involving error handling, the type of
> > `fail` gives you some requirements on how to use it, but you get no
> > promise that it does something useful (note: `fail = error` is not
useful).
> >
> > However, when you use something like MonadError, you're guaranteed (by
> > the type) that you can use throwError, and promised (by those who create
> > instances for MonadError) that it will have a useful meaning.
> >
> > (And this is just one of the reasons.)
>
> But as long as it used for pattern match failures, those problems will
> exist anyway - is using it explicitly any worse than writing incomplete
> patterns in a do block?
>
> Ganesh

You're right that fail can be used sensibly when there'd be a pattern match
failure otherwise.

I was going to write that people use fail for other things as well, but I
just realize that the distinction between a pattern match failure and any
other failure 'based on a value' is very vague. Warning about fail but
allowing it implicitly is then a pretty unfounded solution.

So I change my +1 into a -1. Let's split fail off of Monad instead.

Thanks,
Stijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131221/660c0df8/attachment-0001.html>

From daniel.trstenjak at gmail.com  Sun Dec 22 09:38:51 2013
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Sun, 22 Dec 2013 10:38:51 +0100
Subject: Proposal: Add a strict version of <$> for monads
In-Reply-To: <CAK-tuPZEnj3B0CAMKEKgjuNHUyKVLvQ0CbjsPZcJdJxR7y3Xqg@mail.gmail.com>
References: <CAK-tuPY2rEkKW83=_119iGOtd-utVOS6EeZn9hh6ttJ-G9NGsw@mail.gmail.com>
 <CAHYVw0wk7HE7eo_jz4WibgFRkPoF7F_LgVp9_bfGinvS6onZxg@mail.gmail.com>
 <CAJumaK-98TP_rh_kF1iHcxgB2p3Q4WW=JHxiMZbyiVxDu-AMKQ@mail.gmail.com>
 <CABuTkcfZtQvsCwJbAvaKhOX=PGeQS1hr7-52wZtJJDq2ByJ8zw@mail.gmail.com>
 <20131130110506.GA4626@sniper> <878uw5d95l.fsf@gnu.org>
 <CAK-tuPaaQpLrDb8_3-mMeeEPa5+-SLJUQJMkZ6pq-qPYGtKKFA@mail.gmail.com>
 <20131220081554.GA2035@machine> <m2pporho6l.fsf@newartisans.com>
 <CAK-tuPYY2o0SehLVC19BRgkq=ierpT+S9F6FRG1VpaHezXGtVA@mail.gmail.com>
 <20131220105759.GA11461@machine>
 <CAK-tuPZEnj3B0CAMKEKgjuNHUyKVLvQ0CbjsPZcJdJxR7y3Xqg@mail.gmail.com>
Message-ID: <4F3601BA-4551-4500-8AC9-E284634C972B@gmail.com>

> What's unintuitive about the definition of <$!> above? It's seems like the only sensible one.

Well, call it bikeshedding, but '<$!>' would be defined for Monad and the name might
suggest, that it's defined for Functor.


From nominolo at googlemail.com  Sun Dec 22 10:32:20 2013
From: nominolo at googlemail.com (Thomas Schilling)
Date: Sun, 22 Dec 2013 11:32:20 +0100
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
Message-ID: <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>

Looks like GHC HQ maintains this package.  I don't think it'll make it
into the version released with 7.8, though.

I do have another question, though.  How should Haskell code using the
`unix` library check for whether `fsync` are implemented or not?  If I
call `fsync` I wouldn't want to get a runtime `error` call if the
platform doesn't support it.  Either I should be able to check at
compile time, or I should get a defined exception call which then must
be handled by the library.  In either case it should be documented
with the function.

On 12 December 2013 22:33, Ricardo Catalinas Jim?nez
<jimenezrick at gmail.com> wrote:
> If anyone else doesn't have any other objection, how should I proceed?
> Should I open a ticket in ghc's Trac asking for integration of this
> patch?
>
> Regards,
> /Ricardo
>
>
> On Wed, Dec 11, 2013 at 10:55 PM, Ricardo Catalinas Jim?nez
> <jimenezrick at gmail.com> wrote:
>> Shame on me! Wrong copy&paste from fsync to fdatasync... Fixed and
>> tested on Linux. Changelog corrected and commits squashed.
>>
>> Review:
>> https://github.com/jimenezrick/unix/compare/master...file-utils
>> /Ricardo
>>
>>
>> On Wed, Dec 11, 2013 at 4:00 PM, Thomas Schilling
>> <nominolo at googlemail.com> wrote:
>>> Also, adding a function should bump the third component, not the fourth.
>>>
>>> On 11 December 2013 16:57, Thomas Schilling <nominolo at googlemail.com> wrote:
>>>> There's a typo in line:
>>>>
>>>> +#ifndef HAVE_FDAYASYNC
>>>>
>>>> I assume it should read HAVE_FDATASYNC
>>>>
>>>> Did you try to compile this on a system that has fdatasync?
>>>>
>>>> On 7 December 2013 20:20, Ricardo Catalinas Jim?nez
>>>> <jimenezrick at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this pull request:
>>>>> https://github.com/jimenezrick/unix/compare/master...file-utils.patch
>>>>>
>>>>> If you find interesting this patch, then:
>>>>> git pull https://github.com/jimenezrick/unix.git file-utils
>>>>>
>>>>> /Ricardo
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/libraries

From haskell at fvisser.nl  Sun Dec 22 12:56:24 2013
From: haskell at fvisser.nl (Sebastiaan Visser)
Date: Sun, 22 Dec 2013 13:56:24 +0100
Subject: Adding a finalizer to a TVar
Message-ID: <F851A070-4CA3-4A46-89DA-5AE783F72311@fvisser.nl>

Hi,

Both MVar and IORef have specialized functions to attach a finalizer to there inner identifiable (stable) reference cell. I happen to need something similar for TVars, but that one doesn't seem to exist.

The documentation of System.Mem.Weak tells me:

 "Finalizers can be used reliably for types that are created explicitly and have identity, such as IORef and MVar. However, to place a finalizer on one of these types, you should use the specific operation provided for that type, e.g. mkWeakIORef and addMVarFinalizer respectively (the non-uniformity is accidental). These operations attach the finalizer to the primitive object inside the box (e.g. MutVar# in the case of IORef), because attaching the finalizer to the box itself fails when the outer box is optimised away by the compiler."

Does it make sense to add a similar function to the STM package?

What I do now is hack around it by adding an IORef next to my TVar which I attach the finalizer to. Because my outer datatype is opaque I expect both variables to go out of scope and get garbage collected simultaneously. As you might expect, this isn't a very satisfiable solution.

Thanks,
Sebastiaan

From hvr at gnu.org  Sun Dec 22 15:28:29 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 22 Dec 2013 16:28:29 +0100
Subject: Unavailable system functions in `unix` (was: Pull request for
 inclusion in `unix' module of fsync(2), fdatasync(2),
 posix_fadvise(2) and posix_fallocate(2))
In-Reply-To: <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 (Thomas Schilling's message of "Sun, 22 Dec 2013 11:32:20 +0100")
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
Message-ID: <87fvpkgb1e.fsf_-_@gnu.org>

On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
> Looks like GHC HQ maintains this package.  I don't think it'll make it
> into the version released with 7.8, though.

fwiw, I've been wanting to review that submission but didn't get to it
yet;

> I do have another question, though.  How should Haskell code using the
> `unix` library check for whether `fsync` are implemented or not?

there's a HsUnixConfig.h include file generated (and installed) you can
include from your Haskell code, and use CPP

> If I call `fsync` I wouldn't want to get a runtime `error` call if the
> platform doesn't support it.  

To be fair, `unix` does not seem consistent with respect to handling
potentially missing lib/syscalls; I've seen the following three cases:

 a) fallback to implement semantics via different calls
    (e.g. `System.Posix.Env.unsetEnv`), or
 
 b) the implementation returns bottom via an `error`-value
    (e.g. `System.Posix.Temp.mkstemps`), or

 c) the symbol is conditionally exported
    (e.g. `System.Posix.Directory.tellDirStream`)

> Either I should be able to check at compile time, or I should get a
> defined exception call which then must be handled by the library.  In
> either case it should be documented with the function.

It might be worth adding more information to the Haddock-comments
mentioning the respective `HAVE_*` CPP symbol and whether a
fallback-implementation is used.

Moreover, the use of `error` to signal non-existing implementations
could be reconsidered (e.g. maybe switch to a properly thrown
"call-not-implemented" exception)


From jwlato at gmail.com  Sun Dec 22 20:02:16 2013
From: jwlato at gmail.com (John Lato)
Date: Sun, 22 Dec 2013 12:02:16 -0800
Subject: Unavailable system functions in `unix` (was: Pull request for
 inclusion in `unix' module of fsync(2), fdatasync(2),
 posix_fadvise(2) and posix_fallocate(2))
In-Reply-To: <87fvpkgb1e.fsf_-_@gnu.org>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
Message-ID: <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>

On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
>
> On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
> > Looks like GHC HQ maintains this package.  I don't think it'll make it
> > into the version released with 7.8, though.
>
> fwiw, I've been wanting to review that submission but didn't get to it
> yet;
>
> > I do have another question, though.  How should Haskell code using the
> > `unix` library check for whether `fsync` are implemented or not?
>
> there's a HsUnixConfig.h include file generated (and installed) you can
> include from your Haskell code, and use CPP
>
> > If I call `fsync` I wouldn't want to get a runtime `error` call if the
> > platform doesn't support it.
>
> To be fair, `unix` does not seem consistent with respect to handling
> potentially missing lib/syscalls; I've seen the following three cases:
>
>  a) fallback to implement semantics via different calls
>     (e.g. `System.Posix.Env.unsetEnv`), or
>
>  b) the implementation returns bottom via an `error`-value
>     (e.g. `System.Posix.Temp.mkstemps`), or
>
>  c) the symbol is conditionally exported
>     (e.g. `System.Posix.Directory.tellDirStream`)
>
> > Either I should be able to check at compile time, or I should get a
> > defined exception call which then must be handled by the library.  In
> > either case it should be documented with the function.
>
> It might be worth adding more information to the Haddock-comments
> mentioning the respective `HAVE_*` CPP symbol and whether a
> fallback-implementation is used.
>
> Moreover, the use of `error` to signal non-existing implementations
> could be reconsidered (e.g. maybe switch to a properly thrown
> "call-not-implemented" exception)

This would definitely be better than calling error. Personally I would
prefer conditional exports, as it would turn up errors sooner.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131222/ac7c14df/attachment.html>

From jwlato at gmail.com  Sun Dec 22 20:10:54 2013
From: jwlato at gmail.com (John Lato)
Date: Sun, 22 Dec 2013 12:10:54 -0800
Subject: Adding a finalizer to a TVar
In-Reply-To: <F851A070-4CA3-4A46-89DA-5AE783F72311@fvisser.nl>
References: <F851A070-4CA3-4A46-89DA-5AE783F72311@fvisser.nl>
Message-ID: <CAJ727GhiHits1icO+ddKcRBye+saFHNi6uYcUwOUaU8pGLjCHg@mail.gmail.com>

On Dec 22, 2013 4:56 AM, "Sebastiaan Visser" <haskell at fvisser.nl> wrote:
>
> Hi,
>
> Both MVar and IORef have specialized functions to attach a finalizer to
there inner identifiable (stable) reference cell. I happen to need
something similar for TVars, but that one doesn't seem to exist.
>
> The documentation of System.Mem.Weak tells me:
>
>  "Finalizers can be used reliably for types that are created explicitly
and have identity, such as IORef and MVar. However, to place a finalizer on
one of these types, you should use the specific operation provided for that
type, e.g. mkWeakIORef and addMVarFinalizer respectively (the
non-uniformity is accidental). These operations attach the finalizer to the
primitive object inside the box (e.g. MutVar# in the case of IORef),
because attaching the finalizer to the box itself fails when the outer box
is optimised away by the compiler."
>
> Does it make sense to add a similar function to the STM package?
>
> What I do now is hack around it by adding an IORef next to my TVar which
I attach the finalizer to. Because my outer datatype is opaque I expect
both variables to go out of scope and get garbage collected simultaneously.
As you might expect, this isn't a very satisfiable solution.
>
> Thanks,
> Sebastiaan
>


I needed something similar a while ago, and wrote this (I think it's
correct, haven't had any problems at  any rate):

> {-# LANGUAGE MagicHash #-}
> {-# LANGUAGE UnboxedTuples #-}
>
> {-# OPTIONS_GHC -Wall #-}
> module Weak.TVar (
>   mkWeakTVar
> , mkWeakTVarKey
> ) where
>
> import GHC.Conc.Sync (TVar (..))
> import GHC.Weak
> import GHC.Base
>
> mkWeakTVar :: TVar a -> Maybe (IO ()) -> IO (Weak (TVar a))
> mkWeakTVar t f = mkWeakTVarKey t t f
>
> -- | Create a Weak reference keyed off a TVar.
> mkWeakTVarKey :: TVar b -> a -> Maybe (IO ()) -> IO (Weak a)
> mkWeakTVarKey (TVar r#) v (Just f) = IO $ \s ->
>       case mkWeak# r# v f s of (# s1, w #) -> (# s1, Weak w #)
> mkWeakTVarKey (TVar r#) v Nothing = IO $ \s ->
>       case mkWeakNoFinalizer# r# v s of (# s1, w #) -> (# s1, Weak w #)

Perhaps something similar would work for you until such a function is added?

(FWIW I support adding this function to the stm package)

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131222/0a286133/attachment.html>

From merijn at inconsistent.nl  Mon Dec 23 00:44:43 2013
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Mon, 23 Dec 2013 01:44:43 +0100
Subject: Adding a finalizer to a TVar
In-Reply-To: <CAJ727GhiHits1icO+ddKcRBye+saFHNi6uYcUwOUaU8pGLjCHg@mail.gmail.com>
References: <F851A070-4CA3-4A46-89DA-5AE783F72311@fvisser.nl>
 <CAJ727GhiHits1icO+ddKcRBye+saFHNi6uYcUwOUaU8pGLjCHg@mail.gmail.com>
Message-ID: <C0EAEFCC-2AC2-44C8-8A9B-4E680E7724FE@inconsistent.nl>

+1 on adding to stm, I need this too.

Cheers,
Merijn

On Dec 22, 2013, at 21:10 , John Lato wrote:
> On Dec 22, 2013 4:56 AM, "Sebastiaan Visser" <haskell at fvisser.nl> wrote:
> >
> > Hi,
> >
> > Both MVar and IORef have specialized functions to attach a finalizer to there inner identifiable (stable) reference cell. I happen to need something similar for TVars, but that one doesn't seem to exist.
> >
> > The documentation of System.Mem.Weak tells me:
> >
> >  "Finalizers can be used reliably for types that are created explicitly and have identity, such as IORef and MVar. However, to place a finalizer on one of these types, you should use the specific operation provided for that type, e.g. mkWeakIORef and addMVarFinalizer respectively (the non-uniformity is accidental). These operations attach the finalizer to the primitive object inside the box (e.g. MutVar# in the case of IORef), because attaching the finalizer to the box itself fails when the outer box is optimised away by the compiler."
> >
> > Does it make sense to add a similar function to the STM package?
> >
> > What I do now is hack around it by adding an IORef next to my TVar which I attach the finalizer to. Because my outer datatype is opaque I expect both variables to go out of scope and get garbage collected simultaneously. As you might expect, this isn't a very satisfiable solution.
> >
> > Thanks,
> > Sebastiaan
> >
> 
> 
> I needed something similar a while ago, and wrote this (I think it's correct, haven't had any problems at  any rate):
> 
> > {-# LANGUAGE MagicHash #-}
> > {-# LANGUAGE UnboxedTuples #-}
> > 
> > {-# OPTIONS_GHC -Wall #-}
> > module Weak.TVar (
> >   mkWeakTVar
> > , mkWeakTVarKey
> > ) where
> > 
> > import GHC.Conc.Sync (TVar (..))
> > import GHC.Weak
> > import GHC.Base
> > 
> > mkWeakTVar :: TVar a -> Maybe (IO ()) -> IO (Weak (TVar a))
> > mkWeakTVar t f = mkWeakTVarKey t t f
> >
> > -- | Create a Weak reference keyed off a TVar.
> > mkWeakTVarKey :: TVar b -> a -> Maybe (IO ()) -> IO (Weak a)
> > mkWeakTVarKey (TVar r#) v (Just f) = IO $ \s ->
> >       case mkWeak# r# v f s of (# s1, w #) -> (# s1, Weak w #)
> > mkWeakTVarKey (TVar r#) v Nothing = IO $ \s ->
> >       case mkWeakNoFinalizer# r# v s of (# s1, w #) -> (# s1, Weak w #)
> Perhaps something similar would work for you until such a function is added?
> (FWIW I support adding this function to the stm package)
> John L.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131223/0baa18d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131223/0baa18d1/attachment-0001.sig>

From johnw at fpcomplete.com  Mon Dec 23 03:37:44 2013
From: johnw at fpcomplete.com (John Wiegley)
Date: Sun, 22 Dec 2013 21:37:44 -0600
Subject: Adding a finalizer to a TVar
In-Reply-To: <C0EAEFCC-2AC2-44C8-8A9B-4E680E7724FE@inconsistent.nl> (Merijn
 Verstraaten's message of "Mon, 23 Dec 2013 01:44:43 +0100")
References: <F851A070-4CA3-4A46-89DA-5AE783F72311@fvisser.nl>
 <CAJ727GhiHits1icO+ddKcRBye+saFHNi6uYcUwOUaU8pGLjCHg@mail.gmail.com>
 <C0EAEFCC-2AC2-44C8-8A9B-4E680E7724FE@inconsistent.nl>
Message-ID: <m2lhzc44qf.fsf@newartisans.com>

>>>>> Merijn Verstraaten <merijn at inconsistent.nl> writes:

> +1 on adding to stm, I need this too.

+1

John

From k-bx at k-bx.com  Thu Dec 26 17:35:45 2013
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Thu, 26 Dec 2013 18:35:45 +0100
Subject: cabal sandboxes executable path
Message-ID: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>

Hi!

After I do `cabal install`, I get two binaries:
- in `dist/dist-sandbox-$ID/build/Foo/Foo`
- in `.cabal-sandbox/bin/Foo`

They seem to be different. Is this ok? Which one of them is the right one?

Sorry if I missed this in docs.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131226/e38362db/attachment.html>

From allbery.b at gmail.com  Thu Dec 26 18:00:52 2013
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 26 Dec 2013 13:00:52 -0500
Subject: cabal sandboxes executable path
In-Reply-To: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
Message-ID: <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>

On Thu, Dec 26, 2013 at 12:35 PM, Konstantine Rybnikov <k-bx at k-bx.com>wrote:

> After I do `cabal install`, I get two binaries:
> - in `dist/dist-sandbox-$ID/build/Foo/Foo`
> - in `.cabal-sandbox/bin/Foo`
>
> They seem to be different. Is this ok? Which one of them is the right one?
>

This isn't sandbox specific; you'll find that executables get staged under
dist/ in normal cabal builds and even when using the old `runhaskell
Setup.hs` method. This should be considered a temporary build file, like
everything else under dist/; the one in bin/ is the final executable.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131226/b3015269/attachment.html>

From k-bx at k-bx.com  Thu Dec 26 19:18:40 2013
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Thu, 26 Dec 2013 20:18:40 +0100
Subject: cabal sandboxes executable path
In-Reply-To: <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
 <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
Message-ID: <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>

Wow, this is a real surprise for me! Thank for clarifying that!

I hope it's just me who missed this important information. Could you please
share where was it described and how people know about it?

Thank you!


On Thu, Dec 26, 2013 at 7:00 PM, Brandon Allbery <allbery.b at gmail.com>wrote:

> On Thu, Dec 26, 2013 at 12:35 PM, Konstantine Rybnikov <k-bx at k-bx.com>wrote:
>
>> After I do `cabal install`, I get two binaries:
>> - in `dist/dist-sandbox-$ID/build/Foo/Foo`
>> - in `.cabal-sandbox/bin/Foo`
>>
>> They seem to be different. Is this ok? Which one of them is the right one?
>>
>
> This isn't sandbox specific; you'll find that executables get staged under
> dist/ in normal cabal builds and even when using the old `runhaskell
> Setup.hs` method. This should be considered a temporary build file, like
> everything else under dist/; the one in bin/ is the final executable.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131226/c9542996/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Dec 26 19:33:19 2013
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 26 Dec 2013 19:33:19 +0000
Subject: cabal sandboxes executable path
In-Reply-To: <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
 <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
 <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>
Message-ID: <20131226193319.GJ17875@weber>

On Thu, Dec 26, 2013 at 08:18:40PM +0100, Konstantine Rybnikov wrote:
> Wow, this is a real surprise for me! Thank for clarifying that!
> 
> I hope it's just me who missed this important information. Could you please
> share where was it described and how people know about it?

This is a surprise to me too.  What's the difference between the executable
in 'dist' and the final one?   What happens if I just do 'cabal build'?  Is
the final one not actually built?

Tom

From roma at ro-che.info  Fri Dec 27 00:02:29 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 27 Dec 2013 02:02:29 +0200
Subject: cabal sandboxes executable path
In-Reply-To: <20131226193319.GJ17875@weber>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
 <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
 <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>
 <20131226193319.GJ17875@weber>
Message-ID: <20131227000229.GA5062@sniper>

* Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> [2013-12-26 19:33:19+0000]
> On Thu, Dec 26, 2013 at 08:18:40PM +0100, Konstantine Rybnikov wrote:
> > Wow, this is a real surprise for me! Thank for clarifying that!
> > 
> > I hope it's just me who missed this important information. Could you please
> > share where was it described and how people know about it?
> 
> This is a surprise to me too.  What's the difference between the executable
> in 'dist' and the final one?   What happens if I just do 'cabal build'?  Is
> the final one not actually built?

In that case the executable is built (and placed under dist/), just not
copied to the final destination (such as ~/.cabal/bin or .cabal-sandbox/bin).

This is much like traditional make && make install.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131227/574f6561/attachment.sig>

From k-bx at k-bx.com  Fri Dec 27 07:21:39 2013
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Fri, 27 Dec 2013 08:21:39 +0100
Subject: cabal sandboxes executable path
In-Reply-To: <20131227000229.GA5062@sniper>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
 <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
 <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>
 <20131226193319.GJ17875@weber> <20131227000229.GA5062@sniper>
Message-ID: <CAAbahfSGYT3bPcP4gBgw94p3BHC5oxQPjb2pQvreag9iUjbpKQ@mail.gmail.com>

On Fri, Dec 27, 2013 at 1:02 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
> * Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> [2013-12-26 19:33:19+0000]
> > On Thu, Dec 26, 2013 at 08:18:40PM +0100, Konstantine Rybnikov wrote:
> > > Wow, this is a real surprise for me! Thank for clarifying that!
> > >
> > > I hope it's just me who missed this important information. Could you please
> > > share where was it described and how people know about it?
> >
> > This is a surprise to me too.  What's the difference between the executable
> > in 'dist' and the final one?   What happens if I just do 'cabal build'?  Is
> > the final one not actually built?
>
> In that case the executable is built (and placed under dist/), just not
> copied to the final destination (such as ~/.cabal/bin or .cabal-sandbox/bin).
>
> This is much like traditional make && make install.
>
> Roman
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

The problem here (for me at least) that they're different, it's not
just "copying". At least in size in my case (20mb and 30 mb, looks
like one is stripped, but what else?). So it's strange that in one
case dist/ contains "temporary build file that differs from end-one",
and then (on build) it contains actual binary.

I think we should at least make sure the files are equal (do all steps
in dist/ and then copy binary), or, if this is not acceptable, at
least write a note about that everywhere :)

Konstantine.

From roma at ro-che.info  Fri Dec 27 10:02:12 2013
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 27 Dec 2013 12:02:12 +0200
Subject: cabal sandboxes executable path
In-Reply-To: <CAAbahfSGYT3bPcP4gBgw94p3BHC5oxQPjb2pQvreag9iUjbpKQ@mail.gmail.com>
References: <CAAbahfQiwJ_xbmt_oZAknqeor+K+C=c1soBcD_ZrJbMAJcLwtQ@mail.gmail.com>
 <CAKFCL4WkvLR4287GJ8FGqswEXuVsC5xkqCSbg-aUy42WgUFh1A@mail.gmail.com>
 <CAAbahfSqFEf0LpfpGAAXJfQS7j1ostrejEC5-E20gpj6SWgvCg@mail.gmail.com>
 <20131226193319.GJ17875@weber> <20131227000229.GA5062@sniper>
 <CAAbahfSGYT3bPcP4gBgw94p3BHC5oxQPjb2pQvreag9iUjbpKQ@mail.gmail.com>
Message-ID: <20131227100212.GA11184@sniper>

* Konstantine Rybnikov <k-bx at k-bx.com> [2013-12-27 08:21:39+0100]
> On Fri, Dec 27, 2013 at 1:02 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> >
> > * Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> [2013-12-26 19:33:19+0000]
> > > On Thu, Dec 26, 2013 at 08:18:40PM +0100, Konstantine Rybnikov wrote:
> > > > Wow, this is a real surprise for me! Thank for clarifying that!
> > > >
> > > > I hope it's just me who missed this important information. Could you please
> > > > share where was it described and how people know about it?
> > >
> > > This is a surprise to me too.  What's the difference between the executable
> > > in 'dist' and the final one?   What happens if I just do 'cabal build'?  Is
> > > the final one not actually built?
> >
> > In that case the executable is built (and placed under dist/), just not
> > copied to the final destination (such as ~/.cabal/bin or .cabal-sandbox/bin).
> >
> > This is much like traditional make && make install.
> 
> The problem here (for me at least) that they're different, it's not
> just "copying". At least in size in my case (20mb and 30 mb, looks
> like one is stripped, but what else?).

Yes, it's stripped. Nothing else at the moment, from what I can tell:

  installBinary dest = do
    installExecutableFile verbosity
      (buildPref </> exeName exe </> exeFileName)
      (dest <.> exeExtension)
    when (stripExes lbi) $
      Strip.stripExe verbosity (withPrograms lbi) (dest <.> exeExtension)

(Distribution/Simple/GHC.hs)

> So it's strange that in one
> case dist/ contains "temporary build file that differs from end-one",
> and then (on build) it contains actual binary.

Not sure what you mean here. Stripping occurs after copying, in the
destination directory. The binary in dist/ is never stripped.

> I think we should at least make sure the files are equal (do all steps
> in dist/ and then copy binary), or, if this is not acceptable, at
> least write a note about that everywhere :)

Can you explain why this matters?

Stripping on install makes perfect sense. dist/ should only be used for
development purposes, so we're saving some time by not stripping.

OTOH, `cabal install` is clearly for installation/deployment.

Again, this is consistent with what make and make install have been
doing for a long time.

(BTW, I don't think libraries@ is the right list for this discussion.
It's for discussing changes to the core libraries.
haskell-cafe would be a better choice.)

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131227/39a0e8b5/attachment-0001.sig>

From jimenezrick at gmail.com  Fri Dec 27 15:22:57 2013
From: jimenezrick at gmail.com (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=)
Date: Fri, 27 Dec 2013 15:22:57 +0000
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
Message-ID: <CAFM17DsT=4BD1Ps=vNhxuK4KsbiEpuMrwpBt-9Mmm6zqwS+WPw@mail.gmail.com>

OK, all the new functions are conditionally exported. Branch and ticket
updated.

/Ricardo


On Sun, Dec 22, 2013 at 10:32 AM, Thomas Schilling
<nominolo at googlemail.com>wrote:

> Looks like GHC HQ maintains this package.  I don't think it'll make it
> into the version released with 7.8, though.
>
> I do have another question, though.  How should Haskell code using the
> `unix` library check for whether `fsync` are implemented or not?  If I
> call `fsync` I wouldn't want to get a runtime `error` call if the
> platform doesn't support it.  Either I should be able to check at
> compile time, or I should get a defined exception call which then must
> be handled by the library.  In either case it should be documented
> with the function.
>
> On 12 December 2013 22:33, Ricardo Catalinas Jim?nez
> <jimenezrick at gmail.com> wrote:
> > If anyone else doesn't have any other objection, how should I proceed?
> > Should I open a ticket in ghc's Trac asking for integration of this
> > patch?
> >
> > Regards,
> > /Ricardo
> >
> >
> > On Wed, Dec 11, 2013 at 10:55 PM, Ricardo Catalinas Jim?nez
> > <jimenezrick at gmail.com> wrote:
> >> Shame on me! Wrong copy&paste from fsync to fdatasync... Fixed and
> >> tested on Linux. Changelog corrected and commits squashed.
> >>
> >> Review:
> >> https://github.com/jimenezrick/unix/compare/master...file-utils
> >> /Ricardo
> >>
> >>
> >> On Wed, Dec 11, 2013 at 4:00 PM, Thomas Schilling
> >> <nominolo at googlemail.com> wrote:
> >>> Also, adding a function should bump the third component, not the
> fourth.
> >>>
> >>> On 11 December 2013 16:57, Thomas Schilling <nominolo at googlemail.com>
> wrote:
> >>>> There's a typo in line:
> >>>>
> >>>> +#ifndef HAVE_FDAYASYNC
> >>>>
> >>>> I assume it should read HAVE_FDATASYNC
> >>>>
> >>>> Did you try to compile this on a system that has fdatasync?
> >>>>
> >>>> On 7 December 2013 20:20, Ricardo Catalinas Jim?nez
> >>>> <jimenezrick at gmail.com> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Please review this pull request:
> >>>>>
> https://github.com/jimenezrick/unix/compare/master...file-utils.patch
> >>>>>
> >>>>> If you find interesting this patch, then:
> >>>>> git pull https://github.com/jimenezrick/unix.git file-utils
> >>>>>
> >>>>> /Ricardo
> >>>>> _______________________________________________
> >>>>> Libraries mailing list
> >>>>> Libraries at haskell.org
> >>>>> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131227/91b748ec/attachment.html>

From jimenezrick at gmail.com  Fri Dec 27 15:27:30 2013
From: jimenezrick at gmail.com (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=)
Date: Fri, 27 Dec 2013 15:27:30 +0000
Subject: Unavailable system functions in `unix` (was: Pull request for
 inclusion in `unix' module of fsync(2), fdatasync(2),
 posix_fadvise(2) and posix_fallocate(2))
In-Reply-To: <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
 <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
Message-ID: <CAFM17Ds27JFTU2T-eym9naTvE47-e0hObV6QXdSox_8KdkwY3Q@mail.gmail.com>

On Sun, Dec 22, 2013 at 8:02 PM, John Lato <jwlato at gmail.com> wrote:

>
> On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
> >
> > On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
> > > Looks like GHC HQ maintains this package.  I don't think it'll make it
> > > into the version released with 7.8, though.
> >
> > fwiw, I've been wanting to review that submission but didn't get to it
> > yet;
> >
> > > I do have another question, though.  How should Haskell code using the
> > > `unix` library check for whether `fsync` are implemented or not?
> >
> > there's a HsUnixConfig.h include file generated (and installed) you can
> > include from your Haskell code, and use CPP
> >
> > > If I call `fsync` I wouldn't want to get a runtime `error` call if the
> > > platform doesn't support it.
> >
> > To be fair, `unix` does not seem consistent with respect to handling
> > potentially missing lib/syscalls; I've seen the following three cases:
> >
> >  a) fallback to implement semantics via different calls
> >     (e.g. `System.Posix.Env.unsetEnv`), or
> >
> >  b) the implementation returns bottom via an `error`-value
> >     (e.g. `System.Posix.Temp.mkstemps`), or
> >
> >  c) the symbol is conditionally exported
> >     (e.g. `System.Posix.Directory.tellDirStream`)
> >
> > > Either I should be able to check at compile time, or I should get a
> > > defined exception call which then must be handled by the library.  In
> > > either case it should be documented with the function.
> >
> > It might be worth adding more information to the Haddock-comments
> > mentioning the respective `HAVE_*` CPP symbol and whether a
> > fallback-implementation is used.
> >
> > Moreover, the use of `error` to signal non-existing implementations
> > could be reconsidered (e.g. maybe switch to a properly thrown
> > "call-not-implemented" exception)
>
> This would definitely be better than calling error. Personally I would
> prefer conditional exports, as it would turn up errors sooner.
>
> John L.
>

OK, sounds good. Now everything is conditionally exported:

https://github.com/jimenezrick/unix/compare/master...file-utils.patch

Yeah, the unix library is messy as it is having to much preprocessor
infection and different ways of handling this situations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131227/25fd728f/attachment.html>

From haskell at benmachine.co.uk  Sat Dec 28 00:11:40 2013
From: haskell at benmachine.co.uk (Ben Millwood)
Date: Sat, 28 Dec 2013 00:11:40 +0000
Subject: Unavailable system functions in `unix` (was: Pull request for
 inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and
 posix_fallocate(2))
In-Reply-To: <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
 <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
Message-ID: <20131228001140.GA28557@srcf.ucam.org>

On Sun, Dec 22, 2013 at 12:02:16PM -0800, John Lato wrote:
>On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
>>
>> On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
>> > Either I should be able to check at compile time, or I should get a
>> > defined exception call which then must be handled by the library.  In
>> > either case it should be documented with the function.
>>
>> It might be worth adding more information to the Haddock-comments
>> mentioning the respective `HAVE_*` CPP symbol and whether a
>> fallback-implementation is used.
>>
>> Moreover, the use of `error` to signal non-existing implementations
>> could be reconsidered (e.g. maybe switch to a properly thrown
>> "call-not-implemented" exception)
>
>This would definitely be better than calling error. Personally I would
>prefer conditional exports, as it would turn up errors sooner.
>
>John L.

What does client code look like, if this is your implementation 
strategy? Note that the network package recently changed to *stop* 
conditionally exporting things, because it led to bad error messages 
(yes, your error is caught at compile time, but it's not so clear what 
it *is*) and ugly client code. See e.g. 
https://github.com/haskell/network/issues/40

From hvr at gnu.org  Sat Dec 28 10:04:04 2013
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sat, 28 Dec 2013 11:04:04 +0100
Subject: Unavailable system functions in `unix`
In-Reply-To: <20131228001140.GA28557@srcf.ucam.org> (Ben Millwood's message of
 "Sat, 28 Dec 2013 00:11:40 +0000")
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
 <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
 <20131228001140.GA28557@srcf.ucam.org>
Message-ID: <87iou91ecr.fsf@gnu.org>

On 2013-12-28 at 01:11:40 +0100, Ben Millwood wrote:
> On Sun, Dec 22, 2013 at 12:02:16PM -0800, John Lato wrote:
>>On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
>>>
>>> On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
>>> > Either I should be able to check at compile time, or I should get a
>>> > defined exception call which then must be handled by the library.  In
>>> > either case it should be documented with the function.
>>>
>>> It might be worth adding more information to the Haddock-comments
>>> mentioning the respective `HAVE_*` CPP symbol and whether a
>>> fallback-implementation is used.
>>>
>>> Moreover, the use of `error` to signal non-existing implementations
>>> could be reconsidered (e.g. maybe switch to a properly thrown
>>> "call-not-implemented" exception)
>>
>>This would definitely be better than calling error. Personally I would
>>prefer conditional exports, as it would turn up errors sooner.
>>
>>John L.
>
> What does client code look like, if this is your implementation
> strategy? Note that the network package recently changed to *stop*
> conditionally exporting things, because it led to bad error messages
> (yes, your error is caught at compile time, but it's not so clear what
> it *is*) and ugly client code. See
> e.g. https://github.com/haskell/network/issues/40

btw, as a compromise, one could export the symbol always (even if its
body is exception-throwing stub) and at the same time enable a '{-#
WARNING #-}' for that symbol for the not-implemented; that way one gets
both, a stable API as well as compile-time warnings...


From svenpanne at gmail.com  Sat Dec 28 15:30:05 2013
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 28 Dec 2013 16:30:05 +0100
Subject: Pull request for inclusion in `unix' module of fsync(2),
 fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAFM17DsT=4BD1Ps=vNhxuK4KsbiEpuMrwpBt-9Mmm6zqwS+WPw@mail.gmail.com>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <CAFM17DsT=4BD1Ps=vNhxuK4KsbiEpuMrwpBt-9Mmm6zqwS+WPw@mail.gmail.com>
Message-ID: <CANBN=mty5ktLpG__sDb2eotNvxTu8_nSYYj8m4FABLwM-9yiyA@mail.gmail.com>

2013/12/27 Ricardo Catalinas Jim?nez <jimenezrick at gmail.com>:
> OK, all the new functions are conditionally exported. Branch and ticket
> updated.

Hmmm, I don't really like conditional exports in libraries, because
you have no clue in advance if things will compile or not. How is one
supposed to check for this? Do we have a 'hautoconf'' ? :-} I know
that there are already conditional exports, but this doesn't make it
better.

From jwlato at gmail.com  Sat Dec 28 19:24:37 2013
From: jwlato at gmail.com (John Lato)
Date: Sat, 28 Dec 2013 11:24:37 -0800
Subject: Unavailable system functions in `unix` (was: Pull request for
 inclusion in `unix' module of fsync(2), fdatasync(2),
 posix_fadvise(2) and posix_fallocate(2))
In-Reply-To: <20131228001140.GA28557@srcf.ucam.org>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
 <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
 <20131228001140.GA28557@srcf.ucam.org>
Message-ID: <CAJ727GhZPTLYw5hSu4n0Wq6tj7jqU7rEz3uAxuZE0=2ZAPCLOw@mail.gmail.com>

On Fri, Dec 27, 2013 at 4:11 PM, Ben Millwood <haskell at benmachine.co.uk>wrote:

> On Sun, Dec 22, 2013 at 12:02:16PM -0800, John Lato wrote:
>
>> On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
>>
>>>
>>> On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
>>> > Either I should be able to check at compile time, or I should get a
>>> > defined exception call which then must be handled by the library.  In
>>> > either case it should be documented with the function.
>>>
>>> It might be worth adding more information to the Haddock-comments
>>> mentioning the respective `HAVE_*` CPP symbol and whether a
>>> fallback-implementation is used.
>>>
>>> Moreover, the use of `error` to signal non-existing implementations
>>> could be reconsidered (e.g. maybe switch to a properly thrown
>>> "call-not-implemented" exception)
>>>
>>
>> This would definitely be better than calling error. Personally I would
>> prefer conditional exports, as it would turn up errors sooner.
>>
>> John L.
>>
>
> What does client code look like, if this is your implementation strategy?
> Note that the network package recently changed to *stop* conditionally
> exporting things, because it led to bad error messages (yes, your error is
> caught at compile time, but it's not so clear what it *is*) and ugly client
> code. See e.g. https://github.com/haskell/network/issues/40
>

These days I pretty much exclusively work on linux systems, so my client
code is pretty clean :)

I would consider that example from the network package a different
situation.  Conditionally-defined data types are not the same as a function
that might not be exported.  If you're serializing/logging, it makes
perfect sense to enumerate values that aren't supported locally for
example, and I can see that working around that could lead to really ugly
client code.  But I don't think it makes much sense to export a function
that just calls error if it's unsupported.  Handling an exception is at
least as awkward as CPP in that case, and in practice worse because we
can't differentiate between error calls except by matching on the message
string.  At least a custom exception would solve that problem.  But for me,
conditional exports are still better.  A big advantage for us is that when
we update our toolchain (e.g. a new ghc release comes out), it's much
faster to find problems in the toolchain build by just typechecking code
rather than actually needing to run executables to test every
possibly-defined function we might call (of course we do end-to-end testing
as well, but this is a case where errors arising sooner leads to
significantly less work).

As an alternative, how about throwing an exception, but also using CPP to
add a WARNING pragma to any function that's system-unavailable?  Then we'd
get a good message at compile-time.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131228/b8c71c69/attachment.html>

From jwlato at gmail.com  Sun Dec 29 23:41:47 2013
From: jwlato at gmail.com (John Lato)
Date: Sun, 29 Dec 2013 15:41:47 -0800
Subject: Unavailable system functions in `unix`
In-Reply-To: <87iou91ecr.fsf@gnu.org>
References: <CAFM17Dvc=pciL0hJ7+s91xJdYs523t2E3gmsdB+kt4hoc1rd-g@mail.gmail.com>
 <CAOJG3uBeTE1uAHDXEnTRJynALen5su_xkxkBA_QQ6imwBv+8zw@mail.gmail.com>
 <CAOJG3uBdV5nQC8KKE+73LhfTo-UQ6027fmL2CY1hUuxoO-_9xw@mail.gmail.com>
 <CAFM17DtX9ni2fBFDuQOqM+LvHHFjZ6Kp+cYk-NS9M6MNUf4A3g@mail.gmail.com>
 <CAFM17Dt+ZAmrTfU9E6RB1k_n2TLD3yjBJAugd6-=uFw5xD1kig@mail.gmail.com>
 <CAOJG3uCahOUN6gjfDazTL1phq19D8tjwwqweBQm_+VDKX148Cw@mail.gmail.com>
 <87fvpkgb1e.fsf_-_@gnu.org>
 <CAJ727GgjC_4D31vgGXhyVHxLM8-wvMugG_woVm1XL0gyCOOcng@mail.gmail.com>
 <20131228001140.GA28557@srcf.ucam.org> <87iou91ecr.fsf@gnu.org>
Message-ID: <CAJ727GiAVHonPVa0pPO+uKG0UjYFfC9yRxbbb5BzhLFMhdQd4g@mail.gmail.com>

On Sat, Dec 28, 2013 at 2:04 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2013-12-28 at 01:11:40 +0100, Ben Millwood wrote:
> > On Sun, Dec 22, 2013 at 12:02:16PM -0800, John Lato wrote:
> >>On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <hvr at gnu.org> wrote:
> >>>
> >>> On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:
> >>> > Either I should be able to check at compile time, or I should get a
> >>> > defined exception call which then must be handled by the library.  In
> >>> > either case it should be documented with the function.
> >>>
> >>> It might be worth adding more information to the Haddock-comments
> >>> mentioning the respective `HAVE_*` CPP symbol and whether a
> >>> fallback-implementation is used.
> >>>
> >>> Moreover, the use of `error` to signal non-existing implementations
> >>> could be reconsidered (e.g. maybe switch to a properly thrown
> >>> "call-not-implemented" exception)
> >>
> >>This would definitely be better than calling error. Personally I would
> >>prefer conditional exports, as it would turn up errors sooner.
> >>
> >>John L.
> >
> > What does client code look like, if this is your implementation
> > strategy? Note that the network package recently changed to *stop*
> > conditionally exporting things, because it led to bad error messages
> > (yes, your error is caught at compile time, but it's not so clear what
> > it *is*) and ugly client code. See
> > e.g. https://github.com/haskell/network/issues/40
>
> btw, as a compromise, one could export the symbol always (even if its
> body is exception-throwing stub) and at the same time enable a '{-#
> WARNING #-}' for that symbol for the not-implemented; that way one gets
> both, a stable API as well as compile-time warnings...
>
> I didn't see this before I replied to Ben, but I think this is a fine
solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131229/5fa78363/attachment.html>