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?

>>36
Now you have n problems, where n is the number of posters on /prog/.

ITT: all 3 of /prog/'s resident Haskallers (in b4 U MENA HASKAL) discuss things that no one but the 3 of them actually give a shit about.

>>1
where have you been you anus.

>>43
that's not him. where's the tripcode?

>>32
yeah, his "zip" is actually "transpose". but lispers aren't smart enough to understand the difference between lists and tuples.

>>45
change #'list with #'cons and you've got it, dumbass.

Nice post OP.

I've always imagined TTE to be Kenny trolling /prog/, but I wonder who he really is on c.l.l.

>>46
a list is a cons, dumbass.

>>48
wrong bitch! a cons is a data structure, a list is a few conses.

>>48
The cons is a base object present in most Lisps. It's a pair of 2 objects, the first being called the CAR, and the second being called the CDR. In low-level languages it can be represented as a simple structure of 2 elements, but in Lisp, a CONS' internal structure depends on the implementation (can be stored more efficiently sometimes).

(cons a b) -> (a . b) ; dotter pair notation, also known as a way to denote improper lists

The list is not a basic structure in most Lisps, instead it's a chain of conses:

A proper list is either:
1)A cons, whose car points to the first element of the list, a cdr who is also a proper list.
2)NIL, '(), the empty list.

(equal (list 1 2 3) '(1 2 3) (cons 1 (cons 2 (cons 3 nil)))) ;=> T

An improper list (usually either dotted, circular list, circular with shared structures, ...) is a list similiar a proper list (chain of conses), but which doesn't end in a NIL (nothing says it has to end at all, it could contain self-references, shared structures, circularities!).

>>44
who would be bored enough to impersonate him? It must be FV

>>51
We all know FV doesn't code in haskell nor lisp

>>52
nor
This is the wrong word to use there.

>>16
that's true, but it's also true you will never need a zip4+ in your entire life.

you might need a zip+4 sometime in your life, though

>>39
You really need to ask yourself "Do lisp programmers need networking?"
Yes.

How does Haskell cope with errors?
try/catch for impure, Error type for pure.

How do you design your programs?
How do you cook a meal?

Or do you write your own error system?
No.

If Haskell came with fibs and facts implementation in the prelude there would be no more reasons to use it. Sadly, I feel the Mr. Joints intentionally omitted this feature for this very reason.

Terminology
Define S to be the set of all touring complete languages. For a given language L in S with name N, let f(L) and g(L) be the number of Google results for the search queries "N" and "N fibs" respectively.

Definition 1
The fibs ratio of a language L, fibs(L) is defined as f(L)/g(L), g(L) ≠ 0.

Axiom 1 The well ordering property.
Let K be the set of all possible fibs ratios. Every nonempty subset of K has a least element.

Theorem 1
"Haskell" ∈ S.
Proof: Haskell is a touring complete language.¹

Theorem 2
∀x ∈ S, fibs("Haskell") ≤ fibs(x).
Proof: Left as an exercise to the reader.

Corollary 1
Haskell is for basement dwelling nerds.
Proof: Directly follows from Theorem 2.

__________________________________
[sub]1. http://www.haskell.org/pipermail/haskell/2006-August/018355.html retrieved 18 May, 2009.[/sup]

>>57
After a quick check, about 3.6569579288025889967637540453074% of Haskell google posts are about fibs. 0.00058% for lisp, 3.1354838709677419354838709677422% for scheme(used with programming language keyword),0.21581196581196581196581196581197% for C#. I never realized people talked that much about fibs. and did you mean
∀x ∈ S, fibs("Haskell") > fibs(x) instead?

>>58
percentage of fibs = 100 * g(x)/f(x) => fibs(x) = f(x)/g(x) decreases as the  percentage of fibs increases, notably, when fibs(L)=1 (Perhaps the definition should be altered, this is somewhat counter intuitive), every post is about fibs. Your numbers also seem quite off; I get lisp as 7.59%

>>59
lisp programming language - 434000
lisp programming language fibs - 5170
lisp programming language fibs precentage - 1.1912442396313364055299539170507%

lisp - 5020000
lisp fibs - 29000
lisp fibs precentage - 0.57768924302788844621513944223108%

The numbers themselves seem to be changing, I've tried refreshing some of the searches and the result count sometimes varied by an order of magnitude. Maybe using multiple search engines and calculating a weighted mean might be a better idea?

Why is your compiler smarter than you are? Is it because your compiler is very smart?
I am smarter than my compiler, so I can delegate dumb tasks like finding type-related bugs to it while I'm busy making smart things like writing instance Monad (Either (Int -> Map Int) a)

>>53
Nor it's not.

>>61
We lisp programmers don't have type related bugs.

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

>>63
expected ')'

>>63
Except compile time bugs might not exhibit themselves until it's too late. Oh, and why the hate on automatic coercion? Perl does it too, so does ruby and j.

>>65
automatic coercion is the work of the devil.

>>65
Automatic coercion could be done by a type class and therefore have predictable/definable behaviour. FUCK automatic coercion. It's nice and all but there's much better solutions out there.

>>65
To be fair, CL does have designators, which means that various types of objects can be used to denote something, but this is nothing more than a convention. For example, you could use a string, a symbol/keyword, an package object to denote a certain package - that would be called a package designator, but the difference is that functions which are made to work with a certain type of designator specify it exactly in the documentation, and it's a very well understood behaviour (and it's usually worth implementing designators for some of your own functions if needed). On the other hand, coercing strings to integers to booleans and so on, in most operations, just to avoid type errors is stupid and can lead to much more subtler errors which hardly make sense and could make you pull your hair out. IMO, automatic coercion doesn't belong in the language directly, but using it in the limited form of designators, which is nothing more than a coding convention, is likely a better choice (not too different from when one overloads a method so it'd take a few different, but well specified types as one of its arguments (for example, a filename object, or a direct path to it)).

The circle masturbation is over. Just stop it.

I got a nice pun, instead of definitely you'll say deaf in italy

>>71
Yes, that is a great reason why haskell's standard library sucks.

>>72
reason why
I'm not willing to go into a discussion about meta-reasoning right now.

http://www.ghdbest.com    GHD
I read that as GHCbest

78 Name: Anonymous 2010-12-25 22:45

79 Name: Anonymous 2011-02-03 3:19

80 Name: Anonymous 2011-04-13 5:35

Dead dog.

---

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List

All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -