What is the best way to process this list
in [Lisp]
|
From: Madhu on 7 Jan 2010 02:57 * Ron Garret <rNOSPAMon-D4C120.10381605012010(a)news.albasani.net> : Wrote on Tue, 05 Jan 2010 10:38:16 -0800: |> 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. The remarkable bonding between you (the master of the socratic method) and MATT-THE-SURNAME-LESS (the pupil) is due to the fact that both of you suffer from acute cases of Dunning–Kruger effect. Heres a hot tip for your success: You need to find more victims of the Dunning Kruger effect as students, to walk down every misleading path you show, and thank you for it. -- Madhu
From: Thomas F. Burdick on 7 Jan 2010 03:58 On Jan 7, 4:14 am, mdj <mdj....(a)gmail.com> wrote: > you (IMO incorrectly) stated that a structure #S(:a a :b b) > which has it's definition altered to (b a) has *not* been re-organised > when it later displays as #S(:b a :a b). If it was re-organised it > would display as #S(:b b :a a), which it did not. There is, you'll > agree, only two possible organisations for that structure. I'm sorry > you seem to think this makes me a dishonest person, but it seems clear > to me that no reasonable implementation would attempt to reorganise > the (potentially terabytes) of existing instances when a defstruct is > redefined. One has to check what their own implementation does, but I > think you'll find that the one you're advocating is the *least* > likely, considering it's only even possible at all if the structures > remain the same size, and in that case it isn't even necessary to do > it at all. I would contend that the only reason implementations allow > redefinition at all is to facilitate prototyping and bottom-up design, > since the results of doing so will in practice be unpredictable at > best, contrived examples notwithstanding. There are other alternatives to either (1) blindly assuming the new layout applies to the old instances, or (2) eagerly changing the layout of existing instances. You could hypothetically update them lazily using (something like) update-instance-for-redefined-class. I don't know of any implementation that does that, however. SBCL/CMUCL offer the option to mark the old instances as invalid, so, while you won't get A when trying to access the A slot in the above example, at least you'll get an error instead of B. I think it's too bad more implementations don't do this, it's really useful behavior.
From: Thomas F. Burdick on 7 Jan 2010 04:02 On Jan 7, 8:01 am, Madhu <enom...(a)meer.net> wrote: > Matt, quit pretending you are engaging in an honest exchange. I hope you have something to help you automate this nonsense, a keyboard macro at least. > you exhibit > continued behaviour you continue go out of your way to engage me in > pointless debate while you shift shape. OMG! Ron has enlisted sci-fi creatures in his nefarious lexiconical consipiracy?!?! THAT must have been his motivation for sending MCL into space! The plot thickens!!1!
From: Madhu on 7 Jan 2010 04:06 * "Thomas F. Burdick" Wrote on Thu, 7 Jan 2010 01:02:57 -0800 (PST): | On Jan 7, 8:01 am, Madhu <enom...(a)meer.net> wrote: |> Matt, quit pretending you are engaging in an honest exchange. | | I hope you have something to help you automate this nonsense, a | keyboard macro at least. OK, burdick, quit pretending you are engaging in an honest exchange with me. | |> you exhibit continued behaviour you continue go out of your way to |> engage me in pointless debate while you shift shape. | | OMG! Ron has enlisted sci-fi creatures in his nefarious lexiconical | consipiracy?!?! THAT must have been his motivation for sending MCL | into space! The plot thickens!!1! No, it just means that Ron has engaged more similar intellectually dishonest types (as familiar to you as yourself), that change their argument everytime it is shown that it is untenable -- Madhu
From: mdj on 7 Jan 2010 04:15
On Jan 7, 6:58 pm, "Thomas F. Burdick" <tburd...(a)gmail.com> wrote: > On Jan 7, 4:14 am, mdj <mdj....(a)gmail.com> wrote: > > > > > you (IMO incorrectly) stated that a structure #S(:a a :b b) > > which has it's definition altered to (b a) has *not* been re-organised > > when it later displays as #S(:b a :a b). If it was re-organised it > > would display as #S(:b b :a a), which it did not. There is, you'll > > agree, only two possible organisations for that structure. I'm sorry > > you seem to think this makes me a dishonest person, but it seems clear > > to me that no reasonable implementation would attempt to reorganise > > the (potentially terabytes) of existing instances when a defstruct is > > redefined. One has to check what their own implementation does, but I > > think you'll find that the one you're advocating is the *least* > > likely, considering it's only even possible at all if the structures > > remain the same size, and in that case it isn't even necessary to do > > it at all. I would contend that the only reason implementations allow > > redefinition at all is to facilitate prototyping and bottom-up design, > > since the results of doing so will in practice be unpredictable at > > best, contrived examples notwithstanding. > > There are other alternatives to either (1) blindly assuming the new > layout applies to the old instances, or (2) eagerly changing the > layout of existing instances. You could hypothetically update them > lazily using (something like) update-instance-for-redefined-class. I > don't know of any implementation that does that, however. SBCL/CMUCL > offer the option to mark the old instances as invalid, so, while you > won't get A when trying to access the A slot in the above example, at > least you'll get an error instead of B. I think it's too bad more > implementations don't do this, it's really useful behavior. I wasn't aware of that for SBCL (which I use primarily) but I've been dabbling a bit with Clozure so I'll check out what it offers next time I transfer some code to it (I was tempted by the MacOS X integration possibilities) I must admit though, other than during development, I can't come up with a good use-case for the more elaborate functionality you elude to ... Matt |