ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/12/90)
Category 10, Topic 2 Message 212 Wed Jan 10, 1990 PRESS16 [Elizabeth] at 21:44 EST Hello, all. This is my first visit, preparing for a guest appearance next week. Just so everyone knows, the price of BASIS is now $10. This is due to rising costs, as the document itself is getting fat and expensive to reproduce. But it has some good stuff in it, particularly a "portability guide" by John Hayes. A 20-pg set of highlights will be posted shortly, probably tomorrow , in preparation for a discussion 1/18. Hope you will all be there. By the way, since I'm using FIG's number for practice, I should identify myself: Elizabeth Rather, chair X3J14, FORTH, Inc. Cheers ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
BARTHO@CGEUGE54.BITNET (PAUL BARTHOLDI) (01/12/90)
Hi Elizabeth,
> Just so everyone knows, the price of BASIS is now $10. This ...
Just a silly question : What is BASIS ?
Happy New Year to evryone at Forth Inc !
Paul Bartholdi, Geneva ObservatoryForthNet@willett.UUCP (ForthNet articles from GEnie) (01/15/90)
Category 18, Topic 16 Message 2 Sun Jan 14, 1990 GARY-S at 08:12 EST To: Paul Bartholdi Subj: ANS FORTH TECHNICAL COMMITTEE In message: <9001132253.AA02323@jade.berkeley.edu> Paul Bartholdi writes: >> Just so everyone knows, the price of BASIS is now $10. This ... > >Just a silly question : What is BASIS ? BASIS x is the document describing the current state of the model being developed by the X3/J14 ANS Forth Technical Committee. ie: the working, unfinished, draft. After each meeting of the X3/J14 TC a new BASIS is produced describing changes made to the previous BASIS, items under discussion, etc... Gary uunet!wuarchive!texbell!ark!lrark!glsrk!gars co-SysOp, GEnie Forth RoundTable (GARY-S) co-SysOp, GEnie Unix RoundTable (GARS) ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/15/90)
Category 10, Topic 2
Message 215 Tue Feb 13, 1990
L.ZETTEL at 19:31 EST
The following is an excerpt from a report I gave my company after coming
back from ANS San Diego:
ANSI X3J14
This committee is the latest of a line of standardization
efforts that can be traced back to 1978 or so. It functions
officially under ANSI (American National Standards Institute)
auspices and rules, like any other language standardization
committee. There are twenty or so official members, representing
a cross section of Forth vendors and implementors, users, and
other interested organizations.
January
San Diego was the eleventh meeting of X3J14. Around 650
technical proposals have been submitted to the committee so far,
and upwards of 550 have been dealt with. Forth started out in an
environment where machines were byte addressable, arithmetic was
integer 16 bit twos complement, and operating systems were
minimal to nonexistent. The major issues left to the committee
seem to this observer to principally involve the best ways to
specify a standard Forth that will work in an equivalent manner
in this and other environments. (Under a file-oriented operating
system with 32 bit arithmetic not necessarily twos complement,
for instance).
Specific issues still outstanding include (in no particular
order):
Integer division (round or floor? sign of remainder?)
Specifying the size of a least addressable memory unit, character,
and stack entry in a way that allows portability and yet does not
unduly inhibit implementor options when dealing with a particular
hardware architecture.
String handling.
Number definition.
Bit operations.
Floating point formats.
Error handling.
Requirements for multi-tasking systems.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/16/90)
Date: 02-14-90 (00:42) Number: 2903 (Echo)
To: BOB LEE Refer#: 2897
From: JERRY SHIFRIN Read: NO
Subj: ANS FORTH Status: PUBLIC MESSAGE
BL>One of the things I noticed in the Basis 10 Summary was a word I'd never
BL>heard of: >COLROW - what an ugly word! I don't see why such a word is
BL>necessary in a standard system. Even if it must be included for some
BL>reason or another, I wish it had a more readable name (POSITION maybe?).
One of the problems the standards team runs into is the existing
use of certain words, parhaps with slightly different meanings.
>COLROW is implemented in most vendors' Forths, frequently named
AT or GOTOXY. >COLROW is, at least, more explicit about its
function and parameters.
---
* QDeLuxe 1.10 #214s
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/16/90)
Date: 02-14-90 (16:27) Number: 2906 To: BOB LEE Refer#: 2897 From: MIKE NEMETH Read: NO Subj: ANS FORTH Status: PUBLIC MESSAGE The November 1990 Washington DC meeting is the Target date for completion of committee work. After that the basis Doc will recieve another edit to turn it in to a new doc called DPANS (draft proposed ansi standard. A mail ballot of the standards committee must approve the dpans unanimously. OK its probabality Jananuary 1991 now. The DPANS is now published and a manditory 4 month public review period starts. The committee MUST answer all remarks/complaints about the DPANS to the SATISFACTION OF ANSI. OK that may cause revision of the DPANS; start the cycle again! If and when it does then it is summited to ANSI for consideration. ANSI meets only a couple of time a year. OOPs they meet and kicked it back; begin again. IF thing worked fairly smoothly there MAY be an ANS forth by late 1991. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/19/90)
Category 10, Topic 2
Message 218 Sun Feb 18, 1990
L.ZETTEL at 14:48 EST
Having discussed it with them, I can assure you that ANSI X3J14 is
not particularly enthused over the name >COLROW either, but they had to
call it *something*... The function is important, because it ensures
that portable code can manipulate the cursor.
Naming Forth words is a delicate business. Criteria that have been
advanced over the years include: names should 1) be single English words
2) be short 3) encode maximum information in their first three characters
(with modern practice, this one may be on its way to becoming a dead issue)
4) describe the effect they produce, not the manner of its production
5) preempt a minimum of useful user vocabulary 6) be memorable.
In addition, the committe now worries about the dead hand of history. It
would be better if 7) words in the new standard were not the same as widely
used words with similar, but not identical, behavior.
For any particular word the result is going to be a design compromise,
because the criteria conflict. >COLROW, besides being ugly, clobbers 1).
It was advocated because of its compliance with 6) and 7), but I wonder
about 6). Most of the rival ideas, AT for instance, got whomped by 7).
(I have personally liked AT and AT? as a working pair).
POSITION pushes 2). My informal favorite is CURSE, but that will
no doubt have other problems. POINT and MARK have trouble with 5). At
the moment my personal candidate is SPOT, as in the way golfers place
their balls.
Anybody out there got the ideal solution?
-LenZ-
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/25/90)
Category 10, Topic 2
Message 219 Sat Feb 24, 1990
L.ZETTEL at 15:53 EST
I have just received my copy of the minutes of X3J14 meeting eleven. Since
I believe there is a finite porbability they w ll eventually be read by
somebody who was not at the meeting, and that it would not be easy to
understand the summary of the remarks I made if you weren't there, here
are the remarks re-expanded.
The basic ideas are those of Russell Ackoff. I apologize to Dr. Ackoff
for any mangling that may occur in the translation (I can protect myself
from my enemies, but what about my friends....?).
A *system* is a collection of parts, each of whose perfomance is
significantly affected by the behavior of at least one other part.
Dr. Ackoff presents as a theorem the proposition that when any system is
peforming as well as it can, none of the parts are performing as well
as *they* can. It follows as a corollary that any system in a state where
each part is performing as well as it can will not be performing
at maximum.
Consider the classic three part system, of which countless examples
have existed - a Forth novice, a Forth implementation, and a copy of
"Starting Forth". If the behavior of the implementation does not match
the behavior described in Starting Forth, the performance of the novice is
going to be impaired, even if the implementation is in some sense "better"
because of its changed behavior.
Dr. Ackoff presents an additional concept: A *mess* is a system of
problems. The important point to note is that a mess can not be
straightened out just by solving the problems of which it is composed.
You have to consider the way each problem acts on the others. In Ackoff's
view, what makes our time different is that we are recognizing and
dealing with messes more than any other era.
I submit that when you view the Forth scene at any level, what you will
see is a mess (in the technical sense given above, of course :-).). The
best thing for Forth that we can do is work together to solve it,
remembering that insisting on shoving any part (most definitely including
ours) too close to optimum will hurt the system.
-LenZ-
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'jax@well.sf.ca.us (Jack J. Woehr) (02/26/90)
ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: >L.ZETTEL at 15:53 EST > Len writes, in part ... > Dr. Ackoff presents an additional concept: A *mess* is a system of > problems. The important point to note is that a mess can not be > straightened out just by solving the problems of which it is composed. > You have to consider the way each problem acts on the others. That's the principle of Intrinsic Difficulty restated as a sociological theorem, Len, instead of in its normal context of Game Theory. Intriguing proposition, Intrinsic Difficulty is why you have to solve chess endings from the back rather than from the front. Now, if a mathematical solution could be found for Chess, defeating the vague presuppositions of Intrinsic Difficulty, what an impact that would have on *all* kinds of gamesmanship, from sales to international politics! It would be the moral equivalent of what Isaac Asimov's fictitious psychohistorian, Hari Seldon, discovered ... {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} {} jax@well ." Sysop, Realtime Control and Forth Board" FIG {} {} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {} {} JAX on GEnie ." Tell them JAX sent you!" Coordinator {} {} jax@well.sf.ca.us Now Starting to Attend ANSI X3J14 and going bald {} {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/27/90)
Date: 02-25-90 (22:23) Number: 372 (Echo)
To: L.ZETTEL Refer#: 371
From: DARRYL BIECH Read: NO
Subj: *MESS* Status: PUBLIC MESSAGE
Being a novice with FORTH, but involved with other languages as well, it
sounds like history repeating itself. Problems of group dynamics, and of
fears that an implementation may be left behind etc., or that the
standard will be too big. Having to support both Intel and Motorola
based architectures, and yet maintain performance and a high degree of
compatibility are difficult items for a small group to address let alone
a committee. If all the standard does is provide a good small core that
encourages increased commercial involvement, the language will benefit.
-d.b.
NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'dwp@willett.UUCP (Doug Philips) (02/27/90)
In <563.UUL1.3#5129@willett.UUCP>, DARRYL BIECH writes: > Being a novice with FORTH, but involved with other languages as well, it > sounds like history repeating itself. Problems of group dynamics, and of > fears that an implementation may be left behind etc., or that the > standard will be too big. Having to support both Intel and Motorola > based architectures, and yet maintain performance and a high degree of > compatibility are difficult items for a small group to address let alone > a committee. If all the standard does is provide a good small core that > encourages increased commercial involvement, the language will benefit. > -d.b. Has anyone on X3J14 yet read Plauger's comments on X3J11 in (Feb or Mar?) issue of Computer Language? He talks about some of the things that Darryl mentions. I recall reading somewhere (no, I don't remember where) that the folks that got involed with X3J14 initially didn't know much about the workings of ANSI. Perhaps someone on the committee now could drop ANSI a note and suggest that perhaps they oughta get something like Plauger's article to give to the various 'approach-ees' and perhaps cut down somewhat on 're-inventing the political wheel'? (Of course, this might be a good idea even if I'm wrong and the original X3J14 cast *did* know what they were getting into) -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (04/07/90)
Category 10, Topic 2
Message 222 Thu Apr 05, 1990
R.BERKEY [Robert] at 23:30 PDT
Re: Perspective on the state of BASIS
The Forth Vendors Group has been the leading source of input to the X3.J14
committee, having outlined the charter and officered the committee. A concern
of the vendors is in being able to say that their systems are ANS standard.
Inconsistently, the concern of programmers in being able to say that their
programs are ANS standard is belittled by elements of the committee. Consider
an idea presented recently in Forth Dimensions, "For example, machines that
use sign-magnitude numbers are rare and probably don't deserve much thought."
In my opinion that's double-talk. A program must concern itself with any and
all standard systems, otherwise it isn't standard. Note the suggestion at the
end of the quote to "not think", as in, "don't think about portability". A
Forth-83 system implemented on a sign-magnitude machine will run Forth-83
programs. If the sign-magnitude implementor implements what he/she feels like
implementing, and can call it ANS Standard, then of course programs will have
difficulty in being "portable".
Alas, if sign-magnitude and also one's complement machines are so rare, why is
the standard cutting some of the more useful elements in what we know as Forth
on their behalf?
By comparison, the X3.J11 "C" committee just took it for granted that
implementations would be undergoing substantive changes in order to support
the portability of programs.
The implementor viewpoint and political voice has taken from the Program, and
given to the System. And Forth-83 is no picnic for programs.
Losses to the standard program include:
@ and ! 50% capability remaining.
+ and - unsigned and wraparound math gone.
/ Mathematically neither a function nor an operator.
MOD A not-so-funny joke.
KEY This one just changed as of BASIS11. 32 out of 128
characters gone. Note that programs cannot get a
carriage return using KEY . (Some UNIX's usurp ^S and
^Q. With the Forth-83 spec, implementor's provide
programs some way for these characters to get from the
keyboard to the program, such as reserving function keys,
or specifying combinations of keystrokes that are
interpreted as one input to KEY .)
WORDLIST (nee VOCABULARY ) 0% remaining.
Mass storage 0% remaining.
Bit-mask literals 50%.
Addresses Cannot be compared. Cannot be entered into DO loops.
The basis for the floating-point wordset has been criticized in a
JFAR article as biased towards vendor interests.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'wmb@MITCH.ENG.SUN.COM (04/10/90)
> Losses to the standard program include: > ... > KEY This one just changed as of BASIS11. 32 out of 128 > characters gone. Note that programs cannot get a > carriage return using KEY . (Some UNIX's usurp ^S and > ^Q. With the Forth-83 spec, implementor's provide > programs some way for these characters to get from the > keyboard to the program, such as reserving function keys, > or specifying combinations of keystrokes that are > interpreted as one input to KEY .) Here is my 2 cent's worth on this issue: a) The definition of KEY in BASIS11 is broken. b) The reason is because there are 2 conflicting requirements, and people seem to think that the single word KEY must simultaneously fulfill both requirements. The 2 requirements: 1) "hardware key": returns a number indicating exactly which key (or keys, in the case of "chords", like shift, control, etc) that the user typed. 2) "ASCII key": returns a number from the set 0...127, representing a 7-bit ISO character. You can't have both (1) and (2) and call them the same word. Many peaple argue with great fervor that (1) is what they want, but (1) is not, and cannot possibly be made to be, portable. On the other hand, it can be used quite profitably in a section of code that is environmentally dependent (e.g. in a "DOS version" of an otherwise portable program). (2) is necessary for a program that intends to concern itself only with "standard characters". (Note that this self-imposed restriction can be valuable; those standard characters can be stored in files and transmitted across many communication channels. The further restriction of only using printable characters can also be valuable; note that we all pretty much adopt this further restriction in postings to these networks). Okay, you say, but why not make (1) the primitive and then synthesize (2) by masking off the high bits? Well, because it won't work. How does the program know whether those high bits are something boring like parity, or instead a code that tells you that the character is not an ASCII character at all, but instead a function key or a mouse event or something. (hex) C1 might be 'A' with parity, or it might be the "Home" key. Here is the most general solution, requiring 2 words (quibble about the names all you want; it's the semantics I'm interested in: KEYBOARD-EVENT ( -- n ) Returns a number specifying the next keyboard event. The encoding of the event is implementation-defined. All keyboard events that the Forth implementation is able to receive from its environment must be available through KEYBOARD-EVENT . EVENT>CHAR ( n -- false | char true ) If the event "n", as if returned by KEYBOARD-EVENT, represents a character in the ISO character set, returns true and that character. Otherwise returns false. Then, you code define the portable "KEY" as : key begin keyboard-event event>char until ; Why not just have 2 functions KEY and EVENT ? You have to specify what happens if the program is expecting an ASCII characters (with KEY) and instead the user types a function key, for instance. Does the function key get ignored? Thrown away? Stuck on a different queue for later transmission out-of-sequence? It is important to have a single function to receive an ordered sequence of primitive events, and an orderly way of interpreting those events. Mitch
wmb@MITCH.ENG.SUN.COM (04/11/90)
> Losses to the standard program [ from BASIS 11 ] include: > ... > @ and ! 50% capability remaining. > ... > WORDLIST (nee VOCABULARY ) 0% remaining. > ... > Mass storage 0% remaining. Can somebody explain to me what has been "lost" in these cases? Thanks, Mitch Bradley
ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/25/90)
Category 10, Topic 2 Message 225 Wed May 23, 1990 D.RUFFER [Dennis] at 23:19 EDT Well 43 proposals down, but it's hard to say how many more we have to go. We are really trying to get all the technical issues out of the way in this meeting, so please, if you have a technical issue to raise, do it now. The next meetings are to work on the documentation and structure of the Basis. Basis 12 will probably have a totaly new layout as we try to get it into its final form. If you have any thoughts on that, I'm sure the committee would like to hear them. The goal really is to be done by the end of the year, so if you are going to speak, do it now. More later. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/03/90)
Category 18, Topic 16 Message 13 Sat Jun 02, 1990 D.RUFFER [Dennis] at 17:10 EDT Re: ir230@sdcc6.ucsd.edu (john wavrik) > Declaring the action of fundamental words to be "implementation > dependent" is not the kind of compromise which will contribute to > portability. John, that wording is only used in cases where the committee members can not agree on the action. IMHO, specifying where those grey areas are goes a long way to helping me decide what things to avoid when writting a "standard application". It also means that I can choose to take advantage of a vendor's "value added" features if I do not care about portability. > How many users are aware of what has been decided? I agree with you there John, but I don't see many alternatives. Thanks to Mitch and others who have been keeping us aware of what is going on by discussing it openly. However, having been one of the ones who tried to make the whole process electronic, I can tell you it is not easy to get everyone involved. The process they are using now (paper mail) is adequate, but IMHO not sufficient. There are many people who can not contribute. However, anyone can order a copy of the BASIS, and starting with BASIS 12, anyone will be able to download it in electronic format. That is a step in the right direction, albeit very late, but about as much as we can expect. As for the goals of the TC, they were hotly discussed during this last meeting. I do not have a copy here at home, otherwise I would type them in, but they do describe precisely what ground rules the TC is using to decide what it is doing. It appears as if they have choosen different interpretations of those goals on occasion, but having read it very carefully, I feel it expresses all of our concerns. Perhaps someone with a copy will take the time to type it in for those who have not seen it. > Let me propose a simple test for doneness: > > Suppose the programmers at FORTH, Inc or any other software shop > that uses programming teams, were equipped with different > computers running randomly selected different ANSI-Standard > implementations of Forth. Would it be possible to complete > projects just as easily as now? That is certainly "a" test, but I'm not sure how valid it is. When we work on a project at FORTH, Inc. we are not even hampered by the standards of our existing polyFORTH. As ace programmers, we can make just about anything work no matter how the system works. If the system gets in the way of our solution, without hesitation, we change the system. Giving us ANS Forths would not make any difference, so by this test, the standard was "done" before we started. Let me suggest an alternative to your words: Suppose you were required to write an application that would run on any ANS Forth. Would it be possible? Notice, I did not say what kind of application, for IMHO that merely describes how rich the standard is. I also removed the requirement that it be as easy to write the application as it is now. Certainly writting portable applications is going to be harder than it is to write non-portable ones. Anyone who believes otherwise has not been writting applications long enough. This is also "a" test, and I contend that it is not possible now. Even with Martin Tracy's PRELUDE suite, you can not cover all the Forth implementations unless you limit yourself to such a small set of words that the application is impossible. Now, who is willing to propose an application that could be done with BASIS 12 so that we can call it done? > I believe that the ANSI effort is a one-shot deal. I certainly hope that is not the case, but it is certainly true that the current TC members are going to be burned out for a while after this standard is released. However, I believe we must have a dynamic standard that can be expanded as we learn new techniques. Certainly we could resolve a lot of the debates between the minimalists and the kitchen-sink groups by making the standard extensible, and I think that would fit very nicely with the nature of Forth. This is not the first time we have attempted to standardise Forth, and I can not believe it will be the last. This time, we have CBEMA telling us how to do it, so the standard might actually be followed. Let's just hope that the process does not kill the evolution. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
dwp@willett.UUCP (Doug Philips) (06/04/90)
In <1069.UUL1.3#5129@willett.UUCP>, D.RUFFER [Dennis] writes: > Re: ir230@sdcc6.ucsd.edu (john wavrik) > > > Declaring the action of fundamental words to be "implementation > > dependent" is not the kind of compromise which will contribute to > > portability. > > John, that wording is only used in cases where the committee members can not > agree on the action. IMHO, specifying where those grey areas are goes a long > way to helping me decide what things to avoid when writting a "standard > application". It also means that I can choose to take advantage of a vendor's > "value added" features if I do not care about portability. I agree with Dennis here. One of the most useful things that came out of X3J11 was a classification of kinds of behaviours into which things would be put. Implementation dependant is certainly a valid one, so long as the entire standard doesn't end up in it! You need to know exactly what is *and isn't* guaranteed by the standard. Knowing that word <X> is implementation defined means that you'll avoid using word <X> (or will explicitly define it yourself) if you care about portability. Just because this bin doesn't say strict things about the semantics of a word doesn't mean the bin is useless. (see Plauger's column in Computer Language [early 1990's, I can get the specific issue if anyone is interested] for more info along these lines). > not sufficient. There are many people who can not contribute. However, > anyone can order a copy of the BASIS, and starting with BASIS 12, anyone will > be able to download it in electronic format. Side Issue: Is this something that will benefit other standards or not? How did X3J14 pull it off? (X3J11 never did, but one doesn't know how hard they tried either, or what the political changes since then have been?) > Suppose you were required to write an application that > would run on any ANS Forth. Would it be possible? > > I also removed the requirement that it be as easy > to write the application as it is now. Certainly writting portable > applications is going to be harder than it is to write non-portable ones. > Anyone who believes otherwise has not been writting applications long enough. Yep. There was lots of flap about this kind of thing with X3J11. "If you do that you'll break my application/user's application." Such people don't seem to realize that ANSI/X3/X3Jn doesn't have that kind of power. Pointing out that something isn't portable doesn't suddenly make go from being portable to being not portable! On the other hand, there will be no X3J14 police going around to make sure your Forth conforms. If you want to push the envelope, the ANSI standard won't stop you. There is a case for having "standard libraries" even if they aren't part of "Forth" itself, or of the standard. I'm not quite sure how that worked out for the C people, but it makes a lot of sense. I'm not talking about layers of standard here, but just "appendices", such as Appendix J, the <X: say File System I/O> wordset. I think this is a good kind of thing and hope it manages to stay in. (It ain't over till its over!) > Let's just hope > that the process does not kill the evolution. It probably won't kill the evolution, but it might just take out a few people! :-) -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]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/06/90)
Category 18, Topic 16 Message 20 Mon Jun 04, 1990 D.RUFFER [Dennis] at 23:01 EDT Re: dwp@willett.UUCP (Doug Philips) > > will be able to download it in electronic format. > > Side Issue: Is this something that will benefit other standards > or not? How did X3J14 pull it off? They just finally decided to do it. I think what did it was that Jack and I both were there (we have both been pushing for it from day one). We also sell the BASIS which is not something normally done by other standards groups. I believe we are getting away with it on the arguement that it is being done to promote the submission of proposals. In fact, that is stated right on the first page: "This document exists only as a platform for making proposals" > there will be no X3J14 police going around to make sure your > Forth conforms. I consider this a serious problem that I would like to try to solve. Is anyone else interested in working on a test suite? I would like to see an impartial organization (like FIG) offer tests to all the vendors and award certificates of compliance to those who pass the tests. I think it can be done, but it will take people who are willing to work on the tests, and impartial judges who could do the testing. Do we have any volunteers? DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/11/90)
Category 18, Topic 16 Message 22 Sun Jun 10, 1990 D.RUFFER [Dennis] at 16:11 EDT John Wavrik writes: > If the panel discussion idea appeals to you, or you have something > that would work better, write to Dennis Raffer. [If you can't > mail to him, send your comments to me and I will forward them.] Just a minor note that it's Ruffer not Raffer, but any comments sent over this forum get to me, and most I do forward to the TC Chair (Elizabeth Rather). I highly recommend everyone to respond to John's request. We have talked about it before, and while I am certainly willing to sponsor this, I question if there is enough people who are interested to make the efforts worth while. These electronic messages have been criticised in the past for not being very representative of the Forth comminity as a whole. It can be justly argued that we only represent a handful of people. If we are to have an impact on the TC with any of our activities, we must show them that we have wide participation among the community. That impression if not there today. John's idea may just be a way to show the TC who is listening. Speak up NOW! DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
dwp@willett.UUCP (Doug Philips) (06/11/90)
In <1131.UUL1.3#5129@willett.UUCP>, D.RUFFER [Dennis], writes: > > These electronic messages have been criticised in the past for not being very > representative of the Forth comminity as a whole. It can be justly argued > that we only represent a handful of people. If we are to have an impact on > the TC with any of our activities, we must show them that we have wide > participation among the community. That impression if not there today. > John's idea may just be a way to show the TC who is listening. I don't get it Dennis. I don't think John was suggesting that the Net be considered the whole Forth community, but I fail to see how that is an important issue. The TC should be evaluating proposals on the basis of their merits, not on how big a cabal is shouting to have them put in. [0.5 * :-)] I seem to recall that in past issues of Forth Dimensions there were articles about the ongoing standard and issues being discussed. Between that and ForthNet, I see no other mass medium available to keep the Forth community informed about the standards process, do you? Just because you can't get everybody you shouldn't try for anyone? (Does anyone even know how many people read ForthNet?) -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]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/16/90)
Category 18, Topic 16
Message 27 Sun Jul 15, 1990
GARY-S at 07:29 EDT
Subject: How will others see ANS Forth?
In article Message-ID: <9899@pt.cs.cmu.edu>
koopman@a.gp.cs.cmu.edu (Philip Koopman) writes:
>I had a conversation with a Peter Lee of CMU this week about
>the ANS Forth Standard effort. Peter is a professor in the
>School of CS in the advanced programming language group.
>
>Some folks are worried about how Forth will be judged when
>outsiders see the new standard. My brief interaction with
>Peter indicates that perhaps there is some merit to their
>concern. One way to solve this would be to find a few
>non-Forthers to review the standard in its penultimate form.
>This should include both engineers and computer scientists
>who are *not* Forth experts. I can probably talk Peter into
>a 1- or 2-hour review. Can anyone else recruit people from
>their organizations? Will folks on X3J14 listen if we
>go to this trouble?
Phil - IF you do go to that much trouble, we will be happy to make
the GEnie Forth Real-Time Conference facility available for this
discussion. The transcript would then be available for distribution
by whatever means you choose. I would recommend via servers, but I
will leave that to your good offices. We would maintain a copy on
GEnie and I am guessing Tommy Rolf would be willing to archive a
copy on OLIS. We will have to wait for a reply from Tommy to be sure
that he would do so. I would also recommend distribution to the X3J14
committeee members.
Gary
___ _ Gary Smith <---- co-SysOp, GEnie Forth RoundTable
/ _' _ _ (_ P. O. Drawer 7680 * ph:501-227-7817, fax:501-228-0271 *
/__/ (_|_/ '__) Little Rock,AR 72217 * winken!well!gars *claris!wet!gars *
gars@glsrk.uucp - U. S. A. - * ames!chinet!gars * ark!lrark!gars *
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Date: 08-22-90 (20:27) Number: 3688 (Echo) To: ALL Refer#: NONE From: JACK BROWN Read: (N/A) Subj: X3J14 MEETING 13 Status: PUBLIC MESSAGE The 13th X3J14 ANS Forth Standardization Meeting is underway in Vancouver BC ( at BCIT in Burnaby to be correct). We have put the following three burning issues to rest. * Floating point stack * Division * Orphans I'll post the details later. NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Date: 08-23-90 (08:20) Number: 463 (Echo) To: ALL Refer#: NONE From: JACK BROWN Read: (N/A) Subj: X2J14 MEETING 13 Status: PUBLIC MESSAGE The following proposal has been passed by both the X3J14 TSC and TC at the Vancouver Meeting to remove the floating-point stack burning issue. Proposal TP90-729 "Remove Floating-Point Stack" was failed by TSC and TC. +------------------------------------------------------+---------------+ | ANSI X3J14 Forth Technical Proposal |Page 1 of 2 | +------------------------------------------------------+---------------+ | Title: Keep Floating-Point Stack | |----------------------------------------------------------------------+ | Related Proposals: TP90-729 (Remove Floating-Point Stack) | +------------------------------------------------------+---------------+ | Keyword(s): floating-point stack , |Proposal ( x ) | | floating-point number , floating-point format |Comment ( ) | +------------------------------------------------------+---------------+ | Forth Word(s): FDEPTH ENVIRONMENT? | | | +----------------------------------------------------------------------+ | Abstract: Allow ANS Forth systems that include the Floating-Point | | Word Set to keep floating-point numbers on either the data stack | | or a separate floating-point stack. | +----------------------------------------------------------------------+ | Proposal: | | 1) Change all occurances of the phrase "floating point" | | in the document to "floating-point" and make terms | | "floating-point stack" , "floating-point number" , | | "floating-point format" , "floating-point equality" | | "floating-point package" , "floating-point value" and | | floating-point search terms for the concordance. | | 2) Add the following entry to the attribute list of | | 7.1345 ENVIRONMENT? | | Name Type Interpretation | | -------------------------------------------------------- | | FLOATING-STACK n if n=0 floating-point numbers are kept on | | the data stack, otherwise n is the maximum | | depth of the separate floating-point stack | | 3) Change 4.0410 floating-point stack to: | | A last in, first out list that is used by all floating-point | | operators. The width of the floating-point stack is | | implementation-defined. | | By default the floating-point stack is separate from the data | | and the return stacks. A program can determine whether floating-| | point numbers are kept on the data stack by passing the string | | " FLOATING-STACK" to ENVIRONMENT? . | | | | 4) Change 7.1497 FDEPTH description to: | | +n is the current number of floating-point values contained | | on the default separate floating-point stack. If floating | | point numbers are kept on the data stack +n is the current | | number of possible floating-point values contained on the data | | stack. | | 5) Add to 6.8.1 Stack Parameter Abbreviations | | | | Stack Abbr Number Type Range in Dec Size on Stack Size in Mem | | r floating-point impl-defined impl-defined impl-defined| | number | | ( continued ) NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Date: 08-23-90 (08:25) Number: 464 (Echo) To: ALL Refer#: NONE From: JACK BROWN Read: (N/A) Subj: X3J14 MEETING 13 Status: PUBLIC MESSAGE Part 2 of Keep Floating-Point Stack. +------------------------------------------------------+---------------+ | ANSI X3J14 Forth Technical Proposal, cont'd |Page 2 of 2 | +------------------------------------------------------+---------------| | Title: Keep floating-point Stack | +----------------------------------------------------------------------+ | 6) Add the following sentence to 6.7.3 floating-point stack | | Floating point-stack notation when the floating-point stack | | is separate is for example | | | | F! ( a-addr -- ) ( F: r -- ) | | or | | F! ( r a-addr -- ) | | when kept on the data stack. | | | | 7) Create a combined data stack diagram for all floating point | | words using the following algorithm: | | If floating-point numbers are kept on the data stack the | | stack notation ( F: before -- after ) should be read as data | | stack notation. If data stack notation present then | | the data stack "before" arguments are placed on top or after | | the floating-point "before arguments". | | | | | +----------------------------------------------------------------------+ | Discussion: | | | | 1) The phrase floating-point xxxx and floating-point xxxx | | where xxxx = stack , number , equality etc are both used in | | the document. We should be consistent and use one or the other. | | I prefer hyphens. | | | | 2) This will allow an ANS Forth program to determine how the | | floating-point stack is implemented which should address the | | concern of proposal TP90-729 | | | | 3) Update 4.0410 to reflect change to ENVIRONMENT? | | | | 4) Modify definition of FDEPTH to allow for floating-point numbers | | on the data stack. When floating-point numbers are kept on the | | data stack the following definition of FDEPTH should work in | | many systems. : FDEPTH DEPTH CELLS 1 REALS / ; | | This assumes that numbers would be represented in memory the | | the same as they are on the data stack. | | | | 5) The designation of r for floating-point number is missing | | from 6.8.1 | | | |6&7) We need to state how to read the floating-point stack notation | | when floating-point numbers are kept on the data stack. The | | alternative is to explicitly give the alternate data stack | | notation for each word that has floating-point stack notation. | | | +----------------------------------------------------------------------+ | Submitted by: Jack W. Brown NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Category 10, Topic 2 Message 229 Sun Aug 26, 1990 B.RODRIGUEZ2 [Brad R.] at 16:33 EDT Is this for real? This proposal seems to guarantee that anyone wishing to write a "Standard" application using floating-point will have to write everything twice. Then, of course, at the beginning of your standard program you can test the environment and decide which copy of the application to run. (I invite counter-examples.) BTW, what's this ENVIRONMENT? thing which takes a string argument? (Where's my BASIS document?) I'm reluctant to comment until I see its ANS definition, but it sure seems like someone is taking immense pains to do things the hard way. (Isn't parsing strings what we have a dictionary for?) Better a bad decision than no decision at all, guys. - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
a684@mindlink.UUCP (Nick Janow) (08/28/90)
ForthNet@willett.pgh.pa.us (B.RODRIGUEZ2 [Brad R.]) writes: > This proposal [floating point] seems to guarantee that anyone wishing to > write a "Standard" application using floating-point will have to write > everything twice. Then, of course, at the beginning of your standard program > you can test the environment and decide which copy of the application to run. Nope, it means that you have to write all your floating point code under the restrictions of both (separate FP stack and single data stack). I wasn't happy to see the restrictions, but after a _loooong_ discussion, it seemed like the best compromise. Hopefully, by the time the standard is reviewed again (5 yrs?), the majority of stack machines (RTXn000?) will have separate FP stacks and we can drop the coding restrictions. If anyone wants the standard to be separate FP stack only, all you have to do is come up with an argument that will convince the ANS committee to choose that method. Good luck (you'll need it). :-)
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/29/90)
Category 10, Topic 2
Message 230 Tue Aug 28, 1990
D.RUFFER [Dennis] at 01:00 EDT
Re: B.RODRIGUEZ2 [Brad R.]
> what's this ENVIRONMENT? thing which takes a string argument?
7.1345 ENVIRONMENT?[730] "environment-query" CORE
( b-addr u -- value true ) (known)
or -- false ) (unknown)
b-addr is the address of a text string and [ED] u is the string's character
count. u may have a value in the range from 0 to an implementation-defined
maximum which may not be less than 31. The text string should contain [ED] a
keyword from the table below [ED] to be checked for correspondence with an
attribute of the present environment. If the system treats the attribute [ED]
as unknown, the returned flag is false; otherwise, the flag is true and the
value returned is of the type specified in the table for the attribute
queried. [ED]
Name Type Interpretation
/ALIGN n alignment granularity, in address units of an
aligned address.
/CHAR n size of a character in address units
/COUNTED-STRING n maximum number of characters in a counted
string
/DATA-SPACE n size of the aligned data space in address units
/HOLD n maximum size of a pictured numeric output
string in address units
/PAD n size of the scratch area pointed to by PAD,
in address units
/TIB n size of the text input buffer in address units
ADDRESS-UNIT-BITS n Size of one address unit in bits
BLOCK flag block word set present
BLOCK-EXT flag block extension word set present
CORE flag core word set present
CORE-EXT flag core extension word set present
DOUBLE flag double number word set present
DOUBLE-EXT flag double extension word set present
FAR-MEMORY flag far memory word set present
FAR-MEMORY-EXT flag far memory extension word set present
FILE flag file word set present
FILE-EXT flag file extension word set present
FLOATING flag floating-point word set present
FLOATING-EXT flag floating-point extension word set present
FULL flag full compliance
LOCALS flag locals word set present
LOCALS-EXT flag locals extension word set present
MAX-D d the largest usable signed double number
MAX-FLOAT r the largest usable floating-point number
MAX-N n the largest usable signed integer
MAX-U u the largest usable unsigned integer
MAX-UD ud the largest usable unsigned double number
MEMORY-ALLOC flag memory allocation word set present
MEMORY-ALLOC-EXTflag memory allocation extension word set present
RETURN-STACK-CELLS n the maximum size of the return stack in cells
SEARCH-ORDER flag search order word set present
SEARCH-ORDER-EXTflag search order extension word set present
STACK-CELLS n the maximum size of the data stack in cells
STRING flag string word set present
STRING-EXT flag string extension word set present
WORDLISTS n the maximum number of wordlists usable in a
fixed search order
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.usForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 2 Message 231 Fri Aug 31, 1990 D.RUFFER [Dennis] at 13:15 EDT From Elizabeth Rather, Chair, ANS X3J14 Technical Committee: This is addressed to those who have been commenting extensively on our work on UseNet and related boards. We very much appreciate your interest. I have circulated copies of many of your comments in the TC. I'd like to take the opportunity to try to clarify a few things. Current membership is 21 people. Roughly one third are implementors, and only a few of those are commercial vendors. Of the users, they include users of most commercially available systems, as well as individuals who "roll their own" and love it. It's a self-selected group of masochists willing to donate many hours (about 200 hours/year/member in meetings, plus time spent outside meetings) and money for travel. Some are very advanced experts, others just casual users. We've gone to a lot of effort to meet in most parts of the country in order to enable local Forth users to attend at least one meeting: we've met in Washington DC, LA, Northern CA, San Diego, Rochester, Boston, Melbourne FL, Portland and Vancouver. Future meetings are planned for Detroit (11/6-10/90), Los Angeles and Colorado, and we'll happily entertain other suggestions. It's also very easy to join: you can be a voting member of the TC at your second consecutive meeting, and you can vote in the technical sessions on your first visit. Our efforts to get a broad base of input have paid off with active participation (attending meetings, submitting proposals, etc.) of nearly 200 people over the three years we've been working. We're delighted that Nick Janow enjoyed meeting with us, and hope more of you will come. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 2 Message 232 Sun Sep 02, 1990 B.RODRIGUEZ2 [Brad] at 10:00 EDT Thanks, Dennis. As the fates would have it, my copy of BASIS12 arrived the day after I posted that message. Do I understand correctly that this document is now obsolete? It says it expires on the next meeting, on August 21st. It was _postmarked_ August 22nd. This sort of thing makes it very difficult to submit proposals to the committee! --- Elizabeth: what proportion of the TC work is done in the technical sessions? Your peripatetic schedule has finally brought the TC within reach (Detroit), but if all I can do is sit and watch the TC, I may just send a friend with a VCR. :-) - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 2 Message 233 Sun Sep 02, 1990 D.RUFFER [Dennis] at 16:55 EDT Re: B.RODRIGUEZ2 [Brad] > Do I understand correctly that this document is now obsolete? It > says it expires on the next meeting, on August 21st. It was > _postmarked_ August 22nd. This sort of thing makes it very > difficult to submit proposals to the committee! Yep, you understand correctly Brad. The BASIS is only a valid document until the next meeting of the TC where proposals will be accepted that change portions of it. This last time, we ran VERY late getting it out. We managed to send the TC member copies just within the 2 week rule by copying them internally. The rest of the copies were made by a second party and we did not get them out until the meeting had started. Either way, the copies arrived too late and we appologize for that. We hope to do better, but that just reinforces our reasons for not wanting to go to a lot of extra work distributing multiple types of formats. BTW the electronic copy appeared here on GEnie the same day that we printed the TC member copies. That was August 1st. > what proportion of the TC work is done in the technical sessions? The way that the sessions usually go is that the TC meets in the morning. Then it adjourns and the Technical Subcommittee starts up. In the TSC is where all the "real" work happens and where anyone who is present can discuss and vote on the issues. Once the TSC discusses and votes on the proposals, they are sent to the TC where only TC members can vote. Typically, by that point, the issues have been ironed out and the votes go by quickly. If for any reason debate still exists in the TC, the proposal is sent back to the TSC for more work. Thus, if you want to come to a TC meeting, I assure you that you will not be bored. They will try their best to get you sucked into the process and most certainly will put you to work. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/07/90)
Category 18, Topic 16 Message 36 Thu Sep 06, 1990 D.RUFFER [Dennis] at 01:19 EDT Re: ir230@sdcc6.ucsd.edu (john wavrik) > "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: Use POSTPONE in place of ' , COMPILE [COMPILE] In most cases, that is all you will ever need. If you know of a specific case where this will not solve the problem then you may need to look at the problem in a different light. This may mean re-writing sections of your code. However, the goal of the ANS Forth Standard is to enable you to *WRITE* portable code, not to make non- portable code magicly become portable. >> To do more would prevent those systems from >> complying with the standard. > I think this is an example of the kind of thinking that is > crippling the standardization effort. I am very sorry that you think Chuck Moore, Harris Semiconductor, etc. have "crippled" Forth, but that's life. If the biggest supporter of Forth in hardware and the designer of Forth decide that stack addressing is not necessary, then I guess someone might want to listen. The people who listened have changed Forth, and the ANS TC *must* listen and write a standard that allows them to participate. Otherwise, what do we have, two standards? Three? > Do we say that because a special class of machines is not suited > for recursion, Forth in general will not be suited for recursion. > The ANS-Forth approach to language standardization is to choose > the second alternative. This is hogwash John. Of course Forth can do recursion. Even before RECURSE (and all its variants) Forth programmers knew how to do it and the ANS TC recognizes it by including the word in the CORE wordset. However, good programming practices dictate that the programmers knows what resources his program uses and checks that those rsources are available before attempting to use them. Let me ask you John, if you buy a software package for a PC that says that it requires 512K of memory to operate, do you get pissed because it does not operate on your 256K machine? Maybe, but if you really want to run that package, your only recourse is to go out and buy more memory. What the ANS TC has given us is the same capability that exists for PC memory. The program can inquire about how much stack space is available, and it it is not enough, it can abort with an appropriate error message. On your system, you as a user can easily solve the problem (as you have shown), and IMHO most Forths will have a similar capability. It is even likely that providers of CPU Forth systems will also provide their users with some capability to increase the stack, possibly with performance penalties. However, let's not muck up the standard with something that would hamper how the vendors might accomplish it. Are you also pissed that you can't run my 320K portable application in your 64K system? > [We must ask whether we are in danger of eliminating from Forth > precisely those qualities which would lead someone to pick it in > preference to other languages.] Do you have doubts that the vendors who are on the TC have asked this question and continue to ask it every time someone wants to add something that they can not support? That IS the whole point. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/10/90)
Category 10, Topic 2 Message 234 Sun Sep 09, 1990 B.RODRIGUEZ2 [Brad] at 20:10 EDT Apology accepted, Dennis. At our FIG chapter meeting yesterday we formed a working group to critique the ANSI documents and submit proposals to the TC. We all have BASIS12 -- should we bother commenting on it? How much was changed at the last meeting? When will BASIS13 be available? BTW, I don't have Microsoft Word, so I can't use electronic distribution. Thanks for the info re. TC vs. TSC. You may have _two_ Ontario attendees at the Detroit meeting. (When and where is it?) Provided, of course, that we get BASIS13 beforehand. Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/12/90)
Category 10, Topic 2 Message 235 Mon Sep 10, 1990 D.RUFFER [Dennis] at 22:52 EDT Re: B.RODRIGUEZ2 [Brad] > We all have BASIS12 --should we bother commenting on it? How > much was changed at the last meeting? I've heard that a lot of stuff was either ripped out or modified at the last meeting, but I would sincerely suggest submitting comments on BASIS12. You very well may catch something that they missed. Also, proposals for things that have already been fixed are very easy to take care of. Very quickly, they can recognize that the proposal is "moot" and can dispense with it immediately. > When will BASIS13 be available? I haven't got a clue Brad. Hopefully sooner than last time. > (When and where is it?) [Detroit meeting] I haven't heard any further details yet Brad. I will try to forward them as soon as I know. Stay tuned. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/12/90)
Category 10, Topic 2 Message 236 Wed Oct 10, 1990 D.RUFFER [Dennis] at 22:50 EDT Re: B.RODRIGUEZ2 [Brad] > Elizabeth: what proportion of the TX work is done in the > technical sessions? Your peripatetic schedule has finally > brought the TC within reach (Detroit), but if all I can do is > sit and watch the TC, I may just send a friend with a VCR. :-) Reply from Elizabeth Rather: Virtually all our work is done in the technical sessions, where all are welcome to discuss and even vote. Only when consensus is reached in this "free for all" technical forum are issues forwarded to the TC where formal voter's rules apply. Please do come! Your contributions will be very helpful! Unfortunately, most of us are camera shy, and we previously voted not to allow recording. EDR --------------- Sorry it took me so long to get that turned around Brad, September was an exceptionally bad month for me (in fact, things really haven't lightened up yet :-(. Anyway, I'm glad she could get a reply back to youu before the meeting. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Category 10, Topic 2 Message 237 Fri Oct 12, 1990 D.RUFFER [Dennis] at 00:50 EDT ANSI X3J14 November 6-10, 1990 Meeting Information Meeting Site: The meeting will be held in Conference Room A of the Manufacturing Development Center (MDC), Ford Motor Company, 24500 Glendale Avenue, Redford Township, Michigan. Secure storage for computer gear will be available. Lodging: A block of rooms has been reserved in the name of ANS X3J14 at the Holiday Inn, Livonia at a rate of $39.00 per night. The Inn is at 30375 Plymouth Road, Livonia. (Do not confuse it with the Holiday Inn West). Their local phone number is (313) 261-6800. It is 3.7 miles from MDC. There are a movie theatre, shopping mall, and restaurants within a block of the motel. The Travelers Motor Inn, 9939 Telegraph Road, Detroit, Michigan (313) 533-9900 is AAA approved. It offers two (2) single units at $29.95 per night (reserve early!). It has doubles at $32.95. It is 1.6 miles from MDC. For those with a taste (and wallet) for good living, we recommend: The Dearborn Inn Hyatt Regency Ritz-Carlton 20301 Oakwood Blvd. 2 Fairlane Town Center 300 Town Center Drive Dearborn, MI Dearborn, MI Dearborn, MI (313) 271-2700 (313) 593-1234 (313) 441-2000 These are all about 8 miles (15 minutes on the freeways) from MDC. Rates are in the neighborhood of $80 (check them for exact quotes). Transportation: Fly into Detroit Metro airport. In the Detroit area, public transportation (buses etc.) is effectively non-existent (we ain't Motor City for nothin). Plan on using your own or rented wheels or Taxis. All major car rental agencies are represented at Detroit Metro, including: Avis (313) 942-3450 Budget (313) 355-7900 Dollar (313) 942-1900 Hertz (313) 729-5200 To get to MDC from the airport: Go east (toward Detroit) about three miles on I-94. Get off at the Telegraph (north) exit. This exit is on the LEFT side of the freeway. Go north eight miles to Glendale Avenue and turn left. MDC is about half a mile on the left. To get to the Holiday Inn from the airport: Follow signs directing you to Middlebelt Road. Go north (left turn onto Middlebelt) eight miles to Plymouth Road. Turn left onto Plymouth Road. The Inn is on the left about half a block down. To get to MDC from the Holiday Inn: Go east on Plymouth Road two miles and turn left (north) onto Beech- Daley. Go north about .6 miles (just past the railroad viaduct) and turn right (east) onto Glendale Avenue. MDC is about half a mile down on the right, just past Flint Ink. If there is sufficient interest (contact Len Zettel if interested) we may be able to arrange transportation to and from the Inn once each way each day. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Category 10, Topic 2 Message 238 Sun Oct 14, 1990 B.RODRIGUEZ2 [Brad] at 17:11 EDT Many thanks, Dennis! Elizabeth's reply is still timely. I am encouraged to attend the next ANSI meeting. (BTW, the remark about sending a friend with a video camera was facetious.) Thanks also for the meeting notice. November 6-10 is awfully short notice; I thought it was to be December? I have prior commitments for November 9, but perhaps I can make the first 3 days. I'll spread the word around here. - Brad P.S. I may be in your neighborhood in about a week; should I bring my baseball bat for an enlightened discussion? :-) ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Category 10, Topic 2 Message 240 Mon Oct 15, 1990 B.RODRIGUEZ2 [Brad] at 06:14 EDT An afterthought...BASIS12 was distributed to us poor souls after it became obsolete, and thus after it was too late to comment on its adoption. Now the next meeting has been announced, and BASIS13 made available electronically -- not in print form, only to owners of Microsoft Word -- with a scant three weeks notice. I recall something about proposals to the TC needing to be received two weeks in advance. And, of course, travel on short notice is usually twice as expensive. Serious question, with no offense intended: is this just bad planning, or is the TC trying to discourage further input from the masses? - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
Category 10, Topic 2 Message 241 Mon Oct 15, 1990 D.RUFFER [Dennis] at 23:46 EDT Brad, if you can get the job done faster, or better, please step forward and volunteer to take the job. I understand the frustration you feel, but give us a break already. Getting the meeting arrangementes made, and getting the changes into the BASIS document are not easy tasks. This time, Leonard Zettel did both jobs and he did them as fast and as good as he could. If you can do better, please step forward. If not, complaining about it will not help. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/28/90)
Category 10, Topic 2 Message 243 Fri Oct 26, 1990 D.RUFFER [Dennis] at 22:45 EDT Memo to: People interested in submitting proposals for ANS FORTH From: E. Rather, Chair, X3J14, TC for ANS FORTH RE: Proposal format and guidelines The Technical Committee encourages proposals from anyone interested in ANS FORTH. Attached is a recommended format for a proposal. Following are some guidelines to help you form your proposal for maximum effectiveness. 1. Before submitting your proposal, discuss it with a current TC member if possible. Members are listed in the front of BASIS. This can help you avoid proposing something that has already been considered exhaustively, or to understand why certain actions have been taken. If you submit a proposal, having had this discussion will help you focus it for maximum impact. 2. Phrase your proposal as an actionable item, a specific change to BASIS. For example, instead of observing that something is unclear, propose language that you think would be clear. 3. Include a rationale, which not only explains what problem this proposal is trying to solve but also why this is the right solution. 4. Confine your proposal to a single topic (e.g., division). If you're concerned about several topics, write several proposals. 5. Keep it short and simple. Proposals longer than two pages are very hard to deal with, and rarely pass. Following these guidelines, I include a copy of the document describing our "Scope of Work" to help you understand what types of proposals are likely to receive favorable consideration. For example, we have rejected a number of proposals for "nifty" collections of words which have been valuable to the author but are not in widespread use, supported by most vendors, or included in a previous standard. We have a few other internal guidelines: we avoid changing the function of a word from its FORTH83 meaning (e.g., NOT) or widespread practice (e.g., EVAL) without also changing its name; we avoid imposing implementation restrictions or assumptions about CPU or host OS; and we prefer both word names and descriptions that emphasize what the word does rather than how it does it. Our next meetinc vill begin November 6, in Detroit. Anyone who is interested in this process is welcome to attend. Most of our work is done in an informal "technical subcommittee" consisting of all TC members plus all visitors. Only when this body has reached consensus on an issue does it go to the TC for a formal vote. If you think you will be coming, please contact our host, Leonard Zettel of Ford Motor Co., at (313) 592-2773, for specific directions. Thank you very much for your interest and effort on behalf of the standard. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/28/90)
Category 10, Topic 2
Message 244 Sat Oct 27, 1990
D.RUFFER [Dennis] at 00:38 EDT
Scope of Work for X3/J14
The purpose of this resolution is to outline the scope of work for this TC.
It is based upon the project proposal adopted by X3J14/005. The intent is to
present an outline of the significant steps to be followed to achieve an
acceptable standard which will result in broad compliance among all major
vendors of Forth language products, with minimum adverse impact upon
transportability from existing systems in use.
The scope of work for X3/J14 shall encompass the following:
1. Identification and evaluation of common existing practices in
the area of the Forth programming language. This shall include
the following:
a. Identification of all producers of Forth language programming systems
with a distribution in excess of 200 users.
b. Evaluation of Forth implementations distributed by these producers with
respect to the FORTH-83 standard, to identify the primary areas of non-
compliance. Areas in which most producers are in compliance, or in agreement
on a concept outside of the scope of the FORTH-83 Standard, will be considered
to be "accepted practice".
c. Public solicitation from these producers as well as other sources
represented on the TC of specific problem areas within the FORTH-83 Standard,
and recommendations for change. Problem areas are areas of accepted practice
where producers' implementations vary. Problem areas specifically do not
include concepts new to Forth intended to improve perceived deficiencies in
Forth as defined by accepted practice, unless deemed indispensable to the
production of a coherent standard.
2. Evaluate proposed modifications to the FORTH-83 Standard
resulting from Item 1c above, addressing the following areas:
a. Arithmetic and logical operators
b. Flow-of-control structures
c. Input and output operators
d. Memory and mass storage operators
e. Exception handling
f. Vectored execution
g. Compiler extension operators
h. Data description operators
i. ROM-based applications
j. Any other areas that emerge from the study as representing
significant problem areas.
3. Proposed modifications to FORTH-83 shall be deemed unacceptable
if they result in significant variance from "accepted practice"
as identified in Item 1b above, or if the proposed definition
is outside the standards of clarity and unambiguity required of
an ANS.
4. Once an ANS Forth has been approved, the TC may address
proposed standards for language extensions beyond the scope of
item 1 above. Areas in which such extensions may be considered
include data base support and graphics. Other extensions will
doubtless emerge, and may be considered at the discretion of
the TC following approval of ANS Forth.
5. The TC may review existing and proposed standards for other
languages.
6. The TC will consider areas in which the BASIS document or accepted
practice is in conflict with modern hardware characteristics.
7. The TC will primarily consider one's and two's complement
architectures.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/28/90)
Category 10, Topic 2
Message 245 Sat Oct 27, 1990
D.RUFFER [Dennis] at 00:41 EDT
ANSI ASC X3/X3J14 Forth Technical Proposal Page n of m
===============================================================
Title: (title here)
Related Proposals: (list related proposal titles, if any)
Keyword(s): (key words, phrases, or concepts)
Forth Word(s): None
Abstract:
(Brief summary here.)
Proposal:
(State your proposal here. This section should specify one or more specific
changes to BASIS; general observations or comments belong in the discussion
section.)
Discussion:
(Include here arguments for or against your proposal.)
===============================================================
Submitted by: (Name, company) Date: 10/26/90
Address: (street)
(city, state, zip)
Phone: (aaa) nnn-nnnn
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/29/90)
Category 10, Topic 2 Message 247 Sun Oct 28, 1990 GARY-S at 06:58 EST In GEnie message Category 10, Topic 2 Message 246 Sat Oct 27, 1990 B.RODRIGUEZ2 [Brad] writes: >You may regret the day when you encouraged me to get *more* involved. :-) This is _anything_ but true, Brad ! How sad others are not taking the same active interest in ANS Forth as it is being drafted. We ( all of us ) need the hollistic involment of the 'Forth community'. Forth is the only true 'grass-roots' language I know of with the capability to carry a project from prototype to production, yielding to needed hacks along the way. This X3/J14 Technical Committee has been more public than any in ANSI history, yet remains ignored by the public it serves. Regret your involvment ? Not hardly. I regret the echo I hear when you speak in a nearly empty chamber. At least, your voice isn't lost in a vacuum - yet. Stay tough, Brad. Voice your concerns and generate proposals. I, for one, appreciate you, and I am sure I am not alone. Gary ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/26/90)
Category 10, Topic 2
Message 251 Sat Nov 24, 1990
LRWEBBER at 21:50 EST
I am somewhat new to this bulletin board and newer to this topic so please
bear with me if my text is < perfect. I have a comment and two questions:
Comment: I am learning forth (FPC 3.5) and love it. I am a software engineer
at a shop using mainly 'C' but we have one application using H.S. (Harvard
Software) forth and the success and versatility of the language (and
application) have interested others at work in forth. End comment :
Question: 1. when is the forcasted/expected/anticipated date that the ANSI
committee expects to finish with their work..in the eyes
of our management, forth will then become "legitimate".
2. which category/topic should I address when I have questions
about FPC
Thanks,
Larry
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/26/90)
Category 10, Topic 2 Message 252 Sun Nov 25, 1990 D.RUFFER [Dennis] at 21:12 EST Ah, it's Larry. Please type NAME at the Bulletin Board prompt so that your name will be appended to your address on the messages you leave. It really help us know what to call you if/when you forget to sign your postings. Category 1, Topic 21 is where the F-PC messages belong and where you will find a lot of existing information already. There is also a tutorial going on in its own category (14 or 15 I think). As far as a finish date for the ANS Forth efforts, I've been sort of waiting until the minutes from the last meeting come out (sometime next week maybe). However, since you ask, I guess I can slip out a little news. THE PROPOSAL BOOK IS EMPTY folks! That must mean that there are only a few remain issues left to resolve (right? :-). Basis 14 should be really close to final. Actually, they are really hoping to get the thing out for the public comment phase by the end of next year (or earlier). Maybe, just maybe, if we all try to be as constructive as possible, they might just be able to acomplish it. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/28/90)
Category 10, Topic 2 Message 254 Mon Nov 26, 1990 D.RUFFER [Dennis] at 23:52 EST Larry, BASIS 14 is the next version of the prelimnary ANS Forth document that we have been distributing as a basis for making proposals to the X3J14 Technical Committee (TC). They are preliminary documents that are out of date as soon as the TC meets. They just met a couple of weeks ago in Detroit and the document that will come out of that meeting will be called BASIS 14. We distribute it in paper form from the Forth Interest Group or directly from the TC Chair (Elizabeth Rather at FORTH, Inc.) for $10, or you will also be able to download it in RTF format here on GEnie or from any of the Forth Bulletin Boards that carry it. We should have it out in a few weeks (we hope). DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/29/90)
Date: 11-25-90 (22:43) Number: 294 of 303 (Echo)
To: LRWEBBER Refer#: 280
From: JACK WOEHR Read: NO
Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> Question: 1. when is the forcasted/expected/anticipated date that the
-> ANSI committee expects to finish with their work..in the
-> eyes of our management, forth will then become "legitimate".
Hopefully, DPAns will be proposed in 1 Q or 2 Q 1991. Then
the proposed standard will have to be submitted to the ANS parent
body. Then will follow a mandatory comment period.
So I would say that optimistically one could look for 3 Q or
4 Q 1991 as the date for ANSForth. Pessimistically, take your own
cynical guess!
=jax=
Member X3J14 Technical Committee.
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/29/90)
Category 10, Topic 2
Message 256 Thu Nov 29, 1990
D.RUFFER [Dennis] at 00:51 EST
FAX to: Elizabeth Rather
From: John Rible
Here's what I passed out at No. Calf Forth Day & @ FORML.
Send it anywhere you want.
John
------------------------
Summary of BASIS 14 Changes (John Rible's unofficial report)
Added Words:
To Core ext; CASE OF ENDOF ENDCASE REFILL COMPILE C" MS MARKER
To File; SAVE-INPUT RESTORE-INPUT FILE-STATUS WRITE-LINE RESIZE-FILE
REPOSITION-FILE
To File ext; FLUSH-FILE
To Float ext; F"
To Double; D0<
To Programmer; BYE KEY?
Deleted Words:
From File; WRITE-CR SEEK-FILE
From File ext; EXTEND-FILE
From Non-portable; ?KEY ?EKEY
Renamed, Redefined, or Moved Words:
BL from Core ext to Core
" renamed S" in Core and Programmer
-TRAILING from Core ext to String
QUERY restored to traditional meaning in Core ext
.( 0> from Core to Core ext
PARSE redefined so address is in the input stream, moved from Core to Core
ext
LIST from Non-portable to Block
ONLY ALSO PREVIOUS ISOLATE from Search to Search ext
ORDER from Non-portable to Search ext
[COMPILE] made "non-obsolescent" in Core ext
FILEPOS is FILE-POSITION and FILESIZE is FILE-SIZE in File
BLOCK-FILE is FILE-BLOCK and BUFFER-FILE is FILE-BUFFER in File ext
RENAME-FILE from File to File ext
Other Changes:
Non-portable word set renamed "Programmers toolkit" word set
Cell and Floating-point number sizes are intregal multiples of character size
Nested compilation of definitions is disallowed
Beyond scope of Standard to specify termination condition of ACCEPT or EXPECT
Only graphic characters (from ISO-IRV, ASCII) from 32...126 within scope of
standard
"Error" codes -1...-255 reserved fro ANSI, -256...-4095 for system
New data type taxonomy permits address, character, and other mixed type
arithmetic
Much new text added for rationale and implementor's guide apendices
Many typos and format problems corrected
Some statistics:
958 proposals received (194 from outside the committee, 1/3rd of which
passed)
518 proposals passed (246 were amended)
18 proposals still pending
estimated over $300,000 direct expenditures, plus over $500,000 volunteer
time
DRAFT PROPOSED ANSI FORTH STANDARD EXPECTED AFTER NEXT MEETING
The next meeting is scheduled for Jan 29 - Feb 3 at Forth, Inc. For more
information, please contact:
Elizabeth Rather, X3J14 Chair
111 N. Sepulveda Blvd., Suite 300
Manhattan Beach, CA 90266
We are expecting to have BASIS 14 ready for release by December 10th.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/03/90)
Category 10, Topic 2 Message 257 Sun Dec 02, 1990 B.RODRIGUEZ2 [Brad] at 10:57 EST > That must mean that there are only a few remain issues left > to resolve (right? :-). No, Dennis, it means we've all given up. - Brad "Accept No Substantive Input." ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/06/90)
Date: 12-02-90 (22:26) Number: 365 of 368 (Echo)
To: B.RODRIGUEZ2 [BRAD] Refer#: 353
From: JACK WOEHR Read: NO
Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> > That must mean that there are only a few remain issues left
-> > to resolve (right? :-).
-> No, Dennis, it means we've all given up.
->
-> - Brad
-> "Accept No Substantive Input."
Now, Brad, naughty naughty! Really, we are going to present
you with a very nice dpANS which you may then proceed to cheerily
hack to pieces!
The main dramas left in the process consist of
- seeing whether a last minute charge of a light brigade
of 79-STANDARD programmers will overthrow the last three
years of work;
- keeping Mitch Bradley from inserting ATTENUATE-FRAMISTAN
C-MUMBLE-BLETCH and TOKENIZE-MYASS into the language;
- waiting to discover who wins the Last Wo/Man bottle of
Chateaubriand '97 by being the last to go bankrupt purchasing
airline tickets and hotel accomodations for X3J14 meetings.
All seriousness aside, there shortly will be something
resembling a truly portable Forth ready for your perusal. It is not
totally unattractive, despite constant assaults on its continuity and
integrity. While there is little chance of obtaining an Arabian
Stallion from X3J14, a perfectly serviceable saddle camel seems to be
emerging as dpANS.
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/10/90)
Category 10, Topic 2 Message 262 Sun Dec 09, 1990 B.RODRIGUEZ2 [Brad] at 09:45 EST >> No, Dennis, it means we've all given up. > Is this the same Brad that I had lunch with a few weeks ago? Yes, it is, Dennis; it's just that I've hit my optimism limit, and cynicism is coming to the fore. Elizabeth asked me for my comments as I left the Detroit meeting, and I told her I'd have to digest for a while. I think I can now sum up the experience in two sentences: 1. I found the X3J14 committee accomodating, but not responsive. 2. I won't be going to any more X3J14 meetings. To wit: I no longer believe it possible for those outside the X3J14 committee to influence the process. I could write quite a long dissertation based upon my notes from Detroit; suffice it to say that it is the committee's _own_stated_position_ that they are no longer accepting substantive proposals. The majority of outside proposals that are passed are cosmetic or typographical, which caused me to report to our Ontario ANSI Review group that we have acquired the status of proofreaders. (_Inside_ proposals are another matter; and yes, the distinction is subtly made.) On the positive side, let me commend the group, and in particular Greg Bailey, the TSC chair, for hospitality and accomodation. They were willing to adjust their schedule, and not once invoke the "two- week" rule, so that the Ontario proposals could be aired while I was present. I truly appreciated that. But the fact remains, there is no point for me to attend future meetings. My attendance at Detroit accomplished no more than simply mailing the proposals in would have. Well, almost. I'm glad to have attended _one_ meeting, so that I can critique with some knowledge and authority. I've heard so many "if you don't vote, you shouldn't complain" comments -- a specious argument, by the way -- that I'm happy to have earned my right to complain. - Brad P.S. Jax, I probably won't hack the dpANS to pieces. First, my comments are not the kind that are likely to carry weight with ANSI. (I commented elsewhere that the ANSI guidelines favor improvement at the expense of standardization.) Second, and more significant, I prefer "voting with my feet" -- it's easier to ignore it than to fight it. (And I appreciated your "camel" quip.) ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/13/90)
Date: 12-10-90 (10:35) Number: 480 of 483 (Echo)
To: B.RODRIGUEZ2 [BRAD] Refer#: 445
From: JACK WOEHR Read: NO
Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> To wit: I no longer believe it possible for those outside the X3J14
-> committee to influence the process. I could write quite a long
-> dissertation based upon
Brad, there *may* be some resistance to proposals *at this stage*
but PLEASE REMEMBER after dpANS comes THE PUBLIC RESPONSE PERIOD and
everything is up for grabs once again, in effect. We're just trying to
reach *some closure* at this level of a very intricate, formal and
legalistic proceeding of a sort that is alien to all our Forthian
natures!
-> P.S. Jax, I probably won't hack the dpANS to pieces. First, my
-> comments are not the kind that are likely to carry weight with ANSI.
-> (I commented elsewhere that the ANSI guidelines favor improvement at
-> the expense of standardization.) Second, and more significant, I
-> prefer "voting with my feet" -- it's easier to ignore it than to
-> fight it. (And I appreciated your "camel" quip.)
Once again, ANSForth will be there for ONE REASON: to provide us
with a publically-accepted universal portable Forth. THERE WILL BE NO
DOOR-TO-DOOR SEARCHES BY THE FORTH POLICE to insure that you use it! :-)
It is just ONE MORE| TRICK in your bag. Forth programmers have
to be salespeople ... this is one more product for you to sell an
otherwise-recalcitrant client.
Frankly, I'm looking forward to it!
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/15/90)
Category 10, Topic 2
Message 265 Fri Dec 14, 1990
D.RUFFER [Dennis] at 00:22 EST
Re: BASIS delivery and cost
From: Elizabeth Rather
BASIS is sent to subscribers usually within a couple of days after it goes to
TC members and observers. This is the same time as it goes on the BBS
systems. I expect Brad sees a delay due to the Canadian postal service, but
US subscribers shouldn't notice any delay.
The concordance goes out anywhere from several days to two weeks later; so far
only to TC members, although on request we can mail it to anyone else. It is
not available electronically at all.
BASIS 14 is currently at the printers and will be available in all forms early
next week. That's the good news - the bad news is that its bulk has soared to
>200 pages, and so the cost is up to $15. Still a bargin! Send checks to:
Forth Vendors Group
c/o FORTH, Inc.
111 N. Sepulveda Blvd, Suite 300
Manhattan Beach, CA 90266
or be prepared to download a VERY big file.
EDR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpdcp@world.std.com (David C. Petty) (12/15/90)
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.' /______\ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/17/90)
Category 10, Topic 2 Message 266 Sat Dec 15, 1990 B.RODRIGUEZ2 [Brad] at 16:11 EST > [ANS Forth] is one more product for you to sell an otherwise- > recalcitrant client. To be sure; and you can rest assured that I will study ANS Forth and be prepared to use it when the occasion (i.e. client) demands. But...in the experiences I've had with recalcitrant clients, I don't think the existence of an ANS Forth would have swayed the decision. Either they're open to "screwball" languages -- in which case my natural persuasive talents :-) have been adequate to sell Forth -- or they're dead set against it, and can marshal a dozen objections. The most common is, "who can we get to maintain/extend this software (besides you)?" And, for those clients that leave the decision up to me, I have yet to be convinced that ANS Forth is the right recommendation to make. - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
dcp@world.std.com (David C. Petty) (12/18/90)
This is an open letter I sent to the ASC X3 / X3J14 in care of Elizabeth
Rather, the chair, on behalf of the Boston Forth Interest Group -- American
National Standard Forth Group (BFAFG). It was recorded as X3J14 document
TC90-067. It describes the differences between the views of the current
members of X3J14 and those of the BFAFG, and where we see those differences
arising. No one should have any illusions -- those differences are
fundamental.
I am not convinced that it is not possible to forge a compromise that
reconciles those points of view to the extent that one can include the other.
If such a compromise is to be forged, however, it must come from _both_ sides
making an effort to understand the other's point of view and try to include it
in their own thinking. Thus far our group has said (by way of proposals and
comments), ``This is what we need'' and X3J14 has replied, ``That's nice, but,
sorry, you can't have it.''
There is also a very strong (though I do not yet know how widespread) grass
roots opinion that the current membership of X3J14 does not necessarily
represent the views of the Forth community at large, specifically with respect
to the BASIS they have thus far constructed. It is certainly true that an ANS
Forth that is not supported by the majority of Forth _users_ will not be in
the best interest of _anyone_.
------------------------------>8 CUT 8<------------------------------
September 21, 1990
Elizabeth D. Rather, Chair, X3J14
FORTH, Inc.
111 North Sepulveda Boulevard, Suite 300
Manhattan Beach, CA I90266-6861
This is an open letter to the members of ANSI ASC X3 / X3J14 addressed to
you, the chair. I would like to thank you and X3J14 for the opportunity you
afforded the Boston FIG ANS Forth Group, and me as their representative, to
air our views and act upon our proposals at your recent (thirteenth) meeting
in British Columbia.
Our group had hoped to sway X3J14 to our point of view -- a so-called
"minimalist" point of view -- but the only proposals of ours that passed were
either not controversial at all (post), or fit the already existing views of
the current members of X3J14. The Thirteenth Meeting of X3J14 was therefore a
disappointment to us.
To be fair, there were a few small victories that must be mentioned with the
casualties. X3J14's treatment of division and NOT represent compromise
between FORTH-79 and FORTH-83. X3J14's passage of my motion to the technical
committee (TC) makes it clear in the Scope of Work for X3J14 that the lack of
this or that whizzy feature is not to be considered a "problem area" (though
an amendment stating "...unless deemed indispensable to the production of a
coherent standard" significantly weakened the wording). And BASIS did get
smaller, if only by one word.
My mission, however, was to try to change the "world view" of the current
members of X3J14 and in that, I failed. This letter is an attempt to better
explain our point of view and to sway the current membership of X3J14 to it.
At our most recent meeting on September 5th the discussion focused on the
question, "why don't they understand our point of view and act on it?" To
that end, the group came up with a way of understanding the standards process
that we hadn't thought of before: "the three Cs" -- Completeness,
Compatibility, and (self-) Consistency. Completeness refers to ANS Forth
specifying a language complete enough to be useful without adding extra
features. Compatibility refers to ANS Forth being compatible with accepted
practice. Consistency refers to the wording of the ANS Forth BASIS document
being self-consistent.
It first appears obvious that "the three Cs" are each goals that ANS Forth
should approach as closely as possible, but a second look reveals that
significantly attaining some goals necessitates compromise on the others. We
feel it best to compromise completeness, while the current members of X3J14
continually compromise compatibility with existing practice and apparently
want ANS Forth to be a specification for the ultimate, complete Forth. It is
our belief that the vendors are responsible for providing complete Forths and
that the standards process should provide the Forth community at large with a
standard document (not a specification) that describes the Forth that is
compatible with accepted practice.
Forth is, after all, one of the few extensible languages. It is not
necessary to put every language extension into standard Forth. It is only
necessary that standard Forth provide the facilities for extending itself, so
that users (and vendors) can add any language extension they want.
We believe that trying to specify every nook and cranny of a complete Forth
system -- especially in new areas that are outside of accepted practice -- is
a process that is doomed to failure. Any specification written describing
what Forth ought to be, rather than what Forth is, is bound to have holes in
it. It is the usual fate of most well-meaning specification writers and it
was the fate of the process that yielded FORTH-83. X3J14 must standardize
last year's Forth, not next year's Forth.
It is the belief of the Boston FIG ANS Forth Group that our point of view,
while not well represented among the current members of X3J14, is prevalent in
the Forth community at large. We will continue to drum up support for our
point of view outside of X3J14 and continue to attempt to win over the current
membership of X3J14 to that view by submitting proposals and comments.
I close with a quotation from Chuck Moore that is appropriate to the
compelling sense of rightness our group recognizes in the minimalist point of
view:
``One principle that guided the evolution of Forth and continues to guide its
application is, bluntly: Keep it simple. A simple solution has elegance. It
is the result of exacting effort to understand the real problem and is
recognized by its compelling sense of rightness. I stress this point, because
it contradicts the conventional view that power increases with complexity.
Simplicity provides confidence, reliability, compactness, and speed.''
Sincerely,
David C. Petty
Boston Forth Interest Group -- American National Standard Forth Group
--
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.' /______\jwoehr@isis.cs.du.edu (Jack J. Woehr) (12/19/90)
In article <1990Dec18.061629.17086@world.std.com> dcp@world.std.com (David C. Petty) writes: ... <stuff> .. >application is, bluntly: Keep it simple. A simple solution has elegance. It >is the result of exacting effort to understand the real problem and is >recognized by its compelling sense of rightness. I stress this point, because >it contradicts the conventional view that power increases with complexity. >Simplicity provides confidence, reliability, compactness, and speed.'' David, the problem seems to have become: What is the minimal Forth in which it is possible to write a large body of Standard programs that are portable across the range of processing units from microcontrollers to mainframes? The answer is, if you can shake down the jigsaw puzzle any more tightly than X3J14 is doing, more power to you. Once again, the Forth police will *not* be knocking on your door in the middle of the night to make sure you use ANS Forth. It's just there so that you have something to peddle to your customers when they demand A TRULY PORTABLE FORTH that allows them to address MODERN COMPUTER PROBLEMS like file access, external mem allocs, etc. IN A TRULY PORTABLE MANNER, eg., portable between, oh, say PICK and VAX/VMS. At home, I will do what I have always done: use 15 different Forths depending on what I want to do at the moment! But you can bet I will $ELL AN$ Forth $y$tem$. -- # ..!apple!dunike!nyx!koscej!jax # "Therefore, the L-RD G-d # # ..!hplabs!hp-lsd!oldcolo!jax # sent him FORTH ..." # # {apple,hplabs,pacbell,ucb}!well!jax # - Genesis 3:23 # # JAX on GEnie SYSOP RCFB 303-278-0364 # Member ANS Forth X3J14 TC #
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/27/90)
To the question of Fat Forths versus Lean Forths as a standard. We ran into the same problem in ANSI X3H3 (Computer Graphics Programming Languages), between those who only wanted to be able to draw passive images on a flatbed plotter, and those who wanted to create images interactively on a screen with a light pen (this was, you may guess, most of a decade ago). The solution achieved, while not perfect, was workable, and cut down the bickering a lot. Rather than fighting forever to find one standard that satisfied all camps, we came out with a layered standard, with levels of functionality from minimal (and lean) to featureful (and large). In fact, because the problem fell apart onto input and output axes most comfortably, the Graphical Kernel System is actually a family of _nine_ standards, with input levels 0, 1, and 2, and output levels 0, 1, and 2 as well. Vendors can create and advertise compliant products at any one of the nine grid points, and include enhancements beyond that minimum without complete compliance with the next level up. Forth might not need so complex a layering, but for the practical problems of getting a standard written and accepted, shifting the arguments from _whether_ to include a feature to _where_ to include a feature proved a godsend; people's egos were much less tied up in the latter questions, and the discussions suddenly became magically collegial and rational. Some such layering in the standard seems very natural to very layered Forth, from a lean, mean standard runtime environment kernel to ship with an embedded controller on the one end, to a full featured standard whizzy development environment with source debuggers, pretty printers, and context sensitive screen oriented editors on the other end. A free suggestion for what it's worth. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/27/90)
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >Category 10, Topic 2 >Message 266 Sat Dec 15, 1990 >B.RODRIGUEZ2 [Brad] at 16:11 EST >> [ANS Forth] is one more product for you to sell an otherwise- >> recalcitrant client. > To be sure; and you can rest assured that I will study ANS Forth and > be prepared to use it when the occasion (i.e. client) demands. > But...in the experiences I've had with recalcitrant clients, I don't > think the existence of an ANS Forth would have swayed the decision. > Either they're open to "screwball" languages -- in which case my > natural persuasive talents :-) have been adequate to sell Forth -- or > they're dead set against it, and can marshal a dozen objections. The > most common is, "who can we get to maintain/extend this software > (besides you)?" > And, for those clients that leave the decision up to me, I have yet to > be convinced that ANS Forth is the right recommendation to make. Ah, but you have missed one of the glories of national and international standards. Today you have, as another poster noted, 15 different Forths and pick the one most nearly suited to the job. But standards not only make programs portable, much more important, they make programmers portable. You can tell your clients: well, if you are worried about maintenance, for a negligible hit in performance I can write in ANS Forth, and "every" Forth programmer knows that. In other words, you have just multiplied the size of the pool of potential maintainers by at least 15. This becomes an excellent sales tool, and is the kind of thing businesses love to hear. Learning that a "standard" language is going to be employed provides the contracting manager a warm fuzzy feeling about the next hardware upgrade, and also about the next programmer hire. It is much easier to advertise for someone who knows ANS Forth than for someone who knows Dingbat Forth on the MaxiClone 100 hardware. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jax@well.sf.ca.us (Jack J. Woehr) (12/29/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: ... <stuff> ... >Some such layering in the standard seems very natural to very layered >Forth, from a lean, mean standard runtime environment kernel to ship >with an embedded controller on the one end, to a full featured standard >whizzy development environment with source debuggers, pretty printers, >and context sensitive screen oriented editors on the other end. That's pretty much waht we are doing. There is a CORE wordset, then CORE EXTENSIONS, FLOAT, FILE, etc. ... -- <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/30/90)
Category 10, Topic 2 Message 271 Sat Dec 29, 1990 B.RODRIGUEZ2 [Brad] at 17:36 EST > But standards not only make programs portable, much more important, > they make programmers portable. Good heavens, man! Do you expect to introduce reality into a _management_ discussion? :-) Seriously, this is a non-issue when I'm trying to sell Forth. Most of the clients I try to sell Forth to remain blissfully ignorant of the profusion of dialects. Whether they've heard of Forth in passing, or never, they automatically assume "_THE_ Forth language", not "_A_ Forth language." And the problem is not that they can't find a programmer for Dingbat Forth; the problem is that they don't think they can find _any_ Forth programmers. ANS Forth won't change that. - Brad P.S. re Fat vs. Thin, the X3J14 team handled this neatly with the "Extension Word Sets," and I promptly quit griping about the inclusion of files, floating point, etc. I _do_ still gripe about whizzy new [to Forth] features, regardless of how long they've been in use in the general computer science community. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/02/91)
Category 10, Topic 2 Message 273 Tue Jan 01, 1991 LRWEBBER [larry] at 20:17 EST Brad, I agree with you wrt your statements concerning ANSI forth making management feel good. Maybe where I work is an exception, but the software manager of us sweenies IS computer literate and knows that HIS boss likes standards. Forth could benefit my company in several areas as opposed to the current 'c' & assembler environment. I know this and he knows this but his boss isn't going to go out on a limb on any high visibility project if the language is too transient. As to the fat vs thin controversy, I personally like the approach the committee has used. I remember some years ago I started "playing" with f83 and gave it up until about a year ago when I got a copy of F-PC. No I don't do floating point in embedded controller stuff aat work but it's darn nice to have as an add on. Ditto the dos interface etc. I vote for lean core with lots of fat extensions for neophytes like myself as well as experienced forthers needing specialized tools. Thanks. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/06/91)
Category 10, Topic 2 Message 275 Fri Jan 04, 1991 L.ZETTEL at 22:07 EST If I may reply to message 274 from James Meyer... I have been a member of the X3J14 committee for just about a year now. To the best of my recollection, every time a proposal (from inside or outside the committee) would involve adding a new word to the standard, the technical subcommittee would think about whether the word could be constructed from other standard words. If it could, that was the kiss of death. .NOTE TO ALL WHO WANT A SMALLER STANDARD Show a simple definition of any word not in Forth 83 or Forth 79 in terms of other standard words that will work in any Forth implementation and get that word (almost certainly) removed from the standard! . The problem with leaving tool development to third party developers is that many of them will not release their work to the public domain, so it becomes difficult or impossible to port stuff from one vendor's system to another, or use their stuff in something sold. Then there is the fact that no two Forth programmers ever seem to do things the same way, so names, usage rules, side effects, etc. etc. also plague reuse and portability. How many times has the message been posted here "I downloaded the file on dingus construction and everything seems to be fine except that the code uses the word FRAMMIS which isn't on my system. Can anybody tell me how FRAMMIS works, or give a definition in F1066, PECULIAR version?" . As for developing your own tools, go ahead, and more power to you, especially if they are good and you share. Nothing in the standard prevents this, and nothing in the standard prevents anybody from giving a standard word non-standard behavior (like having DROP take an argument!). You just can't claim to comply with it. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
dcp@world.std.com (David C. Petty) (01/11/91)
In article <2055.UUL1.3#5129@willett.pgh.pa.us>, JACK WOEHR writes: `` The main dramas left in the process consist of `` `` - seeing whether a last minute charge of a light brigade `` of 79-STANDARD programmers will overthrow the last three `` years of work; From _The Charge of the Boston FIG_ after Alfred Lord Tennyson (1809-1892) (whose poem _The Charge of the Light Brigade_ was first published in the December 9, 1854 `Examiner'). II `Forward the Boston FIG!' They would never renege On stopping untried Words being chosen. Theirs not to make reply, Theirs not to reason why, Theirs but to do and die. Into the jaws of ANSI Propos'd the dozen. III Locals to right of them, CATCH / THROW to left of them, WORDLIST in front of them BASIS was frozen; It forced them to rebel, Boldly they wrote and well, To the jaws of ANSI, Into the mouth of hell Propos'd the dozen. -- 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.' /______\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/25/91)
Category 10, Topic 2
Message 289 Thu Jan 24, 1991
D.RUFFER [Dennis] at 21:31 EST
Forwarded from Elizabeth Rather:
This is in response to recent comments on the various boards.
I'm happy to see some specifics among the generalizations re X3J14, to wit a
strong request from Petty to remove >COLROW and LEX, and some constructive
comments about control structures. The latter are of concern to me, too, as I
believe they aren't adequately specified yet; I am working on some proposals
to that end.
Regarding >COLROW, I'd really like to see a "show of hands" as to whether:
1. It should be removed altogether (it's not required, it's in CORE
EXTENSIONS).
2. It should be kept as is.
3. It should be given a different name and description (if so,
what?).
Some form of this function is found in virtually *all* Forth systems. This
particular form is, I believe, in LMI Forth. Although I personally would
prefer to see it named TAB and with the stack arguments reversed (polyFORTH
usage) I believe it's better to have some version of this common function
standardized than none. Please, folks, take a position!
Regarding LEX, I personally would prefer to see the entire string wordset go,
and there are many on the TC that feel that LEX is the only useful word in the
set. Once again, stand up and be
counted: how do you vote?
RE moving 2DROP, 2DUP, 2OVER, 2SWAP, etc. to DOUBLE: these words have not
only been in all standards and all Forths of which I am aware, they are
extremely useful even on 32-bit implementations for manipulating pairs of
cells.
RE a "portability" wordset with ALIGN etc.: Separate wordsets are optional,
that is, a "standard system" may not have them. If these words are required
to ensure that standard programs are portable across machines of differing
cell size and alignment requirements, programs have to be able to count on
their presence. They simply aren't useful if they aren't required.
RE an Input Stream wordset with #TIB, etc.: what we are standardizing is a
programming system, not a run-time environment. A Forth programming system is
interactive, and therefore has a way of handling an input stream. If we were
to make these words optional we would surely bring down storms of protest from
people who feel, with Wavrik, that we're taking away functionality. I don't
agree with Wavrik about xBRANCH words (they aren't in most Forth systems
anyway, so he isn't losing anything), I certainly would be upset to lose
these.
Petty is mistaken in his belief that we're standardizing a "Forth kernel."
Nothing in BASIS deals with what's in a kernel. The CORE wordset is a list of
words that must be present in some form in a standard system. See B14 Section
5.1:
"This Standard does not require that each word be provided in executable form.
The implementor may choose to provide word definitions, including definitions
of words in the core word set, in source form only. This is acceptable as
long as a mechanism exists for adding the word definitions to the dictionary."
(NOTE: this text may move, as there are several proposals pending for
reorganizing and clarifying Section 5, but the TC is vehemently committed to
this principle.)
RE ONLY/ALSO: there are two proposals pending to discard these words. Once
again, how do you feel?
RE Brad Rodriguez' complaint that we didn't give more time to some of the
proposals from his Toronto friends: Those that I remember represented
controversies that we had discussed exhaustively in past meetings, such as
case insensitivity, use of a decimal point to indicate floating point in input
(which would break a great deal of existing code), and divorcing host OS files
from BLOCKS (which represents an important compromise hammered out over many
hours, guaranteeing a way to access disk compatible between native and non-
native implementations). We don't regard any of these as trivial issues; we
worked very hard and long on them in past meetings, but these proposals didn't
contribute any new facts or logic that would justify reopening them. We also
failed several Toronto proposals that would have added words; this ought to
please BFIG.
In fact, of the 43 proposals submitted by the Toronto group, 20 passed in some
form. This is a very high passage ratio for an outside group -- the overall
pass rate for outside proposals has been about 20%. Outside proposals fail
either because they raise issues that have already been dealt with (without
contributing anything new on the subject), they violate widespread standard
practice, or because they add lots of whizzy new words, which (BFIG
notwithstanding) we have usually declined to do.
RE reported uncertainty about definitions of "standard system," "standard
program," etc.: Please, those of you that have those concerns, read Section
5.6 (Compliance and Labeling) carefully and
tell me what confuses you. I promise I will try to fix it, as we all regard
this as a vital issue.
OK, FOLKS, PUT UP OR SHUT UP. I HAVE LISTED SOME ISSUES THAT ARE OPEN FOR
DISCUSSION AT THE NEXT MEETING AND I PERSONALLY PLEDGE TO
REPRESENT MAJORITY VOTES ON THE ABOVE ISSUES. TAKE A POSITION AND
TELL ME WHAT YOU THINK AND WHY!
Once again, the next meeting of X3J14 is Jan. 29-Feb. 2 at FORTH, Inc., 111 N.
Sepulveda, #300, Manhattan Beach, CA. You're welcome to attend; if you wish
to do so, please call me at (213) 372-8493.
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/28/91)
Category 10, Topic 2
Message 290 Sun Jan 27, 1991
B.RODRIGUEZ2 [Brad] at 14:59 EST
I have to agree with David Petty's observation that the TC has avoided both
objectivity and consistency in its decision criteria.
As part of the residue of the Detroit meeting, I have a list of arguments
which (when I offered them) were rejected as insufficient, but which were
later used without dispute by others on the TSC.
And -- perhaps the issue which has most damned the TC in my eyes -- when I
proposed a set of quantifiable, objective decision criteria to the TC, they
were rejected: not because I had proposed the wrong criteria (which I offered
to change), but because the TC OBJECTED TO HAVING TO MEET ANY CRITERIA AT ALL.
- Brad
P.S. Elizabeth Rather has offered some deceptive statistics re. the Southern
Ontario proposals at the Detroit meeting. Of the 43 proposals we submitted,
23 failed,
6 which passed were "post" proposals, to correct typos and such,
7 which passed were editorial changes to clarify definitions,
2 (of mine) which passed were editorial changes to delete
language which I considered pompous, misleading, or deceptive.
Of the 5 substantive proposals which were passed:
1 was passed as submitted,
1 was amended by the TSC,
1 was amended so much it no longer resembled the original proposal,
2 were replaced with new proposals by the TSC, which essentially
preserved the original intent.
In contrast, 21 of the 23 failed proposals were substantive. (There's that 20%
success rate.) It would seem that outside proposals fail because they raise
issues, period.
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/28/91)
Category 10, Topic 2 Message 291 Sun Jan 27, 1991 F.SERGEANT [Frank] at 14:58 CST Elizabeth Rather> Once again, stand up and be counted: how do you > vote? Well, since you asked, I'll make a few comments. >COLROW I don't like the name. I presume it is to set a cursor position on the screen. I prefer the arguments to be ( row col - ) rather than ( col row - ). I could go along with the name TAB for this. Why not AT? Anyway, let's not require it! If possible, let's remove it altogether. If it must be kept, let's not use the ugly name. >LEX & the string word set. Let's remove them altogether. >2DROP, 2DUP, 2OVER, 2SWAP, etc. I don't feel strongly about where these are put. In general I feel the less in the core wordset the better. I can live with them either place. And yes, certainly, I would ordinarily use them even in 32-bit systems. >ALIGN etc Again I have no strong feeling here, so I give my default advice, although weakly: take it out of the standard if possible; at least take it out of the core. >Input Stream wordset with #TIB, etc. Ditto. See default advice above, but with lower volume. (I don't particularly object, in other words.) >Wavrik about xBRANCH words (they aren't in most Forth systems anyway Regarding this and also Wil's comments about "industrial strength Forths" not having or wanting them, I guess I miss the point. Maybe someone would explain what is done instead? I call 'em branch and 0branch in my system. Don't even the industrial strength Forths have conditional and unconditional branch primitives? So (no pun intended) I guess the question is whether the control structure primitives should be specified in the standard, or just the high-level actions of IF ELSE THEN BEGIN UNTIL etc. I rather liked (what I think Wil was suggesting) the idea of eliminating the need for the programmer to know how many stack items these words kept on the stack at compile time. Whether SO or BUT or whatever should be part of the standard, I don't know. I'd be happy for someone to post a discussion and explanation of all this that I could understand. >"This Standard does not require that each word be provided in > executable form. This may the thing I like most (dislike least, perhaps) about the ANSI standard. It's the way I deal with DO LOOP in Pygmy. (Thanks to Robert Berkey) it's available in source form to load for anyone who wants it, but it doesn't burden my system. >ONLY/ALSO I don't use 'em, so throw them out. Throw out WORDLIST and that other one. Put back VOCABULARY in an optional wordset and say it is implementation dependent. > Toronto I want words to be case sensitive. I want the decimal point to indicate double precision (not floating point). Let's standardize BLOCK as returning an address of some sort that refers to a 1024 byte area, but leave its relationship to disks, files, and the operating system implementation specific. Remove the file handling words from the standard altogether. ( u) FOR ... NEXT Specify that when u is zero the body of the loop is *not* executed at all. Otherwise, the body is executed u times (not u+1 times). Division Leave it implementation dependent. CATCH & THROW Leave 'em out of the standard. -- Frank ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/30/91)
Category 10, Topic 2
Message 292 Mon Jan 28, 1991
GARY-S at 05:57 EST
Casting a few votes:......
In a message posted on GEnie by Dennis Ruffer, Elizabeth Rather asks:
>?Regarding >COLROW, I'd really like to see a "show of hands" as to whether:
- 1. It should be removed altogether (it's not required, it's in CORE
EXTENSIONS).
- 2. It should be kept as is.
Either of the above would suit me. If it is item 1) though, I sure don't
want to see a name change or description change. I realize the folks at
FORTH Inc use a reverse stack notation, but all implementations I have
ever used follow the LMI convention.
>Regarding LEX, I personally would prefer to see the entire string wordset
>go,
This would be my vote. If you want string handlers, fine. Add them. Do
NOT make them part of the core word set. I have no ax to grind with LEX,
SED, or SNOBAL for that matter, just don't put them in my kernel.
>RE moving 2DROP, 2DUP, 2OVER, 2SWAP, etc. to DOUBLE:
While I tend toward a minimal wordset I would personally hate to throw
2DROP away. I could live without some of the others, but if the vote is
'either all or none' I'd have to say keep the extended stack set.
>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.
>RE an Input Stream wordset with #TIB, etc.:
This one has been argued most eloquently by Dr. Wavrik, and he has
convinced me of the wisdom of his thinking. Count me in with the
math professor at UCSD.
That's all me votes for now. Gary
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/30/91)
Category 10, Topic 2
Message 293 Mon Jan 28, 1991
L.ZETTEL at 20:27 EST
This is a reply to Brad's message 250. There was a time when I espoused what
might be called a deductivist approach to decision making and issue
resolution. That is, determine the correct general principles, determine the
relationship of the specific situation to the general principles, and deduce
the proper decision. To persuade someone else, outline the details of the
above exercise to them.
Now I am older and have engaged in serious committee work and have
concluded the above scheme is utterly unworkable. First, it is just about
impossible to get agreement on general principles with any more substance than
"motherhood and the flag" and even then there are issues of "which flag?" and
"what about the population explosion?" Second, it is even harder to get
agreement about how principles properly apply in a given situation.
So now I like an "inductivist" approach. Look at a bunch of specific
situations and see what regularities might be distilled into a general rule of
action. However, remember that induction other than mathematical induction is
always fallible. You never know whether the the induced rule will apply to
the next case or whether that case will force an exception or revision of the
rule. Given that fallibility, I refuse to agree irrevocably in advance to
apply a general rule to a case I have not yet seen. I am also reluctant to
invest time and energy arguing general criteria when I can see no practical
end which that will further.
Further, in something as complicated as the standard there are always
competing goods to be obtained, or criteria to be evaluated. And the weights
change from case to case (importance or degree of fulfillment or both). It
then becomes perfectly reasonable to adopt some specific point because it
fulfills some specific criterion and reject another even though it fulfills
the same criterion - the rejectee had other arguments against it.
Then there are the various forms of committee paradox we have to tame. It
is perfectly possible for a committee of rational and consistent members to
vote for A over B, B over C, and C over A (see the works of Kenneth Arrow). If
nothing else, this gives fertile fields for parliamentary maneuvering, and we
haven't been entirely immune to that.
The committee isn't trying to agree on general principles - it is trying
to agree on a standard. Fortunately, we have found much we can agree on in
spite of our differences of principle.
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/30/91)
Date: 01-27-91 (22:36) Number: 1001 of 1007 (Echo) To: DENNIS RUFFER Refer#: 979 From: RAY DUNCAN Read: NO Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Elizabeth Rather writes: >I believe that this form [ >COLROW ] is from LMI Forth... The name didn't come from us. In LMI systems its called GOTOXY and the stack effect is ( x y - ). I don't really have any strong preference about what X3J14 chooses to do with this as it is only a mechanical editing problem anyway to change the code. As for the X3J14 current string words, I'd like to see them thrown out too. I believe that the set of string primitives in LMI systems is much better thought out and I'd hate to abandon same in favor of the hodge-podge that is now in BASIS. We strongly support the proposals to delete ONLY/ALSO (I proposed this myself some time back, but my proposal was voted down). NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/30/91)
Date: 01-28-91 (09:10) Number: 1007 of 1007 (Echo)
To: B.RODRIGUEZ2 [BRAD] Refer#: 991
From: JACK WOEHR Read: NO
Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> I have to agree with David Petty's observation that the TC has
-> avoided both objectivity and consistency in its decision criteria.
->
Consistency, perhaps: the voting body changes composition
each meeting. But the charge of "avoiding objectivity" is ad hominem.
It doesn't really *say* anything. What objectivity? What is objectivity,
agreeing with you, perhaps?
-> As part of the residue of the Detroit meeting, I have a list of
-> arguments which (when I offered them) were rejected as insufficient,
-> but which were later used without dispute by others on the TSC.
I missed Detroit, so along with your other readers, I am
puzzled what the above paragraph means. What arguments, on what
subjects, did you offer, and how were these arguments later used
without dispute by others? Details, please!
-> And -- perhaps the issue which has most damned the TC in my eyes --
-> when I proposed a set of quantifiable, objective decision criteria to
-> the TC, they were rejected: not because I had proposed the wrong
-> criteria (which I offered to change), but because the TC OBJECTED TO
-> HAVING TO MEET ANY CRITERIA AT ALL.
Oh, Brad, this has to be pure flame. The TC has *many* criteria
it is pledged to meet. If you can give us a magic formula that we can
follow by rote to manufacture the perfect standard, PLEASE hand it
over and we will stand on our heads and chant it WILLINGLY, or whatever.
=jax= "dpANS in 2Q91!"
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/04/91)
Category 10, Topic 2
Message 307 Sat Feb 02, 1991
F.SERGEANT [Frank] at 18:03 CST
Elizabeth Rather wrote:
>I'd really like to see a "show of hands" ...
...
>Once again, stand up and be counted: how do you vote?
...
>OK, FOLKS, PUT UP OR SHUT UP. I HAVE LISTED SOME ISSUES THAT ARE
>OPEN FOR DISCUSSION AT THE NEXT MEETING AND I PERSONALLY PLEDGE TO
>REPRESENT MAJORITY VOTES ON THE ABOVE ISSUES. TAKE A POSITION AND
>TELL ME WHAT YOU THINK AND WHY!
.
I replied to it with some comments (because, naturally, it pleased me to
do so). I was willing to state my opinion (my "vote"). I did not
necessarily go into detail as to the WHY. I was not attempting to convert
others to my views, merely to state what my views were -- more or less in
answer to Elizabeth's request.
.
Then Jan Stout commented on some of my comments.
.
JS>How can you expect people to go along with your ...
.
I really don't expect them to.
.
JS>How can you expect people to go along with your ( row col -- )
JS>proposal if you don't give some example of the benefits of this
JS>factoring.
.
Mainly, I was just saying that I use and prefer ( row col -) to ( col
row -). I am not saying anyone else needs to prefer it. I think my primary
reason is it is easier for me to visualize going down and then across that to
visualize going across and then down. What with + to modify one and +UNDER
to modify the other and the possibility of AT being a CODE definition, I
don't see machine efficiency as the overwhelming criterion for the order of
the arguments. Elizabeth & PolyForth probably prefer ( row col -) for
"better" reasons than I offer. I'd like to hear them. Meanwhile she's got
one more "vote" for her preferred method. I often do something like
STARTING-POINT 2@ ( y x) dX + AT but how can I really object to STARTING-
POINT 2@ ( x y) dX +UNDER AT ? And, while I said what I used & preferred, I
also suggested it be omitted from the standard all together.
.
.
JS>Again I don't understand your enthousiasm for FOR/NEXT over
JS>DO/LOOP.
.
Well, I don't understand it either. FOR/NEXT just resonated with me
somehow. I liked it from the start and never use DO/LOOP. I don't even keep
DO/LOOP loaded in my system. As I mentioned, I don't object to others using
it. And, with the proposed standard allowing its requirement of DO/LOOP to
be met merely by including the source code for it, I'm looking upon the
proposed standard more favorably than I used to.
.
Furthermore, you offer efficiency arguments with the examples
.
: TYPE SWAP OVER + ?DO I C@ EMIT LOOP ;
instead of
: TYPE FOR C@+ EMIT NEXT ; with : C@+ 1+ DUP 1- C@ ;
.
might I offer clarity, simplicity, readability arguments in favor of
FOR/NEXT? In addition there are the many loops that do not need access to
the index. FOR/NEXT's index is down counting. In many situations its index
I can be used as conveniently as FOR/NEXT's I. And, since implementations
vary, I don't see that it is clear that DO/LOOP is more efficient even in
those cases that do use the upcounting index. Depending on the
implementation, it may be that either computing the index is less efficient
or that testing the loop termination condition is less efficient (or both)
than using FOR/NEXT either with or without its index. I believe that Robert
Berkey has offered implementation examples of both FOR/NEXT and DO/LOOP in
terms of the other. All in all I am of the opinion that neither can be
declared the "best" loop based only in terms of efficiency of its
implementation. All I know is I like FOR/NEXT and find it much more pleasing
than DO/LOOP. I think it is because it is simpler to use. I use it (as I
think I've mentioned) with the loop done u times rather than u+1 times. I
have even been speculating lately whether I should convert to an *up-
counting* index in FOR/NEXT. One of the arguments in favor of FOR/NEXT has
been its simplicity of keeping only one item on the return stack and the ease
of testing it for loop termination (<is it zero yet?>). I would give that up
to get my up-counting index. I have come to no conclusion yet about this.
.
-- Frank ---- continued ----
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/04/91)
Category 10, Topic 2
Message 308 Sat Feb 02, 1991
F.SERGEANT [Frank] at 18:03 CST
(Reply to Jan Stout continued)
.
JS> Do indeed you use that many dpliterals??? My opinion is that the
JS>occasional use of doubles shouldn't imply alternative syntax (use
JS>of .) that outside the forthcommunity always meant fpformat. I'd
JS>say use 0 0 for your 0. or if you've sprayed a lot of 0. in your
JS>code define a constant ie 0 0 2CONSTANT D0 and use D0 instead of 0.
.
No, I don't use many decimal-point literals in my code. Recently I've
started using more. I usually do use 0 0 instead of 0. But, I've felt
there's been a long tradition of using the dp to signify double precision. I
am not persuaded this should be changed to meet the expectations of those
"outside the forthcommunity." This hints at two of my philosophical
differences with (some of) those advocating a new standard.
.
First, I'm not very interested in conforming to the standards of other
language so that "we" will be better accepted. I may be wrong in this. Jax
argues eloquently for the standard from a financial standpoint. I might even
use the standard for that very purpose someday. If we want to be better
accepted by making Forth look like C or Pascal or Fortran there is a much
cheaper, more straight forward shortcut to that goal: just use C or Pascal or
Fortran. Bang! An instant solution. If the point of the standard is merely
to be able to say "Forth is now an ANSI recognized standard" for political
and financial purposes (in which case the technical merits of the standard
are unimportant) then the committee has *wasted* a great deal of effort
trying for technical excellence. On the other hand, if the committee is
rightfully trying for technical excellence, it seems that the political
pressures and compromises have been a costly impediment, resulting in what I
think Jax called a comfortable saddle camel (ie better than you might expect
from a committee, but still not a horse).
.
Second, didn't Dijkstra complain that other languages were standardized
way too soon? Rudolf Flesch in *The Art of Plain Talk* says about the
Chinese language: "It is the most grown-up talk in the world. It is the way
people speak who started to simplify their language thousands of years ago
and have kept at it ever since." He also says (I summarize) that English
will never catch up because we became literate and froze the language too
soon. I think it is far too soon to "standardize" Forth. When I offer my
opinions about ( y x -) versus ( x y -) or decimal points, etc they are
merely my current thinking. I am not through thinking. I don't want any of
this frozen into a "standard" yet.
.
However, I am fully convinced there is going to be an ANSI "standard"
regardless of how premature I feel it to be. So, I think the important thing
now is not to call it *the* standard, but to refer to it as *one of the many
competing* standards. Sort of my version of pantheism. So, regarding it as
one of the many standards, I can say to the committee "good work - keep it up
- the ideas and discussion are useful." I look at it as an expensive to
them, cheap to me version of FORML.
.
As comic relief I'd like to quote from a shareware catalog I got
recently:
.
"*FIGFORTH* - The complete FIG-FORTH language that is an '83 ANSI standard
implementation."
.
-- Frank
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/04/91)
Category 10, Topic 2 Message 309 Sat Feb 02, 1991 B.RODRIGUEZ2 [Brad] at 23:37 EST From L.ZETTEL: > ...I refuse to agree irrevocably in advance to apply a general > rule to a case I have not yet seen. Isn't that a general rule of yours? :-) Seriously, this illustrates the point I'm trying to make. There are _some_ general rules -- "necessary" conditions -- which can be applied across the board. These are NOT sufficient to make a final determination, just to narrow the search space. From Jack Woehr: > ...the charge of "avoiding objectivity" is ad hominem. It doesn't > really *say* anything. Apologies, Jack, since you weren't at the Detroit meeting this was certainly a non sequitur. Allow me some time to sift my notes and I'll post the proposal I was referring to, and also the other details you asked for. > The TC has *many* criteria it is pledged to meet. Yes, and many pledges it has broken, too. Name one criterion it hasn't violated. I say again, I do NOT have a set of "sufficient" criteria -- the "magic formula" you requested to produce the perfect standard. But I have suggested some minimum or "necessary" criteria. Please distinguish between the two. From Danial Sorbal: > > Are you kidding? What does "standard" mean to you? > I think that something standard is something that is used in the > "same way" by all the people that use this thing. Your point is taken, and I now understand your previous posting. I do prefer Nick Solntseff's distinction of "conventional" vs. "standard" in this context, though. From Mitch Bradley: > Somebody else said something to the effect that: > "Democracy looks like a pretty terrible system, except when you > compare it with any other system." That seems to be a paraphrase of Winston Churchill. Here's another that may be singularly appropriate: "Democracy is a form of government you have to keep for four years no matter what it does." - Will Rogers - Brad ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (02/11/91)
In article <2301.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (really Frank Sergeant) writes: > I think it is far too soon to "standardize" Forth. When I offer my > opinions about ( y x -) versus ( x y -) or decimal points, etc they are > merely my current thinking. I am not through thinking. I don't want any of > this frozen into a "standard" yet. This attitude would be amusing were not so prevalent. Why is that standardizing Forth (as it exists now) in any way prevents more thinking? Did any of the previous standards do that? Why would this standard be different? Personally I would like to see a standard to address many of the things that have been added since Forth-83 (and to undo some blunders). But what I really really want is a way to write Forth code that will run on more than one Forth and more than one processor, without having to provide all the tedious prolog code. I would like a language to write "examples" in, that are not even going to be read by a machine, in order to communicate more coherently with other Forth programmers. But, Portability is my main interest in this ANSI process. > However, I am fully convinced there is going to be an ANSI "standard" > regardless of how premature I feel it to be. So, I think the important thing > now is not to call it *the* standard, but to refer to it as *one of the many > competing* standards. Sort of my version of pantheism. So, regarding it as > one of the many standards, I can say to the committee "good work - keep it up > - the ideas and discussion are useful." I look at it as an expensive to > them, cheap to me version of FORML. I have never understood why anyone would ever think that ANSI-FORTH would be anything but "*one of the many competing*" standards. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
dcp@world.std.com (David C. Petty) (02/12/91)
In article <2295.UUL1.3#5129@willett.pgh.pa.us>, RAY DUNCAN writes: `` As for the X3J14 current string words, I'd like to see them thrown out `` too. I believe that the set of string primitives in LMI systems is much `` better thought out and I'd hate to abandon same in favor of the `` hodge-podge that is now in BASIS. Please, Ray, can you publish the specifiation for the LMI string word set? I'd hate to miss out on the opportunity of having less of a hodge-podge in ANS Forth. `` We strongly support the proposals to delete ONLY/ALSO (I proposed this `` myself some time back, but my proposal was voted down). Hear, hear! -- 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...' /______\
chip@tct.uucp (Chip Salzenberg) (02/14/91)
In article <2295.UUL1.3#5129@willett.pgh.pa.us>, RAY DUNCAN writes: > We strongly support the proposals to delete ONLY/ALSO (I proposed this > myself some time back, but my proposal was voted down). Could someone enlighten me as to the evil of ONLY/ALSO? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
esj@harvee.UUCP (Eric S Johansson) (02/14/91)
In article <1991Feb12.074203.12102@world.std.com> dcp@world.std.com (David C. Petty) writes: > In article <2295.UUL1.3#5129@willett.pgh.pa.us>, > RAY DUNCAN writes: > > `` As for the X3J14 current string words, I'd like to see them thrown out > `` too. I believe that the set of string primitives in LMI systems is much > `` better thought out and I'd hate to abandon same in favor of the > `` hodge-podge that is now in BASIS. > > Please, Ray, can you publish the specifiation for the LMI string word > set? I'd hate to miss out on the opportunity of having less of a > hodge-podge in ANS Forth. > I second that notion. Ray, Please publish your string primitives wordset. If folks don't find the current string wordset definition acceptable, I suggest we take a clue from another part of the computer world whis has an acceptable set of string manipulation functions. I suggest forthifying the ANSI C set of string functions. These set of routines have passed the test of time, they are in common usage, they are used in portable code, the rest of the computer programming world understands them. what more could you ask for :-) --- eric -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/14/91)
Date: 02-11-91 (18:29) Number: 1135 of 1138 To: GARY SMITH Refer#: 1095 From: CHRIS WATERS Read: NO Subj: Ans Forth Technical Commi Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Reply to: wmb@MITCH.ENG.SUN.COM Subject: Recent ANS Forth Meeting > Conditional compilation: > A wordset for conditional compilation is going out for letter > ballot. It looks like it may pass. The proposal calls for > fully-nestable, immediate words IFTRUE OTHERWISE IFEND (same > names as in Forth 83). I have to ask about this one. What about the simpler methods of conditional compiliation. Have these all been rejected? Why do we have to have the huge overhead of IFTRUE and such, rather than something simple and elegant, such as query-paren. Color me a minimalist, but I don't see the point of IFTRUE. I first implemented one in my Forth back in '81, but I've never used it, and I dropped from the system around '84. Query-paren, or something similar, is much faster and takes almost no overhead. My vote is to leave this [censored] for the pascal and basic programmers. p.s. these names were NOT part of the '83 standard per se. They WERE included in the reference wordset, along with such winners as END and semi-colon-colon. I considered them archaic back then, and even more archaic now. --- Tag1.2 : the ground was hot, so they jumped up and down --- * SFUTI 3.01 / The Cave BBS - Unix/Xenix/C/Forth/Anime/Madness... PCRelay:THECAVE -> #559 RelayNet (tm) 4.10 The Cave (408)259-8098 12/24/96/19.2 HST/DS <<<>>> ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/18/91)
Category 10, Topic 2 Message 322 Sat Feb 16, 1991 B.RODRIGUEZ2 [Brad] at 16:23 EST Doug Philips writes: > ...what I really really want is a way to write Forth code that will > run on more than one Forth and more than one processor.... > Portability is my main interest in this ANSI process. Interesting. I've had relatively little trouble porting applications from processor to processor. It's moving from "standard" to "standard" that gives me headaches. To Mitch Bradley, in reply to my && and || query: My thanks, you are quite correct, and I sit corrected! They're not difficult to implement, just inefficient in space. (Normally I do them in machine code, anyway.) And thanks to Ulrich for catching your (minor) code error. Either way, it illustrates the technique. Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (02/21/91)
In <2359.UUL1.3#5129@willett.pgh.pa.us>, B.RODRIGUEZ2 [Brad] writes: > Doug Philips writes: > > > ...what I really really want is a way to write Forth code that will > > run on more than one Forth and more than one processor.... > > Portability is my main interest in this ANSI process. > > Interesting. I've had relatively little trouble porting applications from > processor to processor. It's moving from "standard" to "standard" that gives > me headaches. Ok, perhaps I should be a bit more explicit. I was thinking of PC versus Unix (Sun, Apollo, etc). PC-Forths versus C-Unix Forths. Since there is no wide spread defacto standard, switching from processors implies (or so I tried to assume) switching between standards. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)
Date: 02-19-91 (09:28) Number: 1249 of 1262 (Echo) To: GARY SMITH Refer#: 1225 From: RAY DUNCAN Read: NO Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Chip Salzenberg writes: >"Could someone enlighten me as to the evil of ALSO/ONLY." First of all, it was never a part of the Forth-83 standard. It was appended to the standard as an "experimental word set" as a political ploy -- to keep Bill Ragsdale (one of the founders of FIG) happy. Second of all, ALSO/ONLY was apparently originally conceived of as a "Forth-like" (i.e. stack-like) way to control search order, but the realization of the concept was brain-damaged. To wit: there are ways to push things onto the search order stack but no way to pop them off; no way to interrogate what is currently in the search order stack; no way to rearrange the search order stack except by dumping the whole thing and starting over; and so on. Third of all, ALSO/ONLY is completely incompatible with at least two of the commercial Forth systems with the largest installed bases (Forth Inc. and LMI). It seems sort of silly to me to put something into the ANSI Forth draft standard --- which is supposed to be founded on concensus and common practice --- which will totally break the code of thousands of serious Forth programmers and CANNOT be mechanically edited/translated from old to new. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)
Date: 02-20-91 (14:08) Number: 1264 of 1274 To: GARY SMITH Refer#: 1225 From: ANIL RODRIX Read: NO Subj: ANS FORTH TECHNICAL COMMI Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) To Gary or anyone else: ll this about not ONLY but ALSO , I must have missed something in my hibernation; I dont even know what they are. Were these words described in Forth Dimensions ? I can go back and look them up. PCRelay:PROPC -> #288 RelayNet (tm) 4.10 Pittsburgh ProPC BBS (412) 321-6645 <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
dcp@world.std.com (David C. Petty) (03/11/91)
In article <2404.UUL1.3#5129@willett.pgh.pa.us>, RAY DUNCAN writes: `` It seems sort of silly to me to put something into the `` ANSI Forth draft standard --- which is supposed to be founded on `` concensus and common practice --- which will totally break the code of `` thousands of serious Forth programmers and CANNOT be mechanically `` edited/translated from old to new. Hear, hear. To me it is worse than silly. It is insidious. But that is not the first time, nor will it be the last. By the way, I know that ONLY and ALSO were removed to the extension word set, but that is not far enough removed for me. I also know that there is a lot of discussion to the effect that SAVE-ORDER and RESTORE-ORDER (or whatever they're called) will ``fix'' the search order word set. Let's let them become accepted practice and then we'll find out! -- 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...' /______\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/19/91)
Category 10, Topic 2 Message 335 Sun Mar 17, 1991 ATFURMAN [Alan F.] at 21:00 PST Jerry Gitomer writes: > (Yes, an ANSI or ISO standard has legal as well as technical status.) To wit: ? ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/06/91)
Category 10, Topic 2
Message 132 Fri Apr 05, 1991
D.RUFFER [Dennis] at 21:08 EST
......NEWS FLASH......
X3J14 Central:
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.
So, you can stop worrying about [IF] or whatever you want to call it and start
thinking about writting comments to ANSI. Actually, there are a couple of
steps let before we have a dpANS. The first happens if they get any no votes
from that mail ballot. They've had enough to pass the resolution, but if any
no's are received they have the responsibility of resolving the issue(s) that
caused the no vote(s). This mostly means writting a whole bunch of words to
justify their position, but there is a tenative meeting scheduled for May 3rd
hosted by Mitch Bradly just in case they need it.
Assuming they can resolve the no votes (if they get any) quickly, they then
send the document to the ANS planning committee (SPARC) who then gets to
decide if they have sweated enough blood. If they feel everything is in
order, they then send it to ANS and we enter the public review period. Best
estimates put this at early June. The public review lasts for 4 months and
then, barring any irreconcilable differences, we'll have an ANS Forth standard
sometime around the 4th quarter.
Let's hope we can do it!
{B-{)> DaR
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/07/91)
Category 10, Topic 2
Message 133 Sat Apr 06, 1991
R.BERKEY at 11:29 PST
copyright (c) 1991 Robert Berkey
Splitting this posting into two parts or truncating it, for transmission
to other computer message systems, constitutes violation of copyright.
It's interesting that I got my dpANS mail ballot yesterday (Thu), and today
(Fri/Sat) I hear a report that that mail ballot has already passed. Looks as
if the ramrodders have been hard at work on this one.
As for how I will be voting on that mail ballot, the issue was closed some
eight to nine years ago. I first committed in 1982 and reiterated during the
current X3.J14 series of meetings that I would vote NO against any so-called
"standard" that violated the mathematical use of the word MOD. If I haven't
repeated this often enough in the last couple of years, I'll say it again. I
will vote NO against any so-called "standard" that violates the mathematical
use of the word MOD. From some viewpoints, this issue may seem minor, but
X3.J14's inability to accommodate a simple fact, the definition of MOD,
exposes fundamental hypocrisy and corruption in X3.J14. The technical
problems that exist in BASIS weigh irrelevant as long as X3.J14 wanders
aimlessly, incapable of adhering to even their own watered-down policies,
procedures, and charter.
Count me out as a party to the fraudulent intent behind the submission of a
Draft Proposed American National Standard (dpANS) from the X3.J14 committee.
The committee has openly discussed that this document is not ready to be an
American National Standard (ANS).
But, why then is X3.J14 attempting to get the committees of X3 and ANSI to
accept this fraud? Since I am not privy to the thinking of those who are
ramrodding this step, the reader's guess is as good as mine. Here's my guess:
(a) What the implementor's-party component of the committee wants
is to be able to label their existing product with the title ANS so
as to induce customers to part with their money in trade for that
product.
(b) At the same time, it is desirable that no external measure
can exist with which to measure a system as ANS non-compliant, as
this essentially reduces the "cost of compliance" to zero.
(c) Note that from this viewpoint, the actual technical content
of the document is irrelevant; however, the document must give an
appearance of being substantive and useful.
(d) The submission of a Technical Bulletin--as opposed to a
dpANS--would assess the viewpoint of the community, but would not
achieve (a).
(e) The current BASIS document is sufficiently vague, ambiguous,
and generalized--and good-looking; that it satisfies the basic goals
of (a), (b) and (c). Therefore; inducing the X3.J14 committee to go
for a dpANS, rather than the Technical Bulletin, is a no-lose
situation under these criteria. If both X3 and the Forth public can
be induced to let the dpANS become an ANS the way it stands, then
"we" can get on with inducing customers to part with their money.
If not, then the burden has been put on the buyer to name his price.
A question I have been asking of members of the committee and community
recently: how many people in the world make money from selling Forth systems?
To put that another way, how many lords of Forth fiefdoms are there who can
profit from permanently dividing the Forth community into dialectic camps?
Now then, given the open admissions that this dpANS isn't taken seriously by
the committee themselves as a possible ANS, it would be a curious event were
X3 to nonetheless ignore the fraudulent intent behind this submission and pass
the document out for public review. However, my experience with X3 has been
that they cannot be trusted any more than X3.J14.
X3, after all, is the committee who selected as the chair of X3.J14 a vendor:
a vendor whose company has never produced a Standard System or a Standard
Program. Robert's Rules of Order notes that the Chairperson selected should
be a neutral party to various interests involved. Yet X3's selection for
chairperson--in addition to being a vendor lacking experience with standards--
was one of the organizers of the Forth standard's cabal of October 1986. So,
X3 could hardly have selected someone less neutral. This combination of
politically manipulative and technically weak pervades the committee and BASIS
to this day.
X3 not only selected a vendor for the position of chair, but selected
literally every officer of the committee from the Forth Vendor's Group. As
with the chairperson, each of these other officers had been part of the Forth
standard's cabal of October 1986.
In this context it should be remembered just who X3 is part of: The Computer
Business Equipment Manufacturer's Association (CBEMA). Hmmm, a vendor's
association picking only vendors as officers?
The seriousness of this matter is underscored in noting that ANS standards are
authorized by Congress.
I propose the following:
Write Congressmen and Senators:
Demand that the American National Standards Institute be called
before Congress to explain why a manufacturer's association (CBEMA)
holds a position of special influence within the American National
Standards Institute.
Write the President of the United States:
Call for the Justice Department to investigate the American
National Standard's Institute's move of the X3 committee to CBEMA.
Call for the Justice Department to investigate CBEMA's relationship to
the X3 committee.
Write the American National Standards Institute (ANSI), NY, NY.
Demand that X3 be deaccredited and reconstituted outside of CBEMA.
Write CBEMA.
Demand that CBEMA divest themselves of X3.
Write X3.
Demand that the X3.J14 charter be revoked.
Write SPARC (c/o X3)
Note to SPARC that X3.J14 doesn't even pretend to themselves that
the current draft proposed American National Standard document is
ready to be an American National Standard, that it is a disguised
political trial balloon, and as such is a fraudulent attempt to
coerce analysis from the Forth public.
(mailing's should be Registered or have Return Receipt Requested.)
X3 Secretariat:
Computer and Business Equipment Manufacturers Association
311 First Street, NW, Suite 500,
Washington, DC 20001-2178
Robert Berkey Member X3.J14 Technical Committee
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/07/91)
Category 10, Topic 2 Message 134 Sat Apr 06, 1991 ATFURMAN [Alan F.] at 20:00 PST Before I commence writing letters to the President, the Congress, and the UN High Commission on Refugees, would someone care to explain just what the legal status of the ANSForth standard will be? ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/07/91)
Category 10, Topic 2 Message 135 Sun Apr 07, 1991 B.RODRIGUEZ2 [Brad] at 11:50 EDT BTW, lest you think that we're the only group with these problems, check out the article "The Standards Process Breaks Down" in the September 15, 1990 issue of Datamation. Among other issues, it mentions the problem of X3 standards being driven by vendors and not users. - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
EBERBERS@YUBGEF51.BITNET (____ Zarko Berberski ____) (04/09/91)
> copyright (c) 1991 Robert Berkey > Splitting this posting into two parts or truncating it, for transmission > to other computer message systems, constitutes violation of copyright. So, I'v just violated that by including this excerpt since I'v truncated the original postingfot transmission to other computer message system :-) > I would vote NO against any so-called > "standard" that violated the mathematical use of the word MOD. This is the only real fact in the whole posting and it is certainly NOT the reason for such severe attack not only to all participants of Forth standardization prosecc but to X3 and CBEMA too. Actually, I seems to me that tha author is simply (mis)using Forth standardization as an excuse for a small private political campain and thas the kind of thing the Forth community certaily does NOT need. By the way - "the mathematical use of" MOD is not as an operator but as a qualifier of equivalence statemant so there is no popular computer language that implement the MOD the way we are using it in mathematics. > exposes fundamental hypocrisy and corruption in X3.J14. ----- ----- ----- ----- ----- ----- > However, my experience with X3 has been > that they cannot be trusted any more than X3.J14. ----- ----- ----- ----- ----- ----- > Robert Berkey Member X3.J14 Technical Committee A nice contradiction - all 3 clauses can't be true! So if I trust the first clause then I might trust the second but then what am I to conclude about Robert Barkey :-) and how am I to trust anything that such person have said ? > Note to SPARC that X3.J14 doesn't even pretend to themselves that > the current draft proposed American National Standard document is > ready to be an American National Standard, that it is a disguised > political trial balloon, and as such is a fraudulent attempt to > coerce analysis from the Forth public. First let me say that the recognition of the fact that dpANS is not ready to be ANS simply proves that members of X3.J14 are honest and reasonable people. Is something is a draft proposal it is NOT EXPECTED to be final, otherwise there would be no point of having that draft and I think that no one needs 500% IQ to realise that simple logical fact. If, after 4+ years the result of X3.J14 is not ready for public review then it will never be and Forth community desperately NEEDS the ANS standard as soon as possible. So, we could all disagree with something in dpANS but I hope that we all realize that standard is NOT something that is supposed to satisfy all our wishes but the document that has the main purpose of providing reasonable common base that will make information/knowledge transportable and widely recognizable/comprehendable. > BTW, lest you think that we're the only group with these problems, check out > the article "The Standards Process Breaks Down" in the September 15, 1990 > issue of Datamation. Among other issues, it mentions the problem of X3 > standards being driven by vendors and not users. Read previous and this excerpt in sequence and you have another contradiction - how could somebody complain about early release of draft proposal for public review and in the same time complain about public not being included in standardization proces? Mr. Barkey who are you trying to fool ??? > In this context it should be remembered just who X3 is part of: The Computer > Business Equipment Manufacturer's Association (CBEMA). Hmmm, a vendor's > association picking only vendors as officers? There are actually just two kinds of people that can realy do any techical standardization - university people and manufactuers. This is not to say that users shouldn't be listened to but just to emphasize that the formal proces of techical standardization must be based on serious work of experts and not on chit-chat in local pub or 1M wish-lists. We all know that there are no two users of anything that agree 100% on how the object they are using look, funcion etc. And we also know that disagreement in Forth community is even more severe so we could either let the honest and qualified members of X3.J14 do their job and then, during the public review period, try to persuade others that this and that should be changed or we can simply forget the very idea of having the ANSI standard. > Demand that X3 be deaccredited and reconstituted outside of CBEMA. With Robert Berkey as a leader perhaps? Why I have such strong filing that the autor of "copyrighted" posting has some kind of political aspiration ? Zarko Berberski : eberbers@yubgef51.bitnet eberbers%yubgef51@pucc.princeton.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/16/91)
Category 10, Topic 2 Message 143 Sun Apr 14, 1991 B.RODRIGUEZ2 [Brad] at 17:26 EDT > : 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,"... Indeed, can the parameter field of the DEFERred word be changed at all? My first thought was something like, : IS ['] >BODY ! ; ['] word-name IS deferred-word but I've been looking at Section 5.3.2, Addressable Memory, in my BASIS13 (sorry, I'm two BASES -- BASISes? -- behind), and I'm getting mixed signals. One clause seems to say that this is not permissible, another says that it is. Is the word IS as given above valid ANS Forth? And would someone please clarify the BASIS in this regard? - Brad P.S. to Zarko Berberski: you have erroneously attributed to Robert Berkey one of my postings, and have accused him of inconsistency thereby. For the record, _I_ was the one who posted the Datamation reference. BTW, is it your contention that "users" cannot be "experts"? Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
uh@informatik.uni-kiel.dbp.de (Ulrich Hoffmann) (04/17/91)
In comp.lang.forth Brad Rodriguez writes: >> : DEFER CREATE ['] COMPLAIN , DOES> @ EXECUTE ; >Indeed, can the parameter field of the DEFERred word be changed at all? My >first thought was something like, > : IS ['] >BODY ! ; > ['] word-name IS deferred-word Brad, you surely mean : IS ( <word> cfa -- ) ' >BODY ! ; and ' word-name IS deferred-word , right? As I understand, ansFORTH will allow to address the parameter fields of words defined by user defined defining words. Thus your implementation of DEFER would be perfectly legal. What about also defining : [IS] ( comp: <word> -- ) ( run: cfa -- ) ' >BODY POSTPONE LITERAL POSTPONE ! ; IMMEDIATE or a state smart IS? Personaly I would like DEFER to be included in the CORE EXTENSION WORDSET. I would expect F83 functionality if I ever see DEFER. (Does anyone use it in a different way?) If DEFER will be in the CORE EXTENSION WORDSET you can take it or leave it, but if you take it you have to define it with a standard funtionality. This would perfectly ok by me. Ulrich Hoffmann ---------------------------------------------------------------------- Christian-Albrechts-Universitaet Kiel, Institut fuer Informatik Preusserstr. 1 - 9 , D - 2300 Kiel 1 Telefon: ++49-431-5604-59 , Telefax: ++49-431-566143 EMail: uh@majestix.informatik.uni-kiel.dbp.de ----------------------------------------------------------------------
S47852EF@ETSUACAD.BITNET ("Frank C. Earl") (04/18/91)
>Personaly I would like DEFER to be included in the CORE EXTENSION WORDSET. >I would expect F83 functionality if I ever see DEFER. (Does anyone use it in >a different way?) >If DEFER will be in the CORE EXTENSION WORDSET you can take it or leave it, but >if you take it you have to define it with a standard funtionality. >This would perfectly ok by me. Hmmm.... CORE EXTENTION WORDSET (You getting this Mitch? :) I agree- the word DEFER doesn't have to be in the core, but I'd much like to standardise the word in the CORE EXTENTION WORDSET or have it as a EXTENTION word- it controlls the useage of the word and sets the ground rules for the operation. The minimalists shouldn't complain about adding onto the CORE EXTENTION WORDSET as it is an OPTIONAL word then- but if you actually have the word in the dictionary, then it'd better be the standard way of defining it... Frank
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/18/91)
Category 10, Topic 2 Message 145 Tue Apr 16, 1991 R.BERKEY at 23:01 PDT Zarko Berberski writes, 91-04-09, > If something is a draft proposal it is NOT EXPECTED to be final, > otherwise there would be no point of having that draft and I think > that no one needs 500% IQ to realise that simple logical fact. This is incorrect: the term "dpANS" has a specific technical meaning. The dpANS is the ultimate act of an X3 Subgroup Technical Committee (TC), such as X3.J14. When all goes well, the TC never sees the document again. Should the document be returned to the TC, the procedural rules change. Whereas before only a majority vote was required in the TC for changes to the document, that now becomes 2/3rds. The first time a dpANS is out for public review, the public gets four months to comment on it. After that, public review periods are only for two months. Robert Berkey ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
EBERBERS%yubgef51@PUCC.PRINCETON.EDU (____ Zarko Berberski ____) (04/19/91)
This is fun - trying to explain why my statement is
incorectt, Robert Barkey actually gives a precise proof of my
statement - I just love that :-)
Act I : statement and counter-statement
> > If something is a draft proposal it is NOT EXPECTED to be final,
> > otherwise there would be no point of having that draft and I think
> > that no one needs 500% IQ to realise that simple logical fact.
>
>This is incorrect: the term "dpANS" has a specific technical meaning.The
>dpANS is the ultimate act of an X3 Subgroup Technical Committee (TC),such as
>X3.J14. When all goes well, the TC never sees the document again.
>
up to now everithing seems to be fine - an occasional reader may
think that Robert Barkey is write and Zarko Berberski is relly
wrong - BUT ...
Act II : explanation
>Should the document be returned to the TC, the procedural rules change.
>Whereas before only a majority vote was required in the TC for changes to the
>document, that now becomes 2/3rds. The first time a dpANS is out for public
>review, the public gets four months to comment on it. After that, public
>review periods are only for two months.
and the conclusion is that - dratf proposal is not supposed to be
final (otherwise there wouldn't be the anticipated additional
rules for after-review TC work). Q.E.D. :-)
Zarko Berberski EBERBERS@YUBGEF51.bitnetForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/24/91)
Category 10, Topic 2 Message 149 Sun Apr 21, 1991 B.RODRIGUEZ2 [Brad] at 21:49 EDT > Brad, you surely mean > : IS ( <word> cfa -- ) ' >BODY ! ; > and > ' word-name IS deferred-word > , right? Duh. Yes, that's what I meant. Thanks, Ulrich. (Thanks also for a posting with your email address...I had lost track of you.) The troublesome clause from BASIS13 is from section 5.3.2. It clearly states: "...it is an exception if a Standard Program addresses memory other than: in dictionary space regions: from the address provided by a CREATEd word or HERE to the end of the region generated by consecutive allocations ( , C, ALLOT ALIGN ) made without intervening definitions or deallocations ( FORGET ); [rest of this section is about non-dictionary space]" This means that if you build a defined word with CREATE (or a word like DEFER which uses CREATE), say CREATE FOO , you can use the address returned by FOO. Period. Nowhere does it say you can tick FOO for its parameter field address, and this clause is carefully worded such that anything not explicitly permitted is forbidden. Has this clause been fixed in the latest BASIS? P.S. I can live with DEFER in the Core Extension wordset. I'm just touchy about the Core wordset. Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/15/91)
Category 10, Topic 2 Message 155 Tue May 14, 1991 D.RUFFER [Dennis] at 20:21 EDT TO: X3J14-watchers FROM: Elizabeth D. Rather, Chair I'm writing to keep you up to date on the status of the developing standard. In April, the TC voted 17-2 to submit our current draft as a dpANS. Exactly what this means will be discussed shortly. May 3-4 we met to consider the two negative votes. During this process, it became clear that additional "clean up" is necessary; to that end we have scheduled another meeting for June 16-18 at the University of Rochester, Rochester, NY (immediately preceding the Rochester Conference). The time and place was chosen to make it as easy as possible for those of us attending the Rochester Conference; if any of you who are interested to join us, you'll be welcome. Contact the Forth Institute or me if you need further information. At this time, primary attention is focussed on making the document as clear and consistent as possible. For example, much work is currently being done on organization, rationales, additional material to help people understand differences between ANS Forth and FORTH-83. A copy of BASIS16 (resulting from the May meeting) will be available about June 1. At the end of the June meeting, we will vote in the TC on submitting the results of that meeting to a letter ballot to approve release as a dpANS. If there are any negative votes on that letter ballot, they will be considered at our next meeting beginning July 30 in Boulder, CO. In any case, it is likely that a dpANS will go out for public review in approximately September. What does this mean? Few standards are as publicly distributed during the development process as this one. In most cases, the first widespread public dissemination of a proposed standard comes with the first 4-month public review. The objective is to get as broad a distribution as possible, and solicit as much public comment as possible. There will be a press release issued by ANSI, and every effort will be made to tell people that it's available for review and how to get it. The document will be sold through an organization called Global Engineering Documents. They not only sell draft and final standards, they also maintain a mailing list of people who buy copies. The reason for this is that when subsequent drafts (and ultimately the final ANS) are published, Global will automatically contact everyone who bought the last one and notify them that a new one is available. We don't know how much it will be; documents of similar size tend to run around $60 (I'm told people have complained about these prices for years -- Global swears it's near their cost. Remember too that you're paying to be on the official list). The dpANS will *not* be available from FORTH, Inc., on a BBS, or anywhere but Global. The purpose of this is to ensure that the proper tracking is done (people have been known to sue because nobody told them that a subsequent draft standard had been released). Comments can be positive or negative. They should be directed to ANSI, who will not only route them to us but will monitor our responses to all negative votes to ensure they're "responsive". The value of these comments, to the commenter as well as to us, will be directly proportional to their specificity. At our May meeting we had a guest from X3 who told us that someone wrote another TC, "your standard is so bad it's only fit for the fireplace." The TC responded, "we're glad you'll be warm this winter." On the other hand, if you call our attention to some critical technical flaw, a misstatement in a rationale, or some important piece of information missing or hard to find, for example, we will make every effort to fix it. We'll also carefully consider requests for missing features or to remove unpopular features, although in these cases we'll be looking more for widespread demand and are less likely to make a change in response to an individual request. ANSI will follow up as to whether you've found our response acceptable (a "resolved negative") or not (an "unresolved negative"). Unresolved negatives follow the document around until it is a final ANS. If ANSI thinks there are too many of them, or that our responses are inadequate, they can hold up further processing. We (the TC) can make any changes at any time. There's been some talk to the effect that at some point it's "out of our hands." This is never true until the final publication of the ANS. I've heard of TCs that stopped a standard days before its final publication because they wanted to change something. In theory, changes get harder to make, because a 2/3 vote is required. But in fact, operating rules require "consensus," which means in practice that virtually all actions are unanamous, and the rest have very small minorities (under 3 votes). Since our decisions have been reached by consensus, frequently achieved only after many hours of debate over several meetings, compromises, revisions, etc., we are unlikely to change them lightly. We were very open to public input throughout our process; we received lots, and it was very influential. At this stage, however, most issues have been dealt with at length and to our technical satisfaction. It is true that if any changes are made the document must repeat the cycle of letter ballot, approval by X3, and public review. After the first 4-mo. review, subsequent review periods are 2-mos. We're expecting the period during and after the public reviews to be active, busy and important. We're looking forward to getting some broad public response to our work. We also think it's very likely that there will be at least one more review period, because of changes either in response to public comments or internally generated. When the happy day arrives when there really is an ANS Forth, its legal status is as follows: no one is required to build systems that conform to it, and no one is required to write ANS Forth programs (at least, not required by ANSI. Your boss may...). Just like previous Forth standards, it will influence public usage precisely to the extent it is voluntarily adopted by implementors and demanded by users. **HOWEVER** -- UNLIKE FORTH-83, if someone claims to have produced an ANS Forth system, and uses that labeling, but is in violation of the standard, ANSI can force the labeling to be removed. They would do so in response to public complaints -- they haven't the capacity to "vet" all systems produced. I hope this clarifies things for you. We look forward to hearing from you. ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/02/91)
Category 10, Topic 2 Message 161 Sat Jun 01, 1991 B.RODRIGUEZ2 [Brad] at 18:02 EDT From Mitch Bradley: > [Cost-benefit analysis] has been applied. You just disagree with > the outcome. Really, Mitch? Can you honestly say that every addition and change to the BASIS was subjected to a cost-benefit analysis? (Before you answer, recall that you were one of the many people who explained how the TC deliberations were a _political_ process.) > A TC can take a document back for changes at any time. Thanks for the clarification, Mitch, and this is good to know -- but it misses the point of my original posting, which was what can be done if the TC "digs in its heels" and refuses to make changes to the BASIS. Only ANSI can force this, and no one knows where ANSI draws the line. - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/04/91)
Category 10, Topic 2 Message 162 Sun Jun 02, 1991 L.ZETTEL at 17:23 EDT I bet the same people who think a cost/benefit analysis isn't a political document also think you learn all the salient features of a system of government from a civics class :-) "There are few things in this world as subjective as a number, especially when you apply it" - president, American Statistical Associtation ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/10/91)
Category 10, Topic 2 Message 163 Sat Jun 08, 1991 B.RODRIGUEZ2 [Brad] at 14:17 EDT > "There are few things in this world as subjective as a number, > especially when you apply it" Indeed. And who was it who said, "There are three kinds of lies: lies, damned lies, and statistics." ? - Brad ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/28/91)
Category 10, Topic 2
Message 165 Fri Jun 28, 1991
D.RUFFER [Dennis] at 01:01 EDT
Re: UNBCIC@BRFAPESP.BITNET Daniel C. Sobral
> What's the current status of dpANS Forth???
Once again, the TC is conducting a letter ballot to forward BASIS17 back to
ANSI. If that ballot passes, BASIS17 will become the dpANS. I think the
deadline for that ballot is sometime in late July. We will let you know after
the deadline how the voting process turned out. I'm also hoping to have the
"rules" for public comment posted at that time. So, stay tuned, and cross
your fingers.
{B-{)> DaR
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp