Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!bu.edu!att!pacbell.com!ucsd!ucbvax!BRFAPESP.BITNET!UNBCIC From: UNBCIC@BRFAPESP.BITNET Newsgroups: comp.lang.forth Subject: dpANS Forth Message-ID: <9101050107.AA00230@ucbvax.Berkeley.EDU> Date: 4 Jan 91 18:46:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Organization: The Internet Lines: 108 > It first appears obvious that "the three Cs" are each goals that ANS Forth > should approach as closely as possible, but a second look reveals that > significantly attaining some goals necessitates compromise on the others. We > feel it best to compromise completeness, while the current members of X3J14 > continually compromise compatibility with existing practice and apparently This is the minimalist point that I really don't understand: WHERE dpANS is NOT COMPATIBLE with the existing practice? See, not where dpANS does not represent existing practice, but where it goes against existing practice. > want ANS Forth to be a specification for the ultimate, complete Forth. It is > our belief that the vendors are responsible for providing complete Forths and Well, although this was read here many times, I'll repeat: when VENDORS provide COMPLETE FORTHS, it usually happens that THE EXTENSIONS ARE DIFFERENT. SO, I CANNOT USE this extensions. > that the standards process should provide the Forth community at large with a > standard document (not a specification) that describes the Forth that is > compatible with accepted practice. Yes. Undoublty yes. But, as my programs usually have: ONLY FORTH ALSO DEFINITIONS ^^^^ > Forth is, after all, one of the few extensible languages. It is not > necessary to put every language extension into standard Forth. It is only ^^^^^ ^^^^^^^^ ^^^^^^^^^ I don't want this, I want what I CANNOT PROVIDE (in a standard way) BY MYSELF. Examples: FILE SYSTEM \ Interface with HOST OS VOCABULARY MANAGEMENT \ Dictionary structure FLOATING POINT \ When I need this, I need this to be FAST STRINGS \ Same point ERROR HANDLING \ Enviromment manipulation > necessary that standard Forth provide the facilities for extending itself, so > that users (and vendors) can add any language extension they want. I cannot manipulate graphics and windows (in a standard way) with the tools provided by this standard, but in ALL *MY* applications I need, at least, one of the extensions above. It's definitly impossible provide a graphics extension in this release (the first) of dpANS Forth, but I'll figth for this extension in the next. > We believe that trying to specify every nook and cranny of a complete Forth > system -- especially in new areas that are outside of accepted practice -- is The main problem here is with error handling. If the standard included graphics, I don't think it would be a problem. If it provided windows, it would be a problem, because there isn't a common set of tools to manipulate windows and errors. We all do the same things with strings, files, floating point math, (graphics) and vocabularies. If they are provided as OPTIONAL FEATURES, then no one should worry about. But, some of us (the Forth community) NEED windows, NEED error handling and other features that we CANNOT write in a standard way. SO, it's better provide them in a standard than wait until we have DOZENS of different implementations, IN MY POINT OF VIEW. I know that YOUR POINT OF VIEW is not the same, but I think that, as long as these features are optional, they will not compromise the CORE WORDSET. That's is why I think that even if OPTIONAL FEATURES of the standard doesn't accomplish what is expected (by the ANS TECHNICAL COMMITTEE) from them, it can be successful in standarizing the "Forth of the last year", the CORE WORDSET, the words that the minimalists want. You CAN JUST FORGET the extensions, and work with ANS Compatible Forths that ONLY HAVE THE CORE WORDSET. > a process that is doomed to failure. Any specification written describing > what Forth ought to be, rather than what Forth is, is bound to have holes in > it. It is the usual fate of most well-meaning specification writers and it > was the fate of the process that yielded FORTH-83. X3J14 must standardize > last year's Forth, not next year's Forth. > It is the belief of the Boston FIG ANS Forth Group that our point of view, > while not well represented among the current members of X3J14, is prevalent in > the Forth community at large. We will continue to drum up support for our > point of view outside of X3J14 and continue to attempt to win over the current > membership of X3J14 to that view by submitting proposals and comments. Fine with me. If you are supporting a standard (the ANSI's Forth standard) then we are making progress. If you just say no, we are going to nowhere. > I close with a quotation from Chuck Moore that is appropriate to the > compelling sense of rightness our group recognizes in the minimalist point of > view: > ``One principle that guided the evolution of Forth and continues to guide its > application is, bluntly: Keep it simple. A simple solution has elegance. It > is the result of exacting effort to understand the real problem and is > recognized by its compelling sense of rightness. I stress this point, because > it contradicts the conventional view that power increases with complexity. > Simplicity provides confidence, reliability, compactness, and speed.'' Being simple doesn't mean being small. It's true, small is better, but I want to be as small as I can (and that can even be just the core), it's just that, many times, being too small (too simple?) is being non-competitive. > Sincerely, > David C. Petty > Boston Forth Interest Group -- American National Standard Forth Group (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET P.S.: I hope we BOTH get what we want.