add map back to Functor

[Carter Schonwald]

and the alluded extension / pragma idea would be for equi typed names,not
for anyting fancy about type subsumption

On Mon, Feb 11, 2019 at 1:14 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> no, map should have the more general type :)
>
> On Sat, Feb 9, 2019 at 11:28 PM Ryan Reich <ryan.reich at gmail.com> wrote:
>
>> ...which is a problem, because you can't distinguish code that was
>> written (either before or after the pragma is introduced) with the
>> assumption of a list in mind from code (written after the pragma is
>> introduced) that intends to use the generalized type signature.  This is
>> different from the situation created by `instance Functor [] where {fmap =
>> map}`, which introduces a specialization of `fmap` rather than a
>> generalization of `map`.
>>
>> On Sat, Feb 9, 2019 at 8:15 PM Ryan Reich <ryan.reich at gmail.com> wrote:
>>
>>> This pragma needs to have a type inference guarantee that the old
>>> signature `map :: (a -> b) -> [a] -> [b]` is applied even after subsituting
>>> `fmap :: (Functor f) => (a -> b) -> f a -> f b`.  There must be
>>> approximately one zillion ad-hoc functions out there written without type
>>> signatures that implicitly depend on inferring a list.
>>>
>>> On Fri, Feb 8, 2019 at 11:33 AM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> You make a good point, we should cook up this desired magic pragma!
>>>>
>>>> Could you sketch out 1-2 examples of what you’d want this pragma to do?
>>>>
>>>> Something like
>>>> {-# method_synonym_of fmap map #-}
>>>> ?
>>>> This would sort of be like a sort of duplicate record field for how
>>>> names are mapped to definitions?
>>>> This example would be “fmap is an alias of map”
>>>>
>>>>
>>>> On Fri, Feb 8, 2019 at 1:46 PM Edward Kmett <ekmett at gmail.com> wrote:
>>>>
>>>>> The real problem with this sketch of a proposal is the lack of a nice
>>>>> migration plan.
>>>>>
>>>>> If it is top level and just calls fmap, then the distinction requires
>>>>> random rote memorization of which one you can define.
>>>>>
>>>>> On the other hand, say you put it in Functor today as an extra member.
>>>>> Currently everybody has definitions in terms of `fmap`, so you'd need to
>>>>> make the two definitions mutual. This would mean enlarging the dictionaries
>>>>> for one of the most common structures in Haskell for a rather far flung
>>>>> removal that breaks everyone.
>>>>>
>>>>> If we had a way (say a pragma or other syntactic form) to say that
>>>>> fmap and map were somehow the 'same name' or something and so that defining
>>>>> one was the same as defining the other, so that this tax didn't exist, I
>>>>> could see how we might get there.
>>>>>
>>>>> That sort of "magic" might be useful for making migration plans to get
>>>>> sequenceA to be sequence and mapM and traverse without requiring folks to
>>>>> memorize which one is in the class and which is a top level definition.
>>>>>
>>>>> Without something like that, I'd remain somewhat inclined against
>>>>> concocting a complicated migration plan to save one letter.
>>>>>
>>>>> -Edward
>>>>>
>>>>> On Fri, Feb 8, 2019 at 12:07 PM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> harkening back to the old Haskell 1.5 days, Lets have map back in
>>>>>> functor. it "F"-  strange to not have our lovely maps be functorial by
>>>>>> default.
>>>>>>
>>>>>> I think it would be a genuine boon for old and new haskellers alike,
>>>>>> and those who disagree with this change already use alt-preludes for
>>>>>> pedagogy reasons anyways
>>>>>> _______________________________________________
>>>>>> Libraries mailing list
>>>>>> Libraries at haskell.org
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>>
>>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190211/873d27a9/attachment.html>