Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : topmind Date : Thu Aug 11 2005 11:07 pm [Part 2 of reply] > > >>> "Locations" are increasingly obsolete and meaningless in cyberspace. > >> > >> [The] bits still need a home *somewhere*. > > > > The "real world" is not tree-shaped for the most part. > > Mu. Un-Mu. > > > >> If you can't answer trivially simple questions about trivial examples, > >> what's the point in discussing more complex ones? > > > > If you can demonstrate that "structure" is a mathematically precise > > term, I will lend credence to your claim of my delusionment. Deal? > > Nope, since it really wasn't a structure question. Your inability to > answer a simple set theory question indicates you don't know set theory. > That's fine. Just checking. End of story. You are trying to use social intimidation instead of facts to back your points. > > > >> So, you bumped the issue up to a higher level and let them work out > >> which of THEM had a higher priority for your time. In other words, > >> it was *entirely* hierarchical. > >> > >> Which was exactly my point. > > > > Being "higher" is not necessarily hierarchical. Jet "A" may be higher > > than Jet "B" in the sky, but that does not necessarily imply that the > > placement of jets is hierarchical, for example. > > Jets in they sky don't have a relationship. Bosses and employees do. > So trees are about *social* relationships??? Your fuzz factory is working all 3 shifts this week. > Hierarchies *are* about relationships, and like it or not, the world > is *filled* with them. > Relationships, yes. Trees, no. > > >> You DO understand the difference between *using* a browser and writing > >> the code for it, don't you? > > > > To keep things clear, let's stick to one viewpoint or the other. You > > pick. Then, let's revisit the topic. Deal? > > Let's recap. You claimed GUI software--note the term: SOFTWARE--was > not hierarchical. I showed you that it was. Then you shifted to talking > about GUI usage. I meant it from the point-of-view of the application developer, and not the builder of the tool ("boxed" software). If that was not clear, I apologize. > > Software--in general--is hierarchically structured. It has high-level > routines, mid-level routines and low-level routines. Not event-driven software (from custom app perspective), at least not on the large scale. The closest thing would be a start-up form, which simply has an attribute or reference somewhere marking it as the starting point. However, it is trivially changable to another form just like picking a different student to be the hall minitor. > > > >>> You know, it is tough to describe this very well with words. > >> > >> For the fourth or fifth time: I UNDERSTAND THE PICTURE! > >> Do you understand the question? > > > > No. > > Once more: > > >You> But a pure tree has no duplicate nodes. > > >Me> Show me one authority that agrees. > > I don't know how to make the question plainer. Sigh. This gets back to the interchangability between duplicate nodes OR cross-branch links. They are interchangable views of the same thing. > > > >> Just because multiple node happen to *refer* to the same thing, the > >> nodes themselves--their place in the tree--ARE NOT DUPLICATES. They > >> represent distinct, *necessary* (we presume) occurrances. > > > > They *are* duplicates or pointers (cross-branch). As proof, if we > > want to change the name of or address in RAM of the called routine, > > we have to update multiple spots. It is a fricken graph. I would > > bet a paycheck on it if my wife would let me. They are multiple > > references to the same thing and they bust tree-ness. > > You'd lose that paycheck. Neener neener tree poop! > > Consider the "list" of routines visited during the execution of > a program. It represents the thread of execution. It is a DYNAMIC > thing generated by a running program. > > If that thread of execution re-visits a routine more than once, then > that routine MUST appear in the list more than once. THAT IS THE > REALITY--the program re-entered that routine. > > If you treat the "main" function that started the program as the root, > you can draw a tree that represents that list of routines. That tree > is "perfect" in the sense that no node "cross-connects" to any other > node. > > Yes, it does have "duplicate" nodes, but NO that doesn't bust "treeness" > (no matter how much you might wish it did). It is a "perfect" tree that > represents the thread of execution of the program. Like I keep saying, ANY graph can be turned into a tree with no cross-branch links simply using node duplication. That is not the issue. I don't dispute that hat-trick, but you keep wording this like I do. Any graph can be a "perfect tree" by your loose definition (allowing dups or CBLs). That does not get us any where. The more duplication and/or cross-branch links, the less useful tree-oriented tools and techniques will be. Maybe our threashold is just different: I may switch to sets when the dup/cross factor is something like 15% and you will wait until something 50%. > > > I am only defining "pure tree" as one without duplication. > > Your definition is seriously broken. Find one authority that agrees. It is a working definition to describe a situation, not a formal one. It would be interesting to see an algorithm that scores node dup or cross-branch-links of a candidate tree. > > > Are you suggesting that since reality has duplication that our > > databases should also even if there are techniques to remove it? > > But they don't *remove* it, they (in a sense) compress it by normalizing > the data. In a database version of the call graph, you'd have one record > for each routine and a separate--"duplicate"--record in some other table > for each time you visited that routine. Normalizing it just turns the duplication into a cross-branch "pointer". Like I keep keep keep saying, both representations are interchangable. But the "pure tree" buster is still there regardless of wether you represent it with dups or CBL's. > > (In fact, given the appropriate query, the duplication "returns".) > > > >>>> ...the parse tree itself is still a "pure" tree, > >>>> because each "IF/ELSE" is contextually different. > >>> > >>> ...I ignore the IF/ELSE issue here, but would like to point out > >>> that in some languages control constructs such as IF and WHILE are > >>> simply function calls with some fancy scope management features > >>> used rather than being built into the language. > >> > >> 1. That doesn't change a thing with regard to parse trees. > >> 2. That is USUALLY the case unless you're programming in assembly. > >> (That is, If/else and while are high-level constructs implemented > >> by the language--they ALL translate to something more complex > >> than the words "if" and "While".) > >> > >> We can apparently add parse trees to the list of things you don't > >> really understand. > > > > In languages such as SmallTalk, LISP, and TCL, one can roll-their-own > > control structures using the language itself. Do you question this? > > Not at all, but it has nothing to do with parse trees. Then please clarify. I see no need to make a distinction between control structures and functions because in some languages that are the SAME thing. The other languages simply "hard-wire" them into the syntax or lang definition. > > > If not, then please apoligize for insulting me. > > It still looks like you don't know what a parse tree is, so no. Whenever you lose and argument, you seem to accuse me of ignorance. Prove I am ignorant with details instead of claim it with vague accusations. By the way, here is an example from c2.com wiki: This code: sub x(a,b,c) { i = a while (i < 20) { if odd(i) { i = i + b } else { i = i + c print("in else") } print("in loop") } // end-while print(i) } Can be represented as a tree: sub x(*) -------- * * * * * * * * * * * * * * * * * * i = a while(*) print(i) ----- ----- -------- * * * * * * if(*) print("in loop") -- ---------------- ** * * * * * * i=i+b else ----- ---- * * * * i=i+c print("in else") ----- ---------------- (*) = full expression not shown > > > >> So? The point was that this GUI program definitely has higher and > >> lower level functions. Apparently you no longer disagree. > > > > It *can* be implemented that way under the hood, but the implementation > > is moot to the user (app developer). > > I have been *talking* about the app developer all along. > I have not been talking about implementing the GUI engine. > > The code I showed you was developed (by me) as an APPLICATION. > As I said last time: Yes, but I asked for an *event driven* example. That is not event-driven, or at least is not the event-driven part of the code. > > >> This isn't about anything hidden or under the hood. > >> It's about how you write a program. > >> It's about how you analyse a problem and break it down. > > > > Where is the "tree" in an event-driven application? > > I **showed** it to you several posts ago. That was APPLICATION code. app, yes. Even-driven, no. Please, show us an "event-driven tree". I have never seen a Unicorn. > > > Remember, I am NOT asking how one may impliment the event manager. > > We are using the tool, not making it here. > > And I have responded ALL ALONG as an app developer. Only if one is rolling their own event handler. > > > -- > |_ CJSonnack _____________| How's my programming? | -T- .