Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!caen!uflorida!gatech!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: Re: what makes Forth notForth? Message-ID: <14326@medusa.cs.purdue.edu> Date: 14 Apr 91 20:35:47 GMT References: <9104121730.AA23595@ucbvax.Berkeley.EDU> Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University Lines: 30 In article <9104121730.AA23595@ucbvax.Berkeley.EDU> "William R(ay) Brohinsky" writes: >to use (say) C or assembly (outside of forth's assembly). Forth doesn't >stop being forth just because it's been extended, does it? If it does, >standardizing the language seems to be even more contradictory to me than >it used to seem, because the standard is going to be different from all >currently existing implementations, simply because it is influenced by >different vendors and users. Thus, the standard Forth won't be forth, and >then neither will the forths that had been... In the strictest sense the standard defines what is Forth. There is no way for a standard Forth to be notForth. I see no problem with there being two different standards which are both Forth. That is the way it has been since 1979, right? I do not believe you are correct in assuming that all extensions to Forth are themselves Forth. For example I could "extend" Forth until I had a Lisp interpreter. Less extreme, would a Forth with type extensions be Forth? I think so, but I am a liberal. >can't agree on exactly what makes Forth Forth, can we agree on what isn't >forth (not that difficult, I think) and when a Forth that is Forth stops >being forth? I think it is difficult as discussion here in the past has shown. When Forth stops being can only be defined in terms of some imprecise formula like: "that point at which the extensions take on a life of their own". In each case, it is personal opinion that decides when that point is reached. -- Bill