Export ($!) from Data.Function

older
Applicative instance of ExceptT is...

Yuras Shumovich

24 Apr 2015 24 Apr '15

8:29 a.m.

Hello, Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it. There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude. Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator. Thanks, Yuras

Show replies by date

Ivan Lazar Miljenovic

24 Apr 24 Apr

8:56 a.m.

On 24 April 2015 at 22:29, Yuras Shumovich wrote:

...

Hello,

Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it.

There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude.

Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator.

Except $! is already exported by Prelude, so it's likely to break code by removing it from there.

...

Thanks, Yuras

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Yuras Shumovich

9:06 a.m.

On Fri, 2015-04-24 at 22:56 +1000, Ivan Lazar Miljenovic wrote:

...

On 24 April 2015 at 22:29, Yuras Shumovich wrote:

...
Hello,

Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it.

There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude.

Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator.

Except $! is already exported by Prelude, so it's likely to break code by removing it from there.

I propose to export ($!) from Data.Function. I don't propose to remove it from Prelude. Just like ($) is already exported from both Prelude and Data.Function. PS: sorry, I typed Data.Functor in the initial email body. The correct module name is Data.Function.

...

...
Thanks, Yuras

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

9:51 a.m.

On Fri, 24 Apr 2015, Yuras Shumovich wrote:

...

Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it.

There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude.

I don't understand. If you don't like to import it, you can import Prelude hiding (($!)) If you have disabled automatic import of Prelude, you can still import it selectively by: import Prelude (($!))

...

Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator.

I think it would better fit in a module for 'seq' and friends. Unfortunately there is no such module yet.

David Feuer

10:09 a.m.

Agreed. I think it would be nice to gather up seq-things and par-things into a nice piece of module hierarchy in some fashion. I make no claim to know how to do so nicely. On Fri, Apr 24, 2015 at 9:51 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

On Fri, 24 Apr 2015, Yuras Shumovich wrote:

Right now ($!) operator can be imported either from Prelude or GHC.Base.

...
The later is specific to GHC, so it makes sense to avoid it.

There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude.

I don't understand. If you don't like to import it, you can import Prelude hiding (($!))

If you have disabled automatic import of Prelude, you can still import it selectively by: import Prelude (($!))

Data.Functor seems to be a good candidate for ($!) operator home module.

...
It already exports ($) operator.

I think it would better fit in a module for 'seq' and friends. Unfortunately there is no such module yet.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Yuras Shumovich

10:18 a.m.

On Fri, 2015-04-24 at 15:51 +0200, Henning Thielemann wrote:

...

On Fri, 24 Apr 2015, Yuras Shumovich wrote:

...
Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it.

There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude.

I don't understand. If you don't like to import it, you can import Prelude hiding (($!))

If you have disabled automatic import of Prelude, you can still import it selectively by: import Prelude (($!))

That is what I'm doing right now. It is too noisy because there is a number of identifiers that live only in Prelude: error, undefined, seq, etc. I believe they should eventually get their homes too.

...

...
Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator.

I think it would better fit in a module for 'seq' and friends. Unfortunately there is no such module yet.

My argument for Data.Function was to unify it with ($), but Data.Evaluate or something similar is OK for me too. Thanks, Yuras.

3679

Age (days ago)

3679

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

David Feuer
Henning Thielemann
Ivan Lazar Miljenovic
Yuras Shumovich