Proposal: unify constant functors

[wren ng thornton]

Hello all,

I recently (re)noticed the following duplication:

     base:Control.Applicative
         newtype Const a b = Const { getConst :: a }
         instance Functor (Const m) where...
         instance Monoid m => Applicative (Const m) where...

     transformers:Data.Functor.Constant
         newtype Constant a b = Constant { getConstant :: a }
         instance Functor (Constant a) where...
         instance Foldable (Constant a) where...
         instance Traversable (Constant a) where...
         instance (Monoid a) => Applicative (Constant a) where...

I don't see any reason for this redundancy. I propose we:

     (1) add the Foldable and Traversable instances to base, and
     (2) deprecate transformers:Data.Functor.Constant

This will cause breakage to any orphan instances of Foldable/Traversable
for Const, but that seems fine by me. Eventually we'll want to remove
transformers:Data.Functor.Constant (or have it re-export the Const stuff
from base:Control.Applicative); but that can be handled later.

Deadline: 14 May 2012.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward Z. Yang]

+1, seems reasonable.

Edward

Excerpts from wren ng thornton's message of Mon Apr 30 01:33:39 -0400 2012:

> Hello all,
>
> I recently (re)noticed the following duplication:
>
>      base:Control.Applicative
>          newtype Const a b = Const { getConst :: a }
>          instance Functor (Const m) where...
>          instance Monoid m => Applicative (Const m) where...
>
>      transformers:Data.Functor.Constant
>          newtype Constant a b = Constant { getConstant :: a }
>          instance Functor (Constant a) where...
>          instance Foldable (Constant a) where...
>          instance Traversable (Constant a) where...
>          instance (Monoid a) => Applicative (Constant a) where...
>
> I don't see any reason for this redundancy. I propose we:
>
>      (1) add the Foldable and Traversable instances to base, and
>      (2) deprecate transformers:Data.Functor.Constant
>
> This will cause breakage to any orphan instances of Foldable/Traversable
> for Const, but that seems fine by me. Eventually we'll want to remove
> transformers:Data.Functor.Constant (or have it re-export the Const stuff
> from base:Control.Applicative); but that can be handled later.
>
> Deadline: 14 May 2012.
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Bas van Dijk-2]

On 30 April 2012 07:33, wren ng thornton <[hidden email]> wrote:
>    (1) add the Foldable and Traversable instances to base, and

+1

>    (2) deprecate transformers:Data.Functor.Constant

+1.

I assume you want to re-export Control.Applicative.Constant from
Data.Functor.Constant and deprecate the whole module as in:

module Data.Functor.Constant
  {-# DEPRECATED "Import Constant from Control.Applicative instead" #-}
  ( Constant(..) ) where

import Control.Applicative

Bas

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ross Paterson]

On Mon, Apr 30, 2012 at 10:55:51AM +0100, Bas van Dijk wrote:

> On 30 April 2012 07:33, wren ng thornton <[hidden email]> wrote:
> >    (1) add the Foldable and Traversable instances to base, and
>
> +1
>
> >    (2) deprecate transformers:Data.Functor.Constant
>
> +1.
>
> I assume you want to re-export Control.Applicative.Constant from
> Data.Functor.Constant and deprecate the whole module as in:
>
> module Data.Functor.Constant
>   {-# DEPRECATED "Import Constant from Control.Applicative instead" #-}
>   ( Constant(..) ) where
>
> import Control.Applicative

Not quite, as the one in Control.Applicative is called Const and the
one in Data.Functor.Constant is called Constant.  I slightly prefer the
full name.  Maybe just move Data.Functor.Constant into base (removing
the copy in Control.Applicative)?

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Andreas Abel]

On 30.04.12 1:56 PM, Ross Paterson wrote:
> On Mon, Apr 30, 2012 at 10:55:51AM +0100, Bas van Dijk wrote:
>> On 30 April 2012 07:33, wren ng thornton<[hidden email]>  wrote:
>>>     (1) add the Foldable and Traversable instances to base, and

