UNBCIC@BRFAPESP.BITNET (01/05/91)
> 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.
UNBCIC@BRFAPESP.BITNET (01/15/91)
> I don't ask for more, I ask for less. If you ask for less in the CORE wordset, I may agree with you. But when you come saying that we shouldn't put CATCH&THROW (for example) in the standard because it's not in commom practice, I have to reply that we have to put (becaus e many of us need and none of us can implement it from CORE ou EXT CORE) BEFORE we have LOTS OF DIFFERENT COMMOM PRACTICE. If you want a small Forth, just forget all the extensions. Or try to explain me why you can't do that! > - Brad (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
UNBCIC@BRFAPESP.BITNET (01/17/91)
> Putting such experimental proposals into ANS Forth as WORDLIST, locals, > and CATCH / THROW where there is no clear accepted practice is > standardization by fiat. By all means, do not ``...deal with [future > additions or changes] before they exist.'' It's just that ``exist,'' in > my book, means ``reflecting clear accepted practice'' not ``someone > thought they would be useful.'' Taking CATCH / THROW as example: 1) Many of us need it. 2) Other languages have it (I am talking about C, that is invading Forth market) 3) Many of us use it. 4) If we do not standarize it now, 4.1 - Many of our programs will not be standard 4.2 - Other languagens will invade Forth market (RTC, Embedded Systems) 4.3 - When the time comes, we will have many different "commom practices". You cannot say that a feature is not standard because it isn't used by most part of Forth community. Many, important, features will never be used by most part of Forth community. > David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
UNBCIC@BRFAPESP.BITNET (01/28/91)
> >COLROW > I don't like the name. I presume it is to set a cursor position on the >screen. I prefer the arguments to be ( row col - ) rather than ( col row - >). I could go along with the name TAB for this. Why not AT? Anyway, let's >not require it! If possible, let's remove it altogether. If it must be kept, >let's not use the ugly name. I though that @ is usually read as "AT". > >LEX & the string word set. > Let's remove them altogether. Okay, okay. You can implement it yourself. But *I* *NEED* machine language speed for this feature. And, I can assure you, I'm *NOT* alone. Anyway, this is one of your most strong points. > >2DROP, 2DUP, 2OVER, 2SWAP, etc. > I don't feel strongly about where these are put. In general I feel the >less in the core wordset the better. I can live with them either place. And >yes, certainly, I would ordinarily use them even in 32-bit systems. I agree. > >ALIGN etc > Again I have no strong feeling here, so I give my default advice, although >weakly: take it out of the standard if possible; at least take it out of the >core. Take it out of the core. > >Input Stream wordset with #TIB, etc. > Ditto. See default advice above, but with lower volume. (I don't >particularly object, in other words.) We use it! So, we need it. [deleted a comment where we are both in the dark, although I have some ideas about it] > >"This Standard does not require that each word be provided in > > executable form. > This may the thing I like most (dislike least, perhaps) about the ANSI >standard. It's the way I deal with DO LOOP in Pygmy. (Thanks to Robert >Berkey) it's available in source form to load for anyone who wants it, but it >doesn't burden my system. I agree. > >ONLY/ALSO > I don't use 'em, so throw them out. Throw out WORDLIST and that other >one. Put back VOCABULARY in an optional wordset and say it is implementation >dependent. "I don't, use 'em, so...". I think there is no need for commenting. > > Toronto > I want words to be case sensitive. I want the decimal point to indicate No case sensitive, please! If you put this in the standard, then I will try to put CAPS. >double precision (not floating point). Let's standardize BLOCK as returning It indicates floating point! :-| >an address of some sort that refers to a 1024 byte area, but leave its >relationship to disks, files, and the operating system implementation >specific. Remove the file handling words from the standard altogether. I don't agree. >> ( u) FOR ... NEXT > Specify that when u is zero the body of the loop is *not* executed at all. >Otherwise, the body is executed u times (not u+1 times). Yeah. > Division > Leave it implementation dependent. NO!!! >> CATCH & THROW > Leave 'em out of the standard. I don't agree, but this is another strong point. > -- Frank (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET