Minutes of a Guest Forth RT Conference. with special guest, Elizabeth D. Rather Elizabeth D. Rather, President of FORTH, Inc, and chair of the X3J14 ANS Forth Technical Committee discusses the ANS Forth standards effort. Entire contents of this transcript copyright (c) 1990 GEnie Forth RoundTable. The contennts may be freely copied and distributed in whole or in part provided origination credit is included. Date: 01/18/90 Time: 22:36EST Attendees: [GARY-S] [[IRVING] I.MONTANEZ] [[Wheels] S.WHEELER] [D.PHILIPS2] [[Dennis] D.RUFFER] [[Kevin] APPERT] [[Len] NMORGENSTERN] [[Wil] W.BADEN1] [[Bess] PRESS16] [[Robert] R.BERKEY] [C.TING] [H.VERA] [[larry] L.FORSLEY] [L.MOFFITT2] Minutes: is here. Just us so far, relax a few is here. is here. is here. is here. mingle and chat a few - our guest is getting set up now <[Kevin] APPERT> what's new, Dennis? <[name] APPERT> oops no bored <- (intentional) meeting wil ??? <[Wil] W.BADEN1> is here. is here. Welcome lady :-) <[Len] NMORGENSTERN> Hello Elizabeth <[Bess] PRESS16> hi, all 1 minute to conference time !!! is here. LETS CONFERENCE The GEnie Forth RoundTable is very pleased to welcome ... Elizabeth D. Rather as tonight's special guest. Elizabeth was ... the first person to learn Forth, working with Chuck Moore at ... the NRAO (Kitt Peak) where Forth was developed. Elizabeth was ... one of the founders of FORTH, Inc. in 1973 where she has been ... dir./engineering, headed marketing & sales, and President since 1982. Elizabeth was a member of the Forth Standards Team from its ... inception in 1977, and has participated in all previous Forth ... Standards efforts.She was a principle instigator of the current ... effort to develop a ANSI standard for Forth, and is chair ... of X3/J14, the Technical Committee drafting the standard. ... Please welcome this evening's guest, Elizabeth D. Rather. .. .. .. ga Bess <[Bess] PRESS16> <[Bess] PRESS16> HI! In the fall of 1986, about a dozen people met at FORTH, <[Bess] PRESS16> Inc. to start an effort to produce an ANSI standard for <[Bess] PRESS16> Forth. They included three major vendors (competitors!), <[Bess] PRESS16> users from large companies (IBM, MCI, etc.), and individual <[Bess] PRESS16> consultants/experts (including Chuck Moore). All of us <[Bess] PRESS16> agreed that an ANSI standard would improve acceptance of the <[Bess] PRESS16> language, improve our ability to hire programmers or get <[Bess] PRESS16> jobs (depending on which side of the fence you're on!), and <[Bess] PRESS16> make it easier to move programs from one Forth to another. <[Bess] PRESS16> <[Bess] PRESS16> The ANSI process operates under very explicit, detailed <[Bess] PRESS16> rules designed to ensure broad participation in the <[Bess] PRESS16> development and review of any standard. Anyone can be a <[Bess] PRESS16> member of the TC who has the time and money (mostly for <[Bess] PRESS16> travel; the fees are minor in comparison), and you don't <[Bess] PRESS16> need to be a member to submit proposals or review our work. <[Bess] PRESS16> When we think we're done, our draft standard will be <[Bess] PRESS16> published for a 4-mo. public review period. We're required <[Bess] PRESS16> to respond in writing to all comments, and if we make <[Bess] PRESS16> changes as a result there will be an additional 2-mo. <[Bess] PRESS16> review. This cycle will repeat as many times as necessary. <[Bess] PRESS16> At the end our governing body will review both our standard <[Bess] PRESS16> and the process - not only must the standard be clear <[Bess] PRESS16> (etc.), but the process must be proven to be open and fair. <[Bess] PRESS16> <[Bess] PRESS16> X3J14 has 26 voting members, about evenly divided into three <[Bess] PRESS16> groups: vendors, users, and programmer/consultants. We <[Bess] PRESS16> meet 4x/yr for 4 days each to consider proposals. Most <[Bess] PRESS16> members put in quite a few hours between meetings. We have <[Bess] PRESS16> received over 600 proposals, of which about 150 are still <[Bess] PRESS16> pending. Our 11th meeting is in San Diego 1/24-27. Anyone <[Bess] PRESS16> who can come is welcome. We also have over 60 people who <[Bess] PRESS16> have ordered one or more copies of our working BASIS <[Bess] PRESS16> document, many of whom have submitted proposals. <[Bess] PRESS16> <[Bess] PRESS16> We welcome proposals from anyone. The most useful are <[Bess] PRESS16> specific proposals to make explicit changes to BASIS. Less <[Bess] PRESS16> specific comments are also welcome and will be taken under <[Bess] PRESS16> advisement, but are harder to act on and thus less <[Bess] PRESS16> effective. <[Bess] PRESS16> <[Bess] PRESS16> A standard should not try to innovate, improve, or extend a <[Bess] PRESS16> technology. Insofar as possible, we try to identify "common <[Bess] PRESS16> practice" and articulate it. Some compromise is inevitable, <[Bess] PRESS16> particularly when there are conflicts in common practice. <[Bess] PRESS16> We have added a number of optional capabilities that have <[Bess] PRESS16> been widely requested and where there is some common usage <[Bess] PRESS16> to represent. These include floating point and host OS <[Bess] PRESS16> interfaces. Others are under consideration, such as local <[Bess] PRESS16> variables. <[Bess] PRESS16> <[Bess] PRESS16> I look forward to your questions and comments. the floor is open Well, then I will ask the question that... keeps poppping up all the time, so we will have an... official definitive answer... Why can the BASIS not be posted electronically ? <[Bess] PRESS16> BASIS is a very complicated MS-WORD file using lots of formatting... <[Bess] PRESS16> to convey information... <[Bess] PRESS16> When we made the excerpts we posted... <[Bess] PRESS16> last week, it took some hours to get that... <[Bess] PRESS16> into a form we could post... <[Bess] PRESS16> The whole document is over 100 pages... <[Bess] PRESS16> We're afraid to make a text file that would be... <[Bess] PRESS16> useful would be pretty hard. thanks - rest assured jax (who conveyed apologies for.. not being here tonite ) will ask again at the TC meeting .. <[Wil] W.BADEN1> I concur with Elizabeth. In particular my proposals use special formatting and special fonts. I would not be happy to see my careful work garbled. care to comment bess <[Bess] PRESS16> We've tried hard to make it easy... <[Wil] W.BADEN1> special fonts. I would not like to see them garbled. <[Bess] PRESS16> and cheap for any one to get BASIS... <[Bess] PRESS16> over 70 people are currently getting... <[Bess] PRESS16> single copies or subscriptions... <[Bess] PRESS16> It's easy enough, I hope. <[Wheels] S.WHEELER> Is there a potential for hardware bias in ... <[Wheels] S.WHEELER> the production of the standard? I haven't ... <[Wheels] S.WHEELER> been following the effort too closely, ... <[Wheels] S.WHEELER> but I've seen several things like "These words ... <[Wheels] S.WHEELER> were developed over X years for the 8087 in ... <[Wheels] S.WHEELER> the XYZZY dialect of Proprietary-Forth, ... <[Wheels] S.WHEELER> and I think they should be adopted." ... <[Wheels] S.WHEELER> Is there a danger of things like that happening, just ... <[Wheels] S.WHEELER> because of the preponderance of PC-type computers? <[Bess] PRESS16> We've tried to remove any hw dependency... <[Bess] PRESS16> Many kinds of cpus are represented, from <[Bess] PRESS16> single-chip ucontrollers to mainframes to... <[Bess] PRESS16> Forth machines. We factored out cell size... <[Bess] PRESS16> to a single documented concept and made... <[Bess] PRESS16> some words to handle address arithmentic, etc... <[Bess] PRESS16> We've removed dependency on 2's complement arithmetic... <[Bess] PRESS16> even, altho some folks are still sorting out... <[Bess] PRESS16> what that implies... <[Bess] PRESS16> We're trying hard, in short. How about implementation dependency, token vs indirect vs direct thread.... single pfa vs multiple pfa... etc. <[Bess] PRESS16> Likewise. People are pretty sensitive about <[Bess] PRESS16> those issues. <[Len] NMORGENSTERN> A comment: I think that the $6 BASIS is cheaper than downloading <[Len] NMORGENSTERN> and printing your own, and much easier to read. <[Bess] PRESS16> Alas, it's $10 now. It's getting fat... <[Bess] PRESS16> But the principle applies. Thanks, len. <[Len] NMORGENSTERN> (Cheap even at that price!) <[Dennis] D.RUFFER> having been the one who did the conversion... <[Dennis] D.RUFFER> I should point out that it lost a lot by going to ASCII <[Dennis] D.RUFFER> the current WORD file is about 400K <[Dennis] D.RUFFER> I think the summary was less than 10K <[Dennis] D.RUFFER> the WORD file assumes specific printers, fonts, etc <[Dennis] D.RUFFER> and I sure don't wish to translate it is here. <[Bess] PRESS16> Is there interest in downloading the WORD file... <[Bess] PRESS16> bulky and hardware specific as it is? <[Bess] PRESS16> If so, I'll as next week whether they... <[Bess] PRESS16> feel ok about ga <[Len] NMORGENSTERN> I would advise <[Len] NMORGENSTERN> waiting for requests. Probably there will be only a few who might <[Len] NMORGENSTERN> want it, or maybe none. <[Bess] PRESS16> Within the TC we provide disk copies... <[Bess] PRESS16> to anyone who submits a disk. We usually <[Bess] PRESS16> get a total of 2 or 3 requests only. <[Wil] W.BADEN1> (Me, every other meeting.) <[Bess] PRESS16> It's really not that useful. I see some movement away from F83 (especially in the Controlled word set)... is this clean up, or rewrite ? <[Bess] PRESS16> Some of both... <[Bess] PRESS16> We've addressed some problems such as <[Bess] PRESS16> hardware dependency, responded to a... <[Bess] PRESS16> lot of requests for things like ?DO... <[Bess] PRESS16> and added some wordsets... <[Bess] PRESS16> We've tried extremely hard not to break code... <[Bess] PRESS16> that is FORTH83 compatible or even otherwise... <[Bess] PRESS16> common usage, but that hasn't always been... <[Bess] PRESS16> possible consistent with a need to address... <[Bess] PRESS16> some specific issue. I think the Standard document is useful... more so every new edition... and I do like it on disk. <[Bess] PRESS16> How do people feel about some of our <[Bess] PRESS16> current ccontroversies: LOCAL variables, <[Bess] PRESS16> for instance. <[Dennis] D.RUFFER> I guess this is as good a time as any... <[Dennis] D.RUFFER> so I will ask now instead of just at work... <[Dennis] D.RUFFER> what is going to happen to VOCABULARY? Is the ONLY/ALSO... <[Dennis] D.RUFFER> stuff going to be required, or alternatives <[Dennis] D.RUFFER> going to be possible? <[Bess] PRESS16> ONLY/ALSO is not required, and will not be... <[Bess] PRESS16> It's currently in an optional wordset... <[Bess] PRESS16> In fact even vocabularies themselves... <[Bess] PRESS16> are no longer required... <[Bess] PRESS16> Several members are very unhappy that... <[Bess] PRESS16> its in at all, and I know it will be... <[Bess] PRESS16> discussed in La Jolla... <[Bess] PRESS16> I doubt that any alternative will be approved, <[Bess] PRESS16> and it remains to be seen whether what's in now <[Bess] PRESS16> will stay... <[Bess] PRESS16> None of the major commercial vendors support... <[Bess] PRESS16> that method... <[Bess] PRESS16> And there are grave problems for multiuser systems. <[Bess] PRESS16> What do you folks think? <[Len] NMORGENSTERN> Is there enough uniformity of usage to warrant making Locals a <[Len] NMORGENSTERN> standard? <[Bess] PRESS16> Not really, which is why it's controversial... <[Bess] PRESS16> But a lot of people are strenuously advocating... <[Bess] PRESS16> something. What's in now is a minimal set... <[Bess] PRESS16> for a trial balloon. It's not required. I was very happy that vocabulary went it ... I think ONLY/ALSO is the best solution so far... I will be very upset if vocabulary is taken out... in the next revision. <[Bess] PRESS16> Doesn't it seem like there must be some... <[Bess] PRESS16> reason neither LMI, CSI, us, etc. is using... <[Bess] PRESS16> that method? It's because there are better... <[Bess] PRESS16> ways, depending on how you view your market... <[Bess] PRESS16> and their needs. is here. I am not familiar with their solutions... but the 8 way threaded vocabulary in polyForth is... too limiting. <[Bess] PRESS16> We're using 16 on some systems. But... <[Bess] PRESS16> the point is that no one method, at this... <[Bess] PRESS16> point, solves a really wide spectrum... <[Bess] PRESS16> of problems. We don't see how ONLY/ALSO... <[Bess] PRESS16> can be made to work in a multiuser environment... <[Bess] PRESS16> for example, and there are also... <[Bess] PRESS16> performance problems. I don't advocate... <[Bess] PRESS16> everyone using our solution... <[Bess] PRESS16> I just don't want to be forced to use... <[Bess] PRESS16> one that's inappropriate for us, either, <[Bess] PRESS16> and don't feel the tens of thousands of... <[Bess] PRESS16> users (literally) of LMI and CSI systms... <[Bess] PRESS16> should be locked out. <[Robert] R.BERKEY> You say, "how you view your market". Could you amplify on your own viewpoint. <[Bess] PRESS16> A lot of our customers don't use... <[Bess] PRESS16> lots and lots of vocabularies, <[Bess] PRESS16> but some folks do. A method appropriate... <[Bess] PRESS16> for people who use few vocabularies but need... <[Bess] PRESS16> to run fast in a multiuser environment... <[Bess] PRESS16> won't likely be fully satisfactory... <[Bess] PRESS16> for someone who uses many (just to give... <[Bess] PRESS16> an example). Not a lots of people use multiuser systems... I better shut up. ga <[Bess] PRESS16> The point is not to preclude a solution... <[Bess] PRESS16> that will satisfy a significant <[Bess] PRESS16> constituency. I would argue the Unix and PS/2 environments.. must not become the 64k barrier for this standard <[Bess] PRESS16> There isn't any 64 k barrier since we... <[Bess] PRESS16> factored out cell size. You just declare... <[Bess] PRESS16> that your system has a 32-bit cell size... <[Bess] PRESS16> in which case stacks, addresses, and... <[Bess] PRESS16> single-precision numbers are 32-bits wide. <[Bess] PRESS16> Everything else works. my point was we can not be embarrassed by ignioring.. the multi-user environment like we were the escalating ram in F83.. that's all. <[Bess] PRESS16> Sorry I misunderstood you, gary <[Len] NMORGENSTERN> I am not sure I understand why vocabularies affect <[Len] NMORGENSTERN> run-time performance. <[Bess] PRESS16> They may or may not be a problem, since... <[Bess] PRESS16> presumably each UNIX etc user has his own... <[Bess] PRESS16> Forth copy, but we run multiple users... <[Bess] PRESS16> on a single polyFORTH sharing a re-entrant... <[Bess] PRESS16> dictionary w/ private extensions. There is no problem extending F83 to multi-user... ONLY/ALSO can also be extended to multi-user system... It is not done because F83 is primaryly used by single user. <[Bess] PRESS16> To Len: it affects compile time, which is... <[Bess] PRESS16> relevant if multiple users are compiling overlays... <[Bess] PRESS16> But I realize that isn't everything. It was... <[Bess] PRESS16> just an example. <[Len] NMORGENSTERN> Thanx. <[Robert] R.BERKEY> What can be done to encourage participation... <[Robert] R.BERKEY> by those on the committee who know the sense of the committee... <[Robert] R.BERKEY> in online discussions. <[Bess] PRESS16> Greg Bailey has been on a lot,... <[Bess] PRESS16> and I think Martin has, too... <[Bess] PRESS16> Jerry Shifrin has been following us... <[Bess] PRESS16> pretty closely... <[Bess] PRESS16> We were ready for a lot more BBS discussion... <[Bess] PRESS16> of issues, and were disappointed to find... <[Bess] PRESS16> that only 3 or 4 people were discussing with us. In part because ONLY Greg and Ted were coming on to respond ! <[Wheels] S.WHEELER> Comment first, then question ... <[Wheels] S.WHEELER> Having used several versions of Forth, including ... <[Wheels] S.WHEELER> several versions of polyForth, I find that ... <[Wheels] S.WHEELER> I find ONLY/ALSO to be the most comfortable ... <[Wheels] S.WHEELER> search order control method, even though I don't ... <[Wheels] S.WHEELER> use vocabularies much. Question: what are some of the ... <[Wheels] S.WHEELER> issues involving local variables? ... <[Wheels] S.WHEELER> I have one Forth which allows them, but haven't ... <[Wheels] S.WHEELER> used them yet (no overpowering reason, yet). ga <[Bess] PRESS16> Several people, including Greg, Dean, Don C. and others... <[Bess] PRESS16> are working on a clarification to ONLY/ALSO... <[Bess] PRESS16> one version of which will be on the floor... <[Bess] PRESS16> next week. If we can iron all the problems out... <[Bess] PRESS16> it may well stay in. We'd appreciate knowing... <[Bess] PRESS16> what it is you like, and how to solve the... <[Bess] PRESS16> problem of multithreaded dictionaries nicely. <[Bess] PRESS16> <[Bess] PRESS16> To respond to Len, the big question... <[Bess] PRESS16> is whether we can do anything useful about... <[Bess] PRESS16> LOCALS in the absence of much common usage... <[Bess] PRESS16> and SHOULD we. What do you think? is here. Closing comments please <[Bess] PRESS16> Sorry I can't respond to everyone. I hope... <[Bess] PRESS16> some of you will come either to our next... <[Bess] PRESS16> meeting in La Jolla next week or another... <[Bess] PRESS16> one. If you need schedule or particulars... <[Bess] PRESS16> please call or fax us. <[Bess] PRESS16> I don't do this often, but it's been fun. <[Bess] PRESS16> Cheers Elizabeth - on behalf of the GEnie Forth RoundTable .... 'Thank you' very much for sharing your insight tonight, ... and providing us with a better handle on X3/J14's mission. All may stay and chat, but this conference has officially ended. === End of Steno notes. ===