+1

>>>     (2) deprecate transformers:Data.Functor.Constant
>>
>> I assume you want to re-export Control.Applicative.Constant from
>> Data.Functor.Constant and deprecate the whole module as in:
>>
>> module Data.Functor.Constant
>>    {-# DEPRECATED "Import Constant from Control.Applicative instead" #-}
>>    ( Constant(..) ) where
>>
>> import Control.Applicative
>
> Not quite, as the one in Control.Applicative is called Const and the
> one in Data.Functor.Constant is called Constant.  I slightly prefer the
> full name.  Maybe just move Data.Functor.Constant into base (removing
> the copy in Control.Applicative)?

I'd second that.  All I get from Const in Control.Applicative is import
conflicts.  The full name, 'Constant' is better.

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

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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Brent Yorgey-2]

On Mon, Apr 30, 2012 at 01:33:39AM -0400, wren ng thornton wrote:

> Hello all,
>
> I recently (re)noticed the following duplication:
>
>     base:Control.Applicative
>         newtype Const a b = Const { getConst :: a }
>         instance Functor (Const m) where...
>         instance Monoid m => Applicative (Const m) where...
>
>     transformers:Data.Functor.Constant
>         newtype Constant a b = Constant { getConstant :: a }
>         instance Functor (Constant a) where...
>         instance Foldable (Constant a) where...
>         instance Traversable (Constant a) where...
>         instance (Monoid a) => Applicative (Constant a) where...
>
> I don't see any reason for this redundancy. I propose we:
>
>     (1) add the Foldable and Traversable instances to base, and
>     (2) deprecate transformers:Data.Functor.Constant

Why do it this way?  For backwards compatibility?  It seems to me it
would be much more consistent to remove the one in
Control.Applicative and have all the fundamental functor combinators
in one place.

-Brent

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Jon Fairbairn]

Andreas Abel <[hidden email]> writes:

> I'd second that.  All I get from Const in
> Control.Applicative is import conflicts.  The full name,
> Constant is better.

+1
--
Jón Fairbairn                                 [hidden email]



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

+1 for going Brent and Ross's way, (removing Const from Control.Applicative and moving Data.Functor.Constant into base) but overall happy with the idea no matter how we do it.

I prefer the separate module approach because there are many other similar functors that we may want to migrate into base over time, and it wouldn't make sense to have one of them hiding in Control.Applicative.

-Edward

On Mon, Apr 30, 2012 at 8:38 AM, Brent Yorgey <[hidden email]> wrote:

On Mon, Apr 30, 2012 at 01:33:39AM -0400, wren ng thornton wrote:
> Hello all,
>
> I recently (re)noticed the following duplication:
>
>     base:Control.Applicative
>         newtype Const a b = Const { getConst :: a }
>         instance Functor (Const m) where...
>         instance Monoid m => Applicative (Const m) where...
>
>     transformers:Data.Functor.Constant
>         newtype Constant a b = Constant { getConstant :: a }
>         instance Functor (Constant a) where...
>         instance Foldable (Constant a) where...
>         instance Traversable (Constant a) where...
>         instance (Monoid a) => Applicative (Constant a) where...
>
> I don't see any reason for this redundancy. I propose we:
>
>     (1) add the Foldable and Traversable instances to base, and
>     (2) deprecate transformers:Data.Functor.Constant

Why do it this way?  For backwards compatibility?  It seems to me it
would be much more consistent to remove the one in
Control.Applicative and have all the fundamental functor combinators
in one place.

-Brent

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ben Moseley]

+1 for the Brent / Ross approach.

--Ben

On 1 May 2012, at 19:43, Edward Kmett wrote:

+1 for going Brent and Ross's way, (removing Const from Control.Applicative and moving Data.Functor.Constant into base) but overall happy with the idea no matter how we do it.

