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

Re: [forth200x] RfD:

Expand Messages
  • Elizabeth D Rather
    ... In the first place, the word that Mitch and others are referring to is BUFFER: (it s been around since the 80 s). It can coexist with CREATE ... No code
    Message 1 of 29 , Jul 1, 2009
    View Source
    • 0 Attachment
      Hugh Aguilar wrote:
      >
      >
      > Your LABEL and BUFFER words aren't a solution because they break the
      > existing code that uses CREATE to define a buffer of memory. A typical
      > example would be.
      >
      > CREATE XXX 10 ALLOT
      > this would have to be changed to:
      > 10 BUFFER XXX
      >
      > This isn't any better than breaking the existing code that uses CREATE
      > in conjunction with DOES>. Either way, something gets broken.
      In the first place, the word that Mitch and others are referring to is
      BUFFER: (it's been around since the 80's). It can coexist with CREATE
      ... ALLOT just fine; in many systems it's defined as:

      : BUFFER: ( n -- ) CREATE ALLOT ;

      No code is broken.

      Don't minimize the potential problems of a standard breaking code,
      though. There are important commercial systems around with millions of
      lines of code. CREATE and <BUILDS would not be perfectly
      interchangeable. The cost of inspecting each instance, and then
      performing validations on the edited result is potentially vast. What
      happens when you make a code-breaking change in a standard is that a lot
      of folks just don't adopt the new standard, so the potential advantages
      for portable code, etc., are lost. It's certainly not worth doing over
      a trivial issue like this, for which there are excellent solutions that
      have been in common practice for many years.

      Cheers,
      Elizabeth

      --
      ==================================================
      Elizabeth D. Rather (US & Canada) 800-55-FORTH
      FORTH Inc. +1 310.999.6784
      5959 West Century Blvd. Suite 700
      Los Angeles, CA 90045
      http://www.forth.com

      "Forth-based products and Services for real-time
      applications since 1973."
      ==================================================
    • Bernd Paysan
      ... No, this wouldn t have to be changed. The code with CREATE still works, it just has a little more overhead than the BUFFER: solution. You only have to
      Message 2 of 29 , Jul 1, 2009
      View Source
      • 0 Attachment
        On Dienstag 30 Juni 2009 21:29:08, Hugh Aguilar wrote:
        > Your LABEL and BUFFER words aren't a solution because they break the
        > existing code that uses CREATE to define a buffer of memory. A typical
        > example would be.
        >
        > CREATE XXX 10 ALLOT
        > this would have to be changed to:
        > 10 BUFFER XXX

        No, this wouldn't have to be changed. The code with CREATE still works, it
        just has a little more overhead than the BUFFER: solution. You only have to
        change your code if you want less overhead.

        > This isn't any better than breaking the existing code that uses CREATE in
        > conjunction with DOES>. Either way, something gets broken..

        No, this is a lot better. The existing code that uses CREATE to allocate a
        buffer continues to work. The existing code that uses CREATE together with
        DOES> continues to work. If you break CREATE, this code will stop to work. The
        new word, BUFFER:, allows implementers to optimize this special case (named
        buffer space), and programs that use this BUFFER: will benefit.

        > Stephen suggested that we introduce <BUILDS but allow CREATE to be used for
        > a while as an obsolescent feature (along with QUERY, TIB, EXPECT, etc.) to
        > support legacy code. I would be okay with that, although it does make the
        > compiler writer's job more difficult. For the most part, I don't think
        > legacy code is all that important.

        Nope, it *is* important. Breaking existing code is not ok for a standard.

        > You can easily enough fix your legacy
        > code by using a text editor to search for DOES> and then replace the
        > associated CREATE with <BUILDS. Then just compile the program. DOES> will
        > crash the compilation with an error message ("---missing <BUILDS---") if
        > you missed one, and it will tell you where the offended DOES> is in the
        > source-code.. Asok the Intern could do this job!

        Of course. It's just a bit tedious if you have 1 million lines of code like
        CCS. And it's annoying if your program that worked perfectly breaks because
        someone changed the standard.

        > When I wrote MFX, I used <BUILDS just to make my own life easier. Other
        > than that, MFX was pretty much Forth-83 compliant. I told my users to make
        > the change, and there were no complaints. Considering that we were
        > implementing a first-ever application on a new microcontroller, with a
        > completely new assembly language, switching from CREATE to <BUILDS wasn't
        > the most difficult aspect of our job! Actually, I only had one coworker, so
        > I should say "user" rather than "users."

        This is a quite different situation from what most system implementers in the
        standard committee face. We have more than one user, and we don't build
        systems from scratch.

        > Forth has a lot of "cruft" in it, most of which are artifacts of the old
        > threaded implementations of the 1980s. CREATE-DOES> is a typical example.
        > As I explained in my RfD, the original motivation was to save memory.
        > Similarly, as I mentioned in regard to VALUE, the original motivation was
        > to increase speed, as a constant was slightly faster than a variable
        > followed by a @. This is all just cruft --- none of these issues matter
        > anymore, now that we have almost completely abandoned threaded systems in
        > favor of optimizing compilers.

        But this argument renders your original motivation null and void. An
        optimizing compiler has no problems whatsoever to compile optimal code both
        for CREATE with and without DOES>, and not waste space in either case. The
        motivation to separate CREATE and <BUILDS is an artifact of simple threaded
        code compilers; especially with the fig-Forth implementation where <BUILDS had
        a two-cell CFA, while all the other words had one-cell CFAs.

        --
        Bernd Paysan
        "If you want it done right, you have to do it yourself"
        http://www.jwdt.com/~paysan/
      • Richard Borrell
        It s not just the source code that is broken, it s the documentation too. Documentation that changes for life-critical applications has to be re-submitted -
        Message 3 of 29 , Jul 1, 2009
        View Source
        • 0 Attachment
          It's not just the source code that is broken, it's the documentation too. Documentation that changes for life-critical applications has to be re-submitted - expensive!
           
          It is good to see such an active and informative thread on this subject. I've been using Forth for more than 20 years, but know very little about how the Forth standards developed and why certain decisions were made. I think Hugh's provocative remarks will make the new standard much stronger.
           
          I too agree with Stephen's comment about phasing in <BUILDS. This should cause minimum disruption.
           
          Richard Borrell.
           
          -----Original Message-----
          From: forth200x@yahoogroups.com [mailto:forth200x@yahoogroups.com]On Behalf Of Bernd Paysan
          Sent: 01 July 2009 08:41
          To: forth200x@yahoogroups.com
          Subject: Re: [forth200x] RfD: <BUILDS

          On Dienstag 30 Juni 2009 21:29:08, Hugh Aguilar wrote:
          > Your LABEL and BUFFER words aren't a solution because they break the
          > existing code that uses CREATE to define a buffer of memory. A typical
          > example would be.
          >
          > CREATE XXX 10 ALLOT
          > this would have to be changed to:
          > 10 BUFFER XXX

          No, this wouldn't have to be changed. The code with CREATE still works, it
          just has a little more overhead than the BUFFER: solution. You only have to
          change your code if you want less overhead.

          > This isn't any better than breaking the existing code that uses CREATE in
          > conjunction with DOES>. Either way, something gets broken..

          No, this is a lot better. The existing code that uses CREATE to allocate a
          buffer continues to work. The existing code that uses CREATE together with
          DOES> continues to work. If you break CREATE, this code will stop to work. The
          new word, BUFFER:, allows implementers to optimize this special case (named
          buffer space), and programs that use this BUFFER: will benefit.

          > Stephen suggested that we introduce <BUILDS but allow CREATE to be used for
          > a while as an obsolescent feature (along with QUERY, TIB, EXPECT, etc.) to
          > support legacy code. I would be okay with that, although it does make the
          > compiler writer's job more difficult. For the most part, I don't think
          > legacy code is all that important.

          Nope, it *is* important. Breaking existing code is not ok for a standard.

          > You can easily enough fix your legacy
          > code by using a text editor to search for DOES> and then replace the
          > associated CREATE with <BUILDS. Then just compile the program. DOES> will
          > crash the compilation with an error message ("---missing <BUILDS---") if
          > you missed one, and it will tell you where the offended DOES> is in the
          > source-code. . Asok the Intern could do this job!

          Of course. It's just a bit tedious if you have 1 million lines of code like
          CCS. And it's annoying if your program that worked perfectly breaks because
          someone changed the standard.

          > When I wrote MFX, I used <BUILDS just to make my own life easier. Other
          > than that, MFX was pretty much Forth-83 compliant. I told my users to make
          > the change, and there were no complaints. Considering that we were
          > implementing a first-ever application on a new microcontroller, with a
          > completely new assembly language, switching from CREATE to <BUILDS wasn't
          > the most difficult aspect of our job! Actually, I only had one coworker, so
          > I should say "user" rather than "users."

          This is a quite different situation from what most system implementers in the
          standard committee face. We have more than one user, and we don't build
          systems from scratch.

          > Forth has a lot of "cruft" in it, most of which are artifacts of the old
          > threaded implementations of the 1980s. CREATE-DOES> is a typical example.
          > As I explained in my RfD, the original motivation was to save memory.
          > Similarly, as I mentioned in regard to VALUE, the original motivation was
          > to increase speed, as a constant was slightly faster than a variable
          > followed by a @. This is all just cruft --- none of these issues matter
          > anymore, now that we have almost completely abandoned threaded systems in
          > favor of optimizing compilers.

          But this argument renders your original motivation null and void. An
          optimizing compiler has no problems whatsoever to compile optimal code both
          for CREATE with and without DOES>, and not waste space in either case. The
          motivation to separate CREATE and <BUILDS is an artifact of simple threaded
          code compilers; especially with the fig-Forth implementation where <BUILDS had
          a two-cell CFA, while all the other words had one-cell CFAs.

          --
          Bernd Paysan
          "If you want it done right, you have to do it yourself"
          http://www.jwdt. com/~paysan/



          __________ NOD32 4202 (20090630) Information __________

          This message was checked by NOD32 antivirus system.
          http://www.eset.com
        • stephen@mpeforth.com
          ... Stephen said no such thing! What I said was that may have some merit, but that Hugh has provided no numeric evidence for his assertions.
          Message 4 of 29 , Jul 1, 2009
          View Source
          • 0 Attachment
            Hugh said:

            > Stephen suggested that we introduce <BUILDS but allow CREATE to be used
            > for a while as an obsolescent feature (along with QUERY, TIB, EXPECT,
            > etc.) to support legacy code.

            Stephen said no such thing!

            What I said was that <BUILDS ... DOES> may have some merit, but that Hugh
            has provided no numeric evidence for his assertions. Until that evidence
            is provided, there's only handwaving in the RfD. More importantly, the
            proposal is a code-breaker, and for that reason alone, I will vote against
            it if it comes as far as an CfV.

            Hugh, please do not twist my words.

            Stephen
          • Hugh Aguilar
            I apologize to Stephen Pelc for crediting him with the idea of introducing , but also allowing CREATE to still be used in this manner
            Message 5 of 29 , Jul 1, 2009
            View Source
            • 0 Attachment
              I apologize to Stephen Pelc for crediting him with the idea of introducing <BUILDS for use with DOES>, but also allowing CREATE to still be used in this manner as an obsolscent feature. I wasn't "twisting your words;" it was just a mix-up on my part --- sorry. This idea was from jethomas. The message I was referring to is below.

              Actually, I have chilled out on this compromise anyway. I had been assuming that CREATE could use a workaround in which it acts one way if it is inside of a colon definition, and another way if it is outside of a colon definition. Jethomas points out quite correctly that this won't work, as DOES> can be used with a CREATE word that was defined outside of any colon definition. There really is no good way for CREATE to boil down to CONSTANT, which in turn boils down to being a literal --- and so we end up forsaking all of the cool optimizations that involve literals --- CREATE words end up being as slow as colon words.

              My suggestion now is to go back to what I originally proposed --- that DOES> only work with <BUILDS, and not with CREATE. Legacy code is really not a big deal. As I explained before, DOES> will notice at compile-time that the previously defined word was something other than <BUILDS (a CREATE or a colon or whatever), and it will halt the compilation with an error message complaining of a missing <BUILDS. What could be easier? 

              I would now like to introduce what I call the "Asok Rule:"

              It is okay for the new standard to break legacy code if fixing this break is easy enough that Asok the Intern can do the job --- rather than requiring one of the more experienced programmers such as Dilbert or Wally --- and especially not Alice, as she might not be able to control her "Fist of Death."

              It is possible for a person to convert a program from CREATE to <BUILDS without knowing how that program works, or even what it does. This means that <BUILDS conforms to the Asok Rule, so it is okay.

              BTW, I did have only one coworker, but we weren't developing from scratch. He was porting over a very large existing Forth program. We were developing the MiniForth because that existing program pushed the limits of commercial microcontrollers in regard to speed requirements --- even after being gradually converted into pure 80C320 assembly language. My job was just to write the development system for the MiniForth, which included a Forth compiler, an assembler, and a simulator. The assembler was actually the most difficult part of the job. The MiniForth was a WISC machine (wide instruction set computer) in which several assembly-language instructions could be packed into a single opcode. My assember would rearrange the instructions in order to pack them together efficiently (minimize empty slots), while being careful that any instruction requiring a certain register to be set would be compiled after the instruction that set that register. Quite complicated!

              My experience with Forth has involved extreme run-time performance on custom hardware. That is also what I expect Forth-200x to be focused on. This is why I think that we should focus on cross-compilers as our #1 priority. The days of everybody using one particular microcontroller (the 8051 and its derivatives) are past. The future involves people using a huge variety of microcontrollers, and many companies using a proprietary microcontroller that they developed on top of a PLD of FPGA. In this environment, we can't wait for a commercial Forth vendor (such as Forth Inc.) to get around to writing a cross-compiler for whatever obscure microcontroller we are using --- we need to be able to write our own cross-compiler. And we can't wait for GCC to catch up either --- that is why Forth will be important in the future. Let the Factor folks have the desktop environment and leave Forth to run on microcontrollers. Forth will literally control the world! That is my vision of the future.



              From: jethomas3182 <jethomas5@...>
              To: forth200x@yahoogroups.com
              Sent: Tuesday, June 30, 2009 2:45:26 AM
              Subject: [forth200x] Re: RfD: <BUILDS


              I like your idea. You would make it easier to build optimising Forth compilers, and also make the language make more sense.

              I believe the problem for compilers is worse than you say. It isn't enough to use two versions of CREATE where one of them is compiled into a definition and the other is not. The Forth-94 standard lets you use DOES> with interpreted CREATE too.

              : BECOME-ARRAY
              DOES> SWAP CELLS + ;

              CREATE FOO 10 CELLS ALLOT BECOME-ARRAY 20 CELLS ALLOT

              This should create an array of 30 elements.

              However, Leon Wagner's second concern is important. Your proposal is incompatible with Forth-83 and incompatible with Forth-94. A whole lot of existing code -- almost all of it -- would become nonstandard. Compiler writers who want to cater to existing code would still have all the problems of dealing with the traditional CREATE and would have the minor additional concern of <BUILDS also.

              If we declared so much standard code to be suddenly nonstandard, too many people would complain bitterly.

              So I think you would do better to propose that <BUILDS be added to the core wordset, to do the same things that CREATE does, and then we could encourage people to use <BUILDS whenever they will later use DOES> . Depending on how widely that gets adopted then in ten years or 20 years the use of CREATE DOES> might get declared obsolescent and eventually become nonstandard.


            • Mitch Bradley
              ... That expectation does not agree with my expectation at all.
              Message 6 of 29 , Jul 2, 2009
              View Source
              • 0 Attachment
                > My experience with Forth has involved extreme run-time performance on
                > custom hardware. That is also what I expect Forth-200x to be focused on.

                That expectation does not agree with my expectation at all.
              • Leon Wagner
                ... No, it is not okay. It appears that you have not been following the Forth200x process and have not read the current draft as your expectations seem to be
                Message 7 of 29 , Jul 2, 2009
                View Source
                • 0 Attachment
                  > It is okay for the new standard to break legacy code if
                  > fixing this break is easy enough that Asok the Intern can do
                  > the job...

                  No, it is not okay. It appears that you have not been following the Forth200x process and have not read the current draft as your expectations seem to be pretty far out of alignment.

                  --Leon
                • Elizabeth D Rather
                  ... This is why it was mandated that DOES is only guaranteed to work with CREATE, not with other defining words. Operationally, FORTH, Inc. and most other
                  Message 8 of 29 , Jul 2, 2009
                  View Source
                  • 0 Attachment
                    Hugh Aguilar wrote:
                    > ...
                    > There really is no good way for CREATE to boil down to CONSTANT, which
                    > in turn boils down to being a literal --- and so we end up forsaking
                    > all of the cool optimizations that involve literals --- CREATE words
                    > end up being as slow as colon words.
                    This is why it was mandated that DOES> is only guaranteed to work with
                    CREATE, not with other defining words. Operationally, FORTH, Inc. and
                    most other implementors abandoned BUILDS> in the early 80's, so there's
                    really over 20 years of experience, incorporating millions of lines of
                    code, that BUILDS> is not needed.
                    > My suggestion now is to go back to what I originally proposed --- that
                    > DOES> only work with <BUILDS, and not with CREATE. Legacy code is
                    > really not a big deal. As I explained before, DOES> will notice at
                    > compile-time that the previously defined word was something other than
                    > <BUILDS (a CREATE or a colon or whatever), and it will halt the
                    > compilation with an error message complaining of a missing <BUILDS.
                    > What could be easier?
                    You clearly have been spared the experience of maintaining code to high
                    reliability standards. One cannot do a sweeping search/replace
                    operation without having to re-certify all the code, which can be a
                    tortuous, time-consuming and expensive proposition.
                    > ...
                    >
                    > My experience with Forth has involved extreme run-time performance on
                    > custom hardware. That is also what I expect Forth-200x to be focused on.
                    Many people working on Forth200x have extensive experience with
                    cross-compilers, including several who have responded to your
                    suggestion. They do not see a problem with the standard use of CREATE
                    with DOES>. Is it possible that the difficulty is with your
                    implementation? Perhaps you would benefit from looking at how some
                    other Forths, particularly cross-compilers, manage this; there are free
                    evaluation versions of cross-compilers from FORTH, Inc. and MPE
                    available, as well as several free systems.

                    Someone else asked you to document your concerns, and I agree this would
                    be helpful. For example, you assert, "CREATE words end up being as slow
                    as colon words." How slow? How much of a speed-up (if any) would
                    result from implementing your proposal? An effective rfd should include
                    such information, including tests on several different widely-used
                    implementations.

                    If you participate in Forth200x discussions on comp.lang.forth, which I
                    have previously suggested, you will see that other people are running
                    size, timing, and accuracy tests on a variety of implementations to
                    document their proposals. If you're going to propose a change that will
                    invalidate 20+ years of experience and require millions of lines of code
                    to change, it seems to me that the least you can do is validate your
                    concerns.

                    Cheers,
                    Elizabeth

                    --
                    ==================================================
                    Elizabeth D. Rather (US & Canada) 800-55-FORTH
                    FORTH Inc. +1 310.999.6784
                    5959 West Century Blvd. Suite 700
                    Los Angeles, CA 90045
                    http://www.forth.com

                    "Forth-based products and Services for real-time
                    applications since 1973."
                    ==================================================
                  • stephen@mpeforth.com
                    Posted by: Hugh Aguilar ... Rubbish. VFX treats children of CREATE as CONSTANTs. It can also optimise the DOES clause such that when DOES x + @ ; is the
                    Message 9 of 29 , Jul 2, 2009
                    View Source
                    • 0 Attachment
                      Posted by: "Hugh Aguilar"

                      > There really is no good way for CREATE to boil down
                      > to CONSTANT, which in turn boils down to being a literal --- and so we end
                      > up forsaking all of the cool optimizations that involve literals ---
                      > CREATE words end up being as slow as colon words.

                      Rubbish. VFX treats children of CREATE as CONSTANTs. It can also optimise
                      the DOES> clause such that when
                      DOES> x + @ ;
                      is the runtime, it is compiled inline with no call. At least one other
                      current Forth handles this. The mechanics can also be applied to
                      cross-compiled code.

                      Please move this discussion to comp.lang.forth, where assertions without
                      quantitative evidence are more acceptable.

                      Stephen
                    • Richard Borrell
                      ... Having spent years creating documentation for medical products I wholeheartedly agree with Elisabeth. The last thing the community needs is for Forth to
                      Message 10 of 29 , Jul 2, 2009
                      View Source
                      • 0 Attachment
                        Elisabeth Rather wrote:
                        > You clearly have been spared the
                        experience of maintaining code to high
                        > reliability standards. One
                        cannot do a sweeping search/replace
                        > operation without having to
                        re-certify all the code, which can be a
                        > tortuous, time-consuming and
                        expensive proposition.
                         
                        Having spent years creating documentation for medical products I wholeheartedly agree with Elisabeth. The last thing the community needs is for Forth to return to being the favourite language of hacks.
                         
                        Regards
                        Richard Borrell.

                        -----Original Message-----
                        From: forth200x@yahoogroups.com [mailto:forth200x@yahoogroups.com]On Behalf Of Elizabeth D Rather
                        Sent: 03 July 2009 03:32
                        To: forth200x@yahoogroups.com
                        Subject: Re: [forth200x] RfD: <BUILDS --- and the "Asok Rule"

                        Hugh Aguilar wrote:
                        > ...
                        > There really is no good way for CREATE to boil down to CONSTANT, which
                        > in turn boils down to being a literal --- and so we end up forsaking
                        > all of the cool optimizations that involve literals --- CREATE words
                        > end up being as slow as colon words.
                        This is why it was mandated that DOES> is only guaranteed to work with
                        CREATE, not with other defining words. Operationally, FORTH, Inc. and
                        most other implementors abandoned BUILDS> in the early 80's, so there's
                        really over 20 years of experience, incorporating millions of lines of
                        code, that BUILDS> is not needed.
                        > My suggestion now is to go back to what I originally proposed --- that
                        > DOES> only work with <BUILDS, and not with CREATE. Legacy code is
                        > really not a big deal. As I explained before, DOES> will notice at
                        > compile-time that the previously defined word was something other than
                        > <BUILDS (a CREATE or a colon or whatever), and it will halt the
                        > compilation with an error message complaining of a missing <BUILDS.
                        > What could be easier?
                        You clearly have been spared the experience of maintaining code to high
                        reliability standards. One cannot do a sweeping search/replace
                        operation without having to re-certify all the code, which can be a
                        tortuous, time-consuming and expensive proposition.
                        > ...
                        >
                        > My experience with Forth has involved extreme run-time performance on
                        > custom hardware. That is also what I expect Forth-200x to be focused on.
                        Many people working on Forth200x have extensive experience with
                        cross-compilers, including several who have responded to your
                        suggestion. They do not see a problem with the standard use of CREATE
                        with DOES>. Is it possible that the difficulty is with your
                        implementation? Perhaps you would benefit from looking at how some
                        other Forths, particularly cross-compilers, manage this; there are free
                        evaluation versions of cross-compilers from FORTH, Inc. and MPE
                        available, as well as several free systems.

                        Someone else asked you to document your concerns, and I agree this would
                        be helpful. For example, you assert, "CREATE words end up being as slow
                        as colon words." How slow? How much of a speed-up (if any) would
                        result from implementing your proposal? An effective rfd should include
                        such information, including tests on several different widely-used
                        implementations.

                        If you participate in Forth200x discussions on comp.lang.forth, which I
                        have previously suggested, you will see that other people are running
                        size, timing, and accuracy tests on a variety of implementations to
                        document their proposals. If you're going to propose a change that will
                        invalidate 20+ years of experience and require millions of lines of code
                        to change, it seems to me that the least you can do is validate your
                        concerns.

                        Cheers,
                        Elizabeth

                        --
                        ============ ========= ========= ========= ========= ==
                        Elizabeth D. Rather (US & Canada) 800-55-FORTH
                        FORTH Inc. +1 310.999.6784
                        5959 West Century Blvd. Suite 700
                        Los Angeles, CA 90045
                        http://www.forth. com

                        "Forth-based products and Services for real-time
                        applications since 1973."
                        ============ ========= ========= ========= ========= ==



                        __________ NOD32 4211 (20090702) Information __________

                        This message was checked by NOD32 antivirus system.
                        http://www.eset.com
                      • Bernd Paysan
                        ... Of course there is. bigForth and gforth-fast detect CREATE in COMPILE, and compile a literal when it s a CREATE without DOES . VFX Forth does the same
                        Message 11 of 29 , Jul 3, 2009
                        View Source
                        • 0 Attachment
                          On Donnerstag 02 Juli 2009 02:20:54, Hugh Aguilar wrote:
                          > There really is no good way for CREATE to boil down to
                          > CONSTANT, which in turn boils down to being a literal --- and so we end up
                          > forsaking all of the cool optimizations that involve literals --- CREATE
                          > words end up being as slow as colon words.

                          Of course there is. bigForth and gforth-fast detect CREATE in COMPILE, and
                          compile a literal when it's a CREATE without DOES>. VFX Forth does the same
                          (its COMPILE, is even more sophisticated), and I bet SwiftForth and iForth
                          aren't any different.

                          If your Forth needs a special <BUILDS and all the others optimize fine with a
                          standard CREATE, and even Asok the Intern can write a compiler that optimizes
                          CREATE fine, I don't see a problem keeping it.

                          --
                          Bernd Paysan
                          "If you want it done right, you have to do it yourself"
                          http://www.jwdt.com/~paysan/
                        • Jonah Thomas
                          This is long and philosophical, I intended it primarily for Hugh Aguilar and posted it here in case it amuses someone. It does not need careful attention as
                          Message 12 of 29 , Jul 3, 2009
                          View Source
                          • 0 Attachment
                            This is long and philosophical, I intended it primarily for Hugh
                            Aguilar and posted it here in case it amuses someone. It does not need
                            careful attention as part of the standards effort.

                            >My suggestion now is to go back to what I originally proposed --- that DOES>
                            >only work with <BUILDS, and not with CREATE. Legacy code is really not a big
                            >deal.

                            I get the impression you have little experience with standards.

                            When Forth-83 was created they changed several fundamental things. For
                            example they changed the meaning of the word NOT and they changed the
                            flags -- words which return a true flag return all bits set at TOS
                            instead of 1 . I considered all of the changes to be improvements. But
                            --

                            People bitterly complained. They had to change their code around.
                            Sometimes people had added flags, so 5 true flags gave a different
                            result than 4 true flags. Suddenly they had -5 true flags instead. It
                            was mostly things that were easy to fix, but people who had tens of
                            thousands of lines of code had a lot of work to do to keep their code
                            running on new Forth compilers -- and all they got from it was their
                            running code *kept* running.

                            Many Forth users kept using Forth-79 systems, maybe more than half.
                            But the majority of the commercial Forth vendors switched, and over a
                            period of time the vendors who stayed with Forth-79 died out. Many,
                            maybe most of the people who stayed with Forth-79 rewrote their apps
                            in other languages as their old compilers got obsolescent, rather than
                            rewrite in Forth-83.

                            Use of Forth had been growing rapidly before 1983, I don't have good
                            numbers about just how rapidly. Sometime around 1983 those numbers
                            started dropping and within a few years had been just about cut in
                            half. There are various possible explanations for this but when a lot
                            of angry programmers publicly announce that they're quitting Forth
                            because of the new standard, that seems like a hint. People who
                            started learning Forth when there was a lot of confusion between
                            Forth-79 and Forth-83 likely saw a lot of confusion and a lot of them
                            backed off from Forth. Since 1984 or so new Forth programmers have
                            developed only about as fast as old Forth programmers died, and the
                            population is aging. A whole lot of Forth programmers don't care about
                            standards, and get angry when they hear about a new standard forming.
                            I think this is because a lot of the people who did care about
                            standards quit Forth or didn't start Forth.

                            Why do we need a standard? Chuck Moore doesn't need a standard, rather
                            often when he wants to build a new application he starts out with a
                            new Forth compiler. He doesn't worry about maintaining old code. It's
                            particularly people who use Forth in traditional settings, large
                            commercial projects etc who need a standard. Managers of large
                            projects insist on having a language standard. Also, a standard allows
                            you to port code from one Forth compiler to another. Why is this an
                            issue? It might usually be easier to modify a new compiler to run your
                            code than to write code to some strict standard so it will port. But
                            no, not for large commercial projects.

                            On the other hand, large commercial projects will mostly be limited to
                            Forth compilers from just two companies. There are very good
                            commercial Forth compilers written by individual people, but what
                            would happen if the developer got run over by a beer truck? So if
                            either of the two main Forth corporations went out of business there
                            would be nobody important for their compilers to be compatible with.

                            Some ways a Forth standard might seem like an exercise in futility.
                            But apart from its commercial implications for a few people, it
                            provides a common language for Forth developers and programmers to
                            discuss what they are doing. They solve problems and document both the
                            problems and how to hide them. This is valuable.

                            Compare to ColorForth. Chuck works fast and changes things around with
                            no documentation. Other enthusiasts try to reverse-engineer what he
                            has done and document it well enough to help each other out. They
                            barely have time to write apps. Chuck makes great progress partly
                            because he's so free, he's like the wild goose flying into the sunrise
                            -- but it is not so easy to chase the wild goose.

                            Without a standard Forth would turn into a cluster of relater
                            languages with barely enough common ground to share ideas. What we
                            have now with Forth, Factor, Joy, etc. And with standards that changed
                            too fast that would still be true. So each standard effort since 1983
                            has been very careful not to break existing code, and has made
                            attempts to make it easy to upgrade Forth compilers to the new
                            standard. They have paid careful attention to common practice. When
                            they try to get rid of stuff that has been common practice they first
                            provide new methods, and then declare the old methods "obsolescent",
                            and then don't remove the obsolescent stuff from the standard until it
                            is no longer in common use.

                            That's how it's been done since we got burned so bad by Forth-83. in
                            general, if you have a great idea to improve Forth it might be best to
                            add it to multiple Forth compilers and get a lot of Forth programmers
                            to use it first, and then write it up to add to the standard as part
                            of an optional extension.

                            Best wishes
                          • Hugh Aguilar
                            Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: Let the dictionary do the deciding (see the
                            Message 13 of 29 , Jul 5, 2009
                            View Source
                            • 0 Attachment
                              Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: "Let the dictionary do the deciding" (see the book, "Thinking Forth," published in the late 1980s).

                              Rather than try to convince me that I'm incompetent, it would make more sense to just admit that overloading CREATE was a bad idea from the beginning, but that it is too late to fix the problem now. I could accept an argument like that. It is always possible to work around such problems. I don't "need" (Bernd Payson's word) <BUILDS; I can use CREATE  if I have to (but I'm not going to like it). The reason why I used <BUILDS in my own compiler was just to simplify the code. Doing so saved time for me, it made the code easier to maintain, and it gave me the warm fuzzy feeling associated with writing elegant Forth code --- typically considered to be the kind of code where each word does only one thing, and does it in a simple and obvious way. If everybody agrees that my decision to use <BUILDS in my cross-compiler marks me as an incompetent, then I should be ejected from the group. I'm not going to accept being told to study other people's code though; that's what interns do. Get real.


                              From: Elizabeth D Rather <erather@...>
                              To: forth200x@yahoogroups.com
                              Sent: Thursday, July 2, 2009 8:31:43 PM
                              Subject: Re: [forth200x] RfD: <BUILDS --- and the "Asok Rule"

                              Many people working on Forth200x have extensive experience with
                              cross-compilers, including several who have responded to your
                              suggestion. They do not see a problem with the standard use of CREATE
                              with DOES>. Is it possible that the difficulty is with your
                              implementation? Perhaps you would benefit from looking at how some
                              other Forths, particularly cross-compilers, manage this; there are free
                              evaluation versions of cross-compilers from FORTH, Inc. and MPE
                              available, as well as several free systems.


                              I'm willing to drop the <BUILDS suggestion. Compiler writers have been working around the problem of CREATE for nearly three decades now, so we might as well continue doing so.

                              I put in another RfD for a HEADER word. This one doesn't break any legacy code, which apparently is a non-starter around here.

                              Once again, my goal here is to make Forth-200x a platform for people like me to write cross-compilers. By "people like me," I mean programmers who are hired off the street --- as compared to Forth vendors who possess the source-code to the host system. The biggest problem that I'm seeing with the Forth-200x committee is an elitist attitude. The general idea is that the little people shouldn't be writing cross-compilers themselves, but should just mail large sums of money to the Forth vendors who will do the job for them. This is not acceptable. As I said before, the future involves lots of companies developing proprietary microcontrollers based upon PLDs and FPGAs. Those companies need to be able to hire programmers off the street to write cross-compilers for them, using any standard desktop Forth system available --- Linux or Windows, open-source or closed-source. My humble goal is just to be one of those programmers who get hired doing that. I have no desire to become a Forth vendor, with my own desktop system. 

                              I'm not an elitist type of guy. I'm an ex-employee of Testra, which is about as rinky-dink of a company as you'll find anywhere. After I left Testra, many human-resource girls informed me that computer programming is done in C and C++, and that my Forth and assembly-oriented resume would not be forwarded to the hiring manager for consideration. They didn't think that I was incompetent because I had chosen to use <BUILDS rather than CREATE in my cross-compiler; they thought that I was incompetent ("lack the appropriate skill-set") because I had chosen to use Forth rather than C. Considering the general unemployability of Forth programmers, an elitist attitude among Forth vendors makes no sense to me. We should be sticking together, rather than putting each other down. 



                            • georgeahubert
                              ... Win32Forth also treats CREATEd words with no DOES as literals ( and also objects, CONSTANTs and all types of variable ). The trick is CREATE sets the
                              Message 14 of 29 , Jul 5, 2009
                              View Source
                              • 0 Attachment
                                --- In forth200x@yahoogroups.com, Bernd Paysan <bernd.paysan@...> wrote:
                                >
                                > On Donnerstag 02 Juli 2009 02:20:54, Hugh Aguilar wrote:
                                > > There really is no good way for CREATE to boil down to
                                > > CONSTANT, which in turn boils down to being a literal --- and so we end up
                                > > forsaking all of the cool optimizations that involve literals --- CREATE
                                > > words end up being as slow as colon words.
                                >
                                > Of course there is. bigForth and gforth-fast detect CREATE in COMPILE, and
                                > compile a literal when it's a CREATE without DOES>. VFX Forth does the same
                                > (its COMPILE, is even more sophisticated), and I bet SwiftForth and iForth
                                > aren't any different.
                                >

                                Win32Forth also treats CREATEd words with no DOES> as literals ( and also objects, CONSTANTs and all types of variable ). The trick is CREATE sets the compilation xt to optimise as a literal and DOES> and ;CODE reset it to compile a call if IMMEDIATE hasn't reset it to EXECUTE.

                                > If your Forth needs a special <BUILDS and all the others optimize fine with a
                                > standard CREATE, and even Asok the Intern can write a compiler that optimizes
                                > CREATE fine, I don't see a problem keeping it.
                                >
                                > --
                                > Bernd Paysan
                                > "If you want it done right, you have to do it yourself"
                                > http://www.jwdt.com/~paysan/
                                >

                                George Hubert
                              • jethomas3182
                                ... OK. Overloading CREATE was a bad idea from the beginning, but it s too late to fix the problem now and most compiler-writers have adapted to handle it. One
                                Message 15 of 29 , Jul 6, 2009
                                View Source
                                • 0 Attachment
                                  --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:
                                  >
                                  > Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: "Let the dictionary do the deciding" (see the book, "Thinking Forth," published in the late 1980s).

                                  > Rather than try to convince me that I'm incompetent, it would make more sense to just admit that overloading CREATE was a bad idea from the beginning, but that it is too late to fix the problem now. I could accept an argument like that..

                                  OK. Overloading CREATE was a bad idea from the beginning, but it's too late to fix the problem now and most compiler-writers have adapted to handle it.

                                  One possible response which has been suggested here, similar to your idea to use <BUILDS for some uses and CREATE for others, is to use CREATE for some uses and BUFFER: for others. If you use BUFFER: whenever you will not apply DOES> and CREATE whenever you will, then it looks to me like the result is just like your proposal except that the names are different.
                                • Elizabeth D Rather
                                  ... How do you figure CREATE is overloaded ? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada)
                                  Message 16 of 29 , Jul 6, 2009
                                  View Source
                                  • 0 Attachment
                                    jethomas3182 wrote:
                                    > --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:
                                    >
                                    >> Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: "Let the dictionary do the deciding" (see the book, "Thinking Forth," published in the late 1980s).
                                    >>
                                    >
                                    >
                                    >> Rather than try to convince me that I'm incompetent, it would make more sense to just admit that overloading CREATE was a bad idea from the beginning, but that it is too late to fix the problem now. I could accept an argument like that..
                                    >>
                                    >
                                    > OK. Overloading CREATE was a bad idea from the beginning, but it's too late to fix the problem now and most compiler-writers have adapted to handle it.
                                    >
                                    How do you figure CREATE is "overloaded"?

                                    Cheers,
                                    Elizabeth

                                    --
                                    ==================================================
                                    Elizabeth D. Rather (US & Canada) 800-55-FORTH
                                    FORTH Inc. +1 310.999.6784
                                    5959 West Century Blvd. Suite 700
                                    Los Angeles, CA 90045
                                    http://www.forth.com

                                    "Forth-based products and Services for real-time
                                    applications since 1973."
                                    ==================================================
                                  • georgeahubert
                                    ... CREATE always had to work with ;CODE anyway, so whoever thunk of using an assembler call instruction to locate the code (at least in ITC Forths) did us all
                                    Message 17 of 29 , Jul 7, 2009
                                    View Source
                                    • 0 Attachment
                                      --- In forth200x@yahoogroups.com, "jethomas3182" <jethomas5@...> wrote:
                                      >
                                      > --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@> wrote:
                                      > >
                                      > > Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: "Let the dictionary do the deciding" (see the book, "Thinking Forth," published in the late 1980s).
                                      >
                                      > > Rather than try to convince me that I'm incompetent, it would make more sense to just admit that overloading CREATE was a bad idea from the beginning, but that it is too late to fix the problem now. I could accept an argument like that..
                                      >
                                      > OK. Overloading CREATE was a bad idea from the beginning, but it's too late to fix the problem now and most compiler-writers have adapted to handle it.
                                      >

                                      CREATE always had to work with ;CODE anyway, so whoever thunk of using an assembler call instruction to locate the code (at least in ITC Forths) did us all a service IMO. Previously <BUILDS was needed only for DOES> and the double CFA meant locaing the code was harder
                                      ( 2 different >BODYs are needed for the 2 types). It's been that way IIRC since Forth79, and doesn't seem to present problems to compiler writers whatever implementation is used. CREATE hasn't changed; it's DOES> that was altered to work with CREATE rather than neediing <BUILDS.

                                      > One possible response which has been suggested here, similar to your idea to use <BUILDS for some uses and CREATE for others, is to use CREATE for some uses and BUFFER: for others. If you use BUFFER: whenever you will not apply DOES> and CREATE whenever you will, then it looks to me like the result is just like your proposal except that the names are different.
                                      >

                                      George Hubert
                                    • Elizabeth D Rather
                                      ... The innovation you mention was the work of Dean Sanderson, at FORTH, Inc., in the early 80 s. Thank you for pointing out that CREATE hasn t changed and
                                      Message 18 of 29 , Jul 7, 2009
                                      View Source
                                      • 0 Attachment
                                        georgeahubert wrote:
                                        > --- In forth200x@yahoogroups.com, "jethomas3182" <jethomas5@...> wrote:
                                        >
                                        >> --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@> wrote:
                                        >>
                                        >>> Having a word perform two disparate functions is bad design. Everybody knows that! The well-known proverb is: "Let the dictionary do the deciding" (see the book, "Thinking Forth," published in the late 1980s).
                                        >>>
                                        >>> Rather than try to convince me that I'm incompetent, it would make more sense to just admit that overloading CREATE was a bad idea from the beginning, but that it is too late to fix the problem now. I could accept an argument like that..
                                        >>>
                                        >> OK. Overloading CREATE was a bad idea from the beginning, but it's too late to fix the problem now and most compiler-writers have adapted to handle it.
                                        >>
                                        >>
                                        >
                                        > CREATE always had to work with ;CODE anyway, so whoever thunk of using an assembler call instruction to locate the code (at least in ITC Forths) did us all a service IMO. Previously <BUILDS was needed only for DOES> and the double CFA meant locaing the code was harder
                                        > ( 2 different >BODYs are needed for the 2 types). It's been that way IIRC since Forth79, and doesn't seem to present problems to compiler writers whatever implementation is used. CREATE hasn't changed; it's DOES> that was altered to work with CREATE rather than neediing <BUILDS.
                                        >
                                        The innovation you mention was the work of Dean Sanderson, at FORTH,
                                        Inc., in the early 80's.

                                        Thank you for pointing out that CREATE hasn't changed and isn't the
                                        issue. Since Mr. Aguilar says he doesn't use DOES>, and those of us who
                                        do don't want to change, I don't see why we're worrying about this.

                                        Cheers,
                                        Elizabeth

                                        --
                                        ==================================================
                                        Elizabeth D. Rather (US & Canada) 800-55-FORTH
                                        FORTH Inc. +1 310.999.6784
                                        5959 West Century Blvd. Suite 700
                                        Los Angeles, CA 90045
                                        http://www.forth.com

                                        "Forth-based products and Services for real-time
                                        applications since 1973."
                                        ==================================================
                                      • Mitch Bradley
                                        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
                                        Message 19 of 29 , Jul 7, 2009
                                        View Source
                                        • 0 Attachment
                                          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.
                                        • 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 20 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 21 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 22 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 23 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.