Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bu.edu!purdue!bouma
From: bouma@cs.purdue.EDU (William J. Bouma)
Newsgroups: comp.lang.forth
Subject: Re: ... and zen there were objects.
Message-ID: <11485@medusa.cs.purdue.edu>
Date: 29 Aug 90 19:48:32 GMT
References: <11455@medusa.cs.purdue.edu> <1626.UUL1.3#5129@willett.pgh.pa.us>
Organization: Department of Computer Science, Purdue University
 
 In article <1626.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes:
 >In <11455@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes:
 >>    No, you seem to be t
Lines: 84


    This is garbage! I have changed nothing! Message NAMES are active.
    This does not mean a message cannot be left on the stack. How can I
    make something so obvious more clear? In forth you can leave a word
    on the stack and "execute" it. Well, the names of forth words are
    active! In my system messages ARE just normal forth words. That is
    why it is so practical to implement.
    
  
 >>    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
 
 
    Your whole argument is based that the objects are unknown, computed on
    the fly. On top of that, you aren't quite sure what other arguments are
    to be included with the messages you are going to send! How often is this
    going to happen? To convice me, you will need to give something more
    specific than just the vague generalities so far! You seem convinced this
    sort of thing will be happening all the time.
 
 
 >>    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
 
 
     Why? Why do you think that the OO message has to care how its other
     arguments got there?  Again, how is this situation different from the
     way forth does everything already?
     
 
 >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
 
 
     Progress, I would call it digress! I still advocate the active messages.
     Why? 1. I see nothing better about the other way. 2. I have to type
     less "SEND"'s. 3. I can see how easy it is to implement. This is the
     same position I have had since day one. But what has this to do with
     our current discussion? I thought we had dealt with this issue 5 or 6
     messages ago. You mistakenly think I have changed my position.
 
 
 >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
 
 
     I wonder why I didn't think of that! 8^)
     It seems a lot of what I wrote has been missunderstood.
 
 
 >>     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?
 
 
     The answer to that question remains to be seen. (for both syntax's)
-- 
Bill <bouma@cs.purdue.edu>      Just ask the Axis   He knows everything