Loading ...
Sorry, an error occurred while loading the content.

Re: [forth200x] Doing DOES>

Expand Messages
  • Anton Ertl
    ... align here [ ] MY-ACTION ACTOR: ; ... This technique can also be varied to not work with addresses, but directly with the data (where it is
    Message 1 of 29 , Jul 8, 2009
    View Source
    • 0 Attachment
      Mitch Bradley wrote:
      > Instead of:
      >
      > : MY-DEFINER CREATE <builder-stuff> DOES> <action-stuff> ;
      >
      > It would be better to say:
      >
      > : MY-ACTION <action-stuff> ;
      > : MY-DEFINER ['] MY-ACTION ACTOR: <builder-stuff> ;

      A slight variation of that is already possible in Forth-94:

      : MY-ACTION <action-stuff> ;
      : MY-DEFINER
      align here <builder-stuff> ['] MY-ACTION ACTOR: ;

      > The only new word here is ACTOR: ( xt "<spaces>name" -- )

      That would then be:

      : actor: ( addr xt "<spaces>name" -- )
      >r >r : r> postpone literal r> compile, postpone ; ;

      This technique can also be varied to not work with addresses, but
      directly with the data (where it is constant), allowing optimization
      that is not possible with DOES>:

      : offset: ( n "name" -- )
      \ "name" execution: ( addr -- addr+n )
      >r : r> postpone literal postpone + postpone ; ;

      - anton
    • Hugh Aguilar
      This looks interesting. I agree with what you say about DOES being odd. In any case though, the action and the builder parts are going to execute at different
      Message 2 of 29 , Jul 8, 2009
      View Source
      • 0 Attachment
        This looks interesting. I agree with what you say about DOES> being odd. In any case though, the action and the builder parts are going to execute at different times and (in the case of a cross-compiler) on different machines. There is nothing that can be done to change that..

        An advantage of your method over mine is that yours doesn't involve manually compiling the action word, which can be clumsy.. A disadvantage of your method is that manual compilation is sometimes a good thing as the action word contains literals that are not known until the time when the builder stuff is/has executed.

        Another disadvantage of your method is that you are still pulling the names out of the input stream. This isn't bad with one-action words, because the programmer writes something like this:

        MY-DEFINER XXX

        So far so good; this is just like a DOES> word. The problem comes with multi-action words in which the programmer writes something like this:

        MY-DEFINER XXX &XXX XXX++ XXX--

        That is requiring the programmer to know all of the helper words that will be generated and get them in the correct order. That shouldn't be his job. He should just provide the single name XXX and let MY-DEFINER derive the helper word names from the XXX by pasting on suffixes and prefixes as needed. 

        I still think that my :NAME is the simpler and more robust solution. Also, my :NAME can be used for a lot of things other than just "the abstract thing that DOES> does." I mentioned early-binding OOP and local variables previously.

        I also think that it makes more sense to define colon in terms of :NAME, rather than define :NAME in terms of colon.. The former is trivial. The latter is complicated and requires taking recourse in EVALUATE. Also, the programmer may want to define his own custom version of colon that generates helper words. All in all, it is best to provide a low-level word such as :NAME and define the high-level words such as colon on top of it, rather than provide the high-level colon and then use EVALUATE to define the low-level :NAME on top if it.

        I'll bet that your ACTOR: and ACTORS: could be defined in terms of :NAME without any other divergence from ANS-Forth standard code. True?



        From: Mitch Bradley <wmb@...>
        To: forth200x@yahoogroups.com
        Sent: Tuesday, July 7, 2009 9:41:08 PM
        Subject: [forth200x] Doing DOES>

        Here is my swag at the right way to do DOES>. I don't mean DOES>
        exactly, but rather the abstract thing that DOES> does. (How's that for
        an obtuse expression?)

        DOES> in its historical form is rather odd. It splits a colon
        definition in half, creating two fragments that are individually almost,
        but not quite, colon definitions. Worse yet, the two
        almost-colon- definitions execute at different times, and perhaps on
        different machines. These factors create problems all over the place -
        in compilers, debuggers, decompilers, language definition, ...

        There is a way to express the utility of CREATE .. DOES> without the
        problems. The first key is to avoid "almost colon definitions" , using
        only real colon definitions. The second key is to use Forth's core
        strength: postfix notation.

        Instead of:

        : MY-DEFINER CREATE <builder-stuff> DOES> <action-stuff> ;

        It would be better to say:

        : MY-ACTION <action-stuff> ;
        : MY-DEFINER ['] MY-ACTION ACTOR: <builder-stuff> ;

        The only new word here is ACTOR: ( xt "<spaces>name" -- )

        It's a defining word that essentially combines CREATE and DOES>, except
        that the action clause is given by the xt instead of compiling it
        afterwards into a funny almost-colon- definition.

        The action need not be a colon definition - the xt could refer to a code
        word just as well, obviating the need for ;CODE .

        If you want the action code to anonymous - you could say:

        :NONAME <action-stuff> ;
        : MY-DEFINER LITERAL ACTOR: <builder-stuff> ;

        This approach is easily extended to multiple actions with ACTORS: ( ..
        xt n "<spaces>name" -- ). Of course, as with any multiple-action
        scheme, you need some way to invoke the alternate actions.

        Syntactically, of course, it's not as compact as CREATE ... DOES>, but
        it does avoid a lot of weirdness.
        (As an example of such weirdness, it took the ANS Forth committee a long
        time to refine the definition of DOES> to some semblance of correctness. )

        New defining words (e.g. MY-DEFINER above) are used exactly as before,
        so the extra verbosity applies only to the less frequent case of making
        new defining words, not to the more important case of using them.


      • brienjenny
        ... Yes that wouldn t work well, and I don t think it was Mitch,s intention. Since Forth already uses prefixes to distinguish multiple actions, perhaps the
        Message 3 of 29 , Jul 9, 2009
        View Source
        • 0 Attachment
          --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:


          > So far so good; this is just like a DOES> word. The problem comes with multi-action words in which the programmer writes something like this:
          >
          > MY-DEFINER XXX &XXX XXX++ XXX--
          >
          > That is requiring the programmer to know all of the helper words that will be generated and get them in the correct order. That shouldn't be his job. He should just provide the single name XXX and let MY-DEFINER derive the helper word names from the XXX by pasting on suffixes and prefixes as needed.
          >

          Yes that wouldn't work well, and I don't think it was Mitch,s intention. Since Forth already uses prefixes to distinguish multiple actions, perhaps the cleanest syntax would be

          xt <prefix> ACTION <actor-name>

          where ACTION associates an existing prefix with all future words defined by an existing actor name.

          Thus:

          prefix TO

          : VALUE ['] @ Actor: 0 , ;
          ' ! TO action VALUE
        • Hugh Aguilar
          Mitch Bradley s idea was good, and your idea is also good. That s the funny thing about Forth programmers --- they are always coming up with good ideas. The
          Message 4 of 29 , Jul 9, 2009
          View Source
          • 0 Attachment
            Mitch Bradley's idea was good, and your idea is also good. That's the funny thing about Forth programmers --- they are always coming up with good ideas.

            The purpose of :NAME is to give the Forth programmers a low-level tool that they can use to implement high-level constructs. Lots of people have their own idea regarding "the abstract thing that DOES> does," as well as various other abstract things. People use Forth (rather than C, etc.) so they can implement these ideas, rather than just fit themselves into the procrustean bed that their language designer has made for them. Well, go for it! I don't really expect that many people will use :NAME directly in their application code. Most of them will write some kind of wrapper around it, and use that in their application code.


            From: brienjenny <jennybrien@...>
            To: forth200x@yahoogroups.com
            Sent: Thursday, July 9, 2009 5:20:41 AM
            Subject: [forth200x] Re: Doing DOES>

            --- In forth200x@yahoogrou ps.com, Hugh Aguilar <hughaguilar96@ ...> wrote:

            > So far so good; this is just like a DOES> word. The problem comes with multi-action words in which the programmer writes something like this:
            >
            > MY-DEFINER XXX &XXX XXX++ XXX--
            >
            > That is requiring the programmer to know all of the helper words that will be generated and get them in the correct order. That shouldn't be his job. He should just provide the single name XXX and let MY-DEFINER derive the helper word names from the XXX by pasting on suffixes and prefixes as needed.
            >

            Yes that wouldn't work well, and I don't think it was Mitch,s intention. Since Forth already uses prefixes to distinguish multiple actions, perhaps the cleanest syntax would be

            xt <prefix> ACTION <actor-name>

            where ACTION associates an existing prefix with all future words defined by an existing actor name.

            Thus:

            prefix TO

            : VALUE ['] @ Actor: 0 , ;
            ' ! TO action VALUE


          Your message has been successfully submitted and would be delivered to recipients shortly.