From: dku@zarniwoop.pc-labor.uni-bremen.de (Dirk Kutscher) Subject: n-words Date: 14 Feb 1995 13:59:42 GMT More or less frequently I have to deal with values that are composed of scalar values of variable number. Rewriting the basic stack operations every time is boring and error prone. The following word set provides an abstract interface for arbitrary data structures (assuming that you know their "size" in terms of cell allocation ;-). (This is F83-Source (constructed with tile forth), sorry about missing stack comments, but I think the semantics of swap, rot etc. are well known...) ---------------------------------------------------------------------- \ n-words: words to support stack and memory handling \ with multi-word data structures. \ Each n-word expects the size of the argument to deal with at TOS. \ \ (all words have linear time complexity) forth definitions vocabulary nwords nwords definitions : ndup ( a1 a2 ... an n -- a1 a2 ... an a1 a2 ... an ) dup 0 do dup pick swap loop drop ; : nover ( a1.1 a1.2 .. a1.n a2.1 a2.2 .. a2.n n -- a1.1 a1.2 .. a1.n a2.1 a2.2 .. a2.n a1.1 a1.2 ... a1.n ) dup 2 * swap 0 do dup pick swap loop drop ; : npick ( ... i n -- ... ) dup rot 1+ * swap 0 do dup pick swap loop drop ; : ndrop ( a1 a2 ... an n ) 0 do drop loop \ crude, ndrop should really be a primitive ; : nswap ( ... n -- ... ) dup 2* 1- swap 0 do dup >r roll r> loop drop ; : nrot ( .. n -- .. ) dup 3 * 1- swap 0 do dup >r roll r> loop drop ; : nroll ( .. u n -- .. ) dup rot 1+ * 1- swap 0 do dup >r roll r> loop drop ; : nnip ( .. n -- .. ) dup >r nswap r> ndrop ; : n@ ( adr n -- a1 a2 ... an ) cells over + swap do i @ 4 +loop ; \ n-variables etc. : n! ( a1 a2 ... an adr n ) swap 1 cells - dup rot cells + do i ! -4 +loop ; : nvariable ( n -- ) create cells allot ; : n, ( .. n ) here over cells allot swap n! ; : nconstant ( a1 a2 ... an n ) create dup , n, does> ( adr ) dup 1 cells + swap @ n@ ; \ user defined operations on n-words... \ execute binary operation op an all n "members" of the 2 n-words on the stack: : nop ( ... ..op. n --- ... ) dup 0 do i over >r swap 2* swap - roll r@ 1+ roll 2 roll dup >r execute r> r> loop 2drop ; \ execute unary operation op an all n "members" of the n-word on the stack: : u_nop ( ... op n --- ... ) dup 0 do dup >r over >r roll swap execute r> r> loop 2drop ; \ "and" n members together - for boolean operations : nand ( ... n -- f ) 1- 0 do and loop ; \ syntactic sugar... : apply ( -- n 0 ) [compile] ' 0 ; : boolean drop -1 ; : _nop ( adr -- op n ) dup @ swap 1 cells + @ ; : compile_boolean does> ( adr ) _nop dup >r nop r> nand ; : compile_binary does> ( adr ) _nop nop ; \ the defining word: : noperator ( adr f n ) swap >r create swap , , r> if compile_boolean else compile_binary then ; \ for example: apply + 2 noperator v+ apply = boolean 2 noperator d= : compile_unary does> ( adr ) _nop u_nop ; : unaryoperator ( adr n ) nip create swap , , compile_unary ; \ for example: apply negate 2 unaryoperator dnegate forth definitions nwords ---------------------------------------------------------------------- -- Bye, Dirk http://wowbagger.pc-labor.uni-bremen.de/Dirk/dku.html From: bevan@cs.man.ac.uk (Stephen J Bevan) Subject: Re: What do you think of FORTH as compared to Smalltalk? Date: 16 Feb 1995 12:24:37 GMT <3hb2kb$138f@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 8 Feb 1995 10:30:35 -0800 In article <3hb2kb$138f@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes: >In principle I agree, but in practice I think it is somewhat >different. For example, consider simple stream IO. Sometimes I need >to be able to read and write to a file, sometimes it is just read or >write. I could modify/reimplement the IO library to take advantage >of this but -generally- I don't since the cost outweighs the benefits. >Similarly I believe that -generally- the cost of modifying an OO >package would outweigh the benefits. ...unless the OO package was simple enough. My point. Even if it is simple enough to modify you still have the problem that you have n program with n variants of the OO system -- IMHO that is a maintenance headache. I was given C originally. I guess I can handle switching languages :), but I'd rather do one I've _heard_ of before. I've heard of TCL-- is that similar to TXL? No TXL is a transformation language/implementation -- see the language list (ir)regularly posted to comp.lang.misc/comp.compilers for more information. Really, I'd like to finish this off-- C is a true general purpose language that we can agree _does not_ have "the basis of OO". In an effort to understand what the "basis of OO" actually is I asked (a few weeks ago) the question: which languages did -not- provide the "basis of OO". The answer didn't include C, indeed if I remeber correctly the answer was that most languages provide the "basis of OO". Is my memory faulty or has the position changed? ... If you just don't like C ... I have no problem with using C, I just don't see why the OO extension has to be Objective-C. How about the simple (though arguably ugly) OO extension at the end of this message? ... how about picking some other language that we can agree does not have the basis of OO? Fine. You list some (say 5) language which you think don't (and the reasons why) and I'll give it a go. ---------------------- snip snip ------------------------------- panther% cat foo.c /* A simple, but arguably ugly, OO hack. Note it is not class based, ** it is a prototype based system with (manual) delegation. */ #include #include #define Object_Data \ void *parent; typedef struct Point_2D { Object_Data; int x; int y; void (* set_x)(struct Point_2D *, int); void (* display)(struct Point_2D *, FILE *); } Point_2D; static void Point_2D_Set_X(Point_2D *p, int x) { p->x= x; } static void Point_2D_Display(Point_2D *p, FILE *out) { fprintf(out, "x= %d y= %d", p->x, p->y); } static void Point_2D_new(Point_2D *p, int x, int y) { p->x= x; p->y= y; p->set_x= Point_2D_Set_X; p->display= Point_2D_Display; } typedef struct Point_3D { Object_Data; int z; void (*set_x)(struct Point_3D *, int); void (*display)(struct Point_3D *, FILE *); } Point_3D; static void Point_3D_Set_X(Point_3D *p, int x) { ((Point_2D *)p->parent)->set_x(p->parent, x); } static void Point_3D_Display(Point_3D *p, FILE *out) { ((Point_2D *)p->parent)->display(p->parent, out); fprintf(out, " z= %d", p->z); } static void Point_3D_new(Point_3D *p, Point_2D *parent, int z) { p->parent= parent; p->z= z; p->set_x= Point_3D_Set_X; p->display= Point_3D_Display; } int main(void) { Point_2D p2; Point_3D p3; Point_2D_new(&p2, 10, 20); Point_3D_new(&p3, &p2, 20); p2.display(&p2, stdout); putchar('\n'); p3.display(&p3, stdout); putchar('\n'); p3.set_x(&p3, 20); p2.display(&p2, stdout); putchar('\n'); p3.display(&p3, stdout); putchar('\n'); return 0; } panther% gcc foo.c panther% ./a.out x= 10 y= 20 x= 10 y= 20 z= 20 x= 20 y= 20 x= 20 y= 20 z= 20 panther% ---------------------- snip snip ------------------------------- From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: 16 Feb 1995 07:34:36 -0500 <792381162snz@chocolat.demon.co.uk> <1995Feb14.154506.3452@debet> <792810184snz@chocolat.demon.co.uk> In-reply-to: PS@chocolat.demon.co.uk's message of Wed, 15 Feb 1995 01:03:04 +0000 Paul Shirley: I think you are going to have to do some more explaining then... 1: Why is using named local variables on a stack (the C way) more buggy than unnamed local variables on a stack (the Forth way)? I see little difference between them. 2: Where do you keep the global data? Do you really keep it on the stack (unnamed)? Just what are these 'side effects' that Forth apparently does not suffer from? The most significant answer to both questions is the multi-value return. C provides three mechanisms for multi-value return: (a) return values in fixed global address space. (b) return values at address provided as argument. (c) return values on heap and explicitly return address of these values. (d) implement some other language (using the above techniques internally but with a cleaner interface for the applications programmer). Forth supports all the above, but adds another option to this list that: (*) doesn't require any extra memory management logic, (*) is not syntactically different from any other value passing, (*) and does not require knowledge of the address of the value. By comparison, multiple values in C has a significant coding and complexity overhead. Yet again someone tries to score cheap points against other languages, with comments that seem to have no justification. Have you ever designed and written a large program? Your postings lead me to believe that you've never had to grappple with issues of code complexity. -- Raul D. Miller / From: dku@zarniwoop.pc-labor.uni-bremen.de (Dirk Kutscher) Subject: Q: Xlib & Xt for Forth Date: 14 Feb 1995 14:04:55 GMT Hi, Some time ago there has been a discussion of building interfaces for Xlib or Xt for Forth. What is the current state of these developments (if they still exist)? -- Bye, Dirk http://wowbagger.pc-labor.uni-bremen.de/Dirk/dku.html From: snf_dw@debet.nhh.no Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: 16 Feb 95 13:46:55 MET In article <792810184snz@chocolat.demon.co.uk>, PS@chocolat.demon.co.uk (Paul Shirley) writes: > > I think you are going to have to do some more explaining then... > > 1: Why is using named local variables on a stack (the C way) more buggy > than unnamed local variables on a stack (the Forth way)? > I see little difference between them. Local variables are a fairly good solution to the side effect problem. They solve the practical problem you would otherwise get in a large problem with no scope rules etc, that no matter how much you debug and test your routines, the global named variable remains wide open for you (or someone else) to clobber its contents from anywhere in many tens of thousands of lines of code. I think the Forth way is a little more reliable, for two reasons: 1) Most Forth words are (or should be) much shorter than most C routines. 2) Most Forth words can (or should be written so they can) be tested regarding stack effects, by executing them alone. If you think named local variables in C are more reliable than global variables, then it would seem you agree with my main point, which is the only one I wanted to make. > > 2: Where do you keep the global data? Do you really keep it on the > stack (unnamed)? Just what are these 'side effects' that Forth > apparently does not suffer from? > Not being a fully trained computer scientist, my definition of side effect may not be standard, but what I mean by it is that when you execute a word, it has a side effect if as a result of execution it alters the environment for executing other routines later, in a way that is not documented by a description of its output. Typically, if it alters the contents of some location in memory that it was meant to be using on a temporary basis, but actually influences other things that happen later. The point of the concept is: 1) You increase reliability if you get rid of as many side effects as you can, or if you name them intelligently and/or put them into structures where the effect can be revealed. 2) Certain methods of proving that code is free of errors work only when it has no side effects. Some theories of programming depend on the absence of side effects. I keep my global data very systematically named, as much in structured tables as possible, and I avoid using global data as much as possible. Correct factoring of code reduces the number of side effects you need to incur in practice, in my experience. But debugging also requires the ability to display well and at appropriate times, the stored data that links different program elements such as Forth words. >>I never said, or meant to imply that *all* your programs do is ... > > Its the logical extrapolation of your statements. > Only if you misunderstand what I said, e.g. it would save time to first ask what I meant by a side effect. > Yet again someone tries to score cheap points against other languages, with > comments that seem to have no justification. > I try not to re-invent the wheel here. Justification for dealing well with side effects is something I have viewed as fairly well known. The point is not cheap. C encourages use of named variables in a way that I have found marginally less reliable (for local variables) than eliminating them in Forth. Forth allows you to remove named variables from your code that it would be natural to keep in a C program. Here is some simple justification: It is easier in C to misuse a global or local variable than it is in Forth to misuse the stack. Good Forth programmers avoid PICK and limit themselves to a subset of stack manipulation words that do not dig deep into the stack. To achieve that you have to factor your code correctly. With Forth, most of the stack is untouched most of the time. With C, the local variables in the stack frame are accessed more or less randomly. If there are more than 6 or 7 of them and they are poorly named, sooner or later there will be trouble that is difficult to debug. Ask yourself, why is it that many Forth words once written, don't have to be debugged or rewritten later ? > I've noticed a big difference between (for example) C users and Forth users. > C users complain about problems in C, then try to fix them. > Forth users complain about problems in C. Period. > Forth "users" tend to fix themselves the problems they find in or with Forth. Your comment squares with my observation that most of the C++ news conference seems to be about how to make it work. I hope you don't mean to imply that Forth users have some sort of responsibility to fix problems in C. > I read this group for Forth, if I want C I read the C groups. If anyone > here really thinks bitching about everyone else will advance Forths > reputation I despair for Forths future. > Many Forth users are indeed very dissatisfied with certain other programming languages. Believe it or not, most of us have a lot of experience with well known languages such as Fortran, Basic, C and C++. Far from bitching about everyone else, I have spent most of my time in this News conference over the last few months arguing that a hybrid Forth/C++ system that takes account of Microsoft software interfaces is important for Forth's future. So you seem to me to be criticizing one of only about 3 people here who seem to think that C/C++ is an important language that we should relate to rather than just bitch about. C in particular has many aspects in common with Forth that distinguish both from most other languages (e.g. relatively compact code, relatively great freedom of expression, relatively short manuals). But we aren't going to get anywhere in the Forth/C++ discussion by ignoring obvious technical weak points in C/C++. Regards, David Walker snf_dw@debet.nhh.no From: bevan@cs.man.ac.uk (Stephen J Bevan) Subject: Re: What do you think of FORTH as compared to Smalltalk? Date: 16 Feb 1995 16:08:02 GMT <3hb2kb$138f@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 8 Feb 1995 10:30:35 -0800 In article <3hb2kb$138f@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes: >In principle I agree, but in practice I think it is somewhat >different. For example, consider simple stream IO. Sometimes I need >to be able to read and write to a file, sometimes it is just read or >write. I could modify/reimplement the IO library to take advantage >of this but -generally- I don't since the cost outweighs the benefits. >Similarly I believe that -generally- the cost of modifying an OO >package would outweigh the benefits. ...unless the OO package was simple enough. My point. Even if it is simple enough to modify you still have the problem that you have n program with n variants of the OO system -- IMHO that is a maintenance headache. I was given C originally. I guess I can handle switching languages :), but I'd rather do one I've _heard_ of before. I've heard of TCL-- is that similar to TXL? No TXL is a transformation language/implementation -- see the language list (ir)regularly posted to comp.lang.misc/comp.compilers for more information. Really, I'd like to finish this off-- C is a true general purpose language that we can agree _does not_ have "the basis of OO". In an effort to understand what the "basis of OO" actually is I asked (a few weeks ago) the question: which languages did -not- provide the "basis of OO". The answer didn't include C, indeed if I remeber correctly the answer was that most languages provide the "basis of OO". Is my memory faulty or has the position changed? ... If you just don't like C ... I have no problem with using C, I just don't see why the OO extension has to be Objective-C. How about the simple (though arguably ugly) OO extension at the end of this message? ... how about picking some other language that we can agree does not have the basis of OO? Fine. You list some (say 5) language which you think don't (and the reasons why) and I'll give it a go. ---------------------- snip snip ------------------------------- panther% cat foo.c /* A simple, but arguably ugly, OO extension to C */ #include #include #define Point_2D_Data \ void (* set_x)(struct Point_2D *, int); \ void (* display)(struct Point_2D *, FILE *); \ int x; \ int y typedef struct Point_2D { Point_2D_Data; } Point_2D; static void Point_2D_Set_X(Point_2D *p, int x) { p->x= x; } static void Point_2D_Display(Point_2D *p, FILE *out) { fprintf(out, "x= %d y= %d", p->x, p->y); } static void Point_2D_new(Point_2D *p, int x, int y) { p->x= x; p->y= y; p->set_x= Point_2D_Set_X; p->display= Point_2D_Display; } typedef struct Point_3D { Point_2D_Data; int z; } Point_3D; static void Point_3D_Display(Point_3D *p, FILE *out) { Point_2D_Display((Point_2D *)p, out); fprintf(out, " z= %d", p->z); } static void Point_3D_new(Point_3D *p, int x, int y, int z) { Point_2D_new((Point_2D *)p, x, y); p->z= z; p->display= Point_3D_Display; } int main(void) { Point_2D *p; Point_2D p2; Point_3D p3; Point_2D_new(&p2, 10, 20); Point_3D_new(&p3, 10, 20, 30); p= &p2; p->display(p, stdout); putchar('\n'); p= &p3; p->display(p, stdout); putchar('\n'); return 0; } panther% gcc foo.c foo.c: In function `Point_3D_new': foo.c:60: warning: assignment from incompatible pointer type foo.c: In function `main': foo.c:74: warning: assignment from incompatible pointer type panther% ./a.out x= 10 y= 20 x= 10 y= 20 z= 30 panther% ---------------------- snip snip ------------------------------- From: mckewan@netcom.com (Andrew McKewan) Subject: Re: doubly linked list in 1 field Date: Thu, 16 Feb 1995 21:41:11 GMT Here's my tu'pence on editor design from my 1993 FORML paper. I started out with a list-of-lines apporroach because I thought it would be easier to access the data during redisplay, etc. Also, some commands such as "goto line 509" are trivial. However, splitting and joining lines were a mess as was doing a search with an end-of-line in the search string. What I discovered is that as I removed "state" information (variables) the code got much simpler. After a few code routines were written to find the next and previous lines (mostly complicated by MD-DOS's horrible habbit of using two characters to delimit a line) things got really simple. I use the buffer-gap model previously described and a single variable POINT to keep the current location. This is a logical offset into the text, so to move to the beginning of the file, the code is 0 POINT ! to go to the next character: 1 POINT +! (with checking for end of buffer). The gap does not need to be moved until we insert or delete text. Moving around is very fast. (ok, go to line 500 might be slow). I don't have the code to reference here, but inserting a character is something like: : INSERT-CHAR ( char -- ) GAP-TO-POINT GAP @ C! 1 GAP +! 1 POINT +! ; (compare this to the code in F-PC (sorry Tom)) I think the model of text as a list of lines leads to complicated manipulations. I prefer the model of text as an array of characters, some of which are used to delimit lines. Andrew. P.S. The premise of the FORML article was the decoupling of display and data-manipulation code. -- mckewan@netcom.com From: mckewan@netcom.com (Andrew McKewan) Subject: Re: Parameter passing Date: Thu, 16 Feb 1995 21:50:33 GMT Scott McLoughlin (smcl@sytex.com) wrote: : etc. etc.) In fact, 99% of the Windows API functions _DO NOT : USE THE "C" CALLING CONVENTION_. Strange but true. They use : the "PASCAL" calling convention (reverse arg order from C and : callee handles stack cleanup). Want to hear something really funny? Microsoft has invented yet another calling convention for Win32. They call it "stdcall". The arguments are passed left to right (like C) but the callee cleans up the stack (like PASCAL). Com'on, make up yer mind! Andrew. -- mckewan@netcom.com From: mckewan@netcom.com (Andrew McKewan) Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: Thu, 16 Feb 1995 22:01:30 GMT snf_dw@debet.nhh.no wrote: : VARIABLE performance : : re_evaluate ( address value -- ) +! ; : : MIN ( n n -- n ) 2DUP > IF SWAP THEN DROP ; : : single_loop_learning ( critical_input n_reps -- critical_input) : 10 MIN 0 DO _defensive_ performance 1 re_examine LOOP ; Last time I tried: VARIABLE FOO FOO 1 +! I don't think I liked what I got :-) Andrew. -- mckewan@netcom.com From: mckewan@netcom.com (Andrew McKewan) Subject: Re: Looking for Forth for Windows Date: Thu, 16 Feb 1995 22:20:14 GMT Charles Berg (cberg@ix.netcom.com) wrote: : I am looking for a Forth environment for Windows that meets the following : criteria. : 1) Commercially available No problem, see posts from Forth Inc. and MPE as well as LMI. : 2) Can call external C functions No problem with any of the above. : 3) Can be called by external C functions Big Problem. As far as I know only LMI's system will allow you to write DLLs. Callbacks in MPE can be constructed "by hand" with the assembler, but not trivial. What you may be asking, and what I personally would like to see, is "how do I write part of my code in C and part in Forth and be able to call back and forth arbitrarily and still be able to use Forth interactively?" I think LMI would be the best bet since they compile their Forth to object modules, but so far their's is only a 16-bit version. Andrew. (I own older versions of both vendors' products by I may not be up-to-date on their latest offerings.) -- mckewan@netcom.com From: rideau@ens.fr (Francois-Rene Rideau) Subject: Re: Truth about the GPL Date: 17 Feb 1995 16:16:16 GMT <792893933snz@chocolat.demon.co.uk> In-reply-to: PS@chocolat.demon.co.uk's message of Thu, 16 Feb 1995 00:18:53 +0000 I'd like to dispell those myth about the GPL being too restrictive to use GNU software as a basis to one's work: 1) The GPL doesn't force you to *actually* distribute the sources of the software, as long as you provide a way for people to get it if they want; e.g. point them to the FTP site you got GNU Forth from, and agree to send a copy against shipping&handling fee. This way, you can distribute binary-only stuff and still not deprive people from their right to have the sources from the GNU software they use. 2) only the GNU sources, not that of your software needs be made available: if you only use the GNU software (even modified), you must provide (as in 1) the sources for the GNU software, in their modified version which shows where you modified it. But you can still have a binary-only distribution, as long as all necessary sources are provided to allow upgrade of the GNU sources: you may distribute only object code for your work, but it must then be able to link to upgraded GNU code (e.g. you give away your .o file, stripped from your symbols, as long as it will successfully link to a .o file generated by new GNU sources). To conclude, the GNU GPL is *not* restrictive to you. It won't apply to any work you do (unless you want that), only to the work you received with the GPL -- -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- Join the TUNES project for a computing system based on computing freedom ! TUNES is a Useful, Not Expedient System http://acacia.ens.fr:8080/home/rideau/Tunes/ From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Parameter passing Date: 17 Feb 1995 15:39:39 -0800 rant@ix.netcom.com (Ran Talbott) writes: >tanksley@coyote.csusm.edu (Billy Tanksley) writes: >>In the mainstream market most people don't ever use such functionality. >Everyone I know personally who has access to that functionality uses at >least some of it. I think we're using different vocabularies. When I said 'such functionality' up there I was referring to the software functionality that actually needs the advanced hardware-- ray tracing (because of the sheer computational heaviness), things like that. I know very few people that are doing that-- most of them are committing word processing with their computers :), and most of that is stuff that could be done for MUCH cheaper with only a user interface change (and I DON'T mean a loss of GUI-- there are efficient GUIs out there). >>It's all very well for simulations and rendering, but word processing and >>database clients don't _need_ that much. >People don't _need_ radial tires, or detached suburban single-family >homes, either. But you'll find very few who would go back to the lifestyles >of even 100 years ago, except at gunpoint. Read what I wrote there. Stop putting those words in my mouth, please; I am not Amish. I like technology, I simply like efficiency more. If you had the choice of two systems with the same capabilities, differing only in date of invention and cost (the later one being the most expensive), which one would you take? >I've done word processing, program development, and database systems >using IBM's equivalent of a teletype, so I'm well aware of how little >such systems really _need_. I'd be only slightly less reluctant to >go back to that than I would be to move into a cave. More so, in fact, >if the cave had a proper door, and utility and net hookups ;-) Same here. Especially the net hookups :), I guess I'm socially handicapped (not really ;). >>The 1M machine can do everything the 8M one can >No, it can't. Period. I said there was a "qualitative" difference in >capabilities, and I used the word advisedly. Name the difference. >As soon as you say "however, it will take longer due to disk swapping", >you've made my point, because there's a significant, and growing, >class of real-time applications that cannot be economically (if at all) >programmed to run on that 1Meg machine. You've made my point. The expensive machines are needed only by a tiny niche, but their makers sell them to all of us. Real time control is a really tiny niche, and one most often filled admirably by small machines. >>Now I'm not denying the utility of the hardware-- I'm just pointing out >>that most of that expence is _wasted_ due to crummy programming. The >>point is proven: good programming is needed to really use good hardware. >No, good programming is needed to get optimum performance out of good >(or any) hardware. One of the objectives of having the extra horsepower is >to enable people to get things done with sub-optimal programming. When >applications can be knocked off quickly with tools like Visual Basic or >Labtech Notebook, because there's enough CPU power available that some >can be "wasted", it makes new uses of computers practical (or even possible, >in some cases). That's part of the "qualitative" difference in capabilities, >and all it takes is a quick skim of the "Help Wanted" ads to see that there's >a rush on to exploit it. That is a good argument. I can't rebut it at all, so I'll let you have it-- but can you point me to any _optimal_ programming? It appears that adding the power increases software bulk without appreciating power proportionally. As exhibit A, I offer MS Works (along with Windows); as exhibit B I offer GeoWrite along with Geos. >Ran -Billy From: maccer@MT.net (Johnathon McAlister) Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: Fri, 17 Feb 1995 19:02:17 -0600 In article <793051751snz@chocolat.demon.co.uk>, PS@chocolat.demon.co.uk wrote: > What annoys me is the way any mention of C|C++ leads to unsupported or > innacurate claims. Don't you think Forth can stand on its own merits? Actually, I don't. There's not enough support for data structures. While you can build just about any type of structure you want with whatever syntax you want (due to Forth's wonderfully extensible nature), I don't like having to re-invent the wheel, esp when it means that I end up building the tools to quarry the rock, carry the rock, and carve the rock first. I miss records, classes, and easy to use arrays. Defining a data structure in Forth feels like I've gone back to using assembly - yuck! Now, I'm also a fan of Forth over C/C++ - the extensibility mentioned above is better than C or Pascal, and I want to have it available. Some form of OOP Forth would be great (I use Mops, and love it). But plain old Forth? Nah, to tough. -- Johnathon McAlister maccer@MT.net - preferred, as it's flat rate johnm10248@aol.com - backup, as it's paid hourly From: dku@zarniwoop.pc-labor.uni-bremen.de (Dirk Kutscher) Subject: Re: n-words Date: 16 Feb 1995 12:29:58 GMT <3ht99e$mkj@minnie.informatik.uni-kiel.de> In-reply-to: uho@informatik.uni-kiel.d400.de's message of 15 Feb 1995 17:14:38 +0100 >>>>> On 15 Feb 1995 17:14:38 +0100, uho@informatik.uni-kiel.d400.de (Ulrich Hoffmann) said: > \ n-words: words to support stack and memory handling > \ with multi-word data structures. Ulrich> One remark: Wouldn't it be wise to support with your new operators Ulrich> the widely accepted rules on existing forth stack operators? Ulrich> I mean: DUP DROP should not alter the stack as well as Ulrich> SWAP SWAP Ulrich> With your version you have to supply the number of elements each Ulrich> time an operator can be used. So: Ulrich> n nDUP n nDROP does not alter the stack n nSWAP n Ulrich> nSWAP does not either Yes, alternatively you could keep the number of elements in a global variable very much like BASE and thus define: variable elements : single 1 elements ! ; : double 2 elements ! ; : swap elements @ nswap ; Ulrich> What about: Ulrich> \ ------------------------------------------------------------ Ulrich> : nreverse ( x1 .. xn n -- xn .. x1 ) 0 ?DO I roll LOOP ; Ulrich> \ ------------------------------------------------------------ Ulrich> ( explicitely following your convention ) (Don't know if the convention is worth following... ;-) I think something like "nnreverse" would be more adequate since you probably don't want to shuffle the elements of an item but rather reverse the items themselves... Ulrich> Your implementation for n@ and n! are dependend on cell size. Instead Ulrich> of 4 and -4 you could have used 2 CELLS and -2 CELLS respectively. Aeh, yes of course. Thanks... Ulrich> Anyway, I think it should be possible to make an ANS Forth complient Ulrich> version of your definitions. Certainly. Ulrich> Greetings, Ulrich> Ulrich : SWAP ( # $ -- $ # ) 2 nreverse ; : nswap 2 swap nnreverse ; -- Bye, Dirk http://wowbagger.pc-labor.uni-bremen.de/Dirk/dku.html From: btiffin@on.bell.ca (Brian Tiffin) Subject: Re: Looking for Forth for Windows X-Nntp-Posting-Host: bnkc0r.on.bell.ca Mime-Version: 1.0 Date: Fri, 17 Feb 1995 14:55:45 GMT In article <3hp4c7$9ud@newsbf02.news.aol.com>, erather@aol.com says... > >cberg@ix.netcom.com (Charles Berg) writes: >>I am looking for a Forth environment for Windows that meets the following > >>criteria. >> >>1) Commercially available >>2) Can call external C functions >>3) Can be called by external C functions > >We sell and support ProForth for Windows (produced by MPE in England) in >the US and Canada. It's a 32-bit implementation compatible with Win 3.1 >with Win32s or NT. It can call external DLLs, do DDE, plus floating >point, graphics, and a point-and-click developement environment for >automatically generating Windows user interfaces, and a lot more. > >Call us at 1-800-55FORTH for more info. > > >Elizabeth D. Rather "Forth-based products and >FORTH, Inc. services for real-time >111 N. Sepulveda Blvd. Suite 300 applications since 1973" >Manhattan Beach, CA 90266 >800-55FORTH -- 310-372-8493 >310-318-7130 FAX Hi, Are there any plans for a FORTH Inc. OS/2 Forth implementation? For that matter are there ANY OS/2 PM Forth implementations? The best language really ought to run on the best OS... :) Brian Tiffin blue@achilles.net Blue ~~~~ "Using a language that gets no respect, using an OS that gets no respect" From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: What do you think of FORTH as compared to Smalltalk? Date: 17 Feb 1995 21:00:30 -0800 bevan@cs.man.ac.uk (Stephen J Bevan) writes: >tanksley@coyote.csusm.edu (Billy Tanksley) writes: > >write. I could modify/reimplement the IO library to take advantage > >of this but -generally- I don't since the cost outweighs the benefits. > >Similarly I believe that -generally- the cost of modifying an OO > >package would outweigh the benefits. > ...unless the OO package was simple enough. My point. >Even if it is simple enough to modify you still have the problem that >you have n program with n variants of the OO system -- IMHO that is a >maintenance headache. That is true. However, we're talking modifiable here, not modified :). A simple OO extension is less of a maintainance headache than a complex OO extension. > Really, I'd like to finish this off-- C is a true general purpose > language that we can agree _does not_ have "the basis of OO". >In an effort to understand what the "basis of OO" actually is I asked >(a few weeks ago) the question: which languages did -not- provide the >"basis of OO". The answer didn't include C, indeed if I remeber >correctly the answer was that most languages provide the "basis of >OO". Is my memory faulty or has the position changed? Neither. I answered your question by stating that all general languages, by definition, provide _some_ possibility of OO. Now, the rest of your message is dedicated to showing that C does provide as much of the basis of OO as Forth does, I think we understand each other (or at least insofar as this discussion requires :). > ... If you just don't like C ... >I have no problem with using C, I just don't see why the OO extension >has to be Objective-C. How about the simple (though arguably ugly) OO >extension at the end of this message? Okay. I'll take it. I was just taking something that I knew was PD and powerful. > ... how about picking some other language that we > can agree does not have the basis of OO? >Fine. You list some (say 5) language which you think don't (and the >reasons why) and I'll give it a go. I think C will serve, and I've already gone through a too-lengthly definition :). Let's talk specifics now. >---------------------- snip snip ------------------------------- >/* A simple, but arguably ugly, OO extension to C */ How was that OO? I can't think of any part of any definition that it satisfied. It wasn't polymorphic, it didn't provide any messaging capabilities, etc. What did it have? Just calling it OO doesn't make it so. But, of course, that last remark applies to me as much as you (if not more, since I made one of the original assertations). I posted an OO extension to Forth a while ago that I've used for a number of diverse projects; I've even extended it to handle structures &c. Should I repost? Here's an example of code (perhaps similar to your C functionality). \ This would be simpler and would run better with my structure extensions; \ I don't want to bother looking them up now. Just the OO part, might as \ well let C have its strongest [IMAHO] advantage over Forth, independant \ structure names. master object: point point method: object: super object: 0 , 0 , ; \ use parent's object constructor, then build two data fields point method: ->x 6 >object ; point method: ->y 8 >object ; point method: get me ->x me ->y ; point method: draw me ->x me ->y at [CHAR] . EMIT ; point object: 3D-Point 3D-Point method: object: super object: 0 , ; \ add one data field 3D-Point method: ->z 12 >object ; 3D-Point method: draw me ->x me ->y me ->z [CHAR] . 3D-EMIT ; \ 3D-EMIT calculates the right way to draw char C based on a viewpoint \ stored in some variable somewhere. Who cares; it's the thought that \ counts. \ ------- point MyPoint 3D-Point MyOtherPoint MyPoint get ? ? \ ;) ;) ;) Get it? :) : test-OO 2 CHOOSE IF MyPoint ELSE MyOtherPoint THEN draw ; \ notice that not only does this OO extension look better than \ the C one, it also integrates into the language better. What would \ happen if you attempted to treat one of your 'methods' this way? -Billy ( In CASE you were wondering, MyPoint was that the Forth OO extension was not only shorter than your C extension, but FAR more flexible. Therefore, IF this demonstration proved anything, it proved that Forth has more of the basis of OO than C, a representative of 'most languages'. QED. ;) From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: Truth about the GPL Date: 17 Feb 1995 21:04:15 -0800 rideau@ens.fr (Francois-Rene Rideau) writes: >1) The GPL doesn't force you to *actually* distribute the sources of the >software, as long as you provide a way for people to get it if they want; >e.g. point them to the FTP site you got GNU Forth from, and agree to send >a copy against shipping&handling fee. This way, you can distribute >binary-only stuff and still not deprive people from their right to have the >sources from the GNU software they use. This is all OK with me, since I plan to distribute full source (what would a Forth be without source???). What I'm concerned about is the persistent rumors that the GPL puts strictures on the use of GPL code. Can it not be used in commercial software? If I protect my work with it, will I be prohibiting my 'customers' from writing binary-only software for commercial use? -Billy From: jhoward@solar.sky.net (John Howard) Subject: Re: X3J14 TC Document Posted Date: 18 Feb 1995 12:59:28 GMT Ray Duncan (duncan@nic.cerf.net) wrote: : In article <3ha93s$766@solar.sky.net> jhoward@solar.sky.net (John Howard) : writes: : >I downloaded the dpans94.zip and tried to read the doc with OS/2 v3.0 IBM : >Works word processor. It supposedly imports Word 1.x and 2.x format : >documents. : The WinWord 6.0 document format is not the same as the WinWord 1.0 : and WinWord 2.0 document formats. When you try to open a WinWord : 6.0 document in WinWord 2.0 or IBM Works, you will just get gibberish. : If you own Mac Word 5.1, there is a free translator available from : Microsoft that will let Mac Word 5.1 open Mac Word 6.0 and WinWord 6.0 : documents. : Ray Duncan : duncan@cerf.net WinWord version 6.0 produces a 2.x document format too. Listing the doc file indicates the document format number. I may be wrong but I thought it indicated a 2.0 format. Since IBM Works imports 2.x formats it should have handled the 2.0 as a baseline. When I loaded the doc only the first three pages could display but they displayed correctly. I will just have to use WinWord 6.0 once and export the doc as Rich Text Format (RTF) so I can use it from OS/2. Subject: Re: amiga/68k 4th From: marlin@dplanet.xbbs.com (Marlin Schwanke) Date: Fri, 17 Feb 95 11:59:12 PST Greetings, JAX4TH is available for Unix and Amiga systems. It seems a fairly decent implementation. It is ANS compliant and includes extensions to the Amiga OS. The author may be reached at jax@cygnus.com or you can call his BBS at (303) 278-0364 and download the file, JX4A0317.LZH, as I did. Finally you may ftp the file from my site, dplanet.xbbs.com, if you wish. Once connected you will need to "cd amiga:jforth" and you'll find the file there. Another _excellent_ Forth for Amiga is JForth. It is _not_ ANS compliant. It does have a vocabulary that you may restrict your self to that is Forth-83 compliant. It is _very_ Amiga friendly and includes complete extensions to the AmigaOS through around WB 2.04 with additional code available to incorporate 3.x libraries. The additional modules providing interface to the various Amiga OS facilities made it possible for me to delve in to the Amiga and really learn how the system performed. I can help you further if you are interested in this package. Regards, Marlin __ __ _ /._ ---- marlin@dplanet.xbbs.com --- ////-// //// --- the daily planet bbs ------- ------------ +1-619-232-4919 --- \\\\ \\ \\\\ --- 5 lines, v32bis ------------ From: duncan@nic.cerf.net (Ray Duncan) Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: 18 Feb 1995 16:28:33 GMT In article <793051751snz@chocolat.demon.co.uk> PS@chocolat.demon.co.uk writes: >I'd like a Forth that talked to the *Pascal* interface in Windows ;-) Strictly speaking it isn't a *Pascal* interface (since you can just as easily call it from C or whatever) but it does follow the old _far _pascal calling convention. Anyway our WinForth allows direct calls to any Windows API function and has done so from the beginning. Before that, our OS/2 Forth allowed direct calls to all system APIs going all the way back to 1987. So this isn't exactly a new concept. Ray Duncan lmi@cerf.net From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: n-words Date: 18 Feb 1995 00:29:03 -0500 <3ht99e$mkj@minnie.informatik.uni-kiel.de> In-reply-to: dku@zarniwoop.pc-labor.uni-bremen.de's message of 16 Feb 1995 12:29:58 GMT Dirk Kutscher: Ulrich> n nDUP n nDROP does not alter the stack n nSWAP n Ulrich> nSWAP does not either Yes, alternatively you could keep the number of elements in a global variable very much like BASE and thus define: ... Alternatively, you could get rid of the DROP at the end of each of the nword definitions, such that nDUP nDROP and nSWAP nSWAP are more balanced. Raul D. Miller From: rockwell@nova.umd.edu (Raul Deluth Miller) Subject: Re: Truth about the GPL Date: 18 Feb 1995 11:32:29 -0500 <792893933snz@chocolat.demon.co.uk> <3i3v4f$uqf@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 17 Feb 1995 21:04:15 -0800 Billy Tanksley: This is all OK with me, since I plan to distribute full source (what would a Forth be without source???). What I'm concerned about is the persistent rumors that the GPL puts strictures on the use of GPL code. Can it not be used in commercial software? If I protect my work with it, will I be prohibiting my 'customers' from writing binary-only software for commercial use? There are basically two different GPLs. One is designed for "end user." This is the classic GPL -- people are not supposed to distribute this software without also making the source available through similar mechanisms. [There's never a requirement that the source be distributed with the binary -- that would impinge on the use of GNU software in toaster ovens, for example.] The other GPL is intended for "software libraries." This is designed for distribution of code which people may wish to include in a binary-only distribution. This license merely requires that packages which use this code include provision for end users to upgrade the "library" (as bugfixes, efficiency enhancements, end user enhancements and the like become available for the library). There's still the restriction that since your client is distributing the binary the client need to take some steps to make sure that the source code is available to secondary clients. [There's ways of making it so your clients don't have to actually distribute your source code.] If you merely wish your name to be associated with the product, and don't care about the distribution of bugfixes or other improvements, you might wish to use a license patterned after Berkeley unix license. [Basically, you want your copyright notice on derived software and you don't care about anything.] And, of course, there's other agreements possible. The above seem to be the best (so far) at widespread adoption of useful software. -- Raul D. Miller / From: cbbrown@io.org (Christopher B. Browne) Subject: Re: Truth about the GPL Date: 18 Feb 1995 04:08:58 -0500 In article <3i3v4f$uqf@coyote.csusm.edu>, Billy Tanksley wrote: >rideau@ens.fr (Francois-Rene Rideau) writes: >>1) The GPL doesn't force you to *actually* distribute the sources of the >>software, as long as you provide a way for people to get it if they want; >>e.g. point them to the FTP site you got GNU Forth from, and agree to send >>a copy against shipping&handling fee. This way, you can distribute >>binary-only stuff and still not deprive people from their right to have the >>sources from the GNU software they use. > >This is all OK with me, since I plan to distribute full source (what >would a Forth be without source???). What I'm concerned about is the >persistent rumors that the GPL puts strictures on the use of GPL code. >Can it not be used in commercial software? If I protect my work with it, >will I be prohibiting my 'customers' from writing binary-only software >for commercial use? Most certainly GPL code *can* and *is* used in commercial software. I've a recent and slightly unusual example, in the form of a GhostScript "variant." Bought UNIX-based faxing software that included a "Postscript driver." - Said "driver" cost $1000. - Said "driver" was composed of GhostScript containing (amongst other things) a proprietary fax output format. As a result, this software, sold with full knowledge of Aladdin Software (original producers of GhostScript) contained pretty much all of the critical components of a GPL product. And was sold by a company other than Aladdin. -- Christopher Browne - cbbrown@io.org Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux... From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Looking for Forth for Windows X-Nntp-Posting-Host: fermi.clas.virginia.edu Date: Sun, 19 Feb 1995 00:02:08 GMT btiffin@on.bell.ca writes: > In article <3hp4c7$9ud@newsbf02.news.aol.com>, erather@aol.com says... > > > >cberg@ix.netcom.com (Charles Berg) writes: > >>I am looking for a Forth environment for Windows that meets the > following > > > >>criteria. > >> > >>1) Commercially available > >>2) Can call external C functions > >>3) Can be called by external C functions > > > >We sell and support ProForth for Windows (produced by MPE in England) in > >the US and Canada. It's a 32-bit implementation compatible with Win 3.1 > >with Win32s or NT. It can call external DLLs, do DDE, plus floating > >point, graphics, and a point-and-click developement environment for > >automatically generating Windows user interfaces, and a lot more. > > > >Call us at 1-800-55FORTH for more info. > > > > > >Elizabeth D. Rather "Forth-based products and > >FORTH, Inc. services for real-time > >111 N. Sepulveda Blvd. Suite 300 applications since 1973" > >Manhattan Beach, CA 90266 > >800-55FORTH -- 310-372-8493 > >310-318-7130 FAX > > > Hi, > > Are there any plans for a FORTH Inc. OS/2 Forth implementation? For > that matter are there ANY OS/2 PM Forth implementations? The best > language really ought to run on the best OS... :) > > > Brian Tiffin > blue@achilles.net > Blue > ~~~~ > "Using a language that gets no respect, using an OS that gets no respect" There WAS an OS/2 Forth, but it seems to have died a premature death. For one thing, it was said to have been incompatible with the later versions of OS/2. Others may know more. -- Julian V. Noble jvn@virginia.edu From: Paco Pastor Subject: 1994 Rochester Forth Conference Date: 17 Feb 1995 18:10:58 GMT I am interested in getting information about the 1994 Rochester Forth Conference on Rapid Prototyping. Please, if anyone have information, know a site with information about this subject or where I can request information, any help will be appreciated... Thanks. Paco Pastor From: drm6@cornell.edu (David MacGibbon) Subject: Commercial 68HC16 FORTH cross compilers? Date: Sat, 18 Feb 95 21:17:28 PST Mime-Version: 1.0 We are considering using Motorola's 68HC16 rather than the 68HC11 on our next embedded product (an ultrasonic flowmeter). We like FORTH and use nothing else for our embedded software. Does anyone know of a a commercial metacompiler available for the 68HC16? From: Stuart Ramsden Subject: Re: doubly linked list in 1 field Date: 19 Feb 1995 07:07:18 GMT kleiner@navhp1.nav.uni-stuttgart.de (Thomas Kleiner) wrote: > > > In his Article (14143) Richard de Rozario writes: > > ... > > To create a doubly linked list we store the XOR of the > > predecessor and the successor in the link field. The first and > > last items in the list have a predecessor and successor of some > > special value (like zero) that we can recognise as the end of > > the list. > ... > > How do you know wether your link contains > > - a xor b, with a, b != 0 > > - a xor 0? > XOR is a reversible operation whether or not a, b or (a XOR b) is 0. > ... > > To process the list we need two addresses: the predecessor and > > the current element. So, to process our example list from the > ... > > The point is: you XOR the CURRENT element and its PREDECESOR! > Above you said, you would XOR the SUCCESSOR and the PREDECESSOR. > So you create a singly linked list with a usesless XOR-overhead! > Please read what he said. To CREATE the list you XOR the succ and pred to make the current element. To PROCESS the list (ie traverse) you XOR the current element with the pred to get the succ or going in reverse, XOR the current with the succ to get the pred. Unlike conventional linked list (2 field) processing, you need remember the current and the previous locations, not just the current. In terms of addresses, 3 elements of the list look like; PRED: |A| CURR: |B| SUCC: |C| B is assigned PRED XOR SUCC. If we are going forwards, we assume we know what PRED is and what CURR is. To get SUCC we do PRED XOR B. The situation is symetric going in reverse. > In my opinion the advantage of doubly linked lists is that you can walk > through that list back and FORTH ;) starting at any node. > And this is what you can do with this scheme as well. With pointers to the start and end of the list you can traverse in either direction. > In a singly linked list you use the link direction to traverse without > overhead. But finding the predecessor requires a traversal from the beginning > of the list. > Nope. see above. > And that is why you need two links in a doubly linked list! > Nope again. As mentioned in this thread before, this was a widely used technique when RAM was precious down to the byte. Stuart Ramsden Lecturer in Computer Animation, Australian Centre for the Arts and Technology (ACAT), Institute of the Arts Australian National University, Canberra, ACT, Australia. From: sparrow@alaska.net (cc) Subject: help Date: Sat, 18 Feb 1995 21:36:58 I am a graduate student working on a paper on Quality Management Progrmas. There is a lot of information on quality management, but it all comes from the consultants or people who benifit by its use. None seems to come from the people who actually have to use it or be managed by it. I am particularily interested in Quality Management Programs as applied to software production. I need any comments from as many people as possible. Please E-mail me your responces. Please Please answer the following short survey. Once I am done with the paper I will publish it on the net. 1. What position are you in. upper management middle management worker 2. What Quality program do you have experience with. Please discribe it shortly. 3. What stage of the prgram are you in. i.e. begining, middle, end 4. What support do you get from higher management levels? 5. In your opinion, has the program or will the program improve your company and work environment. 6. Is or was the program worth the costs? explain 7. What are your honest feelings and opinions on quality management programs? From: spqr@ruth.uucp (Will Baguhn) Subject: Re: Parameter passing Date: Sat, 18 Feb 95 13:02:03 CST Reply-To: spqr%ruth.uucp@fullfeed.com rant@ix.netcom.com (Ran Talbott) writes: | No, good programming is needed to get optimum performance out of good | (or any) hardware. One of the objectives of having the extra horsepower is | to enable people to get things done with sub-optimal programming. When | applications can be knocked off quickly with tools like Visual Basic or | Labtech Notebook, because there's enough CPU power available that some | can be "wasted", it makes new uses of computers practical (or even possible, | in some cases). That's part of the "qualitative" difference in capabilities, | and all it takes is a quick skim of the "Help Wanted" ads to see that there's | a rush on to exploit it. | | Ran That is exactly why we need more good programmers. Amazing things can be done with little machines, IF you don't waste the horsepower. Suppose some real-time application is patched together in Visual Basic. Great, now it's running in under 8 hours. The concept works. Now, let's refine it and optimize it.... swell, now we can use a machine a third of the size (COST) a week later, and go back to wasting our big machine horsepower on the next task. My favorite example of how a little machine can do amazing things is the Software Animated Mouth for the Apple II. 48k of RAM, 1 Mhz 8 bit processor, 1 bit sound. Crap, by today's standards. But nonetheless, passable quality speech synthesis was done in software. If similar quality programming were done on these 100 Mhz Pentiums (Pentia?), the dreams from AT&T advertisements would be here yesterday. Such a pity people aren't applying themselves.... --- email ... uwvax!gorgon!ruth!spqr , the domain path doesn't work. OBNeatQuote: "My advice to you is to become rich." -- Josh Goldfoot From: bwalzer@lark.magic.mb.ca (Bruce Walzer) Subject: Re: Parameter passing Date: Sun, 19 Feb 1995 17:57:57 GMT rant@ix.netcom.com (Ran Talbott) writes: [...] >Look carefully, and you'll see that when Henry Ford introduced the >Model T, people from Ohio started selling their horses and taking >vacation trips to Yellowstone. When you make power affordable, >people use it. As someone who is bothered by the large slow programs that seem to be the norm these days I wanted to address your points. But then I saw your analogy and decided to attack that instead. It's more fun. :-) I've talked extensivly with someone who lived through the introduction of the model T (my father the retired mechanic). I agree that the success of the model T can give some insight to the success of microcomputers. The problem is, the model T is an example of the sort of thing that made the Commodore 64 successfull, not the Pentium. People bought Model T's because it was the only car they could ever hope to afford. The Model T was a fairly bad car even by the standards of it's day. They broke down constantly. But it was a car dammit. In the same way that cars have not changed in any fundamental way from the days of the Model T, computers have not really changed all that much from the days of the Commodore 64. Speeds have increased an order of magnitude and typical memory sizes have increased maybe 2 orders of magnitude. Sounds great but inproving an algoritum can give _exponential_ increases in performance. Against that, 1-2 orders of magnitude of hardware performance increase are fairly insignificant. When I first started to do significant things with Forth I occasionally wondered why the resulting programs were so fast. After all, benchmarks showed Forth interperters to be at least 8 times slower than the fast compilers of the day. I now think the reason was that the fig-Forth I was using came with nothing. Everything had to be built by the programmer. If you have a programming environment that comes with a fast sort in a library you'll tend to use that to do sorting. The function comes for free. As a result you won't spend much time trying to find a way of advoiding having to sort entirely. When you have a really entensive set of libraries programming can be a matter of tacking the chunks together. There is less thought and understanding of the underlying algorithums. I think that this is the main reason for the vast code bloat we are seeing today. -- Bruce Walzer |Voice: (204) 783-4983 Winnipeg MB |Internet: bwalzer@lark.magic.mb.ca Canada |Amateur Radio: VE4XOR From: snf_dw@debet.nhh.no Subject: Re: Forth vs C++ (was: parameter passing & a lot else) Date: 19 Feb 95 20:41:06 MET In article , mckewan@netcom.com (Andrew McKewan) writes: > snf_dw@debet.nhh.no wrote: > : VARIABLE performance > : : re_evaluate ( address value -- ) +! ; > : : MIN ( n n -- n ) 2DUP > IF SWAP THEN DROP ; > : : single_loop_learning ( critical_input n_reps -- critical_input) > : 10 MIN 0 DO _defensive_ performance 1 re_examine LOOP ; > > Last time I tried: > > VARIABLE FOO > FOO 1 +! > > I don't think I liked what I got :-) > > Andrew. > -- > mckewan@netcom.com Right. Try: : re_evaluate ( address value -- ) SWAP +! ; instead. Thank you Andrew. Regards, David Walker snf_dw@debet.nhh.no From: boulton@netcom.com (David Boulton) Subject: Re: Truth about the GPL Date: Sun, 19 Feb 1995 20:31:17 GMT In article rideau@ens.fr (Francois-Rene Rideau) writes: > >I'd like to dispell those myth about the GPL being too restrictive to use >GNU software as a basis to one's work: > [snip] >2) only the GNU sources, not that of your software needs be made available: >if you only use the GNU software (even modified), you must provide (as in 1) >the sources for the GNU software, in their modified version which shows where >you modified it. But you can still have a binary-only distribution, as long >as all necessary sources are provided to allow upgrade of the GNU sources: >you may distribute only object code for your work, but it must then >be able to link to upgraded GNU code (e.g. you give away your .o file, stripped >from your symbols, as long as it will successfully link to a .o file generated >by new GNU sources). > I see a logical disconnect here. Forth systems traditionally do not use linkers, and do not produce .o files. (Not an absolute, but almost always true). The simple reason for this is that a reasonable Forth can compile faster than your linker will link. Certainly you can argue that in order to be a good OS citizen Forth ought to produce .o files, but that's another argument entirely. The fact is it doesn't. In order for end-users to use upgraded GNU software, they would have to reload my application on top of it from source code. Thus by using a GPL Forth system, I am forced to distribute my application source. Otherwise I would be violating the GPL "ability to upgrade" clause. >To conclude, the GNU GPL is *not* restrictive to you. It won't apply to any >work you do (unless you want that), only to the work you received with the GPL Except that as a practical matter, this is not the case for a traditional Forth system. GPL strongly assumes a C environment with COFF link files, etc. In the Forth world GPL causes an unnecessary (and unintended) burden on the application developer. >-- >-- , , _ v ~ ^ -- >-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- >-- ' / . -- >Join the TUNES project for a computing system based on computing freedom ! > TUNES is a Useful, Not Expedient System > http://acacia.ens.fr:8080/home/rideau/Tunes/ db -- David A. Boulton | knowledge is just a polite boulton@netcom.com | term for dead, Peregrine Associates | but not buried imagination. POB 1385 Redwood City, CA 94064 | -- e.e. cummings From: Johannes Teich Subject: Re: doubly linked list in 1 field X-News-Reader: ix/MBox BBS 2.2 PL5.8 by Date: Sun, 19 Feb 1995 22:41:53 GMT leiner@navhp1.nav.uni-stuttgart.de (Thomas Kleiner) wrote: > ... > > To create a doubly linked list we store the XOR of the > > predecessor and the successor in the link field. The first and > > last items in the list have a predecessor and successor of some > > special value (like zero) that we can recognise as the end of > > the list. > ... > > How do you know wether your link contains > > - a xor b, with a, b != 0 > > - a xor 0? Speaking of the creation of the linked list (i.e. adding one element), we know "by definition" that the successor is a zero. Speaking of a search, the XOR of the predecessor with the current element may eventually result in a zero, indicating the end. > ... > > To process the list we need two addresses: the predecessor and > > the current element. So, to process our example list from the > ... > > The point is: you XOR the CURRENT element and its PREDECESOR! > Above you said, you would XOR the SUCCESSOR and the PREDECESSOR. > So you create a singly linked list with a usesless XOR-overhead! No, I read it the other way: - If we search the linked list, we XOR the *contents* of the CURRENT element with the *address* of the PREDECESSOR getting the *address* of the SUCCESSOR. - If we create the linked list, we XOR the *address* of the PREDECESSOR with the *address* of the SUCCESSOR getting the new *contents* of the CURRENT element. If the *address* of the PREDECESSOR or SUCCESSOR is a zero, then it is a *pseudo address*, indicating the beginning or end of the list. (These pseudo addresses don't have contents.) > In my opinion the advantage of doubly linked lists is that you can > walk through that list back and FORTH ;) starting at any node. We could reverse the search direction at any node, however! :-) Seriously, the point is: FIND doesn't require arbitary entrance. cu Johannes Teich __ __c Internet: jgt@bbs.forth-ev.de (Murnau, Germany) -- _~\<,_ or: 100522.135@compuserve.com ______________________________(_)/_(_)__ CompuServe: 100522,135 From: djohnson@arnold.ucsd.edu (Darin Johnson) Subject: Re: doubly linked list in 1 field Date: 20 Feb 1995 01:25:36 GMT In-reply-to: Stuart Ramsden's message of 19 Feb 1995 07:07:18 GMT > > In my opinion the advantage of doubly linked lists is that you can walk > > through that list back and FORTH ;) starting at any node. > > > And this is what you can do with this scheme as well. With pointers > to the start and end of the list you can traverse in either direction. No, "any node" means more than just the head or tail. And in my experience, the only times that doubly linked lists were important was when I needed to do list operations starting at an arbitrary node. > > In a singly linked list you use the link direction to traverse without > > overhead. But finding the predecessor requires a traversal from the beginning > > of the list. > > > Nope. see above. Nope, he was right. The xor method doesn't count, since you have to remember the predecessor anyway (in a variable or on the stack). If you don't know the predecessor of a node already, and you need to find it, then with a singly linked list you must start at the beginning. > > And that is why you need two links in a doubly linked list! > > > Nope again. As mentioned in this thread before, this was a widely > used technique when RAM was precious down to the byte. Was it widely used, or just widely known about? There are so many disadvantages to it that it seems almost useless. In fact, off the top of my head, I can't think of any place where it would be worthwhile to use that technique. What sort of operations or applications would have a need for starting at a head node, traversing in one direction for awhile, and then needing to reverse? -- Darin Johnson djohnson@ucsd.edu "You used to be big." "I am big. It's the pictures that got small." From: rfergus@delphi.com (Dick Fergus) Subject: Re: Commercial 68HC16 FORTH cross compil Date: 20 Feb 1995 02:14:26 GMT X-To: Dick Fergus > We are considering using Motorola's 68HC16 rather than the 68HC11 on > our next embedded product (an ultrasonic flowmeter). We like FORTH and > use nothing else for our embedded software. Does anyone know of a a > commercial metacompiler available for the 68HC16? New Micros (214/339-2204) has a 68HC16 package (NMIX-0026) with MaxForth on board although the last version I received (1.2) was useable but required modification to make what I consider to be a workable unit. R. W. "Dick" Fergus | Astute Solutions | The eSSSence of engineering: (708) 629-5745 | Serendipity and Sophisticated Simplicity rfergus@delphi.com | From: arvindam@grad.csee.usf.edu (dAffy duCk) Subject: Forth Benchmarks Date: 19 Feb 1995 23:47:25 GMT Hi, I was hoping that someone out there could direct me to an ftp site/journal/magazine/book that contains the source code for the dhrystone benchmark and/or other benchmarks written in Forth. Thanks in advance for your help. Anil. From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: GUARANTEED CREDIT REPAIR BY LAW FIRM Date: 20 Feb 1995 10:53:09 GMT In article <3hr057$j16@newsbf02.news.aol.com>, ouversonm@aol.com (OuversonM) writes: |> An electronic Forth Dimensions, however, is an idea I've been carrying |> around in my hip pocket (ouch!) for a few months now. HTML, or EPS, or |> Acrobat, perhaps? It's most do-able if the chosen format can build the |> e-FD fairly automatically off the page layout we prepare for each issue. I would prefer HTML. |> could you |> enlighten us as to the desirability of "a publicly accessible archive site |> (like the one comp.compilers has)"? The fact that the postings expire after a short time (two weeks at my NNTP server) can discourage elaborate postings. This factor would be reduced, if old articles can be accessed and referenced at an archive. Also, sometimes I put an answer to a question together and some time later the question comes up again. Typically, I don't save my articles (ok, I should use a better newsreader that does it for me), so my answer is lost. Usually I don't like to type it in again, so I give only a short answer the the second incarnation of the question, if any. If there was an archive, I could give a reference, which would save bandwidth and increase the usefulness of the answer. Finally, an archive could reduce the questions of the type "I know this was posted some time ago, but I have not saved it then" and maybe some other questions where people would expect to find the answer in the archive, reducing noise. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen