Burning bridges

[Ivan Lazar Miljenovic]

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...

We have plenty of students who have trouble understanding existing
functions and types themselves; if we were to suddenly find map,
filter, etc. with generalised type signatures then it would confuse
the matter even further (especially as they've only "seen" the
standard Eq, Ord and Show classes, and even then only in deriving
statements and type signatures to be able to use ==, /=, etc. rather
than knowing how to write an instance of them themselves).

(Admittedly, they only see these list functions in roughly the last
third of the course; even so, despite having just written their own
map, filter, etc. functions first for Strings and then generalising
them to work on any list in a tutorial a few weeks back, when it came
time to work on their assignment when map and filter would come in
handy some still kept writing the list traversals by hand due to
unfamiliarity of these functions when compared to all the manual list
traversal they'd already done.)

If the types in the Prelude were generalised, it might be possible to
have a custom Prelude used for the course; however, for this to be
used we'd either have to:

a) get them to use rote boilerplate of {-# LANGUAGE NoImplicitPrelude
#-} (or `import Prelude()') and importing the custom one; this would
still require ensuring that students had the custom prelude installed
on their own laptops, etc.

b) write wrappers around ghc and ghci to load up the custom prelude
instead, though even if we managed to get this to work we'd still need
to somehow make sure all students would install equivalent wrappers on
their own machine... and considering how much luck we've had with
making sure they configured their editors to have the tab key insert
four spaces instead of a tab character, I can see that being painful.

Either way, we'd then find ourselves teaching a "custom" version of
Haskell, and I don't exactly have fond memories of when I was taught
Java in my first year of uni using a custom wrapper/library (and since
my only programming experience to date was Pascal/Delphi, I can't
really blame Java :p)

I do, however, think that the Prelude is over-crowded and that
Data.List should contain most of the list-specific functions (and it
is weird when there is so much overlap between the two).

So my actual votes for the current status of this proposal are:

-1 for generalising the Prelude
+1 for removing stuff from the Prelude (then people can import
Data.List, Data.Traversable, Data.Foldable, etc. as they see fit
without clashes)
-1 for adding monomorphic stuff
-0.5 for doing nothing

>
> Regards,
>     Malcolm.
>
>
>
> On 22/05/2013, at 22:16, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>
>>
>> +1 Generalize Prelude
>> -1 Remove from Prelude
>> -1 Add more monomorphic stuff
>> -1 Do nothing
>> +1 More fun polls like this
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



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