Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!munnari.oz.au!uhccux!dunn From: dunn@uhccux.uhcc.hawaii.edu (John Dunn) Newsgroups: comp.lang.forth Subject: Re: Forth, Creativity, Snobbishness, and the Future Message-ID: <6077@uhccux.uhcc.hawaii.edu> Date: 8 Jan 90 19:22:57 GMT References: <6047@uhccux.uhcc.hawaii.edu> <6622@tekgvs.LABS.TEK.COM> Reply-To: dunn@uhccux.UUCP (John Dunn) Organization: University of Hawaii Lines: 23 In article <6622@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >In article <6047@uhccux.uhcc.hawaii.edu> dunn@uhccux.UUCP (John Dunn) writes: >>Lisp editors, for example, are smart editors that allow you to >>compile individual functions. I would applaud such a Forth editor, > >I don't think a block editor has anything to do with this. I wrote a >Forth system about 1982 that allowed this. > >BTW, I prefere blocks for >source code because it provides the necessary dicipline to keep definitions >short. > Keeping definitions short is a crucial dicipline in Forth, no argument there. But using block screens for that reason seems a little extreme (of course that was the original point, so I guess you got me there too). The Brief-type editors that pop you back to where the error was is a step in the right direction, but they really aren't the same as the EMACS-type smart editors found in Lisp that are closely wedded to the entire process. The one you describe sounds close - I wish you had persued it. Gotta admit though, if ascii text editors were unavailable for Forth I wouldn't miss them much, but if it were the other way around, I'd be quite upset. -John Dunn