I prefer the separate module approach because there are many other similar functors that we may want to migrate into base over time, and it wouldn't make sense to have one of them hiding in Control.Applicative.

-Edward

On Mon, Apr 30, 2012 at 8:38 AM, Brent Yorgey <[hidden email]> wrote:

On Mon, Apr 30, 2012 at 01:33:39AM -0400, wren ng thornton wrote:
> Hello all,
>
> I recently (re)noticed the following duplication:
>
>     base:Control.Applicative
>         newtype Const a b = Const { getConst :: a }
>         instance Functor (Const m) where...
>         instance Monoid m => Applicative (Const m) where...
>
>     transformers:Data.Functor.Constant
>         newtype Constant a b = Constant { getConstant :: a }
>         instance Functor (Constant a) where...
>         instance Foldable (Constant a) where...
>         instance Traversable (Constant a) where...
>         instance (Monoid a) => Applicative (Constant a) where...
>
> I don't see any reason for this redundancy. I propose we:
>
>     (1) add the Foldable and Traversable instances to base, and
>     (2) deprecate transformers:Data.Functor.Constant

Why do it this way?  For backwards compatibility?  It seems to me it
would be much more consistent to remove the one in
Control.Applicative and have all the fundamental functor combinators
in one place.

-Brent

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Simon Hengel]

> +1 for going Brent and Ross's way, (removing Const from Control.Applicative
> and moving Data.Functor.Constant into base)

I'd prefer if Control.Applicative.Const would only be deprecated (for
now).

    {-# DEPRECATED Const "use Data.Functor.Constant.Constant instead" #-}

Otherwise, +1.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Conor McBride-2]

On 1 May 2012, at 19:43, Edward Kmett wrote:

> +1 for going Brent and Ross's way, (removing Const from Control.Applicative and moving Data.Functor.Constant into base) but overall happy with the idea no matter how we do it.

I think this is sensible, but I'm mildly inclined to plead for a much
shorter name: K. I realise it would be completely inappropriate to
use convenient names based on combinatory logic in a programming
language called Haskell, but frankly, every time I have to type
"onstant" I feel like giving someone a "dentity".

If, as I am, you are given to constructing types from polynomials

type BinarySearchTree = Mu (K () :+: (I :*: K Int :*: I))

readability is helped by short names. The many wonderful closure
properties of polynomial functors give lots of standard equipment
(traversability, zippers,...) for free.

Of course, this is something of a minority sport. But it might be
worth thinking about how Constant fits into a bigger picture in
order to design its place in the ecosystem.

All the best

Conor

>
> I prefer the separate module approach because there are many other similar functors that we may want to migrate into base over time, and it wouldn't make sense to have one of them hiding in Control.Applicative.
>
> -Edward
>
> On Mon, Apr 30, 2012 at 8:38 AM, Brent Yorgey <[hidden email]> wrote:
> On Mon, Apr 30, 2012 at 01:33:39AM -0400, wren ng thornton wrote:
>> Hello all,
>>
>> I recently (re)noticed the following duplication:
>>
>>   base:Control.Applicative
>>       newtype Const a b = Const { getConst :: a }
>>       instance Functor (Const m) where...
>>       instance Monoid m => Applicative (Const m) where...
>>
>>   transformers:Data.Functor.Constant
>>       newtype Constant a b = Constant { getConstant :: a }
>>       instance Functor (Constant a) where...
>>       instance Foldable (Constant a) where...
>>       instance Traversable (Constant a) where...
>>       instance (Monoid a) => Applicative (Constant a) where...
>>
>> I don't see any reason for this redundancy. I propose we:
>>
>>   (1) add the Foldable and Traversable instances to base, and
>>   (2) deprecate transformers:Data.Functor.Constant
>
> Why do it this way?  For backwards compatibility?  It seems to me it
> would be much more consistent to remove the one in
> Control.Applicative and have all the fundamental functor combinators
> in one place.
>
> -Brent
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 4/30/12 8:05 AM, Andreas Abel wrote:

