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

[Edward Kmett]

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
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131002/8e72a664/attachment.html>