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

RfD: HEADER

Expand Messages
  • Hugh Aguilar
    Author ... Hugh Aguilar Problem ... There is no good way to construct colon words from within other colon words. We can compile the code okay, but we can t
    Message 1 of 14 , Jul 5, 2009

      Author
      --------

      Hugh Aguilar


      Problem
      ----------

      There is no good way to construct colon words from within other colon words. We can compile the code okay, but we can't create the header for the word because colon requires the header name to be in the input stream.


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

      My own cross-compiler was written in UR/Forth which provided a word called HEADER that acted like colon, but took the word name as a string on the stack, rather than pulling it out of the input stream. Unfortunately, UR/Forth had a bug in it that made HEADER not work properly. I ended up writing my own word in assembly language, making use of undocumented features of UR/Forth that I was familiar with.

      I discussed this with another Forth programmer, whose name I won't provide here, and he suggested putting the colon and the name in TIB and interpreting it. Somewhat humorously (to me), he described this kludge as "the Forth Way." One problem with this technique is that TIB is obsolescent. Another problem is that writing code that constructs source-code and interprets it is actually the Lisp Way, not the Forth Way.


      Solution
      ----------

      The solution is to introduce a new word called HEADER ( adr cnt wl -- ).

      The adr and cnt are the string representing the name of the new word. The wl is the wordlist that the new word will be compiled into. 

      HEADER will behave exactly like colon except for the fact that it will obtain the information it needs from the stack, rather than pull the header name out of the input stream, and rather than use the current wordlist. 


      Usage
      -------

      It will be possible to use HEADER in place of the colon in source-code being interpreted. This is not the purpose of HEADER however. Normally, HEADER would be used within a colon word.

      As an example, the programmer might write a defining word VAL that is similar to VALUE. When he uses VAL to define a word, XXX, then VAL automatically defines the following words:
      XXX \ push the value of XXX to the stack
      XXX++ \ postincrement XXX after pushing the value to the stack
      XXX-- \ postdecrement XXX after pushing the value to the stack
      &XXX \ push the address of XXX to the stack, rather than the value
      etc.,

      The VAL word described above is just one possible use of HEADER. In my own cross-compiler, I used HEADER to construct words like this associated with each local variable. The local variables were held in registers, rather than in memory, so they were good candidates for optimization. There are other methods for doing this, in which the ++, -- and & are distinct words, but these methods are a lot more complicated, and the source code is more cluttered because there is a space between them and the associated XXX. HEADER tends to simplify things quite a lot.

      Note that HEADER takes the wordlist as a parameter, rather than use the current wordlist. This is because the words being defined by HEADER typically will get put into a wordlist of related words, so that they don't clutter up the namespace. As an example, local variables need to disappear from the namespace after the colon word is finished compiling. An easy way to do this is to put them all into a wordlist that is removed from the search order by the semicolon.

      Proposal
      ----------

      Add HEADER to our list of compiling words, alongside colon and :NONAME.

      In keeping with the naming style of :NONAME, it might be a good idea to call our word :STRING rather than HEADER. I chose HEADER primarily because that was what it was called in UR/Forth, and some programmers might be familiar with it from there.

      See: 6.1.0450 colon and 6.2.0455 :NONAME in the Forth08 document.


    • Bernd Paysan
      ... I really think you should take Stephen s advice and look at other Forth systems before you propose something. Gforth e.g. already has a solution to your
      Message 2 of 14 , Jul 5, 2009
        Am Sonntag 05 Juli 2009 10:07:22 schrieb Hugh Aguilar:
        > The solution is to introduce a new word called HEADER ( adr cnt wl -- ).

        I really think you should take Stephen's advice and look at other Forth
        systems before you propose something. Gforth e.g. already has a solution to
        your problem, it's called NEXTNAME ( addr len -- ). The next defining word
        (whatever that is, :, CREATE, CONSTANT, etc.) will take the string described
        by addr len instead of parsing a string from the input stream. I think this
        solution is better, because it is more general than just having a way to
        define colon words by names on the stack. But then, it is still a single-
        system solution, and other systems may have different ways to solve that
        problem.

        Anyway, it *is* possible with a standard program to pass a string on the stack
        to an arbitrary parsing word via EXECUTE-PARSING (see compat/execute-
        parsing.fs in Gforth). This is an even more general solution to the problem,
        and already proposed - the only discussion open is the name.

        Usage for your case, within another word

        s" foo" ['] : execute-parsing

        --
        Bernd Paysan
        "If you want it done right, you have to do it yourself"
        http://www.jwdt.com/~paysan/
      • georgeahubert
        ... I would have said put them in a buffer and EVALUATE them would be better, though it s still kind of kludgy. ... It s trival to use GET-CURRENT if the word
        Message 3 of 14 , Jul 5, 2009
          --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:
          >
          >
          >
          > Author
          > --------
          >
          > Hugh Aguilar
          >
          >
          > Problem
          > ----------
          >
          >
          > There is no good way to construct colon words from within other colon words. We can compile the code okay, but we can't create the header for the word because colon requires the header name to be in the input stream.
          >
          >
          > Current practice
          > --------------------
          >
          >
          > My own cross-compiler was written in UR/Forth which provided a word called HEADER that acted like colon, but took the word name as a string on the stack, rather than pulling it out of the input stream. Unfortunately, UR/Forth had a bug in it that made HEADER not work properly. I ended up writing my own word in assembly language, making use of undocumented features of UR/Forth that I was familiar with.
          >
          > I discussed this with another Forth programmer, whose name I won't provide here, and he suggested putting the colon and the name in TIB and interpreting it. Somewhat humorously (to me), he described this kludge as "the Forth Way." One problem with this technique is that TIB is obsolescent. Another problem is that writing code that constructs source-code and interprets it is actually the Lisp Way, not the Forth Way.
          >

          I would have said put them in a buffer and EVALUATE them would be better, though it's still kind of kludgy.

          >
          > Solution
          > ----------
          >
          > The solution is to introduce a new word called HEADER ( adr cnt wl -- ).
          >
          > The adr and cnt are the string representing the name of the new word. The wl is the wordlist that the new word will be compiled into.
          >
          > HEADER will behave exactly like colon except for the fact that it will obtain the information it needs from the stack, rather than pull the header name out of the input stream, and rather than use the current wordlist.
          >
          >
          > Usage
          > -------
          >
          > It will be possible to use HEADER in place of the colon in source-code being interpreted. This is not the purpose of HEADER however. Normally, HEADER would be used within a colon word.
          >
          > As an example, the programmer might write a defining word VAL that is similar to VALUE. When he uses VAL to define a word, XXX, then VAL automatically defines the following words:
          > XXX\ push the value of XXX to the stack
          > XXX++\ postincrement XXX after pushing the value to the stack
          > XXX--\ postdecrement XXX after pushing the value to the stack
          > &XXX\ push the address of XXX to the stack, rather than the value
          > etc.,
          >
          > The VAL word described above is just one possible use of HEADER. In my own cross-compiler, I used HEADER to construct words like this associated with each local variable. The local variables were held in registers, rather than in memory, so they were good candidates for optimization. There are other methods for doing this, in which the ++, -- and & are distinct words, but these methods are a lot more complicated, and the source code is more cluttered because there is a space between them and the associated XXX. HEADER tends to simplify things quite a lot.
          >
          > Note that HEADER takes the wordlist as a parameter, rather than use the current wordlist. This is because the words being defined by HEADER typically will get put into a wordlist of related words, so that they don't clutter up the namespace.

          It's trival to use GET-CURRENT if the word needs to go to the current wordlist, so passing the wordlist makes it more versatile IMO.

          > As an example, local variables need to disappear from the namespace after the colon word is finished compiling. An easy way to do this is to put them all into a wordlist that is removed from the search order by the semicolon.
          >
          > Proposal
          > ----------
          >
          >
          > Add HEADER to our list of compiling words, alongside colon and :NONAME.
          >
          > In keeping with the naming style of :NONAME, it might be a good idea to call our word :STRING rather than HEADER. I chose HEADER primarily because that was what it was called in UR/Forth, and some programmers might be familiar with it from there.
          >
          > See: 6.1.0450 colon and 6.2.0455 :NONAME in the Forth08 document.
          >

          Win32Forth already has HEADER with a different meaning (it's a factor of CREATE, : CONSTANT etc.) so I'd prefer a different name. Also having : in it implies that it creates a colon definition. Might I suggest :$ or :" since they imply a string will be supplied.

          I wouldn't mind a version of CONSTANT that behaves similarly, i.e has the stack effect ( value addr length wid -- ). Perhaps I'll present a separate RfD for it.

          George Hubert
        • Anton Ertl
          ... I think that his approach here is ok. An RfD is a request for *discussion* after all. So if there are other solutions to the problem, they will hopefully
          Message 4 of 14 , Jul 5, 2009
            Bernd Paysan wrote:
            >
            > --nextPart1932419.TaVhgSPN2c
            > Content-Type: Text/Plain;
            > charset="iso-8859-15"
            > Content-Transfer-Encoding: quoted-printable
            >
            > Am Sonntag 05 Juli 2009 10:07:22 schrieb Hugh Aguilar:
            > > The solution is to introduce a new word called HEADER ( adr cnt wl -- ).
            >
            > I really think you should take Stephen's advice and look at other Forth=20
            > systems before you propose something.

            I think that his approach here is ok. An RfD is a request for
            *discussion* after all. So if there are other solutions to the
            problem, they will hopefully be pointed out in the discussion, and
            then the proponent can (and should) work this information into the
            proposal.

            Stephen Pelc takes a different approach to RfDs, but that does not
            mean that everybody has to take his approach.

            > Anyway, it *is* possible with a standard program to pass a string on the st=
            > ack=20
            > to an arbitrary parsing word via EXECUTE-PARSING (see compat/execute-
            > parsing.fs in Gforth). This is an even more general solution to the problem=
            > ,=20
            > and already proposed

            There is no RfD for EXECUTE-PARSING, and the RfD for FILE-SOURCE
            STRING-SOURCE and CLOSE-SOURCE has been withdrawn.

            > the only discussion open is the name.

            At the meeting this March we had an interesting discussion about this
            topic in relation to the RfD mentioned above, and the name was not the
            only topic. There were also discussions about even more general
            solutions <news:2009Apr3.231453@...>.

            However, given that we did not like the INTERPRET-WITH idea we came up
            with at the time, and that there is no existing practice beyond
            EXECUTE-PARSING and (hard-to-standardize) hooks, whether we should not
            go forward and propose EXECUTE-PARSING instead of waiting forever for
            the perfect proposal.

            - anton
          • Hugh Aguilar
            ________________________________ From: Bernd Paysan To: forth200x@yahoogroups.com Sent: Sunday, July 5, 2009 5:12:10 AM Subject: Re:
            Message 5 of 14 , Jul 6, 2009


              From: Bernd Paysan <bernd.paysan@...>
              To: forth200x@yahoogroups.com
              Sent: Sunday, July 5, 2009 5:12:10 AM
              Subject: Re: [forth200x] RfD: HEADER

              I really think you should take Stephen's advice and look at other Forth 
              systems before you propose something. Gforth e.g. already has a solution to 
              your problem, it's called NEXTNAME ( addr len -- ). The next defining word 
              (whatever that is, :, CREATE, CONSTANT, etc.) will take the string described 
              by addr len instead of parsing a string from the input stream. I think this 
              solution is better, because it is more general than just having a way to 
              define colon words by names on the stack. But then, it is still a single-
              system solution, and other systems may have different ways to solve that 
              problem.

              The problem addressed by my RfD is pretty common. It is likely that every Forth system has some kind of solution available; I don't see any reason to list them all. I used UR/Forth's HEADER as my model because I liked it. The NEXTNAME in Gforth does have the advantage of being more general because it works with defining words other than colon. This doesn't seem very important to me, but if all of you want this generality I would have no objection to allowing for it. My HEADER has the advantage of taking the wordlist as a parameter. I think this is important because, oftentimes, this wordlist is going to be something other than the current wordlist. This is especially true in the case that the programmer is using HEADER to define local variables and their associated colon words. 

              Mostly, I think that NEXTNAME is difficult to explain to novices, and HEADER easier to explain. BTW, I changed my mind about what to call my word. I think that :NAME would be best --- this has a yin/yang quality in regard to the :NONAME that we already have.

              All of that talk previously about DOES> words was of only academic interest to me because I never use DOES> in my own programming anyway. My objection to DOES> words is that they only have one action associated with them (the code after the DOES>). Oftentimes, the programmer will end up writing associated colon words that tweak the data of the DOES> word. This results in non-standard code as it requires the programmer to know how to locate the data in the DOES> word. This is usually just an offset into the word, but it is different from system to system. Aside from the incompatibility issue, this kind of programming is also very inelegant. A maintainance programmer has no way of knowing what words tweak the DOES> word, or where to find them. If a change is made in one place, it can break code in other places unknown to the maintainance programmer. In my cross-compiler's documentation, I said that DOES> was obsolescent and should not be used anymore. I think Forth-200x should also make DOES> obsolescent.

              What I do in my own code instead of using DOES>, is to write a defining word that uses HEADER to generate several colon words associated with the defined word. For example, a defining word 2ARRAY might define an array XXX such that XXX (a colon word) takes two indices into the array and returns the address of that element in the array. 2ARRAY would be given the size of the dimensions as input parameters. So far, this is no different than what would be done with a DOES> definition. My 2ARRAY however, would also generate a word XXX>RESIZE that takes two new dimension sizes as input parameters and resizes the array. This is what I mean by "tweaking" the data. The advantage to my way is that a maintainence programmer can look at the definition of 2ARRAY and see immediately what words are associated with the defined word. This isn't OOP, but it is a halfstep in that direction. 

              HEADER would be a useful tool for any programmer developing an OOP system. I think that the Forth-200x standard should provide the programmers with low-level tools such as HEADER, rather than high-level features such as a full-blown OOP system. Programmers should write their OOP system themselves, so that they can do it to their own liking. I don't want the job of giving programmers a procrustean bed for their software, because they will just complain that it doesn't fit them, and they will blame me for all of their problems.

              The ANS-Forth standard provided support for local variables that was complicated and confusing. If HEADER had been provided in ANS-Forth, there would have been no need to discuss local variables at all. This is another example of how providing the correct low-level tools obviates the need for providing high-level features, as ordinary programmers can use the low-level tools to develop the high-level features to their own liking. Things like OOP and local variables shouldn't be part of the standard itself.

              I'm all about empowering common programmers to implement features themselves, rather than rely on their compiler vendor to provide the features for them. The compilers will have a lower price tag (or be GPL) because they provide fewer high-level features. Ultimately though, more money will be made because the community will be larger. There will always be people who prefer to pay to have work done rather than do it themselves. 


            • jethomas3182
              ... I m not clear quite what the problem here is. When do you want to get the name? If you want to get the name when the word executes, then why not put the
              Message 6 of 14 , Jul 6, 2009
                --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:

                > There is no good way to construct colon words from within other colon words. We can compile the code okay, but we can't create the header for the word because colon requires the header name to be in the input stream.

                I'm not clear quite what the problem here is. When do you want to get the name?

                If you want to get the name when the word executes, then why not put the name into the input stream?

                : MYWORD .... : .... ;

                MYWORD FOO

                If you want to get the name when the word is compiled, you can do the same thing.

                : MYWORD .... S" : FOO " EVALUATE .... ;






                > I discussed this with another Forth programmer, whose name I won't provide here, and he suggested putting the colon and the name in TIB and interpreting it. Somewhat humorously (to me), he described this kludge as "the Forth Way." One problem with this technique is that TIB is obsolescent. Another problem is that writing code that constructs source-code and interprets it is actually the Lisp Way, not the Forth Way.

                The words that would make this sort of thing easy were missing from Forth-94 and I could not get them added partly because senior members of the committee said that Forth programmers should not use them.

                It's still possible to do it with some workarounds.

                : MYWORD ( addr len -- )
                TUCK
                S" : " PAD SWAP MOVE
                PAD 2 + SWAP MOVE
                PAD SWAP 2 + EVALUATE ;

                This version is a little clumsy, you could probably write it better.


                > Solution
                > ----------
                >
                > The solution is to introduce a new word called HEADER ( adr cnt wl -- ).
                >
                > The adr and cnt are the string representing the name of the new word. The wl is the wordlist that the new word will be compiled into.
                >
                > HEADER will behave exactly like colon except for the fact that it will obtain the information it needs from the stack, rather than pull the header name out of the input stream, and rather than use the current wordlist.

                I think that's potentially useful. I think it would be even more useful to have a way to make a buffer become the input stream without automaticly interpreting it. That would give you an easier way to do what you want than we have now, and it would also have other uses. But we currently don't have either one and it might be good to have both provided they didn't go into the Core wordset. Doing something special with the input stream or with headers is something that we shouldn't expect every minimal Forth system to handle.
              • georgeahubert
                ... I don t think either is particularly difficult to explain, though I doubt novices would be using them, since they are both advanced concepts which IMO
                Message 7 of 14 , Jul 7, 2009
                  --- In forth200x@yahoogroups.com, Hugh Aguilar <hughaguilar96@...> wrote:
                  >
                  >
                  > The problem addressed by my RfD is pretty common. It is likely that every Forth system has some kind of solution available; I don't see any reason to list them all. I used UR/Forth's HEADER as my model because I liked it. The NEXTNAME in Gforth does have the advantage of being more general because it works with defining words other than colon. This doesn't seem very important to me, but if all of you want this generality I would have no objection to allowing for it. My HEADER has the advantage of taking the wordlist as a parameter. I think this is important because, oftentimes, this wordlist is going to be something other than the current wordlist. This is especially true in the case that the programmer is using HEADER to define local variables and their associated colon words.
                  >
                  > Mostly, I think that NEXTNAME is difficult to explain to novices, and HEADER easier to explain.

                  I don't think either is particularly difficult to explain, though I doubt novices would be using them, since they are both advanced concepts which IMO should be introduced later in training.

                  BTW, I changed my mind about what to call my word. I think that :NAME would be best --- this has a yin/yang quality in regard to the :NONAME that we already have.
                  >
                  > All of that talk previously about DOES> words was of only academic interest to me because I never use DOES> in my own programming anyway.

                  Given that you don't use it why have you been trying to change it?

                  My objection to DOES> words is that they only have one action associated with them (the code after the DOES>). Oftentimes, the programmer will end up writing associated colon words that tweak the data of the DOES> word. This results in non-standard code as it requires the programmer to know how to locate the data in the DOES> word.

                  What non-standard code is needed; I use >BODY to locate the data and it always works.

                  This is usually just an offset into the word, but it is different from system to system. Aside from the incompatibility issue, this kind of programming is also very inelegant. A maintainance programmer has no way of knowing what words tweak the DOES> word, or where to find them.

                  Surely if you have additional actions that are used you define them with the actual CREATE DOES> word and document their use.

                  If a change is made in one place, it can break code in other places unknown to the maintainance programmer. In my cross-compiler's documentation, I said that DOES> was obsolescent and should not be used anymore. I
                  > think Forth-200x should also make DOES> obsolescent.

                  NO.

                  > What I do in my own code instead of using DOES>, is to write a defining word that uses HEADER to generate several colon words associated with the defined word. For example, a defining word 2ARRAY might define an array XXX such that XXX (a colon word) takes two indices into the array and returns the address of that element in the array. 2ARRAY would be given the size of the dimensions as input parameters. So far, this is no different than what would be done with a DOES> definition. My 2ARRAY however, would also generate a word XXX>RESIZE that takes two new dimension sizes as input parameters and resizes the array. This is what I mean by "tweaking" the data. The advantage to my way is that a maintainence programmer can look at the definition of 2ARRAY and see immediately what words are associated with the defined word. This isn't OOP, but it is a halfstep in that direction.
                  >
                  > HEADER would be a useful tool for any programmer developing an OOP system. I think that the Forth-200x standard should provide the programmers with low-level tools such as HEADER, rather than high-level features such as a full-blown OOP system. Programmers should write their OOP system themselves, so that they can do it to their own liking. I don't want the job of giving programmers a procrustean bed for their software, because they will just complain that it doesn't fit them, and they will blame me for all of their problems.
                  >
                  > The ANS-Forth standard provided support for local variables that was complicated and confusing. If HEADER had been provided in ANS-Forth, there would have been no need to discuss local variables at all. This is another example of how providing the correct low-level tools obviates the need for providing high-level features, as ordinary programmers can use the low-level tools to develop the high-level features to their own liking. Things like OOP and local variables shouldn't be part of the standard itself.
                  >
                  > I'm all about empowering common programmers to implement features themselves, rather than rely on their compiler vendor to provide the features for them. The compilers will have a lower price tag (or be GPL) because they provide fewer high-level features. Ultimately though, more money will be made because the community will be larger. There will always be people who prefer to pay to have work done rather than do it themselves.

                  There are already quite a few free (i.e no cost) Forths with various licenses (PD BSD or GPL). Some like Win32Forth, Gforth and BigForth et al. are full featured while others are more minimilist. You pays your money (or not for free forths) and takes your choice (or as some people do roll your own).

                  George Hubert
                • Hugh Aguilar
                  As for whether words such as HEADER and NEXTNAME are advanced and appropriate for novices, or not, I would say that the question is moot because Forth
                  Message 8 of 14 , Jul 7, 2009
                    As for whether words such as HEADER and NEXTNAME are "advanced" and appropriate for novices, or not, I would say that the question is moot because Forth novices don't exist. Forth is a thin language, which means that the entire language can be learned quickly. The ANS-Forth document is short enough to be read over the weekend. Instant expert! It is really no excuse for anybody to claim that he is still a novice, and hasn't learned the full language yet. Forth is similar to Go (wei-chi) --- anybody can learn to play!

                    Still though, teaching people Forth is necessary. Imagine this conversation between a teacher and his student:

                    Sensei: NEXTNAME changes the behavior of the next defining word to be executed.

                    Grasshopper: What is a defining word?

                    Sensei: Well, um, two examples are colon and CONSTANT. I can't remember the complete list off the top of my head.

                    Grasshopper: I read in "Thinking Forth" that Forth code should be "stateless" as much as possible. Why does NEXTNAME violate good programming style in this regard?

                    Sensei: Well, um, NEXTNAME is mostly for experts, and we don't care about programming style.

                    Grasshopper: You old faker!

                    Personally, I use HEADER early and often. I would rather teach a novice about HEADER than about DOES>. If I teach Grasshopper about DOES>, he will likely ask: "What if I have more than one action associated with this word?" I don't want to have to tell him: 
                    "Well, um, then the technique changes completely. We have another word called >BODY that you need to know about. Also, you need to know how to find the cfa (code-field-address) of a word. The whole process is very complicated and clumsy." 

                    Also, once I have taught Grasshopper about HEADER, then he can use it for a variety of tasks. He can upgrade VALUE so that it also generates several helper words (&XXX, XXX++, XXX--, etc.). He can write an OOP package with early-binding. He can write his own local variables, and provide them with helper words. Etc, etc. HEADER is a powerful tool. By comparison, DOES> is limited and clumsy. There is nothing that DOES> can do that HEADER can't do, but there is a lot that HEADER can do that DOES> can't do. This is why I think that DOES> can be made obsolescent assuming that HEADER is introduced.

                    BTW, does anybody have an opinion on what to call the word? HEADER comes from UR/Forth. Not too many people use UR/Forth anymore though, so Forth-200x doesn't need to use the same name for the sake of familiarity. I'm leaning toward :NAME, which I consider to be more descriptive. Also, I think that we should have the words :NAME-CODE and :NONAME-CODE that are similar to ;CODE in that the standard document mentions them, but just says they are implementation dependent.

                    Finally, Jonah Thomas suggested doing this:

                    : MYWORD .... S" : FOO " EVALUATE .... ;

                    This is possible, but I generally consider any use of EVALUATE to be a kludge; I don't think that the standard should tell the programmers that this is the recommended technique. Also, this doesn't easily allow the new word to be put in a wordlist other than the current wordlist, which is pretty typical in my experience. There are workarounds available for this problem too, but the whole business becomes complicated and hard to read. I use HEADER routinely; I wouldn't want to go through a lot of rigamarole every time.



                    From: georgeahubert <no_reply@yahoogroups.com>
                    To: forth200x@yahoogroups.com
                    Sent: Tuesday, July 7, 2009 2:39:06 AM
                    Subject: [forth200x] Re: RfD: HEADER


                    I don't think either is particularly difficult to explain, though I doubt novices would be using them, since they are both advanced concepts which IMO should be introduced later in training.


                    .

                  • Elizabeth D Rather
                    ... Yeah, right. Over the weekend one can not only read the text, but also memorize over 400 words with their definitions and stack effects. All without
                    Message 9 of 14 , Jul 7, 2009
                      Hugh Aguilar wrote:
                      >
                      >
                      > As for whether words such as HEADER and NEXTNAME are "advanced" and
                      > appropriate for novices, or not, I would say that the question is moot
                      > because Forth novices don't exist. Forth is a /thin/ language, which
                      > means that the entire language can be learned quickly. The ANS-Forth
                      > document is short enough to be read over the weekend. Instant expert!
                      > It is really no excuse for anybody to claim that he is still a novice,
                      > and hasn't learned the full language yet. Forth is similar to Go
                      > (wei-chi) --- anybody can learn to play!
                      >
                      Yeah, right. Over the weekend one can not only read the text, but also
                      memorize over 400 words with their definitions and stack effects. All
                      without having to write a line of code!
                      >
                      > Personally, I use HEADER early and often. I would rather teach a
                      > novice about HEADER than about DOES>. If I teach Grasshopper about
                      > DOES>, he will likely ask: "What if I have more than one action
                      > associated with this word?" I don't want to have to tell him:
                      > "Well, um, then the technique changes completely. We have another word
                      > called >BODY that you need to know about. Also, you need to know how
                      > to find the cfa (code-field-address) of a word. The whole process is
                      > very complicated and clumsy."
                      Funny thing, in over 30 years of teaching Forth courses I've never been
                      asked that.

                      You are welcome to use HEADER, and call it whatever you want, and write
                      about it. If a lot of people also find they need it, they will
                      implement it in their systems. If it becomes popular, it will be an
                      appropriate subject for standardization.

                      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 Pelc
                      ... The factoring of HEADER is actually more complex. In practise, as per FIG-Forth, you need doCreate, doColon and friends as well. With modern CPUs and
                      Message 10 of 14 , Jul 8, 2009
                        Hugh said:

                        > Finally, Jonah Thomas suggested doing this:
                        >
                        > : MYWORD .... S" : FOO " EVALUATE .... ;
                        >
                        > This is possible, but I generally consider any use of
                        > EVALUATE to be a kludge; I don't think that the standard
                        > should tell the programmers that this is the recommended
                        > technique. Also, this doesn't easily allow the new word
                        > to be put in a wordlist other than the current wordlist,
                        > which is pretty typical in my experience. There are
                        > workarounds available for this problem too, but the
                        > whole business becomes complicated and hard to read. I
                        > use HEADER routinely; I wouldn't want to go through a
                        > lot of rigamarole every time.

                        The factoring of HEADER is actually more complex. In practise,
                        as per FIG-Forth, you need doCreate, doColon and friends as
                        well. With modern CPUs and optimisers, correct xt and data
                        alignment can be critical. Our *measurements* on one benchmark
                        gave a 7:1 performance variation on the placement of a single
                        variable on one CPU.

                        I really, really do not want to have to expose a vast array of
                        compiler internals. This will inevitably trigger the law of
                        unintended consequences without ten years of trials. As a
                        result, writing wrappers around EVALUATE is actually the least
                        worst solution.

                        Stephen

                        --
                        Stephen Pelc, stephen@...
                        MicroProcessor Engineering Ltd - More Real, Less Time
                        133 Hill Lane, Southampton SO15 5AF, England
                        tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
                        web: http://www.mpeforth.com - free VFX Forth downloads
                      • Hugh Aguilar
                        It already is popular. UR/Forth has its HEADER, Gforth has its NEXTNAME, etc., etc.. As I said earlier, it is likely that every Forth system has provided some
                        Message 11 of 14 , Jul 8, 2009
                          It already is popular. UR/Forth has its HEADER, Gforth has its NEXTNAME, etc., etc.. As I said earlier, it is likely that every Forth system has provided some kind of solution to the problem --- unfortunately, they are all incompatible with each other.

                          I don't know if SwiftForth has something like :NAME or not (because my $500 SwiftForth compiler doesn't work anymore), but I'll bet its in there somewhere. The reason I say this is because it is good programming practice to write a low-level word such as :NAME and then define colon on top of it, rather than just write colon by itself --- that is factoring, which is pretty much the foundation of Forth style. Assuming that whoever wrote SwiftForth was highly skilled (which I think is true), then he most likely did it this way.

                          Maybe it is an undocumented word that is only available to Forth Inc. employees. SwiftForth is closed-source, so there is likely a lot of cool stuff hidden in there that customers (me) don't know about.

                          BTW, I know a guy who wrote a compiler for a BASIC with Pascal-like extensions. He started out with the 65c02 in the 1980s, then moved up to the 65c816, and then on to the Pentium series. Recently he got a letter from some astronomers in Turkey who were still using his old 65c816 system to control their telescope. They had made some kind of hardware modification (I think adding RAM beyond 64K) and his compiler had failed to work properly. They were upset and wanted the problem fixed immediately. They had paid good money for that compiler after all --- never mind that this was 15 years ago for a processor that nobody uses anymore. Anyway, he dug out the old source-code, fixed the problem, and emailed them a new eprom image at no charge. I can definitely respect that kind of business ethic. That is the way that I would do business (if I owned my own company, of course).

                          Cheers,
                          Hugh



                          From: Elizabeth D Rather <erather@...>
                          To: forth200x@yahoogroups.com
                          Sent: Tuesday, July 7, 2009 5:15:30 PM
                          Subject: Re: [forth200x] Re: RfD: HEADER


                          You are welcome to use HEADER, and call it whatever you want, and write
                          about it. If a lot of people also find they need it, they will
                          implement it in their systems. If it becomes popular, it will be an
                          appropriate subject for standardization.

                          .


                        • Elizabeth D Rather
                          ... Sure, every Forth has lower-level factors of the primary defining words, but they differ from one implementation to another, and since those of us who
                          Message 12 of 14 , Jul 9, 2009
                            Hugh Aguilar wrote:
                            >
                            > It already is popular. UR/Forth has its HEADER, Gforth has its
                            > NEXTNAME, etc., etc.. As I said earlier, it is likely that
                            > /every/ Forth system has provided some kind of solution to the problem
                            > --- unfortunately, they are all incompatible with each other.
                            >
                            > I don't know if SwiftForth has something like :NAME or not (because my
                            > $500 SwiftForth compiler doesn't work anymore), but I'll bet its in
                            > there somewhere. The reason I say this is because it is good
                            > programming practice to write a low-level word such as :NAME and then
                            > define colon on top of it, rather than just write colon by itself ---
                            > that is factoring, which is pretty much the foundation of Forth style.
                            > Assuming that whoever wrote SwiftForth was highly skilled (which I
                            > think is true), then he most likely did it this way.
                            Sure, every Forth has lower-level factors of the primary defining words,
                            but they differ from one implementation to another, and since those of
                            us who spend our lives writing applications, as well as our customers,
                            don't really see a need for access to them, there hasn't been any
                            interest in standardizing them.
                            >
                            > Maybe it is an undocumented word that is only available to Forth Inc.
                            > employees. SwiftForth is closed-source, so there is likely a lot of
                            > cool stuff hidden in there that customers (me) don't know about.
                            I think you have more source than you may realize. We don't release
                            much source with the free version, but most of the source for the
                            kernel and extensions is included with even the cheaper paid version,
                            and even the source for the metacompiler (with the optimizer) is
                            included with the professional version.
                            >
                            > BTW, I know a guy who wrote a compiler for a BASIC with Pascal-like
                            > extensions. He started out with the 65c02 in the 1980s, then moved up
                            > to the 65c816, and then on to the Pentium series. Recently he got a
                            > letter from some astronomers in Turkey who were still using his old
                            > 65c816 system to control their telescope. They had made some kind of
                            > hardware modification (I think adding RAM beyond 64K) and his compiler
                            > had failed to work properly. They were upset and wanted the problem
                            > fixed immediately. They had paid good money for that compiler after
                            > all --- never mind that this was 15 years ago for a processor that
                            > nobody uses anymore. Anyway, he dug out the old source-code, fixed the
                            > problem, and emailed them a new eprom image at no charge. I can
                            > definitely respect that kind of business ethic. That is the way that I
                            > would do business (if I owned my own company, of course).
                            Well, we don't know what kind of business relationship that development
                            was done under, of how extensive the fix was, or how your friend makes a
                            living. But all of the software products that I use that were developed
                            by people whose livelihood comes only from those products depend on
                            people paying for major upgrades to cover the cost of providing those
                            upgrades. A major upgrade costs at least a man-month, often more, to
                            produce, test, and document. Charging a small amount for major upgrades
                            to customers whose last purchase was some time in the past is standard
                            practice.

                            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
                            ... Sounds like you should start a business so you can get more wider exposure for your ideas. I found that my ideas about business, and pretty much everything
                            Message 13 of 14 , Jul 9, 2009
                              > That is the way that I would do business (if I owned my own company,
                              > of course).

                              Sounds like you should start a business so you can get more wider
                              exposure for your ideas.

                              I found that my ideas about business, and pretty much everything else,
                              evolved significantly as a result of running a business.
                            • Hugh Aguilar
                              Putting me in charge of anything is a scary thought --- not just for me, but for the rest of the world too. ;-) Seriously, if I were to start my own business,
                              Message 14 of 14 , Jul 9, 2009
                                Putting me in charge of anything is a scary thought --- not just for me, but for the rest of the world too. ;-)

                                Seriously, if I were to start my own business, I would first have to write my own desktop Forth system. This isn't something that I want to do. I would be happy to just work as a consultant implementing cross-compilers for people, and using whatever desktop Forth system the customer prefers. 

                                As I have said many times already; the future involves lots of companies developing their own proprietary microcontroller based upon a PLD or FPGA, each of which will need a custom cross-compiler written for it. In the future, microcontrollers such as the PIC24 (which I like) will likely disappear. Silicon forges such as MicroChip will switch over to selling PLDs, and below them will be companies that implement microcontrollers on these PLDs, and below them will be companies that are actually building machinery that needs a microcontroller in it.

                                Think about it this way. If a rinky-dink outfit like Testra can develop something like the MiniForth chip on a small PLD such as the Lattice-isp1048 --- and succeed at this in the 1990s --- then lots of companies will be able to do the same thing in the 2010s. I saw the future way back in the 1990s! My only surprise is that it hasn't arrived yet, in 2009.


                                From: Mitch Bradley <wmb@...>
                                To: forth200x@yahoogroups.com
                                Sent: Thursday, July 9, 2009 7:46:02 AM
                                Subject: Re: [forth200x] Re: RfD: HEADER

                                > That is the way that I would do business (if I owned my own company,
                                > of course).

                                Sounds like you should start a business so you can get more wider
                                exposure for your ideas.

                                I found that my ideas about business, and pretty much everything else,
                                evolved significantly as a result of running a business.


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