What is the best way to process this list
in [Lisp]
|
From: Kenneth Tilton on 5 Jan 2010 05:53 mdj wrote: > On Jan 5, 12:14 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > >> Where has anybody timed a plist? I see no timings of the plist >> implementation. Does everyone know what is a plist? Am I the only one >> that understands that PB quickly abandoned "plists are just as fast" as >> soon as he realized his gaffe and pretended the issue was defstructs of >> type list? > > I just assume list based structs are plists and not alists and that > the performance is representative. I see. You are barking mad. Welcome to the group! > I feel no compulsion to prove what > should be obvious ... Good for you! kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
From: w_a_x_man on 5 Jan 2010 06:45 On Jan 2, 7:15 pm, Cecil Westerhof <Ce...(a)decebal.nl> wrote: > Cecil Westerhof <Ce...(a)decebal.nl> writes: > > I am still experimenting with CL. At the moment I am working with > > recipes. > > > To get the ingredient list for my brownies recipe, I use: > > (getf (get-recipe "Brownies") :ingredients) > > > and get: > > ((:QUANTITY "5" :TYPE "stuk" :INGREDIENT "eieren") > > (:QUANTITY "350" :TYPE "gram" :INGREDIENT "suiker") > > (:QUANTITY "175" :TYPE "gram" :INGREDIENT "boter (gesmolten)") > > (:QUANTITY "1" :TYPE "eetlepel" :INGREDIENT "vanille essence") > > (:QUANTITY "175" :TYPE "gram" :INGREDIENT "bloem") > > (:QUANTITY "100" :TYPE "gram" :INGREDIENT "cacao") > > (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(walnoten)") > > (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(kokos)") > > (:QUANTITY "2" :TYPE "stuk" :INGREDIENT "(bananen)") > > (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(hazelnoten)")) > > > 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))) > > > and this gives: > > 5 stuk eieren > > 350 gram suiker > > 175 gram boter (gesmolten) > > 1 eetlepel vanille essence > > 175 gram bloem > > 100 gram cacao > > 100 gram (walnoten) > > 100 gram (kokos) > > 2 stuk (bananen) > > 100 gram (hazelnoten) > > > At the moment this is hard coded, but of course this is not what I want.. > > I want only to use the space that is needed. The way I am thinking about > > it, is to do two dolist and in the first I could find the longest > > lengths for :quantity and :type and use those in the format. I was just > > wondering if there is not a more efficient way to do this. > > 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))))) > > With 'Brownies' I get: > (display-ingredients (get-recipe "Brownies")) > 5 stuk eieren > 350 gram suiker > 175 gram boter (gesmolten) > 1 eetlepel vanille essence > 175 gram bloem > 100 gram cacao > 100 gram (walnoten) > 100 gram (kokos) > 2 stuk (bananen) > 100 gram (hazelnoten) > > With 'Salate de vinete' I get: > (display-ingredients (get-recipe "Salate de vinete")) > 10 stuk grote aubergines > 30 stuk gedroogde en gemalen pepers > 3 stuk ui > 1 eetlepel knoflook > 2 eetlepels zout > olie > > So it does what I want, but I was just wondering if there was a better > way? In this particular case it is not very important, because the lists > will not be very big, but I like to make things for the general case, so > that when the data set changes there are no nasty surprises. In Bigloo Scheme: (module recipe (main main) (extern (macro eprintf::int (string string string string) "printf"))) (define (getf flat-list key) (cadr (member key flat-list))) (define brownies '((:QUANTITY "5" :TYPE "stuk" :INGREDIENT "eieren") (:QUANTITY "350" :TYPE "gram" :INGREDIENT "suiker") (:QUANTITY "175" :TYPE "gram" :INGREDIENT "boter (gesmolten)") (:QUANTITY "1" :TYPE "eetlepel" :INGREDIENT "vanille essence") (:QUANTITY "175" :TYPE "gram" :INGREDIENT "bloem") (:QUANTITY "100" :TYPE "gram" :INGREDIENT "cacao") (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(walnoten)") (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(kokos)") (:QUANTITY "2" :TYPE "stuk" :INGREDIENT "(bananen)") (:QUANTITY "100" :TYPE "gram" :INGREDIENT "(hazelnoten)"))) (define (max-width recipe field) (apply max (map (lambda (x) (string-length (getf x field))) recipe))) (define (main args) (let [(keys '(:QUANTITY :TYPE :INGREDIENT))] (multiple-value-bind (qw tw iw) (apply values (map (lambda(k)(number->string (max-width brownies k))) keys)) (let [(fstring (string-append " %" qw "s %-" tw "s %s\n"))] (for-each (lambda (x) (apply eprintf fstring (map (lambda(k)(getf x k)) keys))) brownies))))) 5 stuk eieren 350 gram suiker 175 gram boter (gesmolten) 1 eetlepel vanille essence 175 gram bloem 100 gram cacao 100 gram (walnoten) 100 gram (kokos) 2 stuk (bananen) 100 gram (hazelnoten)
From: Ron Garret on 5 Jan 2010 13:28 In article <68313485-b59e-4f8c-bfbf-a517182f891a(a)e27g2000yqd.googlegroups.com>, mdj <mdj.mdj(a)gmail.com> wrote: > On Jan 5, 5:22 pm, Ron Garret <rNOSPA...(a)flownet.com> wrote: > > In article <m3my0tf3if....(a)moon.robolove.meer.net>, > > > > > > > > Madhu <enom...(a)meer.net> wrote: > > > * Ron Garret <rNOSPAMon-A6D739.21222604012...(a)news.albasani.net> : > > > Wrote on Mon, 04 Jan 2010 21:22:26 -0800: > > > |> In article > > > |> <d50e5346-8eef-457c-929e-4cce045a4...(a)j5g2000yqm.googlegroups.com>, > > > |> mdj <mdj....(a)gmail.com> wrote: > > > | > > > |> > I just assume list based structs are plists and not alists > > > |> > > > |> Why do you think they have to be one or the other? > > > | > > > | BTW, here's a clue: > > > | > > > | ? (defstruct foo a b) > > > | FOO > > > | ? (setf foo1 (make-foo :a 'a :b 'b)) > > > | #S(FOO :A A :B B) > > > | ? (defstruct foo b a) > > > | FOO > > > | ? foo1 > > > | #S(FOO :B A :A B) > > > > > First This is not conformant code. > > > > I didn't say it was. > > > > > In any case this has no relevance to using either alists or plists or > > > simple position based lists (accessed by NTH) and is bound to be > > > misleading. > > > > That's true, but that's not the topic I was addressing. The topic I was > > addressing was whether the assumption that "list based structs are > > plists and not alists" is reasonable. > > It's not. My bad. List structures are required by the standard to be > position based, and the car will be the structure name if it's :name'd > in the defstruct. Accessors (at least in SBCL) use ELT to access the > element, since you're free to specify vector as the type instead of > list. > > In any case, the example you gave was of an untyped defstruct, which > will be a class, not a list, and the implementation is free to > implement slots on classes however it sees fit. > > Matt Right. The point is that PLIST and ALIST are NOT an exhaustive enumeration of the possible representations of a struct whose type is list. rg
From: Ron Garret on 5 Jan 2010 13:38 In article <m3iqbhf0we.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > * Ron Garret <rNOSPAMon-79BB44.23220404012010(a)news.albasani.net> : > Wrote on Mon, 04 Jan 2010 23:22:04 -0800: > > |> > |> First This is not conformant code. > | > | I didn't say it was. > | > |> In any case this has no relevance to using either alists or plists or > |> simple position based lists (accessed by NTH) and is bound to be > |> misleading. > | > | That's true, but that's not the topic I was addressing. The topic I > | was addressing was whether the assumption that "list based structs are > | plists and not alists" is reasonable. > > Right, My point was that not only was the code you posted > non-conformant, but it is also not relevant to addressing the assumption > you wish to address. Happily, the person to whom the remark was addressed was able to see that it was. > To repeat what I said, the code you posted > illustrates what one your particular lisp implementation changes the > layout of existing instances after a structure definition has > changed. Actually it shows exactly the opposite, that my Lisp does NOT change the layout of existing instances. I am pleased to see that the First Law of Madhu (to wit: Madhu is always Wrong about Everything) will not have to be revised. > There are other alternatives in other implementations. > > Besides What you shewed was the printed representation of the structure > which has no direct relevance to how it is implemented --- in whatsoever > way --- be it ANY type of lists or arrays. One could layout a defstruct > instance using a persistent database backend, and it would still print > as #S(:A 10 :B 20). You need to pay closer attention. The result I exhibited was inconsistent with the underlying implementation being either an ALIST or a PLIST. There is actually one valid criticism of my example, and that is that I left out the :TYPE LIST option. So here's the correct example: ? (defstruct (foo (:type list)) a b) FOO ? (make-foo :a 'aa :b 'bb) (AA BB) ? (type-of *) CONS Heh, look at that. Conforming code! rg
From: Madhu on 5 Jan 2010 19:09
* Ron Garret <rNOSPAMon-D4C120.10381605012010(a)news.albasani.net> : Wrote on Tue, 05 Jan 2010 10:38:16 -0800: | In article <m3iqbhf0we.fsf(a)moon.robolove.meer.net>, | Madhu <enometh(a)meer.net> wrote: | |> * Ron Garret <rNOSPAMon-79BB44.23220404012010(a)news.albasani.net> : |> Wrote on Mon, 04 Jan 2010 23:22:04 -0800: |> |> |> |> |> First This is not conformant code. |> | |> | I didn't say it was. |> | |> |> In any case this has no relevance to using either alists or plists or |> |> simple position based lists (accessed by NTH) and is bound to be |> |> misleading. |> | |> | That's true, but that's not the topic I was addressing. The topic I |> | was addressing was whether the assumption that "list based structs are |> | plists and not alists" is reasonable. |> |> Right, My point was that not only was the code you posted |> non-conformant, but it is also not relevant to addressing the assumption |> you wish to address. | | Happily, the person to whom the remark was addressed was able to see | that it was. I hope he was able to see exactly how wrong an example your code was in the context. |> To repeat what I said, the code you posted illustrates what one your |> particular lisp implementation changes the layout of existing |> instances after a structure definition has changed. | | Actually it shows exactly the opposite, that my Lisp does NOT change | the layout of existing instances. No. It does not show that. | I am pleased to see that the First Law of Madhu (to wit: Madhu is | always Wrong about Everything) will not have to be revised. The law you seem to prove is that you are clueless AND wrong EVERYTIME you post anything related to DEFSTRUCT (as with other parts of Common Lisp) |> There are other alternatives in other implementations. |> |> Besides What you shewed was the printed representation of the structure |> which has no direct relevance to how it is implemented --- in whatsoever |> way --- be it ANY type of lists or arrays. One could layout a defstruct |> instance using a persistent database backend, and it would still print |> as #S(:A 10 :B 20). | | You need to pay closer attention. The result I exhibited was | inconsistent with the underlying implementation being either an ALIST or | a PLIST. No. You did not exhibit that. You exhhibited "undefined behaviour" in a Lisp implementation where a LIST based representation was NOT requested. | There is actually one valid criticism of my example, and that is that | I left out the :TYPE LIST option. So here's the correct example The valid criticism I made of your example was that it was irrelevant nonsense on multiple counts. Comparing your example with the following will only prove that. | | ? (defstruct (foo (:type list)) a b) | FOO | ? (make-foo :a 'aa :b 'bb) | (AA BB) | ? (type-of *) | CONS | | Heh, look at that. Conforming code! |