Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: ... and zen there were objects. Message-ID: <1594.UUL1.3#5129@willett.pgh.pa.us> Date: 24 Aug 90 05:05:11 GMT References: <11444@medusa.cs.purdue.edu> Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 180 In <11444@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > In article <1569.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: > >here. What you seem to be saying is: I can only imagine that OOF is > >implemented by using indirect function calls. Therefore, there is no > >reason to hide that fact from the OOF extensions. > > Not at the expense of efficiency and simplicity. In a language that > doesn't try to be consistently post/pre fix, why do you insist that > the syntax for OO be perfectly postfix? I just don't think the order > of message-object is that big a deal. So use whichever way costs less > in the implementation. I am able to read the OO abstraction into either > syntax, just as I can read word definition into either > : zzy ... ; or { ... } "zzy" define . To paraphrase your reply: "Well, Forth isn't consistent anyway, so there is no need to worry about muddling the pot any more. Just hack whatever is easiest." The point is that in OOP, objects are active and messages are "parameters". Parameters go first. Even CONSTANT has the constant value on the stack, rather than parsing it as " CONSTANT 24 Lines/Page". OOP is not all that simplisitic in its implementation. It is a powerfully simple idea, but it takes *some* machinery to make it work. See my reply to Patel: "What are you trying to get by adding OOP to Forth" etc... > >No, I think inconsistency is ugly. In order to do delayed sends you > > What inconsistency? ( Your scheme: ) 10 20 MyRectangle MoveTo ( vs. ) 10 20 ' MoveTo ( done in a separate word ) MyRectangle SWAP EXECUTE ( delayed sends are not written the same in your message-active version. You even quoted me 'In order to do delayed sends' ) ( In my scheme: ) 10 20 MoveTo MyRectangle SEND (vs.) 10 20 MoveTo ( done in a separate word ) MyRectangle SEND ( see, the message and its arguments are constructed in exactly the same way. Just *add* object and SEND. Easy, simple, consistent.) > >are going to have to play stack manipulation games. In your scheme > >you write delayed sends differently because you have no choice. In > > No, you have no choice! Huh? You have no choice in that you MUST write delayed messages sends differently. It follows directly from the fact that message-names are active. > Same thing with my scheme. No, you're scheme requires gratuitous stack mungling and writing sends differently depending on whether they are delayed or not, see above. Also see below. > You can claim all you want, but you haven't shown anything! You give > me a single example where my method would need to swap and yours wouldn't > and then claim my method is "not as good". I can turn around and give > you an example where yours would need to swap and mine wouldn't. Accuse me of not showing then do it yourself. My method (as I have shown you above) never requires a swap. The order is ALWAYS: SEND. Until you get to the SEND, nothing happens. You can write arbitrary Forth code to compute any and all of the components and the complex cases don't have to do anything special just because they are complex. The code to compute the message and its parameters doesn't change depending on whether you are doing a delayed send or not. You can write a word that pushes parameters and a message name onto the stack. Other code can then merely push an object and SEND. No stack machinations. Works even for cascaded messages: Object SEND SEND which sends with parameters to Object. That message leaves an object on the stack. That object (which may even be Object) is then sent with parameters . In your scheme: Object My scheme allows you to push the messages and their parameters onto the stack from separate words (or arbitrary code) without having to worry about any existing messages already on the stack. You cannot do that in your scheme. You have to arrange to quote the message names so that they don't fire before the object is put onto the stack. You also have to arrange that the messages put on later know how many other messages are already on the stack so that they can put their parameters underneath. The parameters stay in place, but the Ticked message names must be shuffled so that they stay on top of the stack. Therefore you have to know how many message names are on the stack to get the parameters (and the object when it comes to that part) far enough underneath. > Are you trying to say that forth should have no "swap"? Hardly. What I am saying is that everything I've read, and my esthetic sensibilities, both say that gratiutous stack manipulations are indicitive of poor factoring... items on the stack are not ordered the way that they should be. Cascading example above is just the kind of thing I'm refering to here. In order for one word to work properly it should not have to know what other words have (read: To push one message and its parameters onto the stack shouldn't require knowing how many other messages are already on the stack ahead of you). > I give the best implementation I can think of and show how the > object-message syntax matches that implementation more cleanly than > the message-object syntax. Of course it does, you set it up that way in the first place. > People object to me letting the implementation reflect in the syntax as > it somehow offends their OO ideals. You have yet to say what your OO ideals are. You have failed to indicate you have any. You have indicated that you are more interested in adding indirect function calling to Forth with the hopes that it might work out to be useful for OOF. > I claim that in forth the implementation has always been reflected in > the syntax, so that is not a very strong objection. (eg. It is obvious > from the syntax that there is a stack hiding back there somewhere.) Oh, and I objected to there being a stack? Where? I suppose all your data types are just: : ARRAY STACK ; : QUEUE STACK ; : LIST STACK ; : TREE STACK ; Ohh, you really got yourself there! :-) > Now here is some vague claim that my implementation is "not as good" as > some other one that hasn't even been specified! My implementation is > inconsistent? I have yet to see "your way". I challenge you to give an > implementation that fits your chosen syntax and fits as cleanly with forth > as the one I gave for my syntax. If you could do that, I would probably > prefer your syntax too. ... naaaaaah! The inconsistency of your implementation depends only your implementation. I don't have to provide any alternatives in order to show that. Of course you wouldn't, you didn't invent it! :-). Besides, you haven't shown your implementation (I assume your copping one of the ones posted on the net). What I have done is shown you rough-sketches and proofs-of-concept. I will hardly go to the bother of implementing them before I'm sure their sound. Do you always do your coding without thinking through your design? :-). In actuality, I would like to have an implementation that does just what I describe. I think it is possible. I think your way is possible too. I think my way is better. I have seen nothing to indicate an implementation difficulty. I have already sketched several ways to do it. If you may recall I started this whole thread because of the short comings I saw in the existing active object and active message OOFS. I never claimed to have implemented a better way. If I had implemented a better way I would have posted it. My point was to *indicate* that there is a better way. I have shown above that while your scheme may work most of the time, there are cases that it botches: Cascades interacting with delayed message sends. How many cracks do I have to find in a bridge before I won't use it? One, if it is serious enough, even if it is in a corner. You keep asserting that yours is the only efficient way to do OOP in Forth. I grant that you have an efficient mechanism, but withhold granting that it is OOP. You say that I claim you don't understand what OOP is, and yet you can only reply by merely saying that you do in fact understand. You claim that Message-Object and Object-Message can be scanned just as easily. I claim that that is only true in the simplest of cases. Cascading again belies that claim: 10 20 30 40 Object message-1 message-2 Which parameters belong to which message. Where is the dividing line? 10 20 30 message-1 30 Message-2 Object SEND SEND Now where is the dividing line? If you can't get something that simple right, there is no way I'm going to trust you'll get something tricky right. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]