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: <1626.UUL1.3#5129@willett.pgh.pa.us> Date: 29 Aug 90 03:11:51 GMT References: <11455@medusa.cs.purdue.edu> Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 206 [Lines with an odd number of >'s are William J. Bouma.] [Lines with an even number of >'s are Doug Philips.] In <11455@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > No, you seem to be trying to make my chosen syntax fit yours! Try: > > 10 20 MyRectangle Moveto ( done in sep word ) > SEND Sorry, the message/parameters pushing is the part to be put into a separate word, if you change the problem of course the solution will change. BTW: you can't have it both ways. You were advocating an active message name system. Of course it gets simpler if you abandon that, that is one of my points. > If you consistently follow your syntax it is consistent. If you > consistently follow my syntax it is consistent. You argument here is > completely invalid. That claim is based on the fact you changed your position and went from active message names to passive message names. My point is still that the code which pushes messages and their arguments is written exactly the same way whether it is in a separate word or not. > If message is a literal, it must be quoted. That seems appropriate and > there is nothing inconsistent about it. In fact I could argue that your > method is flawed in that it treats literal and not literal messages the > same way. But that would be as stupid as the argument you are making. I > see nothing wrong with doing it either way. You've missed the point. "My way" allows arbitrary code to compute message "names". Your way has "active" message names. That means you must quote them if you want to delay the message invocation. In my method computing the message name and sending the message are separate steps. In my method one doesn't have to "write/construct" messages differently depending on when they will be sent. > to SWAP! An example? Suppose I want to send a list of message to > a group of objects possibly computed on the fly. Isn't that essentially > the inverse of the example you gave? How do you get this "list of messages" onto the stack? Are you assuming that those messages have no parameters? If the messages have parameters you must push those, then push the object, then push the message and send it. Its hard to talk in generalities about this specific case. Without knowing HOW you "store" your message list, it is hard for me to give a more concrete example of HOW we differ here. If your message list is a simple list of parameterless message ID's, then there is little difference in the mechanics of how our schemes work. If the messages have paramters your scheme is more complicated. > Object SEND SEND > > Now you are talking some sense. > You know, both of these look like a real mess when you put it this > way! It seems your syntax is better if you know what messages you > want to send, but the objects are not prespecified. Mine is better > if you have the objects, but the messages are variable. Although I > think you are making much bigger a deal of this than there is, you > way does appeal to me here. Interesting, though, that forth generally > takes the form of my syntax. What a mess it should be! I still disagree here. You have to manipulate the stack to get the objects in-between the parameters and the messages (which is why I called the message-last form "inside out" in my initial posting). Making your scheme into passive message names (i.e. requiring an explicit SEND) does not alter the fact that you have to wiggle the object down the stack to its "proper" place. > >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 am not convinced that it does. Well, I can't say why you aren't convinced, but I'll try re-phrasing it this way: Your scheme requires that objects be on the stack between message parameters and the message id's. That means that cascading requires that you push parameters onto the stack below the object. In order to do that you need to know how deep to go to find the object, i.e. you need to know how many pending messages are already on the stack. As for your question: > Do words in forth need to know how > many other words went before them? They aren't supposed to, as I understand Forth. Words that use parameters on the stack aren't supposed to care how they got there. In your scheme words that want to push "delayed" sends MUST know how many other messages there are pending on the stack in order to work properly. I consider my method to be cleaner and more Forth-like. > Am I talking to a brick wall? I chose the best implementation I could > think of. That implementation just happens to fit a particular syntax > which happens to be different than your ideal. I wish I, or someone > could devise an implementation that fits your syntax as cleanly. Then > perhaps we could stop arguing. We aren't arguing implementation. We are arguing design. You built your design around an implementation (or so it seems from your arguments). I built my design based on principles of how Forth words should be factored. > Huh? What are you blabbering about? I have no idea what you are reading > in to what I wrote there? > You have yet to say anything about implementation. All you have talked > about is syntax. When I say "implementation" I mean the code behind > the concept. How are objects and messages actually implemented in code > to provide the behavior you prescribe to them. Apparently you have a > different definition! I guess I was being too subtle. You have still not responded to my questions about design. As far as I can tell, you insist that the implementation drive the design. If you would decide that the best way to implement a tree were with an array, I would expect to see array operations available for your tree objects. How you use something is not the same as how you implement it. > In my original message I made a case that the object at the end syntax > had problems in its IMPLEMENTATION. That syntax would not be as clean or > simple as the message at the end syntax in its implementation in forth. > I am still waiting for someone to show me I am wrong here! I have shown you that in the case of cascaded messages. My method has suggested (and finally in this message stated directly) that the composing and the sending of a message should be distinct steps. What you have been advocating, until now, is active messages (which requires them to be last, of course). You seem to have backed off to just a message-last position with an explicit SEND. I suppose that means I'm making some progress in convincing you of the uncleanliness of message-last form. You see, there is another issue that has been here too, which is ease of implementation versus ease of use. I claim that if one designs without a specific implementation in mind at the start that one is more likely to achieve both ease of use and ease of implementation. Your method and mine are similar in ease-of-use if one is doing very simple things. If one is doing more complicated things then using your system is more complicated than using mine. > You have argued that the message at end syntax will cause the programmer > stack manipulation grief. You are correct that that would be a valid > reason to scratch that syntax in favor of the object at end. But that > would be DESPITE the implementation. As stated above, I think your > arguments are basically flawed and that either syntax will cause grief > depending on what you are trying to do. Well, you railed at me in an earlier posting for 'claiming without showing,' now you are doing the same thing. You see, I have never wanted to discuss particular implementation details and have avoided doing so as much as I could. I was arguing against active objects and active messages from a users point of view, not from an implementor's point of view. I guess I didn't make that clear enough. In any event, I ask you to SHOW me how my way will cause grief. I am certainly willing to discuss implementation after we can agree on what it is we should be implementing. See next reponse. > Lost me here again. You THINK it is possible, and yet you KNOW several > ways to do it? I must have missed your post on how to do it. I was unclear. I think it is possible in Forth. I know it is possible in other languages, because its been done. The techniques should apply without undue difficulty. In fact I would be hesitant to insist on any one of them over the others since there are, in fact, efficiency trade-offs. > > > > 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 > > You are being very silly here! Of course this is simple to understand > because you have chosen numbers as the arguments, messages have the word > "message" in them and objects say "object"! 8^) I specifically chose enlightening names for two reasons: Its good programming style, and it highlights how even with good names your scheme makes unclear which of the numbers/arguments goes with which of the messages. In my scheme messages and arguments are grouped together, and it is thus easy to tell which parameters go with which messages. > extreme and see if you can parse it either way: > > a b c d e f g SEND SEND I won't try to argue that you can't write opaque and incomprehensible code in Forth. > Let's try a real (contrived 8^) example: > > dog fly frog net shelf obtain-from catch-in > > dog fly frog catch-in net obtain-from shelf SEND SEND > > Again, doesn't it depend on what you are doing? Precisely the point! Again, your method and mine are of similiar comprehensibility and ease-of-use for simple things. My method lets you do compilicated things in an easier way. No programming method will prevent you from writing obscure and incomprehensible code. The question shoule be: How easily/comprehensibly can you write easy AND complicated things? -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]