wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/13/91)
> Here's something else which (to my mind) cannot be implemented _efficiently_ > in a portable way using ANS Forth. Even the inefficient ways are difficult. > > : || IF R> DROP -1 THEN ; ( t - t) ( f - ) ( exit on true) > : && 0= IF R> DROP 0 THEN ; ( t - ) ( f - f) ( exit on false) : || POSTPONE DUP POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE : && POSTPONE DUP POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE This is efficient in terms of speed, but inefficient in terms of space. I don't think it is particularly difficult. The problem with R> DROP is that it implies detailed knowledge of how the return stack is used for colon definitions. For some Forth hardware and some optimizing compilers, the assumptions made by R> DROP are violated. This is an existing problem that ANS Forth did not create; it simply chose not invalidate those existing Forth implementations by requiring something they could not provide. It will still be possible to use R> DROP on most ANS Forth implementations. From a de-facto standpoint, it will remain about as portable as it has ever been (i.e. reasonably portable). It is possible to use the portable implementations shown above for the "completely-standard" version of your application, and substitute the not-quite-portable versions when running on systems on which they work. This is not a new technique; people do it all the time with CODE word "accelerators" for portable high-level definitions. By the way, I sometimes use CATCH and THROW to implement multiple "bail-out" points, which is what it looks like || and && are trying to solve. CATCH and THROW can be compiled inside colon definitions to make new custom tools like the above. Mitch
uh@informatik.uni-kiel.dbp.de (Ulrich Hoffmann) (02/13/91)
In <9102122127.AA04970@ucbvax.Berkeley.EDU> wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: B.Rod>> Here's something else which (to my mind) cannot be implemented _efficiently_ B.Rod>> in a portable way using ANS Forth. Even the inefficient ways are difficult. B.Rod>> B.Rod>> : || IF R> DROP -1 THEN ; ( t - t) ( f - ) ( exit on true) B.Rod>> : && 0= IF R> DROP 0 THEN ; ( t - ) ( f - f) ( exit on false) M.Bra>: || M.Bra> POSTPONE DUP POSTPONE IF POSTPONE EXIT POSTPONE THEN M.Bra>; IMMEDIATE M.Bra>: && M.Bra> POSTPONE DUP POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN M.Bra>; IMMEDIATE Mitch, I think you misinterpreted Brad's words. && and || are ment to leave a flag on exit, to _drop_ it otherwise. Thus possible definitions might be: : || ( true -- true&EXIT ) ( false -- ) ( comp: -- ) POSTPONE DUP POSTPONE IF POSTPONE EXIT POSTPONE THEN POSTPONE DROP ; IMMEDIATE ( ^^^^^^^^^^^^^ ) : && ( true -- ) ( false -- false&EXIT ) ( comp: -- ) POSTPONE DUP POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN POSTPONE DROP ; IMMEDIATE ( ^^^^^^^^^^^^^ ) Apart from that I fully agree to what you stated. || and && CAN implemented portably and (at least runtime efficiently) using ANS Forth. Ulrich 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 ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------
wmb@MITCH.ENG.SUN.COM (02/14/91)
> Mitch, I think you misinterpreted Brad's words. > && and || are ment to leave a flag on exit, to _drop_ it otherwise. > Thus possible definitions might be: > : || ( true -- true&EXIT ) ( false -- ) ( comp: -- ) > POSTPONE DUP POSTPONE IF POSTPONE EXIT POSTPONE THEN POSTPONE DROP > ; IMMEDIATE ( ^^^^^^^^^^^^^ ) Oops, I screwed up while trying to optimize it. How about: : || POSTPONE ?DUP POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE or : || POSTPONE IF POSTPONE TRUE POSTPONE EXIT POSTPONE THEN ; IMMEDIATE which brings up another point: TRUE and FALSE will be in Basis 15. Mitch Bradley, wmb@Eng.Sun.COM
uh@informatik.uni-kiel.dbp.de (Ulrich Hoffmann) (02/19/91)
In <9102141431.AA13743@ucbvax.Berkeley.EDU> wmb@MITCH.ENG.SUN.COM writes: > : || POSTPONE IF POSTPONE TRUE POSTPONE EXIT POSTPONE THEN ; IMMEDIATE >which brings up another point: TRUE and FALSE will be in Basis 15. Exactly what I had mind. I was unsure about TRUE and FALSE, so didn't use them. Well, what about the values they represent. -1 and 0 as in FORTH-83? What's the current status of NOT? I often found it useful to define TRUE and FALSE by 0 CONSTANT FALSE ( -- ff ) FALSE NOT CONSTANT TRUE ( -- tf ) which works on FIG and Forth-83 Systems. 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 ----------------------------------------------------------------------