ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/24/90)
Category 18, Topic 85 Message 33 Thu Aug 23, 1990 D.RUFFER [Dennis] at 16:08 EDT Re: ir230@sdcc6.ucsd.edu (john wavrik) > Suggestion: The ANSI team make available a packet consisting of > the printed BASIS document and a diskette with the document in > machine-readible form (preferably including a plain ASCII text > glossary file). THIS SHOULD BE AVAILABLE IN A TIMELY FASHION SO > THAT USERS HAVE AMPLE TIME TO PREPARE SUBMISSIONS TO THE ANSI > TEAM. I will pass your suggestion along John, but the problems with ASCII represenations of the BASIS document have been discussed at length. Refer to my posting from Elizabeth Rather to Mark Carroll on that subject. As far as the timeliness of the document, we are doing as good as possible. Remember that every 3 months a meeting is held that drastically changes the document. A volunteer editor must then sit down and make some sense out of the stack of 100 some proposals and apply those changes. Then the document is reviewed and made ready for printing. Then and only then is it posted electronically. Depending on the volunteer, this may take a few weeks or a few months. This time was especially difficult since the editor had to buy a computer and learn Word. We just made the 2 week mailing. Hopefully we will do better in the future, but be assured that everything is being done that can be done. II. Deferred Execution > Will the proposed ANSI standard have a portable mechanism for > deferred execution (like the F83 words DEFER and IS) As far as I can tell, you can still define them as follows: : UNINIT ." Not vectored " ; : DEFER CREATE ['] UNINIT , DOES> PERFORM ; : IS ( w -- P: Compile or change defered vector ) ' >BODY STATE @ IF LITERAL POSTPONE ! ELSE ! THEN ; IMMEDIATE Although this is not the way F83 defined them, I believe it is equivalent since BASIS has no definition for USER variables. III. Recursion and return stack size > When implementing a recursive algorithm it often becomes necessary > to increase the size of the return stack. Will there be a portable > way to do this? I would be hard pressed to alter the size of either stack in most Forths without recompiling their nucleus' so I wouldn't expect that to be portable. However, in ANS Forth, I can at least determine how big the return stack is so that I can write an application that can tell if it can run. I think I could use a word such as: : CHECK-SIZE ( n -- P: Check return stack depth ) " RETURN-STACK-CELLS" ENVIRONMENT? NOT IF 24 THEN > ABORT" Return stack is not big enough" ; > Along the same lines: will there be words analogous to RP0, SP0, > RP@, SP@? With multiple segment architectures, I wouldn't know what addresses any of these operators would refer to. If all you are interested is emptying the stacks, then ABORT clears the parameter stack and calls QUIT which clears the return stack. Otherwise, only the DEPTH of the parameter stack can be interrogated. I can see uses for these operators in defining ways to dump the stack contents, but I've never had a need for them in application words. I wouldn't consider debugging aids to be very portable. Can you cite a specific application need for these words? IV. Language Constructs > My impression is that the proposed ANSI Standards will not > provide a portable means for accessing the IP (and that code > which involves handlers cannot be portable). Is this correct? This is my impression also. However, I might take a crack at your example as follows: : )IF ; : IF( 0 >R \ count the number of IFs used BEGIN >IN @ ' ['] )IF = NOT WHILE >IN ! POSTPONE POSTPONE POSTPONE IF POSTPONE POSTPONE POSTPONE ELSE R> 1+ >R REPEAT DROP R> 0 DO POSTPONE THEN LOOP ; IMMEDIATE Wouldn't that accomplish your same objectives? Other than being more careful about how you write applications, I think most of what you can do now is possible with ANS Forth. Some thought may have to go into ways to make things portable, but the point is that it is possible. V. Power of Proposed Standard > Is the ANSI team willing to provide clarification, at this point, > as to whether or not a purpose of the proposed Standard is to > allow users to write significant programs portably? I think this depends on what you mean by a "significant program". The standard does not address user interface techniques that I would want to use in an application, but I could scale the application back so that it uses a simple TTY interface and still remain portable. Basically, if I want to make my application portable, I will have to work harder when designing the application so that I am sure to use only standard words. Although I do not think your question can be answered generically, I do believe that portable solutions can be found for most specific needs. By continuing to ask specific questions, we can determine how well the ANS Standard can be used to solve the problems. Thanks for the excersises. <grin> 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/09/90)
Category 10, Topic 21 Message 46 Sun Oct 07, 1990 B.RODRIGUEZ2 [Brad] at 21:30 EDT The unstated assumption (presumption?) here is that exception handling is necessary in ANS Forth. I, for one, don't believe that we need exception handling in order to standardize the language. And I get very uncomfortable around people who want to "get things into" the ANS Standard. (No offense, Mitch.) - 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) (01/28/91)
Category 10, Topic 21 Message 62 Sun Jan 27, 1991 B.RODRIGUEZ2 [Brad] at 14:59 EST Doug Philips comments: > What you really want here is some kind of UNWIND-PROTECTION so that > if the current word is going to be blasted off the return stack > by a catch, you want some code to execute first. Indeed, I ran into this problem once, and the exception handler I designed (see SIGForth vol.1 no.2) had precisely this capability. (It also allowed execution to continue after corrective action was taken, but this capability may not be as generally useful.) Concerns like this are why I believe it's too soon to standardize a Forth exception handler. - 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
esj@harvee.UUCP (Eric S Johansson) (01/29/91)
In article <2284.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: > > Doug Philips comments: > > > What you really want here is some kind of UNWIND-PROTECTION so that > > if the current word is going to be blasted off the return stack > > by a catch, you want some code to execute first. > > Indeed, I ran into this problem once, and the exception handler I designed > (see SIGForth vol.1 no.2) had precisely this capability. > (It also allowed execution to continue after corrective action was taken, but > this capability may not be as generally useful.) > > Concerns like this are why I believe it's too soon to standardize > a Forth exception handler. > > - Brad > ----- I beg to differ. I believe the knowledge needed for a "good" exception handler is available from outside the forth community. I suggest folks check out exception handlers in eiffle, c++ smalltalk and lisp as role models for a forth exception handlers. I generally find the current definition of catch/throw almost primitive enough to permit construction of more "complete" exception handlers. The one thing I find missing and can't figure out how to synthesize is something like the eiffle retry semantics. the fact that we can think of problems with a part of the standard is no reason to chuck that part. --- 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/04/91)
Category 10, Topic 21 Message 64 Sat Feb 02, 1991 B.RODRIGUEZ2 [Brad] at 23:38 EST > I suggest folks check out exception handlers in eiffle, c++ > smalltalk and lisp as role models for a forth exception handlers. You forgot Ada. :-) Seriously, do ANY TWO mainstream computer languages agree on an exception handler? - 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/08/91)
In article <2756383@harvee.UUCP>, esj@harvee.UUCP (Eric S Johansson) writes: > I beg to differ. I believe the knowledge needed for a "good" > exception handler is available from outside the forth community. > I suggest folks check out exception handlers in eiffle, c++ smalltalk > and lisp as role models for a forth exception handlers. I generally > find the current definition of catch/throw almost primitive enough to > permit construction of more "complete" exception handlers. The one > thing I find missing and can't figure out how to synthesize is > something like the eiffle retry semantics. > > the fact that we can think of problems with a part of the standard is no > reason to chuck that part. Personally, when I consider at what should or shouldn't be in the standard, preference should be given to putting into a core wordset the lowest level words that will *portably* let you write code to do X. Then, if there is a need (real or perceived, but I don't what to get into that here) for some "common tools" like CASE, that can be in an extended wordset. This is one reason I like Wil Baden's control structures, they are at the lowest *portable* level, and give the necessary flexibility. The issue of the CASE statement I'm more ambivalent about. As for CATCH/THROW, I think that we need low-level words to implement a variety of non-local control structures (which are not as important as the local control structures). Of course, it would be ideal if there would be one unified set of control structure words, but I don't know if Wil has looked into that or not, or even if it is possible. I think Mitch's CATCH/THROW are sufficient for that, but I'm not an expert Forth programmer. -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 <2756383@harvee.UUCP>, esj@harvee.UUCP (Eric S Johansson) writes: ``(Brad Rodriguez writes:) `` ``> Indeed, I ran into this problem once, and the exception handler I designed ``> (see SIGForth vol.1 no.2) had precisely this capability. ``> (It also allowed execution to continue after corrective action was taken, ``> but this capability may not be as generally useful.) ``> ``> Concerns like this are why I believe it's too soon to standardize ``> a Forth exception handler. `` ``I beg to differ. ... The one ``thing I find missing and can't figure out how to synthesize is ``something like the eiffle retry semantics. `` ``the fact that we can think of problems with a part of the standard is no ``reason to chuck that part. Au contraire... the fact that ``we can think of problems with a part of the standard'' is _absolutely_ reason enough to ``chuck'' that part. Only those things that are proven aspects of Forth should be standardized as part of ANS Forth (in my heretical opinion). -- 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...' /______\
esj@harvee.UUCP (Eric S Johansson) (02/14/91)
In article <1991Feb12.075739.12678@world.std.com> dcp@world.std.com > In article <2756383@harvee.UUCP>, > esj@harvee.UUCP (Eric S Johansson) writes: > > ``the fact that we can think of problems with a part of the standard is no > ``reason to chuck that part. > > Au contraire... the fact that ``we can think of problems with a part > of the standard'' is _absolutely_ reason enough to ``chuck'' that > part. Only those things that are proven aspects of Forth should be > standardized as part of ANS Forth (in my heretical opinion). Where as I assert that only those things that are proven aspects of many different languages should be standardized as part of ANS language efforts (not just forth) (in my heretical opinion). We *CAN NOT* afford to keep on reinventing the wheel in software development in general and forth specificly. If a concept has stood the test of time and has become common practice, then it is acceptable (IMNSHO) to include it in the forth standard. For example, there is one word I would like to see added to the standard. It is the word OBSOLETE. It would be used after definitions to mark them as OBSOLETE and print a warning when ever the word is used. It would be most useful to users of forth toolkits to warn them of uage of interfaces that are going away. I saw this concept in eiffle. Usage: : xyzzy ... ; obsolete : qwerty ... xyzzy ... ; when qwerty is compiled, The compiler would print the message like " qwerty using obsolete word xyzzy" or some such nonsense. feedback?? Dave, we have been party to many discussions about the ansi std. I respect your opinions (don't always agree but I respect'em) You meet so many interesting people with so many interesting opinions here in forthland. :-) And speaking of interesting opinions, here is another.... read with a bit of salt :-) There is one way I could agree to shrinking the ANSI wordset thereby eliminating all of these controversies over the string or file or ... wordsets. Define a standard way of calling C functions from forth. Then anyone could use all the functions in libc.a or any other C library and not need to reinvent the wheel (or words) in forth. Think about it, interface to C in an standard sequence and all the issues of strings, files, floating point, networking, GUI are mostly solved. Use the C names, with the C specified arguments in a forth context. real easy. But I figure this will never fly because the forth hackers of the world have their egos too wrapped up in reinventing the wheel in the forth way to get any real work done and make money using forth. --- 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/18/91)
Category 10, Topic 21 Message 69 Fri Feb 15, 1991 F.SERGEANT [Frank] at 23:39 CST > We don't chuck Newtonian mechanics because it ultimately fails to > work in relativistic situations. . For another viewpoint on this, readers might want to check out *Einstein Plus Two* by Petr Beckmann (212pp, $36ppd, The Golem Press, Box 1342, Boulder, CO 80306) or the journal *Galilean Electrodynamics* (sample copy probably available through Golem Press). These suggest ways that Newtonian mechanics *can* explain all the observations that are usually thought to require the Einstein theory. Beckmann is also the author of *A History of Pi*, which is a very entertaining book. -- 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