What is the best way to process this list
in [Lisp]
|
From: Giorgos Keramidas on 3 Jan 2010 05:42 On Sun, 03 Jan 2010 02:15:28 +0100, Cecil Westerhof <Cecil(a)decebal.nl> wrote: > I already made a function for it: > (defun display-ingredients (recipe) > (let ((quantity-length 0) > (temp) > (type-length 0)) > (dolist (this-ingredient (getf recipe :ingredients)) > (setq temp (length (getf this-ingredient :quantity))) > (when (> temp quantity-length) > (setq quantity-length temp)) > (setq temp (length (getf this-ingredient :type))) > (when (> temp type-length) > (setq type-length temp))) > (dolist (this-ingredient (getf recipe :ingredients)) > (format t "~v@a ~va ~a~%" > quantity-length (getf this-ingredient :quantity) > type-length (getf this-ingredient :type) > (getf this-ingredient :ingredient))))) getf may only have to be called once per property (think of what getf does to do its job): CL-USER> (defun get-ordered-properties (plist indicator-list) (mapcar (lambda (item) (mapcar (lambda (prop) (getf item prop)) indicator-list)) plist)) GET-ORDERED-PROPERTIES CL-USER> (get-ordered-properties *ingredients* (list :quantity :type)) (("5" "stuk") ("350" "gram") ("175" "gram") ("1" "eetlepel") ("175" "gram") ("100" "gram") ("100" "gram") ("100" "gram") ("2" "stuk") ("100" "gram")) Since your plist values are all strings, you can loop over the result and just keep a running maximum for each string item: CL-USER> (loop :for (quantity type) :in *foo* :maximizing (length quantity) :into quantity-width :maximizing (length type) :into type-width :finally (return (list quantity-width type-width))) (3 8) Now you have your column widths.
From: Nicolas Neuss on 3 Jan 2010 06:57 Cecil Westerhof <Cecil(a)decebal.nl> writes: > This I want to display and this can be done with: > (dolist (this-ingredient (getf (get-recipe "Brownies") :ingredients)) > (format t "~3@a ~8a ~a~%" > (getf this-ingredient :quantity) > (getf this-ingredient :type) > (getf this-ingredient :ingredient))) Something as (loop for (&key quantity type ingredient &allow-other-keys) in (getf (get-recipe "Brownies") :ingredients) do (format t "~3@a ~8a ~a~%" quantity type ingredient)) looks nicer to me. Nicolas
From: Pascal J. Bourguignon on 3 Jan 2010 09:17 Kenneth Tilton <kentilton(a)gmail.com> writes: > Not worth worrying about, or even close to worth worrying about. It's > not even close to close to worth worrying about. Correct. > I suggest you write the code you are writing now and not the code you > might write someday. Someday you can have a recipes container with > slots for max length of each column, and maintain it as you add new > elements. Yes. > Using a plist is not the lay to go. Use defstruct. Simpler than a > plist, really, and massively more efficient. False. Structures are not always faster than plist. Notaby, implementations may typecheck the structure object, which slows structure accessors so much that plist up to 5 or even more slots is faster. Of course, if you need that kind of speed, you can always add (:type list) to your defstruct instead. But the point is that short lists are faster than most other data structures. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Tim X on 3 Jan 2010 17:19 pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > Kenneth Tilton <kentilton(a)gmail.com> writes: > >> Not worth worrying about, or even close to worth worrying about. It's >> not even close to close to worth worrying about. > > Correct. > > >> I suggest you write the code you are writing now and not the code you >> might write someday. Someday you can have a recipes container with >> slots for max length of each column, and maintain it as you add new >> elements. > > Yes. > > >> Using a plist is not the lay to go. Use defstruct. Simpler than a >> plist, really, and massively more efficient. > > False. Structures are not always faster than plist. Notaby, > implementations may typecheck the structure object, which slows > structure accessors so much that plist up to 5 or even more slots is > faster. Of course, if you need that kind of speed, you can always add > (:type list) to your defstruct instead. But the point is that short > lists are faster than most other data structures. I also think, at this stage of learning, its often good to first try things using something like a plist and then refactor using something else, such as defstruct. In reality, given what th eOP is doing, the difference in performance between defstruct and plist is likely to be negligible. However, the difference in code clarity and ease of expression using the defstruct is going to make coding the app a lot easier (I suspect this was KTs main point). For some people, it is often only through doing it the wrong way you begin to really appreciate the right way (all too often, I find I'm one of these). The choice of the right abstraction is something that comes with experience - when learning, I find it is sometimes valueable to use all the different abstractions the language offers for the same problem because you then get first hand experience regarding the strengths/weaknesses of each within that language. This is why I suggested to the OP that he continues to use the plist based abstraction, but do so in such a way that you can then change the abstraction later to see what impact it has. While most abstractions will have obvious strengths/weaknesses, sometimes its only hands-on experience which really gives you a feel for them in that language. For example, using a linked list in C has significant overhead and complexity compared to CL, but the basic pros/cons of a linked list are the same in both languages. This also needs to be balanced with the very valid point regarding writing the code you mean to write and avoiding making things to contrived just for the sake of it. When you find things are becoming too contorted or difficult because of your initial choice of abstraction, then its usually time to refactor and select a new abstraction better able to satisfy your evolving requirements. While the recipie app may be a little contrived, its still important to have a 'real' something at the end of the day. Tim -- tcross (at) rapttech dot com dot au
From: Kenneth Tilton on 4 Jan 2010 00:22
Pascal J. Bourguignon wrote: >> Using a plist is not the lay to go. Use defstruct. Simpler than a >> plist, really, and massively more efficient. > > False. Structures are not always faster than plist. Notaby, > implementations may typecheck the structure object, which slows > structure accessors so much that plist up to 5 or even more slots is > faster. Rubbish! What crappy implementation are you imagining for these incredibly slow defstructs (by which I mean which Lisp and how do they implement defstructs by default? Lemme see some timings! kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf |