Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: Re: ... and zen there were objects. Message-ID: <11455@medusa.cs.purdue.edu> Date: 25 Aug 90 02:21:01 GMT References: <11444@medusa.cs.purdue.edu> <1594.UUL1.3#5129@willett.pgh.pa.us> Organization: Department of Computer Science, Purdue University Lines: 206 In article <1594.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >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: When it starts like that, it can only get better! 8^) >> >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 No, you seem to be trying to make my chosen syntax fit yours! Try: 10 20 MyRectangle Moveto ( done in sep word ) SEND > ( 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.) If you consistently follow your syntax it is consistent. If you consistently follow my syntax it is consistent. You argument here is completely invalid. >> >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. Uh, you lost me here? First let me say that my reply above came from a missunderstanding of what you wrote. I though you meant that I write delayed sends differently from the way YOU write them. 8^) I really don't understand what you mean? Differently than what? I can always write my OO lines like this: Arg Arg ... Object Message SEND 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. >> 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. My scheme does not require "gratuitous stack mungling". >> 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. Well, it just seems pretty obvious. You claim that my syntax is flawed because you can have some code compute a message, THEN push an object on the stack and call SEND. Under those circumstamces, I would have to call SWAP before the SEND. So, what if I reverse this on you. I have some code that returns an object, THEN I push a message on the stack and call SEND. Under that circumstance, your method would need 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? > 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 Or: 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! >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. Do words in forth need to know how many other words went before them? >> 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. 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. >> 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! :-) Huh? What are you blabbering about? I have no idea what you are reading in to what I wrote 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. 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! 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! 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. >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 You presume too much! >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. 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. >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 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^) Try going the other extreme and see if you can parse it either way: a b c d e f g SEND SEND 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? -- Bill Just ask the Axis He knows everything