Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!rutgers!aramis.rutgers.edu!topaz.rutgers.edu!mccarrol From: mccarrol@topaz.rutgers.edu (Mark C. Carroll ) Newsgroups: comp.lang.forth Subject: Re: Forth standards - just how standard CAN you make it?? Message-ID: Date: 9 Jan 90 20:07:56 GMT References: <9001081531.AA15962@jade.berkeley.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 108 In article <9001081531.AA15962@jade.berkeley.edu> S72UZAW@TOWSONVX.BITNET (Yahn Zawadzki) writes: ]Greetings... ] I have been witnessing the arguments between you folks for/against a ]windowing standard (and other standards). I am running a forth version for a ]C128. It has a window 'interface' (the 128 does not really support windows in ]the sense Macs or Amigas do). The interface is nice and simple - because it ]uses features unique to the 128. After all - do you want your system to be ]FAST, or to be 'compatible'??? What about colours? Sound? Just how far is ]the standarization reaching..? ] As a poor student - I cannot afford the new ]Forth Standard. And until I will be making $20+ an hour, I will not buy one. ]Maybe not even then... If my forth runs on my machine only, but does it well, ]why standarize? I don't see why you people use Forth, if you expect your code ]to work on different machines. If you want to port a small application, you ]might as well rewrite it - optimize it for the particular machine... If you ]are trying to port a larger application - well, consider yourself lucky if at ]least a minor portion of the code isn't written in assembly. Use C,or Pascal, ]or whatever... We do NOT need a Reverse-Polish C! (I apologize: I do not ]have the memory for names... Whoever said this before...) ] Certain things should remain the same for us to be able to call 'it' ]Forth - by all means... But this is too much like trying to standarize system ]calls between VMS, DOS, UNIX, and whatever else.. However 'neat' an idea - but ]unrealistc and, I feel, unneeded. ]--- ]Jan (Yahn) Zawadzki ]INET: yahn@midget.towson.edu ]Bitnet: s72uzaw @ TOWSONVX ]--- The included article, to my reading, raises the following points: 1> He uses forth on a machine with a different set of abilities from the Unix machines that I want to aim a standard towards. A standard way of handling abilities that his machine doesn't really have is bound to be horrible. 2> The forth standard is too expensive, so he'll never really see the thing. The same holds for a very large part of the forth community. 3> He doesn't see any purpose for writing portable programs, for the following reason: a> if the program is small, you're better off completely recoding it for efficiency on the new machine. b> if the program is large, it's probably at least partly in assembly, which is completly non-portable anyway. So now, let me respond to these points, one by one: 1> I'm not suggesting an exhaustive standard. Things like window environments, graphics, and other machine specific features should not be covered by a standard, because they are non-standard. You include non-standard words for non-standard functions! When you use those functions, you do it with the understanding that you are no longer completely portable. 2> I agree with you about the ANSI Forth standard. To me, one of the attractive things about Forth is that it's a small, inexpensive system to work with. I bought a complete Amiga Forth system with a developers liscence for under $100. Now, they want me to pay that much for a stack of paper? Ridiculous... But what I'm proposing is a completely free standard. You want it? Fine, here's a copy for you to download... 3> Both of these complaints are, in my opinion, utter nonsense. I basically make a living porting software to Pyramid Unix boxes. I've been doing it for about 7 months, and I've worked on over 200 different programs. The packages I've worked on have ranged from 10 line Perl scripts, to multi-megabyte monstrosities like gcc, and SRC-Modula3. In that time, I've never completely recoded a package - at most, I've had to tweak a couple of routines. I've seen a total of two packages that required ANY assembly language at all - and each of them needed a total of two short subroutines. And I've never seen a package where the CPU time I can save by writing Pyramid specific code is more valuable than the time I take writing it. And finally, why do I want to use Forth at all if it's so non-portable? Simple: productivity. I can do more work in less time using a decent Forth system. The way things stand now, I totally lose that advantage because of the time that I have to spend recoding each of my programs for each of my machines. I could be more productive, and do better work with a standard Forth system. And that goal, increasing my productivity is the ENTIRE goal of the Forth as a language! In a different post, someone mentioned that screens give you the ability to do incremental compilation. I concede the point. The ability to do incremental compilation in a system like Forth, without sacrificing speed and efficiency is worthwile. I did a simple comparison: A4th on the Amiga, doing incremental compilation using screens, works very nicely on a 512K machine, without filling the machine. Tile with GnuEmacs on this pyramid requires over a megabyte just for the object files, without even considering the dataspace that Emacs requires. So, despite the fact that I don't like screens, I do see how that can be useful! -- \ Mark Craig Carroll: \ "Humanity isn't a physical description, \ Student Systems Programmer - LCSR \ it's a spiritual goal. It's not \ Rutgers University \ something we're given, it's something \ mccarrol@topaz.rutgers.edu \ we earn" -- Richard Bach, _One_