[Proposal] Renaming (:=:) to (==)

[Erik Hesselink]

I still think there's a case to be made for having type and value
level functions have the same name. We'll already have things like (+)
have the same name on both levels. It might be confusing if other
things don't have the same name on both levels.

Erik

On Thu, Oct 3, 2013 at 5:07 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Thanks for pointing this out, Edward. I think consistency within the type
> level is more important than consistency between the type level and the term
> level. So, if we settle on a convention that a symbol ending in `?` means
> Boolean-valued and other symbols mean constraints, I'm all for making the
> change to (==).
>
> I'm not aware of a wide poll on the names in TypeLits, so we shouldn't
> necessarily just follow that lead. That said, the above proposal about `?`
> seems sensible to me. If we decide to do this, we should find somewhere
> (where??) to articulate this.
>
> Richard
>
> On Oct 2, 2013, at 9:28 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
> GHC.TypeLits code looks to be using (<=?) as the boolean valued version of
> the predicate and (<=) for the assertion.
>
> This points to a coming disagreement over style across the different parts
> of GHC itself, if we're saying that the principle reason for not using (==)
> is that we want it to be the boolean valued version.
>
> -Edward
>
>
> On Mon, Sep 30, 2013 at 4:03 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> Agreed.
>>
>>
>> On Monday, September 30, 2013, Edward A Kmett wrote:
>>>
>>> I think if someone went through the effort of writing a patch so you
>>> could at least introduce local operator names with an explicit forall, like
>>> with ScopedTypeVariables and the proposed explicit type applications then
>>> it'd probably be accepted.
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 30, 2013, at 2:25 PM, Conal Elliott <conal at conal.net> wrote:
>>>
>>> -1.
>>>
>>> I'm hoping we don't get more deeply invested in the syntactic change in
>>> GHC 7.6 that removed the possibility of symbolic type variables ("~>", "*",
>>> "+", etc). I had a new job and wasn't paying attention when SPJ polled the
>>> community. From my perspective, the loss has much greater scope than the
>>> gain for type level naturals. I'd like to keep the door open to the
>>> possibility of bringing back the old notation with the help of a language
>>> pragma. It would take a few of us to draft a proposal addressing details.
>>>
>>> Not at all meaning to start a syntax debate on this thread. Just an
>>> explanation of my -1 for the topic at hand.
>>>
>>> - Conal
>>>
>>> -- Conal
>>>
>>>
>>> On Sat, Sep 28, 2013 at 9:57 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>>>
>>>> As part of the discussion about Typeable, GHC 7.8 is going to include a
>>>> Data.Type.Equality module that provides a polykinded type equality data
>>>> type.
>>>>
>>>> I'd like to propose that we rename this type to (==) rather than the
>>>> (:=:) it was developed under.
>>>>
>>>> We are already using (+), (-), (*), etc. at the type level in type-nats,
>>>> so it would seem to fit the surrounding convention.
>>>>
>>>> I've done the work of preparing a patch, visible here:
>>>>
>>>>
>>>> https://github.com/ekmett/packages-base/commit/fb47f8368ad3d40fdd79bdeec334c0554fb17110
>>>>
>>>> Thoughts?
>>>>
>>>> Normally, I'd let this run the usual 2 week course, but we're getting
>>>> down to the wire for 7.8's release. Once 7.8 ships, we'd basically be stuck
>>>> with the current name forever.
>>>>
>>>> Discussion Period: 1 week
>>>>
>>>> -Edward Kmett
>>>>
>>>> _______________________________________________
>>>> 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
>