> On 30.04.12 1:56 PM, Ross Paterson wrote:
>> On Mon, Apr 30, 2012 at 10:55:51AM +0100, Bas van Dijk wrote:
>>> On 30 April 2012 07:33, wren ng thornton<[hidden email]> wrote:
>>>> (1) add the Foldable and Traversable instances to base, and
>
> +1
>
>>>> (2) deprecate transformers:Data.Functor.Constant
>>>
>>> I assume you want to re-export Control.Applicative.Constant from
>>> Data.Functor.Constant and deprecate the whole module as in:
>>>
>>> module Data.Functor.Constant
>>> {-# DEPRECATED "Import Constant from Control.Applicative instead" #-}
>>> ( Constant(..) ) where
>>>
>>> import Control.Applicative
>>
>> Not quite, as the one in Control.Applicative is called Const and the
>> one in Data.Functor.Constant is called Constant. I slightly prefer the
>> full name. Maybe just move Data.Functor.Constant into base (removing
>> the copy in Control.Applicative)?
>
> I'd second that. All I get from Const in Control.Applicative is import
> conflicts. The full name, 'Constant' is better.

I rather prefer the short name m'self. Where do you get the import
conflicts from?


For the record, I'd be fine with moving Data.Functor.Constant to base (I
rather prefer that as the module name, as opposed to exporting it from
Control.Applicative), I was just proposing the smallest change that
would resolve the duplication.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 4/30/12 8:38 AM, Brent Yorgey wrote:

> On Mon, Apr 30, 2012 at 01:33:39AM -0400, wren ng thornton wrote:
>> Hello all,
>>
>> I recently (re)noticed the following duplication:
>>
>>      base:Control.Applicative
>>          newtype Const a b = Const { getConst :: a }
>>          instance Functor (Const m) where...
>>          instance Monoid m =>  Applicative (Const m) where...
>>
>>      transformers:Data.Functor.Constant
>>          newtype Constant a b = Constant { getConstant :: a }
>>          instance Functor (Constant a) where...
>>          instance Foldable (Constant a) where...
>>          instance Traversable (Constant a) where...
>>          instance (Monoid a) =>  Applicative (Constant a) where...
>>
>> I don't see any reason for this redundancy. I propose we:
>>
>>      (1) add the Foldable and Traversable instances to base, and
>>      (2) deprecate transformers:Data.Functor.Constant
>
> Why do it this way?  For backwards compatibility?  It seems to me it
> would be much more consistent to remove the one in
> Control.Applicative and have all the fundamental functor combinators
> in one place.

I think that Const/Constant should be in base because it's such a
primitive thing and used all over the place. Other than that, I was
mainly aiming for minimal breakage in resolving the duplication.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 5/2/12 6:36 AM, Conor McBride wrote:

>
> On 1 May 2012, at 19:43, Edward Kmett wrote:
>
>> +1 for going Brent and Ross's way, (removing Const from Control.Applicative and moving Data.Functor.Constant into base) but overall happy with the idea no matter how we do it.
>
> I think this is sensible, but I'm mildly inclined to plead for a much
> shorter name: K. I realise it would be completely inappropriate to
> use convenient names based on combinatory logic in a programming
> language called Haskell, but frankly, every time I have to type
> "onstant" I feel like giving someone a "dentity".

Indeed. I'm fine with Const (we don't call the value-level function k,
afterall), but Constant is just too much. Ditto for the excessively
lengthy naming of the identity functor. For things this basic and this
widely used, all that verbosity gives me flashbacks to coding in Java.

I don't think I'll argue for the combinatory names, but I certainly
wouldn't argue against them either.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Henning Thielemann]

On Thu, 3 May 2012, wren ng thornton wrote:

