add map back to Functor

[Carter Schonwald]

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/6f5ce71f/attachment.html>