add map back to Functor

[Ryan Reich]

...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/20190209/54afbc11/attachment.html>