What is the best way to process this list
in [Lisp]
|
From: Thomas F. Burdick on 7 Jan 2010 08:12 On Jan 7, 10:15 am, mdj <mdj....(a)gmail.com> wrote: > 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) Yeah, that is a nice feature of ccl. Their original cocoa bridge was pretty ugly compared to what a couple of us sbcl users were developing, but theirs got nicer over time and ours got wiped out by changes to the objc runtime, so I guess they had the better strategy :-) > 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 ... "Other than during development". Well, yeah, that's generally when you redefine classes/structs :-) In general, I greatly prefer my Lisp to either do the right thing or give me an error, not give me the wrong answer.
From: mdj on 7 Jan 2010 08:15 On Jan 7, 10:53 pm, Madhu <enom...(a)meer.net> wrote: > | Don't be ridiculous. Implementors can choose whatever representation > | they see fit, as long as the opaque interface defined by the standard > | is adhered to. One would hope that they chose a faster one, however. > > Except There is no "opaque interface defined by the standard." Provide > the citation if youre talking of the specification, or if you just want > to indulge in your clueless pathological bickering, FOAD, > Matt-with-No-surname. It creates a new type. Types are opaque. Don't be silly.
From: Madhu on 7 Jan 2010 08:16 * mdj <cce2f265-4d37-471a-8650-5e9bbdcc7985(a)m25g2000yqc.googlegroups.com> : Wrote on Thu, 7 Jan 2010 05:15:35 -0800 (PST): | On Jan 7, 10:53 pm, Madhu <enom...(a)meer.net> wrote: | |> | Don't be ridiculous. Implementors can choose whatever representation |> | they see fit, as long as the opaque interface defined by the standard |> | is adhered to. One would hope that they chose a faster one, however. |> |> Except There is no "opaque interface defined by the standard." Provide |> the citation if youre talking of the specification, or if you just want |> to indulge in your clueless pathological bickering, FOAD, |> Matt-with-No-surname. | | It creates a new type. Types are opaque. Don't be silly. Why are you are posting bullshit on a technical newsgroup?
From: Thomas F. Burdick on 7 Jan 2010 08:19 On Jan 7, 10:21 am, Ron Garret <rNOSPA...(a)flownet.com> wrote: > In article > <6d821556-254b-4df1-87ce-746055a1f...(a)a15g2000yqm.googlegroups.com>, > "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. > > Marking all the old instances as invalid can still be expensive if there > are a lot of them. A better approach would be to have all the instances > have a back-pointer to a (shared) wrapper, and have the wrapper marked > as invalid when the struct is redefined. That's how it's actually implemented. > Whether this is a good idea or not depends on whether you think that > DEFSTRUCT ought to be a high-level facility or a low-level one. Not sure I know what you mean here. If you mean that you think the :layout vector behavior could be seen as the model, and structure- instances would be expected to follow that .... it seems weird (and I would disagree about that being the best behavior), but I guess I could see that. But if you would take that interpretation, and would think that foo-a should return either A or B, then at least in the situation: (defstruct foo a b) (setq >>foo (make-foo :a 'a :b 'b)) (defstruct foo a b c) (foo-c >>foo) you should want the call to foo-c to raise an error, and not give you the content of the memory word one past >>foo, right?
From: mdj on 7 Jan 2010 08:33
On Jan 7, 10:58 pm, Madhu <enom...(a)meer.net> wrote: > | Just when I thought you couldn't get anything else bassackwards > | today.... > > Are you implying I have said anything incorrect? What was your first clue ? |