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

RfD:

Expand Messages
  • Hugh Aguilar
    Author ... Hugh Aguilar Note: This is changed to be an RfD rather than a CfV. Problem ... This works on a system in which code space and data space are
    Message 1 of 29 , Jun 29 3:35 PM


      Author
      --------

      Hugh Aguilar

      Note: This is changed to be an RfD rather than a CfV.


      Problem
      ----------

      The word CREATE is overloaded. In my own cross-compiler (and likely others), CREATE is defined like this:

      : CREATE  HERE CONSTANT ;

      This works on a system in which code space and data space are separate. When code and data are interleaved it is slightly more complicated, but still boils down to defining a CONSTANT of a memory address. Constants get compiled the same as literals, and all literals are typically fodder for a variety of optimization techniques, in which the literal number is not pushed onto the stack but is incorporated into a machine-language instruction as an operand. 

      CREATE is also used to define a word that will be "filled in" by DOES>. This has nothing at all to do with the idea of CREATE being defined as shown above.

      Because CREATE is being used for two completely different purposes, novices have a difficult time in learning what CREATE means.

      Compiler writers also have a difficult time in implementing CREATE. A common technique is for CREATE to do one thing (the HERE CONSTANT definition) if it is used outside of a colon definition, but to do another thing (compile code that will be filled in by DOES>) when it is used inside of a colon definition.. In a single-pass compiler (which most Forth compilers are), it is not (easily) possible inside of a colon definition when encountering CREATE to know if there is a DOES> up ahead in the input stream. This kludge pretty much works, but it can get messed up in the event that the user puts CREATE inside of colon definition but doesn't have an associated DOES>. This is somewhat unusual, but there is nothing in the standard that says that doing so is against the rules, so eventually somebody will do it. 


      Current practice
      ------------ --------

      In FIG-Forth, CREATE was used in the HERE CONSTANT sense, and <BUILDS was used together with DOES>. In the 1980s unoptimized Forths, CREATE and <BUILDS were often synonyms. Constants were not compiled as literals because, in a threaded Forth system, a constant occupies a single cell of code memory, whereas a literal occupies two cells of code memory. In the bad old days, Forth compiler writers were primarily focused on conserving memory (remember the VIC20 with its 5K of total RAM space?). Because CREATE and <BUILDS were synonyms anyway, somebody decided to drop the <BUILDS word and just use CREATE.. This also conserved memory because it made for one less word in the dictionary (the VIC20 EPROM was 8K, which the entire Forth compiler and IDE had to fit into).

      The use of CREATE in conjunction with DOES> became part of the Forth-83 standard, which got carried over into the ANS-Forth standard --- despite the fact that we have optimizing compilers nowadays that treat literals differently than other kinds of Forth words. Compiler writers nowadays are primarily focused on speed and ease of use, with memory conservation being a matter of little importance.


      Solution
      ----------

      The solution is to bring back <BUILDS as the word that is used in conjunction with DOES>, and to use CREATE only for defining a constant of a memory address in data space.


      Proposal
      ----------

      Change the definition of CREATE in the standard to drop the last sentence: "The execution semantics of name may be extended by using DOES>." 

      Add a definition for <BUILDS in the standard that is the same as theCREATE definition but to include a last sentence: "The execution semantics of name must be extended by using DOES>. An error condition exists if <BUILDS is used outside of a colon definition or does not have an associated DOES> provided to define its run-time action."

      Change the definition for DOES> so that the sentence, "An ambiguous condition exists if name was not defined with CREATE or a user-defined word that calls CREATE," uses the word <BUILDS rather than CREATE. Also, where it says, "See CREATE," that should be: "See <BUILDS."

      See: 6.1.1000 CREATE and 6.1.1250 DOES> in the ANS-Forth standard.


    • Elizabeth D Rather
      ... I also recommend that you post this on comp.lang.forth, which is where the most thorough discussions are taking place. Cheers, Elizabeth --
      Message 2 of 29 , Jun 30 12:53 AM
        Hugh Aguilar wrote:
        >
        >
        >
        >
        > Author
        > --------
        >
        > Hugh Aguilar
        >
        > Note: This is changed to be an RfD rather than a CfV.







        I also recommend that you post this on comp.lang.forth, which is where
        the most thorough discussions are taking place.

        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, that s not the solution. CREATE DOES is standard, used by many programs and systems, and can t be changed. The solution is to add another word, e.g.
        Message 3 of 29 , Jun 30 1:05 AM
          On Dienstag 30 Juni 2009 00:35:03, Hugh Aguilar wrote:
          > Solution
          > ----------
          >
          > The solution is to bring back <BUILDS as the word that is used in
          > conjunction with DOES>, and to use CREATE only for defining a constant of a
          > memory address in data space.

          No, that's not the solution. CREATE DOES> is standard, used by many programs
          and systems, and can't be changed. The solution is to add another word, e.g.
          LABEL, or BUFFER: which is defined as

          : label ( "name" -- ) here Constant ;
          : buffer: ( n "name" -- ) here Constant allot ;

          in systems like yours. I'd vote for BUFFER:, because it already exists in VFX
          Forth and others.

          --
          Bernd Paysan
          "If you want it done right, you have to do it yourself"
          http://www.jwdt.com/~paysan/
        • jethomas3182
          ... 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
          Message 4 of 29 , Jun 30 1:45 AM
            --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:

            > Proposal
            > ----------
            >
            >
            > Change the definition of CREATE in the standard to drop the last sentence: "The execution semantics of name may be extended by using DOES>."
            >
            > Add a definition for <BUILDS in the standard that is the same as theCREATE definition but to include a last sentence: "The execution semantics of name must be extended by using DOES>. An error condition exists if <BUILDS is used outside of a colon definition or does not have an associated DOES> provided to define its run-time action."
            >
            > Change the definition for DOES> so that the sentence, "An ambiguous condition exists if name was not defined with CREATE or a user-defined word that calls CREATE," uses the word <BUILDS rather than CREATE. Also, where it says, "See CREATE," that should be: "See <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
            ... The first appearance of BUFFER: that I know of was in my Open Boot implementation for Sun SPARCstations. I needed a convenient way to allocate
            Message 5 of 29 , Jun 30 6:21 AM
              >
              > No, that's not the solution. CREATE DOES> is standard, used by many programs
              > and systems, and can't be changed. The solution is to add another word, e.g.
              > LABEL, or BUFFER: which is defined as
              >
              > : label ( "name" -- ) here Constant ;
              > : buffer: ( n "name" -- ) here Constant allot ;
              >
              > in systems like yours. I'd vote for BUFFER:, because it already exists in VFX
              > Forth and others.
              >

              The first appearance of BUFFER: that I know of was in my Open Boot
              implementation for Sun SPARCstations. I needed a convenient way to
              allocate possibly-large buffers without wiring down dictionary space and
              without using any memory in the case where a subsystem didn't get used
              on a particular run. It eventually became standardized in IEEE
              1275-1994 (Open Firmware) as follows:

              buffer: (E: -- a-addr )
              ( len "new-name< >" -- )

              Creates a data variable named "new-name" and allocates a data buffer
              of len bytes (using alloc-mem).
              Upon later execution of "new-name", return the address a-addr of the
              first byte of the buffer.
              Used as: ok 100 buffer: new-name
              Later used as: 55 new-name 20 + c!

              Note that, in IEEE 1275, the memory does not come from the data space,
              i.e. the memory cannot be assumed to have been allocated with ALLOT.

              The IEEE 1275 standard stipulates that the memory is allocated with
              alloc-mem, but from a usage standpoint, that's invisible to the
              application - allocating with ALLOT is okay too. The intention of the
              "alloc-mem" stipulation was to assert that the memory is not allocated
              with "dma-alloc", so you can't depend on being able to do direct DMA
              into the buffer.

              My implementation is as follows:

              1) At compile time, allocate a single cell in the user area, zero that
              cell, and "comma" the size and the user area offset into the body of the
              new word.

              2) At run time, if the user area location contains nonzero, push that
              value on the stack as the address of the buffer. If it contains zero,
              allocate a memory region of the given size, store its address in the
              user area location and push its address on the stack.

              This is a good technique for large systems where the dictionary image
              will be stored in ROM. Large buffers can be declared without consuming
              dictionary space. Memory is only allocated when you need it, i.e. if
              you never use the buffer, no memory is consumed. And buffers can be
              task-specific if desired.
            • Hugh Aguilar
              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.
              Message 6 of 29 , Jun 30 12:29 PM
                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.

                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. 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!

                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." 

                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.


                From: Bernd Paysan <bernd.paysan@...>
                To: forth200x@yahoogroups.com
                Sent: Tuesday, June 30, 2009 2:05:01 AM
                Subject: Re: [forth200x] RfD: <BUILDS

                On Dienstag 30 Juni 2009 00:35:03, Hugh Aguilar wrote:
                > Solution
                > ----------
                >
                > The solution is to bring back <BUILDS as the word that is used in
                > conjunction with DOES>, and to use CREATE only for defining a constant of a
                > memory address in data space.

                No, that's not the solution. CREATE DOES> is standard, used by many programs
                and systems, and can't be changed. The solution is to add another word, e.g.
                LABEL, or BUFFER: which is defined as

                : label ( "name" -- ) here Constant ;
                : buffer: ( n "name" -- ) here Constant allot ;

                in systems like yours. I'd vote for BUFFER:, because it already exists in VFX
                Forth and others.

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


              • 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 7 of 29 , Jul 1, 2009
                  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 8 of 29 , Jul 1, 2009
                    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 9 of 29 , Jul 1, 2009
                      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 10 of 29 , Jul 1, 2009
                        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 11 of 29 , Jul 1, 2009
                          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 12 of 29 , Jul 2, 2009
                            > 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 13 of 29 , Jul 2, 2009
                              > 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 14 of 29 , Jul 2, 2009
                                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 15 of 29 , Jul 2, 2009
                                  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 16 of 29 , Jul 2, 2009
                                    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 17 of 29 , Jul 3, 2009
                                      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 18 of 29 , Jul 3, 2009
                                        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 19 of 29 , Jul 5, 2009
                                          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 20 of 29 , Jul 5, 2009
                                            --- 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 21 of 29 , Jul 6, 2009
                                              --- 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 22 of 29 , Jul 6, 2009
                                                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 23 of 29 , Jul 7, 2009
                                                  --- 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 24 of 29 , Jul 7, 2009
                                                    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 25 of 29 , Jul 7, 2009
                                                      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 26 of 29 , Jul 8, 2009
                                                        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 27 of 29 , Jul 8, 2009
                                                          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 28 of 29 , Jul 9, 2009
                                                            --- 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 29 of 29 , Jul 9, 2009
                                                              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.