wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/02/90)
> John Wavrik writes ... > If Forth retains is main asset, the ability of users to add major > features to the language, the dispute between "minimalists" and > "kitchen sinkists" disappears. I disagree. As a "kitchen sinkist", I believe that many people choose not to use Forth because it is lacking so much. Certainly it is *possible* to "roll your own" major features, but who has the time, either to write the feature packages or even to dig around on bulletin boards in hopes of finding quality public domain implementations of the needed packages? Important extension packages MUST be standardized at the "official" level. If not: a) Most people won't know of their existence b) There will be broad and fundamental differences between implementations of packages purporting to do the same thing c) Extension packages will not be supported, or else each vendor will do something different. File system interfaces are a case in point. It became clear to me in 1982 that Forth desperately needed a portable file system interface package, similar to C's "standard I/O". So, I wrote one in a very portable fashion, published the spec and the implementation in the FORML proceedings, placed the code in the public domain, and proceeded to announce its existence at every Forth meeting and convention that I attended for the next n years. (This was before the popularity of networks; even so, what percentage of Forth users read one of these networks? I bet it's a small percentage) Do most people know about it? No. Have other incompatible file interface packages been "reinvented"? Yes. Do most vendors now supply file interface packages? Yes. Are those vendor-supplied packages compatible with one another? No. Consequently, in any real sense it is currently not feasible to write a standard Forth program that accesses files. That is why, when somebody recently asked for a program to convert Forth screens into text files, all of the responses (except my own) were WRITTEN IN C. Claiming the *possibility* of user extensions ISN'T GOOD ENOUGH. The good news is that ANS Forth DOES standardize a number of much needed extensions, including files, floating point, memory allocation, strings, local variables, extended memory access, run-time search order control, and error handling. ANS Forth will make the situation a lot better, if it is not already too late. Mitch Bradley
dwp@willett.UUCP (Doug Philips) (06/04/90)
In <9006011903.AA03706@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > Claiming the *possibility* of user extensions ISN'T GOOD ENOUGH. > > The good news is that ANS Forth DOES standardize a number of much needed > extensions, including files, floating point, memory allocation, strings, > local variables, extended memory access, run-time search order control, > and error handling. > > ANS Forth will make the situation a lot better, if it is not already too > late. Actually it seems to be as if you and Mr. Wavrik are not really in disagreement. There is nothing about a clean "core" system that would prevent ANSI from declaring various "extensions". X3J11 (the 'C' effort) did something along those lines by declaring various name spaces. Identifers were "allocated" to various groups (users and implementers) on the basis of their leading characters. The only anomaly in this was the preexisting libraries. They used identifiers which would otherwise be left to the users. Additionaly X3J11 specified various behaviours that the compiler 'could do' and but which the user must not assume any knowledge of, when composing conforming code. Forth may be just too much of an anarchy for an approach like that to work, though. -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/05/90)
> > So, "NOT" is no longer a standard word (and in actual fact, > > "NOT" has not been portable since 1983). > > This is not the case. The Forth-83 Standard was quite specific. ... > There is no ambiguity on this point -- all standard systems behaved > in the same way. Oops, I should have made my point more explicitly. It is true that the Forth-83 Standard is explicit about how NOT behaves, however !!! Several important vendors, representing a significant fraction of all Forth systems, DID NOT IMPLEMENT FORTH 83 AND STILL HAVE NOT DONE SO. So, NOT has been quite portable among Forth-83 systems, but not across the board. I still see a lot of code published for FIG-Forth, MVP-Forth, MMS-Forth, and Mac Forth, and that code is probably closer to Forth-79 than to Forth-83. The ANS committee apparently wishes to avoid that splintering effect this time around, and thus has bent over backwards to accomodate factions with strongly-held opinions, such as how divide works and what NOT does. We may hope (perhaps over-optimistically) that conversion to ANS Forth will be more-or-less universal in the medium term. > the code will not run -- IT IS BROKEN. Moreover, it is broken in a > serious way -- it can only be fixed by rewriting code. This conclusion is incorrect, because the assumption stated in the following paragraph is incorrect. > The original code used NOT (as was the Forth-83 Team's intent) to > function in both a boolean and bitwise sense. For this to be possible on > the new system, standard words leaving a true flag would have to leave a > number with all bits set. I would assume that those dissenting members > of the ANSI team object to this stipulation (since most Forth-79 and > FIG-Forth used 1 for true). ANS Forth "true" flags DO have all the bits set. I am not aware of any controversy on this issue. Perhaps it died out before I joined the committee, but there has been no evidence of any lately. I reiterate: : NOT INVERT ; added to the start of the application does the right thing for a Forth-83 program. > Current code *will* be broken by the proposed Standard. Undoubtedly, but not by NOT . Mitch Bradley
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/06/90)
> By making multi-line comments part of the standard, you prevent the use of > a simple get-a-line-and-feed-it-to-interpret style of file loader. Not true. The file loader semantics IS specified as "get-a-line-and-feed- it-to-interpret". "(" is responsible for refilling the input buffer as needed until the closing ")" is encountered. That is why the QUERY function (which refills the input buffer) has been extended to apply to text files in addition to the keyboard. > If you can't get the semantics of divide right The semantics of divide, in all its flavors, ARE right. It is just the spelling that is in question. > What's wrong with: > > foo() > { > jmp_buf bar; > ... > } It is useless because the name scope of "bar" is the definition "foo", so any setjmp()/longjmp() pair using "bar" would have to be entirely contained inside "foo". It is nearly always the case that setjmp() and longjmp() are called from different procedures. There is little reason to use a setjmp()/longjmp() pair inside a single procedure, because other control structures like "while" or "goto" work better within a procedure. Mitch Bradley
dwp@willett.UUCP (Doug Philips) (06/10/90)
In <9006051307.AA07733@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > Oops, I should have made my point more explicitly. It is true that > the Forth-83 Standard is explicit about how NOT behaves, however > > !!! Several important vendors, representing a significant > fraction of all Forth systems, DID NOT IMPLEMENT FORTH 83 > AND STILL HAVE NOT DONE SO. > > So, NOT has been quite portable among Forth-83 systems, but not across > the board. I still see a lot of code published for FIG-Forth, MVP-Forth, > MMS-Forth, and Mac Forth, and that code is probably closer to Forth-79 > than to Forth-83. This seems obvious! After all, if everyone had been using Forth-83, would there have been a need for a new standard? (Or would it just have gone much more smoothly and therefore have been over already?) Did the TC actually try to get statistics on what Forth systems are out there, and how many? Did the TC just rely on the vendors to blow their own horns? How many members of the TC are not associated with Forth Vendors, or are not FIG officials? -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
dwp@willett.UUCP (Doug Philips) (06/10/90)
In <9006051819.AA27558@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: [Is the '> > ' Peter da Silva? -dwp] > > What's wrong with: > > > > foo() > > { > > jmp_buf bar; > > ... > > } > > It is useless because the name scope of "bar" is the definition "foo", > so any setjmp()/longjmp() pair using "bar" would have to be entirely > contained inside "foo". It is nearly always the case that setjmp() and > longjmp() are called from different procedures. There is little reason > to use a setjmp()/longjmp() pair inside a single procedure, because > other control structures like "while" or "goto" work better within a > procedure. True, the identifier "bar" is only in scope for the definition of foo. That doesn't prevent foo from passing the address ('&bar' or 'bar' depending on how 'bar' is defined (structure or array)) of bar to a another function. (personally I find a "malloc"ed array of jmp_buf's treated as a stack of recovery points more useful than the potential uses of "foo", but that's just me.) -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
aph@compulink.co.uk (Andrew Haley) (08/14/90)
The following is a proposal I intend to send to the ANS
Forth Technical Committee in a few days time. Anyone who
wishes to comment on this, please do so soon; it might save
me some embarrassment! I will post a message detailing the
reply I get after I send this.
Andrew Haley
Software Manager
Computer Solutions Ltd.
Canada Road
Byfleet
Surrey KT13 8HT
England
13th Aug 1990
ANS ASC X3/X3J14 Forth Technical Committee
111 N. Sepulveda Boulevard
Manhattan Beach
California 90266
The following are proposals for the Technical Committee;
please note that all comments below refer to BASIS 12.
1. The word PAUSE should be defined as doing nothing
(i.e., having no execution semantics) but having
multiprogramming impact.
2. In systems that implement CATCH and THROW, there should
be no words predefined in the system which QUIT; all
exceptions should be raised by THROW. This way, a portable
application can be written in such a way that a user will
NEVER be dumped into the Forth interpreter.
3. The definition of WITHIN is incorrect in that it
assumes a particular overflow behaviour for - (minus) which
is not specified by the standard.
4. The word " (quote) should be removed from the non-
portable word set (p119).
5. The definition of floating-point numbers as rationals
is unnecessarily confusing. It would be more helpful to
define floating-point numbers as an implementation-defined
subset of reals.
6. It is not specified whether the word EVALUATE is "state
smart". If EVALUATE is executed by a word (presumably
defined as IMMEDIATE) whilst the system is compiling, does
it compile execution tokens into the dictionary or execute
words? If EVALUATE is not "state smart", there seems to be
no way to specify the compilation behaviour.
7. There seems to be no way to use ?DO with a negative
step in +LOOP so that the loop executes just once. I don't
think that with the existing FORTH-83 loop structure there
is anything that can be done about this, but this somewhat
odd behaviour should be documented somewhere, perhaps in
?DO.
8. There are many Forth systems which compile for a small
target computer which does not, itself, have a dictionary,
(or an interpreter) but relies on another computer to
compile for it. Some of these (such as chipFORTH) have full
support for interaction. These are an important (and
increasing) part of the market for Forth systems. It would
be unwise to exclude them from the standardisation process.
I propose that there should be a recognised "Run Time
Subset" of ANS Forth for such systems. This should specify
a MINIMUM set of core words for these systems.
The subset I propose is:
! ( * */ */ */MOD + +!
+LOOP - / /MOD 0< 0= 0> 1+
1- 2! 2* 2/ 2>R 2@ 2DROP 2DUP
2OVER 2R> 2SWAP < = > >R ?DUP
@ ABS ALIGNED AND BEGIN C! C@ CELL
+ CELLS CHAR CHAR+ CHARS D+ D<
DEPTH DNEGATE DO DROP DUP ELSE EXECUTE EXIT
FILL HERE HOLD I IF INVERT J
LEAVE LITERAL LOOP MAX MIN MOD MOVE
NEGATE OR OVER R> R@ RECURSE REPEAT ROT
S>D SWAP THEN U< UM* UM/MOD UNLOOP
UNTIL WHILE XOR [ ['] [CHAR] ]
In addition, the following words may be used, but only
outside a definition, i.e. they may not be used between :
and ;
' , : ; ALIGN ALLOT C,
CONSTANT CREATE VARIABLE
Clearly this subset lacks some of the power of Forth, but it
specifies a means of partial compliance for these important
systems which have no way to comply fully with the standard.
It is unlikely that any application program written for such
a microcontroller-like system will be fully portable,
because of I/O hardware dependencies. However, this subset
defines a minimum subset which a Forth vendor must supply.
Unfortunately, there seems to be no portable way to allow
compiling and defining words. Despite this fact, it is
better to have the minimum commonality which this list
represents than none at all.
9. PICK should be moved from the CORE to the EXT CORE word
set.
10. [ has been lost from the left hand column on page 110.wmb@MITCH.ENG.SUN.COM (08/21/90)
> I believe it is through this method that they are able to determine that > the Forth-83 standard was NOT a success as it is NOT used by almost all > the customers of the vendors, and therefore the current committee cannot > merely update the Forth-83 standard with minor changes. ... > Without this countability it would be much more difficult to determine > that Forth-83 was so terribly unacceptable to so many people. > ... this method of counting excludes > the few users of L&P's F83 (and the few users of its few derivatives such as > F83X, Y, etc & F-PC), some of which probably DO find the Forth-83 standard > acceptable. Surely, and the sample made up from the vendors' to represent > all of them. a) F83 and F-PC users are not ignored. Far from it. b) 3 very respected Forth vendors (Creative Solutions (MacForth), MVP, and Miller Microcomputer Systems) are still using Forth 79. Together they represent a significant Forth user community. Neither side is being ignored. Where the committee has "picked one side in favor of the other side", it has always chosen in favor of Forth 83. In other cases, the committee has tried to accommodate both groups. > Of course, in the previous paragragh I'm not being entirely serious, or fair. The ANS Forth committee does not have the luxury of not being fair. Mitch
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (08/26/90)
> It was natural to ask if some agreement was reached on a mechanism for > vectored execution. The answer is no. The answer is that there is a simple, portable, reasonably efficient way of implementing vectored execution in terms of ANS Forth words. Many people claim that is sufficient rationale for not adding additional words to the standard. Those people who are interested in a small standard use this argument frequently. If you couldn't reasonably define vectored execution in terms of the standard, then that would be a strong argument for adding the capability. But you can. > BEGIN BL WORD DUP COUNT " )IF" $= <> > WHILE COUNT EVALUATE POSTPONE IF > .. > This is to be used in the form IF( c1 e1 ... ck ek )IF > IF( is IMMEDIATE, so it is now executing. ... EVALUATE > should now evaluate this string -- i.e. execute the condition c1 -- > rather than compile it into the dictionary. It is executing *in compile state*, so EVALUATE will compile it into the dictionary rather than execute it. In fact, Basis 12 tweaked the description of EVALUATE in an attempt to make it clear that EVALUATE does not change STATE . Whether it succeeded or not is anybody's guess, considering the difficulty of writing unambiguous English and the propensity for humans to apply their own preconceptions and world model to what they are reading. Dennis Ruffer's POSTPONE solution works too. So the answer to question 3 is definitely "can do". > ARE GLOSSARY DESCRIPTIONS SUFFICIENTLY CLEAR AND UNAMB- > IGUOUS? Would two people who implement a word based on > the glossary description produce words that execute in the > same way under all conditions? Who is to say? The only way to be 100% sure is for a lot of people to implement it. We will know when we know. The committee is extremely concerned about this, as evidenced by the large proportion of proposals concerned solely with the clarity of the wording of Basis. If anybody has problems with particular wording, they are encourage to submit specific proposals suggesting improved wording. I assure you that such proposals are acted-upon with high priority, and have a high probability of passing. Taken literally, the answer to this question is certainly no, considering the high probability that someone will simply screw up (otherwise software wouldn't have bugs!). Mitch
wmb@MITCH.ENG.SUN.COM (09/07/90)
> We've established that most users will need to do considerable > rewriting to have existing code comply with the proposed ANSI > Standard. Have we indeed established this? We have seen some examples of code that is not compilant, but we have not established the extent to which such code exists in the applications of "most users". > And we've established that tools that they have used in the past will > not be available -- so it is just a matter of learning about what newer > and better tools the ANSI team has provided. Have we indeed established this? Forth system vendors will continue to provide at least the same level of tools that they currently provide (trust the marketplace to ensure this), and users will still be able to create implementation-dependent tools as they do now. > "You used to create control structures, in-line data handlers, > etc. by storing addresses in the dictionary, using your access to > the IP, etc. -- now, under the proposed ANSI Standard, you will > be able to accomplish the same things in the following way: You used to create (etc. etc.) using your *implementation dependent* access to the IP, etc. ANS Forth won't make these techniques portable, but neither did it create the existing portability problem. Like it or not, these techniques have never been portable except among selected subsets of Forth systems. Even in the halcyon days of FIG Forth, there were other Forth implementations that did things differently. Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (09/07/90)
> >> ARE USERS ALLOWED TO ASK QUESTIONS YET? > > > > Of course John! .... > > I was reacting to the fact that a reply to my questions about how > (or whether) things could be done was titled "ANS BASHING". The "ANS Bashing" title did not appear on a reply to your questions. Your questions were answered calmly, respectfully, and thoughtfully. The "ANS Bashing" title was applied to your flat denial of all points of the reply, in which you attempted to use the answers to your questions as "proof" that the standard is seriously flawed, and claimed (incorrectly) that one of the solutions presented does not work. This claim was not posed as a request for clarification, but as a statement. Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (10/19/90)
>> The point I was making is that even when all previous >> implementations _agreed_, the ANSI team has changed things. > Offhand? How about WORDLIST for VOCABULARY, and ADDITIONS for DEFINITIONS? > (I realize that search orders vary from implementation to implementation, but > the acts of declaring and invoking a vocabulary are remarkably constant across > Forth standards.) Turns out not to be the case. Creative Solutions implements VOCABULARY with a numerical argument on the stack. Not only that, but also the question of whether new vocabularies "chain to Forth" or "chain to their parent" or are independent. That is why VOCABULARY was changed to WORDLIST. As I recall, there was some problem about DEFINITIONS too, but I don't remember the details. I can't think of ANY example where something has changed when all previous implementations agreed. > I would argue that CHAR is an example, although I realize ASCII was never > formally adopted anywhere -- it was just a widely accepted informal standard. > (A pity those aren't recognized more often.) ASCII was changed because there is substantial sentiment against ruling out EBCDIC machines and non-US character sets. > ... and why C and Pascal were never objects of their ridicule? [ about > lack of error recovery ] C has error recovery (setjmp()/longjmp()), and a great many significant C programs use it. > BTW, I note that the proposal/comment form is no longer included in the BASIS > distribution, and hasn't been for some time now. Had I not pestered Martin > Tracy at a FORML conference, I wouldn't know how to submit a proposal to the > TC. Just a thought. It would be nice if the proposal form were still included; its omission is probably an oversight. I can assure anyone who may be considering writing a proposal that the form is really not necessary; just write down what you want to say and send it in. The detailed format is not important. From a practical standpoint, what DOES matter is conciseness. Long-winded proposals just do not fly. One page (one side) is best, 2 pages max. If you have a lot of related stuff, break it down into several proposals and note that they are related. I know this is counter-intuitive, but I guarantee that it is VERY important. Trust me. > Sounds to me like some members of the TC are indulging in a little extortion. > "Give me what I want, or I'll torpedo this standard!" Is this the model of > behavior you wish to promote? Are these the kind of people who should decide > a national standard? ... > IMHO, had there been fewer people who were hot to get their pet ideas into the > standard, this could have been accomplished sooner. Well, I guess I'm as guilty of this as anybody, especially since I authored the CATCH/THROW proposal. a) It is difficult to unilaterally engage in this kind of extortion. Most such "burning issues" garner the support of at least several committee members. If the sentiments of the committee are clearly against you, most people (myself included) generally back down. A successful proposal has to win by a "substantial majority"; this usually means about 80% or more in favor. b) The people on the committee are those who care enough about Forth to pay the price, in dollars and time committment and emotional stress (don't downplay the stress factor; it is real and significant). I have paid my committee "dues" out of my own pocket and my own vacation time, so I feel entitled to vote as I see fit. My "pet ideas" are successful only to the extent that I can convince 15 other independent-minded people that they are right. So far, my "pet ideas" have been in the form of OPTIONAL extensions that other successful languages have had for many years, and which Forth needs (based on my own personal experience, the existence of many papers describing various implementations of such extensions, and the requests of many of my customers). Mitch Bradley, wmb@Eng.Sun.COM
UNBCIC@BRFAPESP.BITNET (10/19/90)
Date: Tue, 16 Oct 90 03:16:44 GMT From: ForthNet articles from GEnie <dsl.pitt.edu!pitt!willett!ForthNet@PT.CS.CMU.EDU> Subject: What are the existing standards? Category 10, Topic 1 Message 21 Mon Oct 15, 1990 B.RODRIGUEZ2 [Brad] at 07:25 EDT >>> The point I was making is that even when all previous >>> implementations _agreed_, the ANSI team has changed things. >> Can you give me an example Brad? > Offhand? How about WORDLIST for VOCABULARY, and ADDITIONS for DEFINITIONS? > (I realize that search orders vary from implementation to implementation, but > the acts of declaring and invoking a vocabulary are remarkably constant across > Forth standards.) Really? Don't you think that 30 ( words ) VOCABULARY ONE and VOCABULARY ONE are something different? Well, starting from this I could put the whole Standard down saying that in Gra-Forth this or that is different... I would like to know how commom are the non-standard VOCABULARYs. But I don't know everything. If this proposal passed all the Committees and SubCommittees, they probably are right. I don't know, also, any DEFINITIONS that isn't like 79/83. But.. > I would argue that CHAR is an example, although I realize ASCII was never > formally adopted anywhere -- it was just a widely accepted informal standard. > (A pity those aren't recognized more often.) Yes. I agree with that. But then, if you say (write?) ASCII " you know what you will get, because " in ascii is 34. It makes more sense writing CHAR ", don't you think so? Well, your answer to this is obvious, but do you think that ASCII is more commom than CHAR? *REALLY* more commom? >> ...are you willing to continue having Forth laughed at for its >> lack of error recovery? > Really? Can you tell me who's been doing this laughing, and why C and Pascal > were never objects of their ridicule? I've heard Forth criticized for many > reasons, but this was _never_ one of them. I agree with this. But I would like to have more than C or Pascal (otherwise I would not be using Forth). And such things must be Standard, or your program will never be ported. I think that Ctach&Throw must be put in Future Directions... >> Some members of the TC are unwilling to accept a standard that >> does not address this issue... ...either the issue is resolved, >> or we will not have a standard. It's as simple as that. > Sounds to me like some members of the TC are indulging in a little extortion. > "Give me what I want, or I'll torpedo this standard!" Is this the model of > behavior you wish to promote? Are these the kind of people who should decide > a national standard? *I* hope not. >>> Even minor variations in the implementation details can radically >>> affect the usefulness of a construct. [Examples] >> I'm sorry, I can not group the changes you mention in the 83 >> Standard as "minor". They have major impact to applications. > Sorry, Dennis, I should have put "minor" in quotes originally. This is > exactly the point I was trying to make -- seemingly trivial details in an > implementation can have major applications impact. Only I wasn't referring > just to the problem of updating old applications code; I was saying that even > in _brand_new_ constructs, little things make a big difference, and these are > hard to see without experience. If you were designing a new language, would > you make "true" -1 or +1? What would you have done if you hadn't experienced > both in the Forth community? Yeah. >> Are there any volunteers who would record the debates...? > Oh, I can imagine what a TC meeting is like -- I've been involved in similar > efforts. I was just saying that, so long as TC meetings are conducted and > reported as they have been, the only option many of us have is to protest and > criticize their decisions after the fact. > BTW, I note that the proposal/comment form is no longer included in the BASIS > distribution, and hasn't been for some time now. Had I not pestered Martin > Tracy at a FORML conference, I wouldn't know how to submit a proposal to the > TC. Just a thought. > The "proposal log", a useful innovation which appeared briefly around BASIS10, > is now gone too. *Sigh* I quoted this because it's true and I agree with this. >> The TC is not in the "public debate" mode yet. ??? Again, I agree with the following: > Then why this category on GEnie? :-) Seriously, if you don't get the debate > accomplished now, you'll be in for a REALLY rough ride later, when the dpANS > is officially published for comment. Which you already know. And more, if it's not a public debate, why you are reading about it, anyway? >> ...their goal is to get the dpANS publish next year. > IMHO, had there been fewer people who were hot to get their pet ideas into the > standard, this could have been accomplished sooner. Shucks, I was reasonably > happy with BASIS8. (Or was it BASIS6? :-) ) So am I with BASIS 12 (although I still don't know how to LOAD a text file, only how to know if my program is being LOADed from one :-) >> Anything else, either new features or resurections of past >> resolutions, will be given little consideration. > Does this mean it's too late to comment on BASIS12? According to MINUTES.13, > the BASIS12 document has been officially adopted now. Although no one saw it > but the TC. (Grumble.) ??? THIS I didn't understand. What, then, I have, that's supposed to be BASIS 12 text? Sent as UUENCODED file in the FIGI-L (at Bitnet), and by mail (not e-mail)? > - Brad It's good to hear someone who do not agree with me (although I agree with most of your ideas): it's easy to perceive my errors... (8-DCS) Oh, one more thing: This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp Thanks, Doug.
UNBCIC@BRFAPESP.BITNET (10/19/90)
Date: THU, 18 OCT 90 21:31:11 EDT From: wmb@MITCH.ENG.SUN.COM Subject: ANS Forth >> I would argue that CHAR is an example, although I realize ASCII was never >> formally adopted anywhere -- it was just a widely accepted informal standard. >> (A pity those aren't recognized more often.) > ASCII was changed because there is substantial sentiment against ruling > out EBCDIC machines and non-US character sets. Although I agree with CHAR, I think I can talk about non-US character sets. Nothing again the seven-bits ASCII, but we use one more bit. OK with EKEY, but I just can't write my name in an EXPECTed line... >> ... and why C and Pascal were never objects of their ridicule? [ about >> lack of error recovery ] > C has error recovery (setjmp()/longjmp()), and a great many significant > C programs use it. Well, I have already answered this.. >> BTW, I note that the proposal/comment form is no longer included in the BASIS >> distribution, and hasn't been for some time now. Had I not pestered Martin >> Tracy at a FORML conference, I wouldn't know how to submit a proposal to the >> TC. Just a thought. > It would be nice if the proposal form were still included; its omission > is probably an oversight. > I can assure anyone who may be considering writing a proposal that the > form is really not necessary; just write down what you want to say and > send it in. The detailed format is not important. Oh, yes? This is new for me. And for many ones who don't have E_MAIL access or just don't read 500Kb of messages a week. (In fact, I have one or two Mb of old mail that I never read in my computer. Only from FIGI-L.) Maybe you can make it clear to everyone, ok? > Mitch Bradley, wmb@Eng.Sun.COM (8-DCS), UNBCIC@BRFAPESP.Bitnet
wmb@MITCH.ENG.SUN.COM (12/18/90)
> Adding tons of whizzy new, but > _optional_, features to Forth might be OK as long as we can all agree to the > extent to which they are optional and can allow for minimal Forths to still be > standard. To be labeled as a ANS Forth "standard system", an implementation must have all the CORE words, and even those CORE words need not always be present in memory. It suffices to provide them is source or "demand load" form, so long as the system documentation tells the programmer how to get them in. There are presently 135 CORE words, 3 more than the number of required words in Forth 83. A system may choose to also provide some subset of the CORE EXTENSION words. A system may choose to provide one or more optional wordsets (e.g. floating point, file access, local variables, search order, etc). If a system claims to have a particular optional wordset, it must have the entire base portion of that wordset, and may include a subset of the extension portion of that optional wordset. This doesn't prevent an implementor from including selected words from an optional wordset. However, you can't label your system as "having the wordset" unless you have the complete base wordset. You can say, e.g. "includes F+ , F- , F/ , and F* from the Floating Point wordset", but in order to say "includes the Floating Point wordset", you must have the complete set. It has been argued that market pressures will force vendors to include every optional word. This may be true in "big system" environments where those optional words are useful, but I don't think it is true in general. I certainly don't plan to include the text file access wordset in my products that run on embedded systems without mass storage. Most successful Forths for the "big system" environments already include the functional equivalents of the optional wordsets, and I think it is a good time to try to standardize the names and meanings of these words. (10 years ago would have been an even better time). Mitch Bradley, wmb@Eng.Sun.COM
a684@mindlink.UUCP (Nick Janow) (01/11/91)
dcp@world.std.com (David C. Petty) writes: > The advocates of a ``less is more'' ANS Forth are not unwilling to > compromise, it's just that some of us: > a) would like a standard that is more layered so that the Core > Word Set is truly the _kernel_ of Forth and What are your expected applications that require only the minimum kernel? ANSI Forth is supposed to make portability--both of programs and programmers--easier. If you need a minimum-kernal Forth for some special application and know that portability isn't a problem, then no one will force you to use the full ANSI Forth wordset. Think about what you really fear: will it actually make a difference in actual use? > b) fear adding (relatively) new and untried ``improvements'' to > ANS Forth, because that may (will) lead to the types of > problems we experienced with FORTH-83 and it may (will) > prevent adoption of the (possible) _best_ versions of > language features that may be just around the corner, but > incompatible with what we adopt in ANS Forth. Those language features will be here "real soon now"? If so, what computer will you run them on? You shouldn't buy a computer now, since a better one is "just around the corner". There will always be something better "just around the corner". The ANSI standard has to deal with what is available today. Where possible, it should allow for future additions or changes, but it can't deal with them before they exist. > It has been difficult to formulate a succinct description of our view versus > X3J14's, because oppositional catch-phrases (minimal versus maximal; > compatible versus complete; useful versus portable) only serve to polarize > the discussion and always leave out important areas of agreement. .... > > In future postings I will attempt to make the ``less is more'' point of view > explicit (though that point of view seems so naturally consistent with Forth > itself that it is sometimes difficult to come up with words of > justification). Usually, difficulty in communicating a point of view indicates that the speaker (or writer) has an imprecise understanding of the issues. There has been a lot of confusion about the definitions of "core word set", "extended word set", "standard words"etc. There is also confusion between "ANS Forth Programming System", "Standard System" and "Standard System with Environmental Restrictions". Do you know exactly what it means to be able to call your compiler an "ANSI Forth" implementation? I know the definitions were still fairly vague at the Vancouver conference. Look over your complaints again, and the definitions in the basis document. Are you absolutely certain that what you are arguing against is really what you think it is?
dcp@world.std.com (David C. Petty) (01/11/91)
I was sick with pneumonia through new year's day and so wasn't able to
read news for a couple of weeks and during that time (of course) the
messages were purged from my system. I missed any messages posted
between 20 December and the first of the year. I am not sure if I
missed any responses to the attached message, but since it mentions
``important areas of agreement,'' and ``...that there is much room for
compromise between the two points of view,'' and the hope that ``...we
can all agree to the extent to which [ANS Forth] can allow for minimal
Forths to still be standard'' I am reposting it.
The advocates of a ``less is more'' ANS Forth are not unwilling to
compromise, it's just that some of us:
a) would like a standard that is more layered so that the Core
Word Set is truly the _kernel_ of Forth and
b) fear adding (relatively) new and untried ``improvements'' to
ANS Forth, because that may (will) lead to the types of
problems we experienced with FORTH-83 and it may (will)
prevent adoption of the (possible) _best_ versions of
language features that may be just around the corner, but
incompatible with what we adopt in ANS Forth.
Having said that, let's each move towards the other's position. After
all, this ain't the Persian Gulf! (Except that you _must_ remove
>COLROW and LEX from the BASIS, or we will unleash a Forth jihad and
nuke you into the stone age.)
------------------------------>8 CUT 8<------------------------------
Greetings:
I am new to Usenet, so please bear with me as I get used to the network
etiquette. I am particularly interested in the Usenet (and GEnie and
BBS) discussion of ANS Forth. I have been, off and on, a member of the
X3J14 Technical Committee since the first meeting.
I am also a member of the Boston Forth Interest Group -- American
National Standard Forth Group (BFAFG), a sub-group of our local FIG
chapter with a long name. That group has been meeting monthly for the
past fifteen months to try and form a coherent minority position in
opposition to the view held by the majority of the current members of
X3J14.
It has been difficult to formulate a succinct description of our view
versus X3J14's, because oppositional catch-phrases (minimal versus
maximal; compatible versus complete; useful versus portable) only serve
to polarize the discussion and always leave out important areas of
agreement. The group's position is simply that BASIS is too big -- that
there are too many Forth words in ANS Forth -- but it is not a
simplistic ``small is beautiful'' position. The kinds of words we
object to are those that cannot, in our view, reasonably be said to be
included in ``accepted practice.''
Rather than going into a full blown specific discussion of what those
words are and to what extent they are not ``accepted,'' I will simply
make the point now that there is a difference of opinion between some
vendors who are members of X3J14 and some in the Forth user community as
to what makes a good Forth standard. It was heartening to learn that a
group from southern Ontario has been making proposals to X3J14 that are
_very_ consistent with our view. I only hope a groundswell of input
will continue to come into X3J14 before, during, and after they
``promulgate'' a Forth dpANS (draft proposed American National
Standard).
In future postings I will attempt to make the ``less is more'' point of
view explicit (though that point of view seems so naturally consistent
with Forth itself that it is sometimes difficult to come up with words
of justification). I just want to add that I (personally) believe that
there is much room for compromise between the two points of view.
Adding tons of whizzy new, but _optional_, features to Forth might be OK
as long as we can all agree to the extent to which they are optional and
can allow for minimal Forths to still be standard.
I hope that by adding to the discussion of ANS Forth I can sway some
people to our view and can encourage those that already share it to make
that view known to X3J14. I can also _guarantee_ that I will be hearing
from those that do not agree, but _c'est la vie_.
The BFAFG can be reached care of Gary Chanson at the snail-mail address
that appears on all of our proposals.
Boston FIG -- ANS Forth Group
c/o Gary Chanson
360 Waltham Street
West Newton, MA 02165-1732 USA
Telephone: +1(617)527-7206
My addresses and telephone numbers are:
Telephone: +1(617)492-1232
FAX: +1(617)491-2345
--
David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\
POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \
Cambridge, MA | `I thought I was wrong once, / \
02140-0001 USA | but I realized I was mistaken.' /______\dcp@world.std.com (David C. Petty) (01/15/91)
In article <15126@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: ``Eaker's CASE statement OCCUPIES ONE SCREEN OF CODE. Anyone who has ``liked it and wanted in their system has been able to add it and use it ``-- so the fact that it has not been part of Forth Standards is hardly In article <9101102147.AA13938@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: ``> >-- so the fact that it has not been part of Forth Standards is hardly ``> >evidence of the sluggishness and perversity of the Forth community -- ``> >but is, rather, evidence that previous Standards teams have understood ``> >the nature of Forth. `` ``> Oh, oh, oh! That surely is beautifully written, especially the final ``> phrase! `` ``Beautifully written, perhaps, but irrelevant. `` ``The "nature of Forth" is an abstract thing that is largely a matter of ``one's personal set of programming values. Some people appear to be ``trying to use it as a decision criteria. As such, it is pretty useless, ``because it is so imprecise and so subjective. Au contraire... The ``nature of Forth'' is indeed relevant to the X3J14 deliberative _process_, because it is the of nature of the beast that X3J14 is attempting to wrestle to the ground. I do not think that the current members of X3J14 do not understand the nature of Forth -- they have just failed to let that understanding form the basis of their _decision criteria_. =*= Let's take the example of control structures. X3J14 might have said: ``OK we want a perfectly general and complete standard that allows users to define whatever control structures they want, so (referring to BASIS14 section B.3 pp. 158-9, Wil Baden's dissertation on Control Flow) we will define their compile time behavior as: BEGIN ( -- dest ) dest to be resolved by UNTIL and AGAIN THEN ( orig -- ) resolves orig left by IF and WHEN IF ( -- orig ) conditional branch forward from orig UNTIL ( dest -- ) conditional branch back to dest WHEN ( -- orig ) unconditional branch forward from orig AGAIN ( dest -- ) unconditional branch back to dest [NOTE: WHEN is my general factoring of ELSE; see below] DO ( -- dest ) dest to be resolved by +LOOP or LOOP LEAVE ( -- ) leave information to be resolved by +LOOP and LOOP LOOP ( dest -- ) loop back to dest, resolving any LEAVEs +LOOP ( dest -- ) loop back to dest, resolving any LEAVEs [NOTE: UNLOOP has no compile time behavior] BUT ( orig1|dest1 orig2|dest2 -- orig2|dest2 orig1|dest1 ) orig|dest swapper (used by ELSE, ENDOF, and WHILE) YET ( orig|dest -- orig|dest orig|dest ) orig|dest duplicator (used to resolve LEAVEs, but I'm not sure for what else) THENCE ( i*orig dest -- ) resolve any number of origs U> dest The glossary entries for some accepted control structure words (if they are even still _needed_) then become: ELSE is semantically equivalent to: : ELSE ( orig1 -- orig2 ) POSTPONE WHEN POSTPONE BUT POSTPONE THEN ; IMMEDIATE WHILE is semantically equivalent to: : WHILE ( dest -- orig dest ) POSTPONE IF POSTPONE BUT ; IMMEDIATE REPEAT is semantically equivalent to: : REPEAT ( orig dest -- ) POSTPONE AGAIN POSTPONE THEN ; IMMEDIATE This approach leaves a few issues hanging -- like whether orig and dest are the same size on the control flow stack; whether this scheme meets everyone's compiler security needs; what to do about ?DO, FOR, and NEXT; which words should be in the Core Word Set and which should be in the Core Extension Word Set (or a Control Flow Word Set) -- but it allows users to _portably_ `roll their own' control structures, like case statements: : CASE ( -- dest ) ( a la Eaker ) POSTPONE BEGIN ; IMMEDIATE : OF ( i*orig dest -- i*orig dest orig ) POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP ; IMMEDIATE : ENDOF ( i*orig dest orig1 -- i*orig orig2 dest ) POSTPONE ELSE POSTPONE BUT ; IMMEDIATE : ENDCASE ( i*orig dest -- ) POSTPONE DROP POSTPONE THENCE ; IMMEDIATE'' =*= The _other_ approach that X3J14 might have taken is to say: ``OK, we'll standardize what we _know_ everyone expects (is accepted practice) in the Core Word Set (+LOOP, AGAIN, BEGIN, DO, ELSE, IF, LEAVE, LOOP, THEN, REPEAT, UNTIL, WHILE) -- though WHILE will have a specification that requires an implementation change by many system implementors to comply with the now standard `multiple WHILE' feature (but it does not break existing code). We'll factor LOOP (and +LOOP) and throw a new word into the Core Word Set (UNLOOP) that names a function that has always existed in Forth (but has not had an accepted name until recently), because it gives us the nice behavior of allowing WHILE ... THEN to be used with a do-loop `for free.' Then we'll put a bunch of other stuff that we know about and think would be nice to have (?DO, CASE, ENDCASE, ENDOF, FOR, NEXT, OF) into the Core Extension Word Set.'' =*= I believe that the latter case is close to what has actually happened (over time and through compromise) with BASIS14. My question is, what vaunted ``decision criteria'' were applied to the control flow words of BASIS14? On one hand, accepted practice seems to be an important decision criterion (trading BUT, THENCE, WHEN, and YET for CASE, ENDCASE, ENDOF, and OF). On another hand, usefulness and completeness seem to have overruled accepted practice in the case of multiple WHILEs and the new word UNLOOP. But neither is completeness the main decision criterion, for the current BASIS has no provision for an unconditional forward branch (WHEN) and it standardizes only one form of case statement. Another decision criterion is minimizing system implementor pain, but that has been overruled by the let's-make-Forth-better criterion in the case of multiple WHILEs. But can it truly be said that the currently standardized control structures make Forth ``better'' when, with BUT, users could implement their own preferred form of WHILE and REPEAT? I realize that the control structure words were arrived at through compromise over three years and that one decision criterion that has not been compromised is the commendable and overriding desire for code portability (something X3J14 has thus far been _much_ more successful with than was the Forth Standards Team), but it appears to me that the _other_ decision criteria have become a muddle of inconsistently applied arguments. As I said above, I believe that X3J14 has failed to form coherent decision criteria based upon their understanding of the nature of Forth. John Wavrik implies that a standard Forth based on such an understanding will provide building blocks from which users can derive the greatest flexibility, but at the same time will place as few restrictions as possible on their use. With that approach X3J14 would have: standardized +LOOP, AGAIN, BEGIN, BUT, DO, IF, LEAVE, LOOP, THEN, THENCE, UNLOOP, UNTIL, WHEN, and (possibly) YET; left ?DO, FOR, and NEXT in an extension word set (though ?DO has problems); provided rationale (or implementors) notes for the default standard behavior of ELSE, WHILE, and REPEAT; and provided implementors notes for sample case statements. BASIS would thus be reduced by three words and the ultimate decisions on how control structures are used would be left to the users. In article <15126@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: ``Petty's statement: `` ``> It ``> is only necessary that standard Forth provide the facilities for ``> extending itself, so that users (and vendors) can add any language ``> extension they want. `` ``It is not clear that the ANSI team believes this. <...stuff...> ``Instead it seems that members of the Forth community are being asked ``(or dragged) to accept some high level features that many people don't ``want -- and, in return, are being expected to give up certain low ``level capabilities and simplicity which they regard as essential ``qualities of Forth. `` ``Mitch Bradley (member of ANSI team) writes, `` ``> If everything goes well, ANS Forth will drag the Forth community ``> kicking and screaming into the late '70's. I don't believe X3J14 will actually change the current BASIS (and I am not writing any proposals to the effect that they do). The purpose of my discussion is to point out what, in my heretical opinion, is a major problem with the X3J14 deliberative process -- the lack of clearly articulated decision criteria. It has been my experience that the decision criteria of accepted practice, code portability, ``[indispensability] to the production of a coherent standard'' (see BASIS 14, _Preface: Scope of Work for X3J14_, between pp. viii and ix), dragging Forth ``...kicking and screaming into the late '70s'' (whether the added features are gotten ``for free'' or not), fixing bugs, compromise with existing standards (God forbid!), and others, have all been used to justify the inclusion or exclusion of any word or concept whatsoever, depending on the whim of the person presenting the argument! I have seen people use certain decision criteria to argue both for and against an idea (though not usually in the discussion of a single proposal). In short, I do not believe that X3J14 has a firm and consistent grasp on the nature of the process of standardizing Forth. In article <9101102147.AA13938@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: ``Forth must adapt to the new "climate" or die. On this, I agree with Brad Rodriquez that the ends do _not_ justify the means, but (mercifully) _that_ is a topic for another message. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
dcp@world.std.com (David C. Petty) (01/15/91)
In article <4410@mindlink.UUCP>, a684@mindlink.UUCP (Nick Janow) writes: ``> a) would like a standard that is more layered so that the Core ``> Word Set is truly the _kernel_ of Forth and `` ``What are your expected applications that require only the minimum kernel? The ``layered standard'' arguments have been made many times in this forum. I agree that embedded systems need not be standard. It just seems to me that, if X3J14 is taking the extension word set idea seriously, they might consider moving 2DROP, 2DUP, 2OVER, 2SWAP (and maybe 2! and 2@) to the Double Number Word Set, or making a Portability Word Set that includes ALIGN, ALIGNED, CELL+, CELLS, CHAR+, CHARS, and ENVIRONMENT?, or making an Input Steam Word Set that includes #TIB, >IN, ACCEPT, BLK, EVALUATE, and TIB. All of these were proposals by me and / or the BFAFG that were rejected by X3J14. I know that X3J14 argues that it is wrong to divide the Forth kernel up along functional lines, but I cannot recreate the arguments against doing so and I do not know what criteria they are using to define extension word sets. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
dcp@world.std.com (David C. Petty) (01/15/91)
In article <4410@mindlink.UUCP>, a684@mindlink.UUCP (Nick Janow) writes: ``> b) fear adding (relatively) new and untried ``improvements'' to ``> ANS Forth, because that may (will) lead to the types of ``> problems we experienced with FORTH-83 and it may (will) ``> prevent adoption of the (possible) _best_ versions of ``> language features that may be just around the corner, but ``> incompatible with what we adopt in ANS Forth. <...stuff...> ``There will always be something better "just around ``the corner". `` ``The ANSI standard has to deal with what is available today. Where possible, ``it should allow for future additions or changes, but it can't deal with them ``before they exist. I find it incredibly ironic that, when arguing against my contention that adding whizzy features to Forth may cause problems, someone would suggest that ANS Forth, as it is currently constituted, is dealing with the Forth of today. Your talking to Mr. ``Let's standardize this year's Forth, not next year's Forth!'' I am not suspicious of a Forth standard, per se (I was on the Forth Standards Team and was at the founding meeting of X3J14). I am suspicious of ``improvements'' to Forth ending up in ANS Forth. Some of the ``improvements'' of FORTH-83 over FORTH-79 were changing LEAVE, changing DO, changing division, changing PICK, changing ROLL, changing state-smart words, and on and on. I maintain that it was a mistake to make (some of) these changes -- that they were not that well thought out. X3J14 has generally avoided these gross mistakes, but the goals of X3J14 are loftier and the document is much more complex than the FORTH-83 standard. By attempting to standardizing a complete Forth, X3J14 may be introducing subtle and non-trivial problems -- after all, what seem like obvious problems today were too subtle for us to notice in 1983. FORTH-83 also put forth the ONLY ... ALSO search order control mechanism as an experimental proposal. A variant of it exists in BASIS14, but there is no accepted practice in this area (that does _not_ mean that it is not accepted practice to have VOCABULARY in your system, just that implementations vary). _I do not believe that it is the best search order mechanism we can come up with_. Having _no_ standard search order mechanism is better than having one that will preclude the ``obvious'' best (and as yet unknown) search order mechanism from being standard (especially when having only one word list (FORTH) does not materially efffect the usefulness of the language). 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.'' -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
dcp@world.std.com (David C. Petty) (01/15/91)
In article <4410@mindlink.UUCP>, a684@mindlink.UUCP (Nick Janow) writes: ``> It has been difficult to formulate a succinct description of our view ``> versus X3J14's, because oppositional catch-phrases (minimal versus maximal; ``> compatible versus complete; useful versus portable) only serve to polarize ``> the discussion and always leave out important areas of agreement. .... ``> ``> In future postings I will attempt to make the ``less is more'' point of ``> view explicit (though that point of view seems so naturally consistent with ``> Forth itself that it is sometimes difficult to come up with words of ``> justification). `` ``Usually, difficulty in communicating a point of view indicates that the ``speaker (or writer) has an imprecise understanding of the issues. I do not fail to understand the issues. The current membership of X3J14 and I have wholly different views of what a Forth standard ought to be. We are speaking a different language when we attempt to explain our points of view to one another and thus we are often at a loss for words _that the other will understand_. We just simply don't agree on whether ANS Forth ought to include whizzy new features (like locals). I say standard Forth is the Forth that has proven itself in the user community and they say Forth must be ``improved'' to include things that have yet to gain near universal acceptance. <...stuff...> ``There has been a lot of confusion about the definitions of "core word set", ``"extended word set", "standard words"etc. There is also confusion between ``"ANS Forth Programming System", "Standard System" and "Standard System with ``Environmental Restrictions". `` ``Do you know exactly what it means to be able to call your compiler an "ANSI ``Forth" implementation? Do you? Does anyone? ``I know the definitions were still fairly vague at the Vancouver conference. During the panel discsussion with members of X3J14 at the Rochester Forth Conference working group on ANS Forth, the audience asked many questions on conformance and labeling and routinely got conflicting answers from the panelists. It is not only the user community who is confused on this point. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
dcp@world.std.com (David C. Petty) (01/15/91)
In article <1991Jan15.041300.14326@world.std.com>, dcp@world (David C. Petty) writes: ``As I said above, I believe that X3J14 has failed to form ``coherent decision criteria based upon their understanding of the nature ``of Forth. I do _not_ consider the proposal metric described by Larry Forsley in the _Rationale to Statement of Work_ (BASIS 14, between pp. viii and ix) to be an adequate substitute for consistently applied decision criteria. In short, it says: 1) when accepted practice is clear (DUP), accept it, 2) when practice is conceptually clear, but there are code differences (VOCABULARY), attempt to form a synthesis satisfactory to proponents of each method, 3) when practice isn't conceptually clear, and code differences abound (vocabulary search order), leave it out of the standard, and 4) when accepted practice in the specific is usurped by considerations in the general (POSTPONE), develop a new technique. [Please note that the _Rationale to Statement of Work_ has no force whatsoever, its proximity to the _Scope of Work for X3J14_ notwithstanding. X3J14 is charged by the _Scope of Work for X3J14_ and the _Rationale to Statement of Work_ is on the order of, ``this is kinda how we're gonna go about it.''] I agree with the first three, but the fourth has come to mean, ``We will add whatever whizzy things we want for whatever reason we can think of.'' I believe a more comprehensive proposal metric as an amendment to the _Scope of Work for X3J14_ might be helpful to the process of applying decision criteria, but it is a difficult question and no one (including me) has been able to come up with a better (adequate) one. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
a684@mindlink.UUCP (Nick Janow) (01/15/91)
dcp@world.std.com (David C. Petty) writes: > We just simply don't agree on whether ANS Forth ought to include whizzy new > features (like locals). I say standard Forth is the Forth that has proven > itself in the user community and they say Forth must be ``improved'' to > include things that have yet to gain near universal acceptance. A lot of us find features--such as locals--to be a very useful addition to Forth. Since there will be a lot of people using locals, it's nice to have a standard way of handling them, so that programs--and programmers--are portable. Let me make an analogy to what I think is your point of view; you can tell me if it's a bad analogy. The steel industry has a set of standards for identifying alloys, including modern high-performance alloys. This allows steel users to simply specify a certain alloy for an application. A xxx.yyy.zzz alloy means the same thing to everyone. If the standard was developed using your arguments, we'd probably be limited to basic carbon steel. "Carbon steel has been good enough for hundreds of years. We don't need to mess with these 'whizzy new alloys'. Adding molybdenum alloys would make the standard too big. If anyone needs more capabilities, they can add them to their stock of recipes." While it's true that carbon steel might be the "core" alloy set and anyone can add new alloy blends from that, it's not very productive. If each steel producer makes its own (non-portable) alloys, users get locked into one producer. You have to rewrite all your design tools to switch to a new producer, or else you have to do all your design work at the lowest level (specifying the exact requirements of each alloy for every project) instead of using standard high-level alloy specifications. Limiting the "core" alloy set to carbon steel is fine for steel alloy "hackers", but it isn't productive for the industry.
UNBCIC@BRFAPESP.BITNET (02/01/91)
> This would be my vote. If you want string handlers, fine. Add them. Do If they are not fast, they are not useful for me. > NOT make them part of the core word set. I have no ax to grind with LEX, Not CORE word set! STRING word set! > SED, or SNOBAL for that matter, just don't put them in my kernel. And, anyway, if they were in the core, just write, in plain Forth, the words, and provide the source in documentation. No need to be in CORE. In fact, I would be more happy if they were provided as source in disk, as long as they were fast. > >RE a "portability" wordset with ALIGN etc.: > This question pits the side of me that wants portability against the > side that wants a small, tight kernel. IF I HAD TO CHOSE THIS MINUTE > I would opt for trashing it, but I would like to see the pros and > cons argued (rationally) first. Well, imagine if I have need to a word that creates something like that: : ID CREATE CHAR " WORD ( Need to get HERE ? ) C@ 1+ ALLOT ( Alocate name ) ( place ALIGN here ) , ( Alocate age ) CHAR " WORD ( Need to get HERE ? I don't know the stack diagram for WORD in ANS Forth...) C@ 1+ ALLOT ( Alocate address ) ; And use this like this: 20 ID Daniel C. Sobral"SHIN QL 8 Conj. 8 Casa 1" Without the ALIGN in the right position, this, probably, won't run in a Forth for Macintosh, for example. See, my name have an even number of bytes, one more byte for the counter and --- if I didn't get an even value at HERE --- the , would proceed an ilegal operation. If the comma automatically ALIGN the address, I would still have problems when accessing my age with @. If the @ too automatically ALIGN the address, I would still have problemwhen calculating the start of my address. If you need more arguments, please say so. I'll provide them. (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP
UNBCIC@BRFAPESP.BITNET (02/01/91)
Sorry, a big error in the last message:
--- If I didn't get an even value at HERE ---
should be:
--- If the address returned by WORD (or HERE) were already ALIGNed ---
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETdcp@world.std.com (David C. Petty) (02/12/91)
I am posting this proposal (which was passed at the most recent
meeting of X3J14, because everything was deleted from it except for
(16)) so that anyone and everyone can respond to the questions raised
in it. One member of the X3J14 Technical Committee (TC) has agreed to
respond point-by-point to these questions. Those responses will also
be posted.
----------------------------------------------------------------------
ANSI ASC X3 / X3J14 Forth Technical Proposal TP91-1082
----------------------------------------------------------------------
Title: Clarify BASIS on the subject of the Forth input stream.
----------------------------------------------------------------------
Related Proposals: TP90-833, TP91-1070
----------------------------------------------------------------------
Keyword(s): input stream, block file, implementation-defined
default block space, text file
----------------------------------------------------------------------
Forth word(s): #TIB ( >IN BLK EVALUATE INCLUDE INCLUDE-FILE LOAD
LOAD-FILE QUERY REFILL SOURCE-FILE SPAN TIB \
----------------------------------------------------------------------
Abstract: Clarify BASIS on the subject of the Forth input stream.
BASIS is still unclear on the specific input stream ``entitlements''
to the point that we have heard differing interprpreter, 5.3.2
addressable memory, 5.3.4.1 Input Stream, 8.1.006 #TIB, 8.1.0080 (,
8.1.0560 >IN, 8.1.0790 BLK, 8.1.1360 EVALUATE, 10.1.1713 INCLUDE,
10.1.1717 INCLUDE-FILE, 11.1.1790 LOAD, 10.2.1792 LOAD-FILE, 8.2.2040
QUERY, 8.2.2125 REFILL, 10.1.2218 SOURCE-FILE, 8.2.2240 SPAN, 8.1.2290
TIB, and 8.2.2535 \ (plus other new sections).
----------------------------------------------------------------------
Discussion:
In the following discussion the term ``legitimate'' means ``portable,
consistent with the intention of X3J14, and within the boundaries of
good taste.''
1) There is a question about the general nature of #TIB. Which of
the following are legitimate and correct in ANS Forth?
: stream-empty? ( -- flag ) BLK @ : stream-empty? ( -- flag )
IF 1024 #TIB @ >IN @ = ;
ELSE #TIB @
THEN >IN @ = ;
It appears, given the letter of BASIS, that the first ought to
be correct in all cases, but is #TIB also meant to hold the input stream
length?
2) There is a question about the general nature of TIB. Which of
the following are legitimate and correct in ANS Forth?
: stream ( -- c-addr u ) BLK @ ?DUP : stream ( -- c-addr u )
IF BLOCK 1024 TIB #TIB @ ;
ELSE TIB #TIB @
THEN ;
It appears, given the letter of BASIS, that the first ought to
be correct in all cases, but is TIB also meant to specify the beginning
of the input stream (i.e., does it call BLOCK)? Also, does the value
returned by TIB ever change, e.g. during EVALUATE, INCLUDE, or
INCLUDE-FILE, or do the values of #TIB and >IN change relative to it?
3) There is a question about what >IN holds. Are the following
legitimate and correct in ANS Forth?
: initialize-stream ( -- ) : skip-stream ( -- )
0 >IN ! ; #TIB @ >IN ! ;
That is, can anything but a previously saved value of >IN be
legitimately stored in >IN by a user?
4) There is a question about what #TIB holds. Is the following
legitimate and correct in ANS Forth?
: truncate-stream ( -- )
>IN @ #TIB ! ;
That is, can #TIB ever be legitimately modified directly by a
user?
5) There is a question about what BLK holds. Is the following
legitimate and correct in ANS Forth?
: ans-query ( -- )
TIB +n ACCEPT #TIB ! 0 BLK ! 0 >IN ! ;
That is, (in addition to the above questions) can BLK ever be
legitimately modified directly by a user? If not, what does it mean to
say that ``QUERY is semantically equivalent to [that] sequence...''
(BASIS section 8.2.2040 QUERY)?
6) There is a question about accessing the contents of the input
stream. Is any of the following legitimate and correct in ANS Forth?
: uppercase ( c-addr u -- ) ... ; ( converts string to uppercase )
: uppercase-next-word ( -- )
>IN DUP @ 2>R BL PARSE uppercase 2R> SWAP ! ;
: remaining-stream ( c-addr u -- )
stream >IN @ CHARS TUCK - >R + R> ;
: CHAR ( "ccc" -- char )
remaining-stream 0= ABORT" Stream empty." C@
BL WORD DROP ;
Given that uppercase-next-word will not generally work if the
input stream is coming from a block (and what about EVALUATE?), can the
contents of the input stream ever be legitimately modified directly by a
user (uppercase-next-word, above)? Can the contents of the input stream
ever be legitimately manipulated in any way directly by a user (CHAR,
above), or is it only ever legitimate to parse from the input stream?
If it is not legitimate for a user to directly calculate addresses
within the input stream without parsing, can a user ever do anything
legitimate with the value of TIB?
7) There is a question about parsing. Is the following legitimate
and correct in ANS Forth?
: CHAR ( "ccc" -- char )
BL WORD COUNT 0= ABORT" Stream empty." C@ ;
Section 4.0575 Parsing says, ``If the current input stream is
empty or contains no characters other than the delimiter, the string is
empty.'' Is an empty string-implementation defined, or is the count
zero?
8) Is it true that, ``words using TIB and modifying the contents
of BLK, >IN, or #TIB are responsible for maintaining the integrity of
the input stream specification and its contents'' (changes added)?
Ought section 5.3.4.1 Input Stream paragraph four (from where the above
was taken) to be so modified? Ought there to be more prose in that
section about nesting and un-nesting the input stream and if so, what
prose?
9) There is a question about CURRENT-FILE and SOURCE-FILE. We
have heard from the TC that CURRENT-FILE is obsolete, that SOURCE-FILE
is obsolete, and that they are the same! We most definitely believe
(and assume) that CURRENT-FILE is not obsolete, that SOURCE-FILE (as a
named value) is obsolete, and that they are definitely not the same
thing (see TP91-1070). C'mon, which is it guys?
10) The wording of BASIS section 8.2.2125 REFILL is unclear and /
or incorrect. When BLK contains a non-zero value and SOURCE-FILE
returns a non-zero value, section 8.2.2125 specifies that REFILL takes
the action ``0 >IN ! 1 BLK +! 0.'' First, does that means that the
system next interprets the block specified by the new value in BLK in
the ``block space'' specified by CURRENT-FILE (regardless of the value
in SOURCE-FILE)? Second, if CURRENT-FILE contains a non-zero value,
shouldn't REFILL return other than zero, or should the system simply
abort if a user attempts a REFILL beyond the end of a block file?
11) Is SOURCE-FILE useful in any way to a user? It is used in
BASIS to help explain the way INCLUDE, INCLUDE-FILE, and REFILL work,
but it can only be modified by INCLUDE, INCLUDE-FILE and little can be
done with it by a user except defining: : INTERPRETING-TEXT-FILE? ( --
flag ) SOURCE-FILE 0<> ;. We cannot see the need for that system value
to be given a name and will help rewrite BASIS in terms of ``source
file'' (the file whose text gets interpreted by INCLUDE and
INCLUDE-FILE), removing any reference to SOURCE-FILE.
12) Section 10.1.1029 CURRENT-FILE refers to ``current block file''
and ``implementation-defined default block space,'' neither of which are
defined. A ``block file'' probably means ``whenever the contents of
CURRENT-FILE are non-zero'' and differs from the implementation-defined
default block space only in that the concept of end-of-file is
meaningful for a block file. Ought ``block file,'' ``current block
file,'' and ``implementation-defined default block space'' be defined in
the Definition of Terms and if so, how?
13) There are some unclear aspects of the specification of comments
(BASIS sections 8.1.0080( and 8.2.2535 \). Section 8.1.0080 refers to
``text file,'' but that term is nowhere defined. It probably means
``whenever the contents of BLK are zero and the source fileid is
non-zero.'' Ought ``text file'' be defined in the Definition of Terms?
Section 8.2.235 refers to ``line,'' but section 4.0510 (the definition
of the term ``line'') is inadequate to describe the lines in blocks (and
block files) versus those in text files (it describes how ``lines'' are
displayed). What is meant by a line within a block (e.g. is it 64
characters) and to what does section 4.0510 refer? Ought the wording of
section 4.0510 be improved and if so, how?
14) There are some questions about (.
- Section 8.1.0080 ( spells out that a null comment, (), is
allowed so that ( cannot be implemented in terms of WORD (though
sections 8.1.0190 ." and 8.2.0200 .( do not specify that behavior).
Does that behavior need a rationale note?
- Sections 8.1.0080 ( and 8.2.0200 .( specify that those words
are immediate. Is that a mistake and if not, why not?
- Does X3J14 really want to require ( to comment to the end of a
text file?
15) Is the following legitimate and correct in ANS Forth and does
it immediately exit the current input stream?
: EXIT-INPUT ( -- ) BLK @
IF 1024 >IN !
ELSE POSTPONE \
BEGIN
REFILL 0=
UNTIL
THEN ;
16) We asked the question of the Input Stream Working Group, ``why
does section 11.1.1790 LOAD have the stack diagram ( i*w -- j*w )?'' and
got explanations as to what the ``i*x'' mean. To us, that stack comment
says, ``LOAD takes a variable number of arguments and leaves a variable
(and potentially different) number of arguments.'' Didn't LOAD used to
take a block number?
----------------------------------------------------------------------
Date: February 1, 1991
Submitted by: David C. Petty and Bent Schmidt-Nielsen
Address: Post Office Box Two
Cambridge, MA 02140-0001
Internet: dcp@world.std.com
Telephone: +1(617)492-1232 FAX: +1(617)491-2345
ANSI ASC X3 / X3J14 Forth Standards Committee
111 North Sepulveda Boulevard, Suite 300 Manhattan Beach, CA
90266-6861
-----------------------------------------------------------------------
X3J14/87-021 12/04/1987
--
David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\
POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \
Cambridge, MA | `It must've been some-other-body, / \
02140-0001 USA | uh uh babe it wasn't me...' /______\UNBCIC@BRFAPESP.BITNET (04/03/91)
Does DEFER exists in BASIS 15?
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETUNBCIC@BRFAPESP.BITNET (04/05/91)
Can I read the lines that follow a word in a source, in a std way, with
what BASIS 15 gives to me?
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET
P.S.: Interesting your last two messages, Clyde.wmb@ENG.SUN.COM (04/05/91)
> Can I read the lines that follow a word in a source, in a std way, with > what BASIS 15 gives to me? Yes. That was a "priority 1" goal of mine for the input stream specification. Mitch Bradley, wmb@Eng.Sun.COM
UNBCIC@BRFAPESP.BITNET (04/06/91)
>> Can I read the lines that follow a word in a source, in a std way, with >> what BASIS 15 gives to me? > Yes. That was a "priority 1" goal of mine for the input stream > specification. Thanks, Mitch, but how? Ah! An old question that nobody answered: there is DEFER in BASIS 15? >> (8-DCS) > Mitch Bradley, wmb@Eng.Sun.COM (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
wmb@ENG.SUN.COM (Mitch Bradley) (04/06/91)
> Is there DEFER in BASIS 15. No. I proposed it at the last meeting, but the proposal was defeated 3-8. > [how do I] read the lines that follow a word in a source, in a std way, with > what BASIS 15 gives to me? You can use WORD to read the rest of the line, or \ to skip the rest of the line, or look at the characters of the line individually by using a combination of BLK , BLOCK , TIB , >IN , and #TIB to develop the current input buffer address. Then, when the input buffer is empty (as indicated by >IN @ equal to #TIB or by WORD returning the address of a string whose length byte is 0), you refill the input buffer with REFILL ( -- okay? ). REFILL returns false at end-of-file. Mitch
UNBCIC@BRFAPESP.BITNET (04/06/91)
: DEFER CREATE 1 CELLS ALLOT DOES> @ EXECUTE ( PERFORM if it exists) ;
Is the above line correct by BASIS 15? Can it use TO?
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETwmb@ENG.SUN.COM (04/06/91)
> : DEFER CREATE 1 CELLS ALLOT DOES> @ EXECUTE ( PERFORM if it exists) ; > > Is the above line correct by BASIS 15? Yes. A slightly better definition would be: : COMPLAIN ." Unitialized DEFER word" cr ; : DEFER CREATE ['] COMPLAIN , DOES> @ EXECUTE ; > Can it use TO? No. There is no standard way to tell an existing system implementation of TO how to recognize children of the new defining word "DEFER", and what to do when they are recognized. Of course, you could pick another name (e.g. IS) and use it to set the value of DEFER words and nothing else. I suppose you could get fancy and do something like: : DEFER CREATE ['] COMPLAIN , 1234 1234 NOT 2, DOES> @ EXECUTE ; : TO \ name ( value -- ) ( Save the input stream pointer, look at the parameter field of ) ( "name" to see if it has 1234 1234 NOT in the right place, and ) ( if so, set the value. Otherwise restore the input stream pointer ) ( and execute the previous definition of TO . ) ; Mitch Bradley, wmb@Eng.Sun.COM
S47852EF@ETSUACAD.BITNET (Frank Earl) (04/07/91)
On Fri, 5 Apr 91 09:01:11 PST Mitch Bradley said: >> Is there DEFER in BASIS 15. > >No. I proposed it at the last meeting, but the proposal was defeated 3-8. > Mitch, how does the standards team propose to handle vectored execution and forward compilation in a clean and easy manner, while also doing it in a standard manner? (Read: This *WILL* be a portion of my comments to the TC) DEFER is one of those words that is nice in that, yes you may be able to portably define it using standard words ( like ' : <deferred-word> ; ') but is cleaner and easier to follow if it's made it's own class of word like F-PC has... (At least I think it's important... :) Frank
wmb@ENG.SUN.COM (04/09/91)
> Of the three items out for mail ballot, 2 have been rejected and 1 has > passed. The ones that failed had to do with conditional compilation words > (nobody likes the names) and left paren. The one that passed is for > sending BASIS 15 on to the SPARC committee. Actually, there were three technical items on the first mail ballot, and then a separate mail ballot with one item: whether or not to send Basis 15 to SPARC. The other technical item (the one that passed) had to do with the word 2R@ . It was a minor issue. Mitch Bradley, wmb@Eng.Sun.COM
UNBCIC@BRFAPESP.BITNET (04/22/91)
This is a small reply to a long message from John J Wavrik. What I think
is that he's comparing ANS Forth with another Forth that we currently use.
I would like to know what Forth we currently use. I, for example, use TCOM
and F-PC 3.53, both from the same guy, and distributed in a same package...
and I can't use comma as John J Wavrik has said we use in neither one.
In fact, he speaks of Parameter Field Address, a.k.a. BODY, wich, to my point
of view, is the DATA Area of ANS Forth. This is the only way I can use comma,
without having to change the code, in both Forths I use.
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET
P.S.: I'm currently working in a OOI written upon ANS Forth. I'm using ZEN,
and looks like it provides everything I need from the Standard (except for
?ENVIROMENT). I'll post more notes on that late.UNBCIC@BRFAPESP.BITNET (05/17/91)
=> In fact, I am personally _very_ interested in working up a test suite for ANS
=> Forth, and am working on a paper on the subject. Part of the reason for the
=> paper is to find out how many others would be interested in contributing to
=> this effort. I certainly can't do it alone, and I don't think any one vendor
=> should have to foot the bill for something that will benifit us all. So, how
=> many people out there are concerned about the testability of Forth and are
=> willing to help define a test suite for the coming versions of ANS Forth?
As I'm writting an Object Oriented Interface, I could help you. The
vocabularies wordset, nameless definitions and portability issues are the most
important to me.
=> Can we have a show of hands? DaR
||||
____/
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETUNBCIC@BRFAPESP.BITNET (05/28/91)
=> Category 10, Topic 15
=> Message 21 Sat May 25, 1991
=> R.BERKEY [Robert] at 20:45 PDT
=>
=>
=> To: Mitch Bradley
=>
=> mb> A standard ANS Forth system is not required to reject
=> mb> non-printable characters in blocks, nor is it required to accept
=> mb> them. The characters whose meanings are precisely defined in the
=> mb> context of block source code are the space character and the ASCII
=> mb> characters with codes from 33 to 126.
=>
=> Forth-83 allows word names defined on blocks to contain any character other
=> than a space. In Forth-83 there are no restrictions on the data that can be
=> stored in a block, a block is simply a 1K segment of RAM that interchangeably
=> resides in some form of mass storage. This "mass storage" may itself be as
=> little and as transient as 32K of RAM.
We were talking about SOURCE code in blocks. Specifically, if CHAR should
accept an >127 character.
=> mb> "127 AND" is often used after KEY to remove junk like parity bits
=> mb> and shift bits. This technique, although quite common, is bogus,
=> mb> because throwing away high bits doesn't necessarily result in a
=> mb> meaningful 7-bit ASCII character. Instead it may for example
=> mb> transform a code that means the "F7" function key into the letter
=> mb> "T", a behavior for which I can think of no justification.
=>
=> The implementation requirements for the Forth-83 Standard word KEY are an
=> entitlement to the "Standard Programmer", i.e., a user of a FORTH-83 Standard
=> System. Historically this definition arose because of conflicting program
=> needs involving KEY . Sometimes the program needs all of the data coming
=> through the I/O stream, principally here meaning through an RS232 serial port
.
=> It's a serious handicap to professional engineers when the implementation
=> arbitrarily discards data from the physical level of the I/O stream. At the
=> logical level of use, just what that data means may simply be information
=> relevant to the I/O stream, such as a parity bit, and not interesting in the
=> logical interpretation of the data. The point of the system requirements
=> involving the Forth-83 Standard word KEY is to assure that the application
=> level on a system-specific basis is able to make relevant decisions regarding
=> how to interpret physical-level data. Further, the Forth-83 Standard
=> guarantees a Standard Program access to logical data, i.e., that all 128 ASCI
I
=> characters can be received. The Forth-83 Standard further specifies the ASCI
I
=> standard as a normative appendix.
If you want binary data input, you can use EKEY. It's provided for that.
=> mb> The correct phrase should be something like this:
=>
=> mb> 126 constant max-graphic \ Value depends on system character set
=>
=> mb> ...
=> mb> key dup bl max-graphic between if ( char )
=> mb> <insert character in buffer>
=> mb> else
=> mb> <process as editing character>
=> mb> then
=>
=> That happens to be an example of a program using the Forth-83 KEY .
=>
=> Mitch, I don't understand your readiness to discard the heritage with KEY and
=> BLOCK . My sense of your view toward blocks is, "someone's not-so-bright ide
a
=> of a way to handle source code." I know that you've cited control-S and
=> control-Q as implementation problems with KEY . Yet especially knowing your
=> prodigious ability as an implementor, I find it difficult to understand that
=> you couldn't support the KEY in a program written to use DC1 or DC3, Device
=> Control 1 and 3, ASCII values hex 11 and 13. (If this issue is a "quibble",
=> then are excuses for not providing a full implementation of KEY other than
=> "quibbles"?)
There is a full implementation of KEY. It's name is EKEY.
=> By the way, I consider X3.J14's handling of the definitions of KEY and BLOCK
=> two of the bigger objections going, either being plenty of reason for
=> reasonable people to reject the label "ANS Forth Standard". The deletion of
=> EXPECT could be rationalized if KEY were conventionally functional. KEY can'
t
=> input a <RETURN>? In my opinion, the committee decision here lacks serious
Key accepts anything with 7 bits.
=> commitment to standardization. Re: disentitling BLOCK . The nominal
=> rationale that embedded systems don't necessarily need source code doesn't
=> wash. The existence of embedded systems that don't allow source code doesn't
=> in any way change the existence of programs that _are_ source code.
Again, we were discussing the behavior of blocks when used as SOURCE code.
=> Robert
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETMitch.Bradley@ENG.SUN.COM (05/28/91)
> Brad Rodriguez writes: > Ah, if only this same cost-benefit analysis had been applied to so many > other parts of ANS Forth! It has been applied. You just disagree with the outcome. Mitch.Bradley@Eng.Sun.COM
Mitch.Bradley@ENG.SUN.COM (05/28/91)
> My understanding is that there is a four-month "window" for comments. Then, > no further comments are accepted unless the dpANS is sent back to the TC for > revision. And this is not a sure thing; the TC is obligated to _respond_ to > all comments, but only ANSI decides -- who knows how? -- if the document has > to be sent back for changes. This turns out not to be the case. I was worried about this too, and I asked Elizabeth for clarification, and I also asked Sun's ANSI representative for confirmation. A TC can take a document back for changes at any time. It doesn't have to be "sent back at ANSI's discretion". In one recent case (SCSI I think), a TC discovered a problem at the absolute last minute, when the document was on the way to the printers for final printing. They "pulled it off the truck" and changed it. > By their own definition, a "superior" argument is one which appeals to the > whims of a majority of the TC -- and nothing else. You call it "whim", I call it "judgement". The committee members are people, so both words probably have some merit. Mitch.Bradley@Eng.Sun.COM
chrisg@cbmvax.commodore.com (Chris Green) (05/31/91)
In article <9105291726.AA13694@ucbvax.Berkeley.EDU> UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV writes: >We were talking about SOURCE code in blocks. Specifically, if CHAR should >accept an >127 character. > ..... >If you want binary data input, you can use EKEY. It's provided for that. >... >Key accepts anything with 7 bits. This is clearly a terrible thing. ANSI standard extended ASCII, which is in use on millions of our computers around the world, and millions of other machines, uses characters >127 to represent the extended characters needed for European writing (characters with tildes, etc). There are a lot more than 96 printable characters in ASCII. -- *-------------------------------------------*---------------------------* |Chris Green - Graphics Software Engineer - chrisg@commodore.COM f | Commodore-Amiga - uunet!cbmvax!chrisg n |My opinions are my own, and do not - killyouridolssonicdeath o |necessarily represent those of my employer.- itstheendoftheworld r *-------------------------------------------*---------------------------d
Mitch.Bradley@ENG.SUN.COM (05/31/91)
> >KEY accepts anything with 7 bits. > This is clearly a terrible thing. (discussion of international > character sets). Actually, as currently defined, KEY accepts anything in the implementation- defined character set, which can include 8-bit international characters. Mitch.Bradley@Eng.Sun.COM
mikeh@touch.touch.com (Mike Haas) (06/01/91)
> >Key accepts anything with 7 bits. KEY needs to do better than that. The rest of the world, where real computing is happening has passed ASCII long ago. most new standards have had the forsight to make 0-7f compatible with ASCII...this greatly assists PRIMITIVE 7-bit systems to make a transition...but is it taken advantage of? I swear, I've seen this kind of thinking in the forth community too long. While other languages are being used to develop multi-media, networking, file-sharing, and other state-of-the-art commercial packages, forth folks argue about shadow screens and whether KEY should accept more than 7 bits. BLOCK is a joke...far outlived it's usefulness from the days when there were no operating systems to run under (or ones that were there too pitiful to use). It's main effect these days is to alienate industry leaders from looking at forth because it's too wierd. fortgh needs files, period. I like using real editors. I had occasion to examine the software products of DEC a few years ago... had 'em all but forth. VMS-C, PASCAL, BASIC, FORTRAN, you name it...it's there. I haven't gotten into a discussion of what forth 'needs' for a long time, and I won't be eager to participate past this message. This is because the mindset of those who restrict forth to outmoded concepts is cast in stone. Everybody picks their pet peeve (usually the subject related to theirt own 'custom' implementation of CASE or whatever) and provokes discussion as though it were the most important aspect of forth as a language ...the very reason it will live or die. Well, my ONE-TIME-ONLY opinion is that the big issues have to do with forth's perception by the rest of the programming world, and our insistence to standby old, outdated concepts is spelling our demise, especially in areas where that world has provided excellent solutions (file systems and graphic character sets) and we REFUSE to listen. 7-bit ASCII, indeed. let's wind our watches 'cause they're running a little slow. Or maybe forth isn't as extensible as we think, huh? >
UNBCIC@BRFAPESP.BITNET (06/02/91)
=> >The issue doesn't revolve around BLOCK, but rather around whether Standard
=> >source code can contain "invisible" characters. I don't think it's a good
=> >idea to allow arbitrary control characters in standard source code. Standar
d
=>
=> Then don't enter them in source code. But don't limit the functionality of
=> the system's tools to handle such data. KEY and BLOCK (ugh) are used for
=> many thing other than funneling data to the interpreter/compiler. In fact,
=> when most forth "applications" are running, doing what they were designed
=> to do, the often use KEY and BLOCK (no?) and never invoke the interpreter.
Ok, so you AGREE with the decision made by X3J14. You can't enter invisible
characters in a Standard program, but you can use BLOCKs for whatever you want
(THERE IS *NO* LIMIT TO WHAT YOU CAN PUT IN BLOCKS!!!). You want >7 bits input?
Then use EKEY. KEY is still there, but for 7-bits input. Maybe the TC throw out
EKEY and make KEY acts like EKEY (puts a word in the stack with the input).
That would be useful for me (I use 8 bit characters).
=> Other languages have been adding page formatting control characters
=> since day 1...right in with their source code. any forth system worth
=> it's salt should be able to handle TAB characters as generic whitespace,
=> like BL. Why the hell not? I HATE it when someone designs limitations
=> into the development tools i have to use...especially forth tools, where
=> I can type in R> at the keyboard! This is an advantage, this power. Why
=> take it away? Remember, as a forth developer, you're creating MY tools;
=> you can't possibly know what I'm going to want to do with them, especially
=> with a language like forth!
That's what was happening. ZEN 15a treats anything greater than 126 and lower
than 33 as a generic whitespace. So I asked Mitch if that was OK with BASIS 15,
and he answered that ANS Forth let the compiler do anything with caracters not
within 32 and 126.
=> Then there are platforms (like tha amiga) where you can type in ANSI
=> escape codes to do VT-100-like forms management (including changing
=> text & background color). a 7-bit KEY is braindamaged! Quit trying
=> to protect me from the power of forth. Both the mac & amiga use the
=> full 8 bits for data...don't strip this out just cause your forth
=> interpreter can't handle it. forth needs to ADAPT to these systems...
=> even 8-bit text is old stuff, the world is now trying to figure out
=> international language support (16 bits & MORE!)...THIS IS WHAT WE
=> SHOULD BE FIGURING OUT!...
=> not whether KEY is gonna pass 8 bits! ludicrous. ADAPT...
=> it may be in Websters, but it sure isn't in many 'forth' dictionaries!
I consider EKEY an adaptation, don't you? ANS Forth have files also. And Error
Handling. And a powerful dictionary wordset. And floating point. And Double
Numbers. And many other things. Ok, we don't have Windows or Graphics, but no
Standard do (there are just too many "Standard" GUIs). What else do you want?
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETUNBCIC@BRFAPESP.BITNET (06/23/91)
What's the current status of dpANS Forth???
(8-DCS)
Daniel C. Sobral Errare Humanum Est...
UNBCIC@BRFAPESP.BITNET ...Perseverare Autem Diabolicum
UNBCIC@FPSP.FAPESP.ANSP.BR
--------------------------------------------------------------------------
No one, but me, is responsible for the above message.jax@well.sf.ca.us (Jack J. Woehr) (06/26/91)
UNBCIC@BRFAPESP.BITNET writes: >What's the current status of dpANS Forth??? Received BASIS 17 in mail today, along with dpANS letter ballot. -- # jax@well.{UUCP,sf.ca.us} # # Member, # # Chapter Coordinator, # # well!jax@lll-winken.arpa # # X3J14 TC # # Forth Interest Group # # JAX on GEnie # # for ANS # # P.O. Box 8231 # # SYSOP RCFB (303) 278-0364 # # Forth # # San Jose CA 95155 #
Mitch.Bradley@ENG.SUN.COM (Mitch Bradley) (06/27/91)
> Received BASIS 17 in mail today, along with dpANS letter ballot.
I want to publicly express my appreciation to John Rible for making it
possible for the letter ballot to go out in time for the ballot to
close before the next X3/J14 meeting. John pulled "all nighters" for
about 4 straight nights at the Rochester Forth Conference in order to
finish all the Basis editing. Don Colburn stayed up all night on Friday
to supervise the final printing.
Three cheers to Don, and 16 cheers to John Rible!
Mitch