> Message: 6 > Date: Sat, 10 Oct 2009 18:48:53 -0500 > From: Doug Coleman <[email protected]> > Subject: Re: [Factor-talk] "Factor Versus Forth" --- the book > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes > > Hi Hugh, > > In your book, you state that you know about the */ word in Forth, > allowing you to quickly solve the resistor problem. Why not go the > whole hog and ship a new word in every Forth implementation: > > : *+/ ( x y -- z ) 2dup + */ ; > > This directly solves the problem -- any competent Forth programmer > would be able to look at the formula for parallel resistors and > immediately think of this solution. It's so elegant! > > But how many three-operator words would you include by default? What > about /-* or +// or */* or some other combination? Which ones should > we package into our Forth distributions?
Forth is a *thin* language --- we don't go whole hog and ship a jillion secondary words in every Forth implementation; that was pretty much the point of my "bad things about Factor" section. Forth only ships a relative handful of words that have been found to be widely useful. One of these is star-slash the scalar. It is called that because it is typically used for scaling integer arithmetic. You use continued fractions to find rational approximations for real numbers, and this allows you to use integer arithmetic for the kind of calculations that are normally done in floating-point. For example, you could write a word like this: : pi* ( n -- n*pi ) 355 113 */ ; > The solution in Factor is to provide data flow constructs that the > user fills in with operations, instead of combining the data flow and > operators into the same word like */ does. ... > In short, separating data flow from operators is a powerful feature. If you had read the next section, "good things about Factor," you would have seen that I like quotations and want them to be introduced into Forth. I agree that separating data flow from operators is a powerful feature. My point is that this good idea shouldn't be taken to a pathological extreme. When you introduce this kind of programming into something as short and simple as the par function, just to get rid of the 2dup stack-shuffler, you are killing a fly with sledgehammer. I did like the use of reduce and map-reduce in the pars function (and I'm going to write those functions in Forth in the next chapter) --- but pars is a bigger function than par so now you are killing a mouse with a sledgehammer, which makes more sense. The kind of programming that you are describing would shine a lot better employed in a larger example program than the ones that I provided in my first chapter. Since you feel so passionately about the elegance of quotations and sequences, as compared to the crudeness of Forth stack-shufflers, why don't you write the Factor version of the 65c02 assembler? I don't want to write this myself, and then shoot it down like a clay pidgeon, as that would hardly be fair --- everybody will say: "If the Factor version had been written by a real Factor programmer, it wouldn't have been so easy to shoot down." Remember that I assume that anybody who complains about my writing is volunteering to step in and do a better job. :-) To make the job easier, it is not necessary to translate traditional assembly such as this: lda #1234 You can use post-fix like this: 1234 lda# Your lda# would be a Factor word that compiles the instruction into the target memory specific to the parameter (1234) that it is given. Your assembly-language code is actually a Factor program itself, and executing this Factor program generates the target image for the microprocessor. This is the typical way that Forth programmers write assemblers, and it is pretty easy. Is there a better way to write an assembler in Factor? As I said before, I just chose the 65c02 because it is super-simple (and I wrote one already, a long time ago). A more modern microprocessor such as the PIC18 is also pretty simple, and would be another reasonable choice. Processors such as the PIC24 are too complicated for a book such as this though. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