> I think that Const/Constant should be in base because it's such a primitive
> thing and used all over the place. Other than that, I was mainly aiming for
> minimal breakage in resolving the duplication.

I just wanted to ask, where you need it. I have never used it. How can I
improve my code with it?

Independent from this question I am concerned with putting so much into
'base'. 'transformers' can be updated independent from the compiler, and
'base' cannot. Thus for me, 'Constant' in 'transformers' has the right
name (understandable to the casual user) in the right place.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Henning Thielemann]

On Thu, 3 May 2012, wren ng thornton wrote:

> Indeed. I'm fine with Const (we don't call the value-level function k,
> afterall), but Constant is just too much. Ditto for the excessively lengthy
> naming of the identity functor. For things this basic and this widely used,
> all that verbosity gives me flashbacks to coding in Java.

It's not all bad in imperative languages ...

Do you really use "Identity" everywhere? I use it only implicitly as part
of transformers:State monads and friends.

Identity's meaning is immediately clear. 'Ident' or 'Id' could also be
'identifier'.

'Const' could also mean 'constructor'.

I also prefer 'Integer' to \mathbb{Z} and 'Rational' to \mathbb{Q}.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 5/3/12 7:23 PM, Henning Thielemann wrote:
>
> On Thu, 3 May 2012, wren ng thornton wrote:
>
>> Indeed. I'm fine with Const (we don't call the value-level function k,
>> afterall), but Constant is just too much. Ditto for the excessively
>> lengthy naming of the identity functor. For things this basic and this
>> widely used, all that verbosity gives me flashbacks to coding in Java.
>
> It's not all bad in imperative languages ...

There's a difference between imperative programming in general, and Java
programming in particular ;)


> Do you really use "Identity" everywhere? I use it only implicitly as
> part of transformers:State monads and friends.

Everywhere would be an exaggeration, but I do use it rather frequently.
It helps reduce boilerplate when you want both pure and
monadic/functorial (i.e., *->*) versions of things and don't care too
much about performance. It's the monad of choice when instantiating
rank-2 quantifiers. It's a primitive of generic programming with
polynomial types, as Conor mentioned. etc.


> Identity's meaning is immediately clear. 'Ident' or 'Id' could also be
> 'identifier'.
>
> 'Const' could also mean 'constructor'.
>
> I also prefer 'Integer' to \mathbb{Z} and 'Rational' to \mathbb{Q}.

Should we rename 'id' to 'identity' and 'const' to 'constant' then? The
purported confusion is exactly the same since there must be values to
inhabit your identity and constructor types. If anything, you're only
making an argument for K and I in lieu of Const and Id.

I'm fine with Integer, in virtue of the fact that it's unbounded and we
have Int for the bounded version, so the lengthiness of the name
actually conveys valuable information. Rational is in a similar position
in virtue of the Ratio type it's an alias for. In mathematics I refer to
those types often enough that having the names \mathbb{N}, \mathbb{Z},
\mathbb{Q}, \mathbb{R}, \mathbb{C},... is extremely helpful for brevity
and clarity. In programming, I use them infrequently enough (compared to
other types) that little would be gained by such brevity.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 5/3/12 7:18 PM, Henning Thielemann wrote:
>
> On Thu, 3 May 2012, wren ng thornton wrote:
>
>> I think that Const/Constant should be in base because it's such a
>> primitive thing and used all over the place. Other than that, I was
>> mainly aiming for minimal breakage in resolving the duplication.
>
> I just wanted to ask, where you need it. I have never used it. How can I
> improve my code with it?

Again, it's primitive for generic programming with polynomial types. I
often use it to lift types of kind * into types of kind *->* which is
frequently necessary for generic programming. The code I was working on
when I noticed the duplication uses it to instantiate a rank-2
quantifier in order to get rid of an existential type.


