Style, or lack thereof in Graham's ANSI CL
in [Lisp]
|
Prev: Question from a non-user: Garbage Collection
Next: Loading a file into a running image with Swank
From: Pascal Costanza on 27 Dec 2009 16:38 On 27/12/2009 13:30, Chris Barts wrote: > Pascal Costanza<pc(a)p-cos.net> writes: > >> On 18/12/2009 03:51, Barry Margolin wrote: >>> In article >>> <404e1698-289b-441e-9d0b-635b432f7781(a)a21g2000yqc.googlegroups.com>, >>> w_a_x_man<w_a_x_man(a)yahoo.com> wrote: >>> >>>> Guy L. Steele, Jr., July 1989: >>>> >>>> I think we may usefully compare the approximate number of pages >>>> in the defining standard or draft standard for several >>>> programming languages: >>>> >>>> Common Lisp 1000 or more >>>> COBOL 810 >>>> ATLAS 790 >>>> Fortran 77 430 >>>> PL/I 420 >>>> BASIC 360 >>>> ADA 340 >>>> Fortran 8x 300 >>>> C 220 >>>> Pascal 120 >>>> DIBOL 90 >>>> Scheme 50 >>> >>> This is a little unfair, because the Common Lisp base language includes >>> lots of things that would be in libraries in most other languages, e.g. >>> hash tables, sequences, association lists, and portable pathnames. In >>> fact, even types that are basic primitives in Lisp, such as linked >>> lists, imaginary numbers, and symbols, would generally be in libraries >>> in traditional languages. >> >> I think there is a change in perspective now. Younger generations >> nowadays consider that these things should be part of a language, and >> that Common Lisp is actually too small and should have even more. > > Which is why we have Clojure (for which there is another little troll in > this very group), which brings all of Java into Lisp without actually > making Lispers write in Java. The fundamental problem with that is it > doesn't bring in any well-designed class libraries along with it. Unfortunately it brings a little bit too much Java into Lisp, for my taste... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: W. James on 28 Dec 2009 08:11 ccc31807 wrote: > On page 61 of Graham's ANSI Common Lisp, he defines bin-search and > finder, which I have copied below. > > I have struggled with this for days, and still don't understand these > definitions completely. This morning, I wrote bin-search-2, which took > about ten minutes to write (and about thirty minutes to debug), but I > understand it thoroughly -- and I am just the merest beginner, barely > a toe in the water. > > I have noticed this about CL in general and in Graham's book in > particular -- Lispers seem to go to great lengths to make their code > obtuse, obscurantist, obscure, and difficult to understand. For > example, in the example below, Why the nested ifs? Why the nested > lets? I've been reading Miller and Benson 'Lisp: Style and Design' and > I simply don't understand why tutorials (like ANSI CL -- which I think > on the whole is a very good book) want to throw up walls to > understanding. Seems to me that materials targeted toward beginners > would be written to be clear and understandable. > > CC. > > ;;; ---------ch_04.lisp----------------------- > (defparameter v (vector 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 > 35 37 39 41)) > > (defun bin-search (obj vec) > (format t "bin-search ~a ~a~%" obj vec) > (let ((len (length vec))) > (and (not (zerop len))) > (finder obj vec 0 (- len 1)))) > > (defun finder (obj vec start end) > (format t "finder obj: ~a, vec: ~a, start: ~a, end: ~a~%" obj vec > start end) > (format t " ~a~%" (subseq vec start (+ end 1))) > (let ((range (- end start))) > (if (zerop range) ; outer if test > (if (eql obj (aref vec start)) ; inner if test > obj ; the return obj > nil) ; else return nil > (let ((mid (+ start (round (/ range 2))))) ; outer then > (let ((obj2 (aref vec mid))) > (if (< obj obj2) > (finder obj vec start (- mid 1)) > (if (> obj obj2) > (finder obj vec (+ mid 1) end) > obj))))))) Bigloo Scheme: (module binsearch) (define *vec* (list->vector (iota 21 1 2))) (define (finder num vec start end) (if (= start end) (and (= num (vector-ref vec end)) num) (let* [ (mid (flonum->fixnum (/ (+ start end) 2.0))) (found (vector-ref vec mid)) ] (if (= found num) num (if (< num found) (finder num vec start (max start (- mid 1))) (finder num vec (+ mid 1) end)))))) (define (bin-search num vec) (let [ (len (vector-length vec)) ] (and (> len 0) (finder num vec 0 (- len 1))))) --
From: joswig on 28 Dec 2009 08:33 On 28 Dez., 14:11, "W. James" <w_a_x_...(a)yahoo.com> wrote: > ccc31807 wrote: > > On page 61 of Graham's ANSI Common Lisp, he defines bin-search and > > finder, which I have copied below. > > > I have struggled with this for days, and still don't understand these > > definitions completely. This morning, I wrote bin-search-2, which took > > about ten minutes to write (and about thirty minutes to debug), but I > > understand it thoroughly -- and I am just the merest beginner, barely > > a toe in the water. > > > I have noticed this about CL in general and in Graham's book in > > particular -- Lispers seem to go to great lengths to make their code > > obtuse, obscurantist, obscure, and difficult to understand. For > > example, in the example below, Why the nested ifs? Why the nested > > lets? I've been reading Miller and Benson 'Lisp: Style and Design' and > > I simply don't understand why tutorials (like ANSI CL -- which I think > > on the whole is a very good book) want to throw up walls to > > understanding. Seems to me that materials targeted toward beginners > > would be written to be clear and understandable. > > > CC. > > > ;;; ---------ch_04.lisp----------------------- > > (defparameter v (vector 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 > > 35 37 39 41)) > > > (defun bin-search (obj vec) > > (format t "bin-search ~a ~a~%" obj vec) > > (let ((len (length vec))) > > (and (not (zerop len))) > > (finder obj vec 0 (- len 1)))) > > > (defun finder (obj vec start end) > > (format t "finder obj: ~a, vec: ~a, start: ~a, end: ~a~%" obj vec > > start end) > > (format t " ~a~%" (subseq vec start (+ end 1))) > > (let ((range (- end start))) > > (if (zerop range) ; outer if test > > (if (eql obj (aref vec start)) ; inner if test > > obj ; the return obj > > nil) ; else return nil > > (let ((mid (+ start (round (/ range 2))))) ; outer then > > (let ((obj2 (aref vec mid))) > > (if (< obj obj2) > > (finder obj vec start (- mid 1)) > > (if (> obj obj2) > > (finder obj vec (+ mid 1) end) > > obj))))))) > > Bigloo Scheme: > This looks even relevant to the newsgroup. I'm surprised by your progress. > (module binsearch) > > (define *vec* (list->vector (iota 21 1 2))) > > (define (finder num vec start end) > (if (= start end) > (and (= num (vector-ref vec end)) num) > (let* [ (mid (flonum->fixnum (/ (+ start end) 2.0))) Still no integer division? > (found (vector-ref vec mid)) ] > (if (= found num) > num > (if (< num found) > (finder num vec start (max start (- mid 1))) > (finder num vec (+ mid 1) end)))))) > > (define (bin-search num vec) > (let [ (len (vector-length vec)) ] > (and (> len 0) > (finder num vec 0 (- len 1))))) > > --
From: game_designer on 28 Dec 2009 10:47 On Dec 16, 8:42 am, ccc31807 <carte...(a)gmail.com> wrote: > On page 61 of Graham's ANSI Common Lisp, he defines bin-search and > finder, which I have copied below. > > I have struggled with this for days, and still don't understand these... > > I have noticed this about CL in general and in Graham's book in > particular -- Lispers seem to go to great lengths to make their code > obtuse, obscurantist, obscure, and difficult to understand. For > example, in the example below, Why the nested ifs? Why the nested Graham writes nice essays which have helped Lisp a lot. I am thankful for that. The reference flavor aspect of ANSI Common Lisp is quite OK but for people writing modern applications especially when including OOP this is a book that needs to be avoided. It is not clear if Graham only hates object oriented programming - there is quite some evidence for that elsewhere - or actually does not understand it. In the end it does not matter. Common Lisp has a very powerful object system (CLOS). If you are planing to write a modern application making use of OO and are not just planning to walk down memory lane then look elsewhere. Alexander Repenning, University of Colorado
From: ccc31807 on 28 Dec 2009 11:52
On Dec 28, 10:47 am, game_designer <alex.repenn...(a)gmail.com> wrote: > Graham writes nice essays which have helped Lisp a lot. I am thankful > for that. The reference flavor aspect of ANSI Common Lisp is quite OK > but for people writing modern applications especially when including > OOP this is a book that needs to be avoided. It is not clear if Graham > only hates object oriented programming - there is quite some evidence > for that elsewhere - or actually does not understand it. In the end it > does not matter. Common Lisp has a very powerful object system (CLOS). > If you are planing to write a modern application making use of OO and > are not just planning to walk down memory lane then look elsewhere. Thank you for your helpful remarks. Two points: (1) There's no such thing as a perfect student, and there's no such thing as a perfect text -- sometimes I think that the match between the student and the text is simply a matter of sheer, dumb luck. Graham's book is strong in many ways, for example I like the way he serves up 'real' programs from the very beginning, and it's probably essential for the development of a mature Lisper, but it's certainly not good for the beginner. For my money, Wilensky and Winston & Horn are probably the best in that regard. (2) I received Norvig's 'Paradigms' for Christmas, and have read through the first three chapters. I've now read about 100 pages each of Graham and Norvig, comparing them. Each adds much, but I suspect that Norvig will have a lot more staying power than Graham. CC. |