What is the best way to process this list
in [Lisp]
|
From: Ron Garret on 7 Jan 2010 05:11 In article <m3skai9qls.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > * Ron Garret <rNOSPAMon-6777F5.01442807012010(a)news.albasani.net> : > Wrote on Thu, 07 Jan 2010 01:44:28 -0800: > > | In article <m3pr5mbdq2.fsf(a)moon.robolove.meer.net>, > | Madhu <enometh(a)meer.net> wrote: > | > |> The redefinition of structs has nothing to do with Point 2 Either. > | > | I don't know what point 2 is, but the original example included a > | redefinition because "real" structs are opaque. The redefinition was > | needed to reveal a particular aspect of the behavior of the underlying > | implementation. > > Let's look at this ex Post - facto justification from the master of > unchallenged master of dishonest debate of comp.lang.lisp. The > > So now you are claiming that redefinition of defstruct (which has > undefined consequences) shows that a "real" structure instance is > opaque? No. > Matt got "something". He probably understands defstruct more than you > now Could well be. rg
From: Madhu on 7 Jan 2010 05:17 * mdj <df6b9976-9854-446e-820e-1041ac715039(a)j14g2000yqm.googlegroups.com> : Wrote on Wed, 6 Jan 2010 23:55:53 -0800 (PST): | Ron likes to interact like a teacher. Teaching, and the socratic | method seems to be another knowledge domain that you're weak in. Ron likes to interact like Gavino --- posting random CL code (random because it is unrelated to the issues being discussed) with undefined/implementation specific consequences which he barely understands after testing it on his one implementation of openmcl --- and waiting for someone like kaz or pjb to correct him and give the explanations he can learn from. By the time the "students" are grappling with the concepts of undefined consequences --- completely forgetting the original issues they were discussing, Ron has now learnt enough to "instruct them" in simpler words. This pattern has been going on for a while -- Madhu
From: Madhu on 7 Jan 2010 05:38 * Ron Garret <rNOSPAMon-80EA8C.02112007012010(a)news.albasani.net> : Wrote on Thu, 07 Jan 2010 02:11:20 -0800: | In article <m3skai9qls.fsf(a)moon.robolove.meer.net>, | Madhu <enometh(a)meer.net> wrote: | |> * Ron Garret <rNOSPAMon-6777F5.01442807012010(a)news.albasani.net> : |> Wrote on Thu, 07 Jan 2010 01:44:28 -0800: |> |> | In article <m3pr5mbdq2.fsf(a)moon.robolove.meer.net>, |> | Madhu <enometh(a)meer.net> wrote: |> | |> |> The redefinition of structs has nothing to do with Point 2 Either. |> | |> | I don't know what point 2 is, but the original example included a |> | redefinition because "real" structs are opaque. The redefinition |> | was needed to reveal a particular aspect of the behavior of the |> | underlying implementation. |> |> Let's look at this ex Post - facto justification from the master of |> unchallenged master of dishonest debate of comp.lang.lisp. The |> |> So now you are claiming that redefinition of defstruct (which has |> undefined consequences) shows that a "real" structure instance is |> opaque? | No. OK. I thought not. Your "real structs" would probably be opaque even sans redefining the defstruct definition. So the "particular aspect of behaviour of the underlying implementation" that you wanted to reveal is implementation specific and comes under "Undefined consequences" AND it acts on a "real struct". How does this relate with your stated stated goal upthread, which was to address, in your words, (<rNOSPAMon-79BB44.23220404012010 @ news.albasani.net>): ``whether the assumption that "list based structs are plists and not alists" is reasonable.''. (Hint: There is no relation.) So what purpose did introducing defstruct redefintion (with undefined consequences) serve? effectively all you now saying is ``I introduced redefinition" to show "aspects of how a particular common lisp implementation interprets "undefined consequences''. So what general conclusion have you drawn on the ordinary list representation of "list based structs" or the "opaque" representation of your "real" structs, from observing the behaviour of redefintion (invoking undefined consequences) in a particular common lisp implementation? -- Madhu
From: Ron Garret on 7 Jan 2010 05:57 In article <m3k4vu9p3k.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > * Ron Garret <rNOSPAMon-80EA8C.02112007012010(a)news.albasani.net> : > Wrote on Thu, 07 Jan 2010 02:11:20 -0800: > > | In article <m3skai9qls.fsf(a)moon.robolove.meer.net>, > | Madhu <enometh(a)meer.net> wrote: > | > |> * Ron Garret <rNOSPAMon-6777F5.01442807012010(a)news.albasani.net> : > |> Wrote on Thu, 07 Jan 2010 01:44:28 -0800: > |> > |> | In article <m3pr5mbdq2.fsf(a)moon.robolove.meer.net>, > |> | Madhu <enometh(a)meer.net> wrote: > |> | > |> |> The redefinition of structs has nothing to do with Point 2 Either. > |> | > |> | I don't know what point 2 is, but the original example included a > |> | redefinition because "real" structs are opaque. The redefinition > |> | was needed to reveal a particular aspect of the behavior of the > |> | underlying implementation. > |> > |> Let's look at this ex Post - facto justification from the master of > |> unchallenged master of dishonest debate of comp.lang.lisp. The > |> > |> So now you are claiming that redefinition of defstruct (which has > |> undefined consequences) shows that a "real" structure instance is > |> opaque? > > | No. > > OK. I thought not. Your "real structs" would probably be opaque even > sans redefining the defstruct definition. There is no "probably." DEFSTRUCT can be used to define three different kinds of things. Two of those things are transparent with respect to their underlying implementations (lists and vectors), and one (what I'm calling "real" structs) is opaque. > So the "particular aspect of behaviour of the underlying implementation" > that you wanted to reveal is implementation specific and comes under > "Undefined consequences" AND it acts on a "real struct". > > How does this relate with your stated stated goal upthread, which was to > address, in your words, (<rNOSPAMon-79BB44.23220404012010 @ > news.albasani.net>): > ``whether the assumption that "list based structs are plists and not > alists" is reasonable.''. > > (Hint: There is no relation.) Of course there is. The fact that redefining the struct in the way that I did causes existing instances to behave in the way that they do is strongly indicative that the underlying implementation is neither a PList nor an AList (nor any other kind of self-contained associative map). BTW, the example works (insofar as the results indicate what I intended for them indicate) in CLisp and SBCL as well. So while the behavior may be "undefined" in terms of the standard, my example turns out to be quite robust with respect to existing practice. rg
From: Madhu on 7 Jan 2010 06:39
* Ron Garret <rNOSPAMon-562C8C.02574207012010(a)news.albasani.net> : Wrote on Thu, 07 Jan 2010 02:57:42 -0800: | In article <m3k4vu9p3k.fsf(a)moon.robolove.meer.net>, | Madhu <enometh(a)meer.net> wrote: | |> * Ron Garret <rNOSPAMon-80EA8C.02112007012010(a)news.albasani.net> : |> Wrote on Thu, 07 Jan 2010 02:11:20 -0800: |> |> | In article <m3skai9qls.fsf(a)moon.robolove.meer.net>, |> | Madhu <enometh(a)meer.net> wrote: |> | |> |> * Ron Garret <rNOSPAMon-6777F5.01442807012010(a)news.albasani.net> : |> |> Wrote on Thu, 07 Jan 2010 01:44:28 -0800: |> |> |> |> | In article <m3pr5mbdq2.fsf(a)moon.robolove.meer.net>, |> |> | Madhu <enometh(a)meer.net> wrote: |> |> | |> |> |> The redefinition of structs has nothing to do with Point 2 Either. |> |> | |> |> | I don't know what point 2 is, but the original example included a |> |> | redefinition because "real" structs are opaque. The redefinition |> |> | was needed to reveal a particular aspect of the behavior of the |> |> | underlying implementation. |> |> |> |> Let's look at this ex Post - facto justification from the master of |> |> unchallenged master of dishonest debate of comp.lang.lisp. The |> |> |> |> So now you are claiming that redefinition of defstruct (which has |> |> undefined consequences) shows that a "real" structure instance is |> |> opaque? |> |> | No. [*] <-------------- LOOK HERE. [POINT-FOO] |> |> OK. I thought not. Your "real structs" would probably be opaque even |> sans redefining the defstruct definition. | | There is no "probably." DEFSTRUCT can be used to define three different | kinds of things. Two of those things are transparent with respect to | their underlying implementations (lists and vectors), and one (what I'm | calling "real" structs) is opaque. [*] <------------------- LOOK-HERE [POINTBAR] OK you have claimed that "opaque representations" are not LIST based representations (alist or plist or something else). | |> So the "particular aspect of behaviour of the underlying implementation" |> that you wanted to reveal is implementation specific and comes under |> "Undefined consequences" AND it acts on a "real struct". |> |> How does this relate with your stated stated goal upthread, which was to |> address, in your words, (<rNOSPAMon-79BB44.23220404012010 @ |> news.albasani.net>): |> ``whether the assumption that "list based structs are plists and not |> alists" is reasonable.''. |> |> (Hint: There is no relation.) | | Of course there is. No there isn't. You are now addressing the representation of opaque defstructs your "real structs", while your earlier intent was to have addressed List based defstructs (whether they were alists or plists). "list based". Sleight of hand. | The fact that redefining the struct in the way that I did causes | existing instances to behave in the way that they do is strongly | indicative that the underlying implementation is neither a PList nor | an AList (nor any other kind of self-contained associative map). So now your claim is that a `particular aspect of behaviour of the underlying implementation' on changing a defstruct definition (which has undefined consequences) in specific implementations is strongly indicative that the underlying representation of "real defstructs" is neither an alist or a plist. But does it not do this by indicating they are opaque? To wit there are three problems with this claim which make it entirely superflous. 1. It is trivially determined that OPAQUE "real defstructs" are NOT LIST-BASED. See [POINT-BAR] above where you DEFINED that they cannot have LIST-BASED representations because they are OPAQUE. 2. Your `particular aspect of behaviour of the underlying implementation' is as good as any other aspect of behaviour that ANY implementation may choose --- in implementing defstruct redefinition, which is defined to have undefined consequences. This means that ANY[1a] INTERPRETATION of UNDEFINED consequences is JUST AS STRONGLY indicative that "real defstruct instances" with OPAQUE representation is NOT list-based. [1a] with the exceptions where an implementation specifically changes the representation from of a "real defstruct" from a opaque represenatation to a list, just to spite you, but these do not exist] IOW Your `strong indication' does not follow from the specific behaviour of "undefined consequences" but from definitions. 3.Your last claim that ``The fact that redefining the struct in the way that I did causes existing instances to behave in the that they do is strongly indicative that the underlying implementation is neither a PList nor Alists'', works because the specific behaviour Only indicates a representation of real defstructs that suggests it is Opaque (and therefore not plists or alists). But when I asked this question earlier you dismissed this with a "No." See [POINT-FOO] above. | BTW, the example works (insofar as the results indicate what I | intended for them indicate) in CLisp and SBCL as well. So while the | behavior may be "undefined" in terms of the standard, my example turns | out to be quite robust with respect to existing practice. But still irrelevant to the `clue' you were going to give to Matt-with-no-surname. -- Madhu |