Re: Burning bridges

On 23 May 2013 11:35, wrote:

El May 22, 2013, a las 9:25 PM, Ivan Lazar Miljenovic escribió:

...

On 23 May 2013 11:06, Casey McCann wrote:

...

On Wed, May 22, 2013 at 8:39 PM, Ivan Lazar Miljenovic wrote:

...

On 23 May 2013 07:32, Malcolm Wallace 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@gmail.com http://IvanMiljenovic.wordpress.com