Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Haskell
Wiki community
Recent changes
Random page
HaskellWiki
Search
Search
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Nitpicks
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Base-related nitpicks == * Re-naming <hask>fmap</hask> to <hask>map</hask>. This has been discussed at length; see http://stackoverflow.com/questions/6824255/whats-the-point-of-map-in-haskell-when-there-is-fmap/6824333 and https://mail.haskell.org/pipermail/haskell-prime/2006-August/thread.html * Cutting up <hask>Num</hask>, which is a mess of various operations one may not want to all define on some type; for example <hask>(+)</hask> makes sense for vectors in βΒ³ but <hask>(*)</hask> doesn't. Also, <hask>fromIntegral</hask> is useful for some types where the full complement of numeric operators aren't. :* ...or just drop type classes altogether and use e.g. System CT [https://homepages.dcc.ufmg.br/~camarao/CT/ :] for top-level definitions by default and use annotations elsewhere, like polymorphic let-expressions [https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.187.9508 :]. An account of a more modest implementation is also available (see chapter 7)[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.628.7053 :]. * <hask>Data.List.nub</hask> and other "Set" operations should be restricted to <hask>Ord</hask> not <hask>Eq</hask> in order to reduce their complexity. It is very unlikely for anyone to create a datatype that can support <hask>Eq</hask> but not <hask>Ord</hask>. <hask>Data.Set</hask> in the "container" package assumes <hask>Ord</hask> as well. * Partial functions like <hask>head</hask> and <hask>tail</hask> in Prelude. The problem is in their partiality. * The proliferation of questions, guides, tutorials, lessons, introductions '''et al''' about the topic indicates that I/O being both ''abstract'' and ''monadic'' is at best pedagogically dubious. Instead, I/O should be defined more directly in standard Haskell: <haskell> -- this is merely a suggestion... -- type IO# a = (a -> IOCall#) -> IOCall# data IOCall# -- abstract </haskell> :which allows beginners to acquire a better understanding of how I/O works - the monadic abstraction can then be taught later in an intermediate or advanced course.
Summary:
Please note that all contributions to HaskellWiki are considered to be released under simple permissive license (see
HaskellWiki:Copyrights
for details). If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!
Cancel
Editing help
(opens in new window)
Toggle limited content width