RAYBRO%HOLON@UTRCGW.UTC.COM ("William R Brohinsky", ay) (04/12/91)
Bill Bouma replied to Pete Hartman with: [some text deleted] What I am trying to say is that to do this right, unix commands should be indistinguishable from Forth words. There should be no special syntax involved. Tell me how to do this, and I will send you fsh. I think if you try doing it, after a while you'll notice you no longer have the same Forth that everyone else in this group has. In fact it will be difficult to convince some of them that what you have even is Forth. ;^) [other text deleted] Bill, I doubt that I have `the same Forth that everyone else in this group has'. Somehow, that seems an incongruous statement: Forth is extensible, so as soon as you make a tool in it, and accept that tool as part of your Forth, your forth is no longer the same forth... I guess what I mean is this: I am using MAX-forth right this minute. In order to make it worth using at all, I've added extensions to the language. Some are rather trivial, some are much more far reaching. Starting from the same base, with my extension code, your copy of MAX-forth could be exactly like mine, but you probably wouldn't want that. fsh (were it possible) would require changes to forth, but these changes can (could they be made at all) be made in forth to forth, without having 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... Of course, none of this answers Pete Hartman's question of `is it possible', but it does raise the converse question from `what makes Forth Forth,' which has gained much air time. I'd therefore like to toss this one out to the community at large: If we 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? raybro
bouma@cs.purdue.EDU (William J. Bouma) (04/15/91)
In article <9104121730.AA23595@ucbvax.Berkeley.EDU> "William R(ay) Brohinsky" <RAYBRO%HOLON%UTRCGW.UTC.COM@SCFVM.GSFC.NASA.GOV> 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 <bouma@cs.purdue.edu>