Burning bridges

[Ivan Lazar Miljenovic]

On 23 May 2013 11:35,  <amindfv at gmail.com> wrote:
>
>
> El May 22, 2013, a las 9:25 PM, Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> escribió:
>
>> On 23 May 2013 11:06, Casey McCann <cam at uptoisomorphism.net> wrote:
>>> On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic
>>> <ivan.miljenovic at gmail.com> wrote:
>>>> On 23 May 2013 07:32, Malcolm Wallace <malcolm.wallace at me.com> wrote:
>>>>> -20 for generalising the Prelude
>>>>> +1 for removals from the Prelude
>>>>> -1 for adding monomorphic stuff
>>>>> +1000 for doing nothing
>>>>>
>>>>> You are all nuts. :-)
>>>>
>>>> I don't know if I'd go quite _that_ for as Malcolm for the weightings
>>>> for the different proposals...
>>>>
>>>> But I was speaking with a few other tutors of an introductory
>>>> CS/programming course that uses Haskell (note: it's teaching
>>>> programming with Haskell, not teaching Haskell per se: for example,
>>>> all pattern matchings must be done with case statements as the
>>>> lecturer considers top-level pattern matching a Haskell-specific
>>>> quirk) about these proposals...
>>>
>>> So in other words, your contention is that the design of the core
>>> library of Haskell should be driven by the needs of an introductory
>>> programming course, which is not even attempting to teach Haskell
>>> specifically, aimed at students who can't even figure out how tab
>>> characters work? That's marvelous.
>>
>> I think you missed my point... I'm not saying it's just because of the
>> course I'm tutoring, but that I disagree with the contention of
>> "people learning Haskell will pick this up relatively easier so we
>> should just dismiss anything about not generalising because it will
>> make it easier for new people".
>>
>> Also, not all people that learn Haskell are self-motivated in doing
>> so, and thus won't take in the extra mental effort to understand how
>> type-classes work right from the beginning.
>>
>
> If you want to avoid throwing people right into typeclasses, I could imagine teaching them:
>  - To write map/fold/filter themselves, with simple [a] types

Well, we have, and then tell them that they're so handy that they're
predefined in the Prelude, Data.List, etc.

>  - By giving them a small "module CS101 where" file, with monomorphic types of all our familiar friends, and then have them import with "import qualified CS101" and call "CS101.map" etc

Sure.

Irrespective of this and my previous points: if the generalisation
proposal is successful, what happens to Data.List?

* Will it still export specialised versions of functions?  If so, then
we have the current problem with Foldable/Traversable but reversed if
you want to use any of the Data.List functions.

* Not re-export functions available from the Prelude (in that case
would `map' still exist or would we silently drop it in favour of
fmap?)

* Re-export the generalised functions with the generalised type
signatures, which would look a little weird in a List-specific module.

(And how would this all tie together with the current build/foldr
fusion for lists?)

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com