Yeah, and the Haskell version isn't strict. I.e. if one application of f to an element of the list produces _|_, the program won't be affected unless it actually requires evaluation of the element. I.e. if that part of the result list is never used, well, nothing happens!
Contrast with the scheme version, where if "f" becomes _|_ at any stage, the whole evaluation of map falls down right there. I've heard that there's "optional" lazy evaluation available for Scheme somehow, but I don't quite see how Haskell's default behaviour could be found there without syntax contortions. The Haskell "map" is two really short lines for fuck's sake.
Name:
Anonymous2007-03-08 8:52 ID:8iiPARSk
Wow. Way to write an unnecessarily verbose implementation in lisp just to claim that it sucks.
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
Also Haskell wasn't around 20 years ago. You idiot.
Name:
Anonymous2007-03-08 8:57 ID:lf8KjFgA
Wrong, Haskell is 20 years old.
Name:
Anonymous2007-03-08 9:15 ID:8iiPARSk
>>4
The decision to form a committee to start work on a language to replace the plethora of lazy functional languages that had sprung up around that time was made in 1987. The first Haskell report wasn't ready until 1990. You can hardly claim that Haskell sprung into existence at that 1987 meeting.
>>7
PS: I just checked out the wikipedia article and found that the simple definition is just a few lines above the version you copypastaed. So you fail doubly hard.
>>10
It's equivalent to the Haskell implementation in >>1
Name:
Anonymous2007-03-08 13:14 ID:fc2iv5gF
map f xs = [f x | x <- xs]
Name:
Anonymous2007-03-08 13:16 ID:8iiPARSk
>>12
That's cheating since list comprehensions are just sugar for map and filter.
Name:
Anonymous2007-03-08 13:36 ID:fc2iv5gF
Okay here's a challenge to you Lisp heads then: write a function that takes a list of numbers X and an arbitrary list Y and splits Y into sublists the size of x1, x2, x3,...
in other words:
f [2,5,0,3] [1..15] == [[1,2],[3,4,5,6,7],[],[8,9,10],[11,12,13,14,15]]
here's the Haskell version:
f = foldr (\n r -> splitAt n >>> second r >>> uncurry (:)) return
What you faggots are forgetting is that faggot shit like list comprehensions and all that syntactical sugar can be added to lisp . With lisp you can get as much syntactical sugar as you want.
Macros faggot, do you speak them?
Name:
Anonymous2007-07-14 15:23 ID:4U/+81ZL
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
(define (map f list)
(if (null? list) list
(cons (f (car list)) (map f (cdr list)))))
THREAD OVER
Name:
Anonymous2007-07-15 20:17 ID:3OgO/mI2
first of all, lisp's map is different than haskell map. Lisp's map takes a variable number of arguments, so you can write something like
(map + '(1 2 3) '(4 5 6)) --> (5 7 9)
still, if you want a nice definition of a haskell-like map in scheme, I'm guessing it would be something like
(define (map f list)
(foldr nil (lambda (e acc) (cons (f e) acc)) list))
which of course is the equivalent of
map f list = foldr [] (/ e acc -> (f e):acc)) list
which of course may seem shorter, but only because of syntax, and if haskell macros are any indication of, it matters little.
(The same applies to pattern matching vs. accesor functions, unless you like 20+ functions breaking when you add a field in your data type).
>>15
If syntactic sugar (see: pattern matching) makes a language good, then a language that allows you to define your own syntactic sugar is even better.