> Independent from this question I am concerned with putting so much into
> 'base'. 'transformers' can be updated independent from the compiler, and
> 'base' cannot. Thus for me, 'Constant' in 'transformers' has the right
> name (understandable to the casual user) in the right place.

Since transformers is in the Haskell Platform, it doesn't especially
matter to me. But this is the sort of thing that belongs in an extended
prelude, much like Data.List and other modules from before the era of
hierarchical module names. The code for the constant functor isn't
liable to change by much, the only reason for it to change would be to
add new instances for new classes in base (since other classes could
provide the instance when defining the class itself), so the fact that
it's in a boot library isn't much of a burden. Whether GHC actually uses
it internally may settle the matter, however.

Even the casual user will recognize Const as a capitalized version of
the const function from the Prelude.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Andreas Abel]

As I see, we have run in a discussion about identifiers and whether to
abbreviate.  While in math every defined symbol should have at most 3
letters, in information technology one tends to spell out names because
there is such an abundant amount of concepts.  [And, of course, because
typing on a keyboard is much faster than handwriting on a chalkboard.]

I think libraries, and in particular standard libraries should prefer to
spell out identifiers, unless the abbreviation has secured its status
due to a long tradition already.

I do not see that for 'Const'.

P.S.: I'd prefer to use Const for my own, internal/throw-away data
types, this is why I talked about "import conflicts" in my previous message.

P.P.S.:  All of discussion would be superfluous if import statements had
a renaming option like in Agda.

   open import Data.Functor.Constant renaming (Constant to K)

Maybe that could be a feature of future Haskell as well?

On 04.05.12 2:12 AM, wren ng thornton wrote:

> On 5/3/12 7:18 PM, Henning Thielemann wrote:
>>
>> On Thu, 3 May 2012, wren ng thornton wrote:
>>
>>> I think that Const/Constant should be in base because it's such a
>>> primitive thing and used all over the place. Other than that, I was
>>> mainly aiming for minimal breakage in resolving the duplication.
>>
>> I just wanted to ask, where you need it. I have never used it. How can I
>> improve my code with it?
>
> Again, it's primitive for generic programming with polynomial types. I
> often use it to lift types of kind * into types of kind *->* which is
> frequently necessary for generic programming. The code I was working on
> when I noticed the duplication uses it to instantiate a rank-2
> quantifier in order to get rid of an existential type.
>
>
>> Independent from this question I am concerned with putting so much into
>> 'base'. 'transformers' can be updated independent from the compiler, and
>> 'base' cannot. Thus for me, 'Constant' in 'transformers' has the right
>> name (understandable to the casual user) in the right place.
>
> Since transformers is in the Haskell Platform, it doesn't especially
> matter to me. But this is the sort of thing that belongs in an extended
> prelude, much like Data.List and other modules from before the era of
> hierarchical module names. The code for the constant functor isn't
> liable to change by much, the only reason for it to change would be to
> add new instances for new classes in base (since other classes could
> provide the instance when defining the class itself), so the fact that
> it's in a boot library isn't much of a burden. Whether GHC actually uses
> it internally may settle the matter, however.
>
> Even the casual user will recognize Const as a capitalized version of
> the const function from the Prelude.
>

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

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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[wren ng thornton]

On 5/4/12 10:44 AM, Andreas Abel wrote:
> open import Data.Functor.Constant renaming (Constant to K)
>
> Maybe that could be a feature of future Haskell as well?

I would love such a feature. Not just for bikeshedding disputes, but as
an alternative to qualified imports for when you're intentionally using
different things with conflicting names.

Seems like it should be easy enough to implement too (sayeth he who
hasn't hacked on GHC). The real difficulty methinks would be in
specifying the module import syntax, since there's a conflict between
(1) creating a coherent integrated system for qualified, unqualified,
renamed, explicit, and hidden imports (plus any other features we want
to add at the same time); and (2) backwards compatibility.

--
Live well,
~wren

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries