Re: [Factor-talk] Factor Versus Forth --- the book
Message: 4 Date: Mon, 12 Oct 2009 01:07:47 +0200 From: Samuel Tardieu s...@rfc1149.net Subject: Re: [Factor-talk] Factor Versus Forth --- the book To: factor-talk@lists.sourceforge.net Message-ID: 87iqelcyws@willow.rfc1149.net Content-Type: text/plain; charset=us-ascii Hugh A more modern microprocessor such as the PIC18 is also pretty Hugh simple, and would be another reasonable choice. PIC18 with their unique work register are pretty awful to work with. Trust me, I've written a Forth compiler for this architecture... Actually, after I suggested the PIC18 I realized that it would be a bad choice. It doesn't really have any addressing modes. There is no indexed addressing like in the 65c02 --- the programmer is expected to simulate addressing modes by writing macros. It is pretty awful. A much better choice would be the 8-bit AVR. That is a hella-fast modern processor that people would be interested in from a practical standpoint (unlike both the 65c02 and the 8080), and it has a fairly straightforward architecture complete with addressing modes. If this book is going to be read by Forth programmers, then it is going to have to discuss real-word programming --- meaning micro-controllers --- because that is what they care about. P.S. for Chris Double --- I will read up on that Joy link that you provided. Maybe then I can come to grips with DIP and all that, which largely confuse me right now. -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
Message: 6 Date: Sat, 10 Oct 2009 18:48:53 -0500 From: Doug Coleman doug.cole...@gmail.com Subject: Re: [Factor-talk] Factor Versus Forth --- the book To: factor-talk@lists.sourceforge.net Message-ID: 3a2525b0-76e7-4815-8641-f537d742e...@gmail.com 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
Hugh == Hugh Aguilar hugoagui...@rosycrew.com writes: Hugh Forth only ships a relative handful of words that have Hugh been found to be widely useful. One of these is star-slash the Hugh scalar. It is called that because it is typically used for scaling Hugh integer arithmetic. You use continued fractions to find rational Hugh approximations for real numbers, and this allows you to use Hugh integer arithmetic for the kind of calculations that are normally Hugh done in floating-point. The main advantage of */ is that it uses a double width for the intermediate result. Hugh A more modern microprocessor such as the PIC18 is also pretty Hugh simple, and would be another reasonable choice. PIC18 with their unique work register are pretty awful to work with. Trust me, I've written a Forth compiler for this architecture... -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
Somewhere in extra is an 8080 emulator written by Chris Double that can even play simple game ROMs like Space Invaders. If it has fallen out of maintenance it will be in the unmaintained folder in the main source tree. On 10/11/09, Samuel Tardieu s...@rfc1149.net wrote: Hugh == Hugh Aguilar hugoagui...@rosycrew.com writes: Hugh Forth only ships a relative handful of words that have Hugh been found to be widely useful. One of these is star-slash the Hugh scalar. It is called that because it is typically used for scaling Hugh integer arithmetic. You use continued fractions to find rational Hugh approximations for real numbers, and this allows you to use Hugh integer arithmetic for the kind of calculations that are normally Hugh done in floating-point. The main advantage of */ is that it uses a double width for the intermediate result. Hugh A more modern microprocessor such as the PIC18 is also pretty Hugh simple, and would be another reasonable choice. PIC18 with their unique work register are pretty awful to work with. Trust me, I've written a Forth compiler for this architecture... -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Sent from my mobile device -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
On Mon, Oct 12, 2009 at 3:19 PM, Adam hiat...@gmail.com wrote: Somewhere in extra is an 8080 emulator written by Chris Double that can even play simple game ROMs like Space Invaders. I even had it running an 8080 Forth, inside Factor. If it has fallen out of maintenance it will be in the unmaintained folder in the main source tree. Yes, it's in 'unmaintained/cpu/8080' and 'unmaintained/space-invaders'. The CPU emulator bitrot would be easy to fix. The GUI side is most likely the bit that needs some work. Chris. -- http://www.bluishcoder.co.nz -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
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? Well, bad idea, you could never cover the number of cases that would potentially come up in the real world. So how hard is it to just define the ones we need? For defining /-*, you could do it by hand: : /* ( x y z -- w ) r / r * ; : /-* ( x y z -- w ) 2dup - /* ; Great, that is quick and easy. But how does Factor get away without shipping a */ word or having to define all these helper words? 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. The Factor definition of *+/ looks like this: : *+/ ( x y -- z ) [ * ] [ + ] 2bi / ; Similarly: : --/ ( x y -- z ) [ - ] [ - ] 2bi / ; Now, this is only basic arithmetic -- what about working with sequences? You might want to append or prepend two sequences, or merge them: merge(append(seq1,seq2),prepend(seq1, seq2)) In Factor you can use the same approach as with the resistors: : seqs-op ( seq1 seq2 -- seq ) [ append ] [ prepend ] 2bi vmerge ; abc def [ append ] [ prepend ] 2bi vmerge . adbecfdaebfc This operation, in shorthand analogous to the above, could be called an APM operation for append,prepend, merge. You can see that the same combinator 2bi is useful here, without defining a ton of helper words. Would you add an AM word to Forth to facilitate solving this problem? It's just not practical. In short, separating data flow from operators is a powerful feature. Doug On Oct 10, 2009, at 5:44 PM, Hugh Aguilar wrote: I have an updated version. Please read it through all the way, rather than just go to the new sections, as there is a lot of rewriting throughout. Thanks for your continued help in improving this documentation. The dvi is here: www.rosycrew.org/FactorVsForth.dvi The pdf is here: www.rosycrew.org/FactorVsForth.pdf Note that I have a section titled: bad things about Factor. Don't stop reading here though --- the next section is titled: good things about Factor. The book is supposed to be balanced and fair. :-) BTW, I'm intending to present a 65c02 assembler later. I chose the 65c02 because it is quite simple, everybody is familiar with it, and there are plenty of simulators available for it even today. The downside, of course, is that it has very little practical value anymore. If you would prefer a more modern microprocessor target, let me know. Of course, if you have an opinion on this, then that also means that you're volunteering to write the Factor version... -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
Doug Coleman doug.cole...@gmail.com wrote: 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 + */ ; Doug, I see your purpose and appreciate it; I think you explained well why Factor separates data flow from operators. However, Forth's */ operator has one additional purpose; it's really merely to be able to avoid typing a space between star and slash. It's actually a scaling operator which uses a double-length intermediate result, so that as long as your final answer fits into a single-length integer, there will be no overflow. In Forth, at that time, that's a very significant guarantee. Factor doesn't need that; it has other ways to avoid integer overflow. -Wm -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor Versus Forth --- the book
On Sun, Oct 11, 2009 at 11:44 AM, Hugh Aguilar hugoagui...@rosycrew.com wrote: I have an updated version. Please read it through all the way, rather than just go to the new sections, as there is a lot of rewriting throughout. Thanks for your continued help in improving this documentation. Have you read any of the papers on Joy? http://www.latrobe.edu.au/philosophy/phimvt/joy.html These cover much of the origin of words like dip, etc. You mention them in your book and seem to not quite understand why they exist so I thought this background material might be interesting to you. Chris -- http://www.bluishcoder.co.nz -- 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 Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
