Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!SUN.COM!wmb From: wmb@SUN.COM Newsgroups: comp.lang.forth Subject: Re: Forth, Creativity, Snobbishness, and the Future Message-ID: <9001040122.AA11294@jade.berkeley.edu> Date: 3 Jan 90 01:44:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Forth Interest Group International List Organization: The Internet Lines: 82 > 2> Let's try to develop some sort of STANDARD ENVIRONMENT! This > should include, at minimum: > a> Recursion > b> File I/O > c> Strings > d> Structures > And we should at least consider the following: > a> Local Variables -- Nice, but kind of against the spirit > of Forth. > b> Multi-tasking -- Also nice, but might be hard to come up > with a portable way of implementing it. Many people agree with this desire, including many people on the ANSI committee. Some of these things are already part of the draft ANSI standard. In particular, file I/O, strings, and local variables. I think recursion is in there (I don't have my copy handy, so I can't say for sure). The following structure definition will work on just about any Forth system. It is so simple and flexible that I rarely feel the need for standardizing anything fancier. Most of the "built-in" structure mechanisms that I have seen in various systems strike me as being "overkill", and everybody seems to overkill in a different direction. : struct ( -- offset ) 0 ; : field ( offset size -- offset' ) ( Input stream: name ) create over , + does> @ + ; : byte ( offset -- offset' ) 1 field ; : short ( offset -- offset' ) 2 field ; : long ( offset -- offset' ) 4 field ; Usage example: struct ( dma-registers ) long >address short >count byte >control constant dma-reg-size hex f100 constant dma \ Base address of DMA chip \ Or you could allocate a structure instance with: \ create dma dma-reg-size allot : set-dma ( address length -- ) dma >count w! dma >address l! DMA-GO dma >control c! ; > 3> Scrap screens! I find that whole screen model to be one of the > most obnoxious, inconvenient, intolerable "features" of Forth! Many people, again including many ANSI team members, also agree with this. However, there are also a number of people who are just as vehement in favor of screens. At the latest ANSI meeting, a battle about this almost escalated into armed warfare. The current compromise position (which I believe is not likely to change) is that a standard system: a) Need not have any disk I/O at all (e.g. embedded systems) b) May have BLOCK (screen) input c) May have file input, and if it has files, the vendor must support BLOCK too. BLOCK support does not necessarily have to be always loaded. The vendors in the file camp accept this compromise, because they can provide a loadable implementation of BLOCK that a user can load if he wants. All it costs is a little space on the distribution disk. They pretty much all do it already, anyway. Further discussion of BLOCKs vs files is probably not productive; everybody already knows all the arguments on both sides. Mitch