The joke that is Haskell stdlib

oBSERVE MY GOOD OL' FELLAS, THE JOKE THAT IS 'HASKELL STDLIB'. i DO NOT DOUBT THE EXCELLENCE IN HASKELL THEORY, BUT ALLOW ME TO MAKE FUN OF THE FRIVOLOUS LIBRARY THEY HAVE FOR STANDARD. LA-FUCKING-OWL.


-- | 'zip' takes two lists and returns a list of corresponding pairs.
-- If one input list is short, excess elements of the longer list are
-- discarded.
zip :: [a] -> [b] -> [(a,b)]
zip (a:as) (b:bs) = (a,b) : zip as bs
zip _      _      = []

;; I shall compare it with Communist Lisp
;; notice the solution is more general
;; and the documentation is built-in
(defun zip (&rest lists)
  "zip takes lists and returns corresponding pairs"
  (apply #'mapcar #'list lists))

o GUESS WAT! BAAA!!! hASKELL PROVIDES zip3 HOHOHOH. wAT ABOUT ZIP4 YOU ASSHOLES??

wAIT, WAIT. nOW IT GETS BETTER.


-- | 'unzip' transforms a list of pairs into a list of first components
-- and a list of second components.
unzip    :: [(a,b)] -> ([a],[b])
{-# INLINE unzip #-}
unzip    =  foldr (\(a,b) ~(as,bs) -> (a:as,b:bs)) ([],[])


;; La Communa lispa
(defun unzip (&rest lists)
  "list of pairs -> list of components"
  (apply #'zip lists))
oH SHIT!!!! fULL GENERAL SOLUTION WITH THE POWAH OF LISPA, HA SS KELL STDLIB IS A JOKE. dID YOU FUCKING LOL READING THIS POST?

>>62
The difference is if you find your type-related bugs at compile time or runtime. In statically typed languages, and even moreso in languages are strictly typed as Haskell or ML, you find such bugs at compile-time, but you have to give up a lot of flexibility and usually have to do all your design up-front, leaving free experimentation and all kinds of code transforms hard to do. In dynamically typed languages (but without the silly automatic type coercions like PHP and other languages like it do) such as Lisp, you do get type errors, but at runtime - a variable can hold any type, at least by default, though you can check types and tell the compiler to force a variable as being of a specific type or have the compiler infer types for you (possible(SBCL does it for example), but not as good as Haskell's, since the language is designed for maximum flexibility, not rigidness). This means that type errors at runtime are possible in dynamicly typed languages, while they're usually impossible in statically typed languages (ML, Haskell,... ). If you actually cheat and use dynamic typing in those languages, all hell can break loose if you're not careful: unlike Lisp(s) which are usually designed to handle such errors gracefully(you could even recover and continue off some continuation), forcing dynamic typing in a staticly typed language is dangerous, will usually lead to crashes or other bad things (I'm talking about Obj.magic-like tricks ).

tl;dr: It's a tradeoff between safety and flexibility. I'm mostly on the flexibility side, but I do like reading well-written ML/Haskell code, just not a bit fan of writing such code myself - I like being able to experiment without any restrictions in my CL REPL.