Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: ANS TC Magnet for Division Message-ID: <12112@sdcc6.ucsd.edu> Date: 1 Aug 90 05:08:38 GMT References: <9007292127.AA24336@ucbvax.Berkeley.EDU> Organization: University of California, San Diego Lines: 72 Daniel Sobral writes: > I think ANS TC Magnet for Division is an excelent Subject > Description for the messages that came with it. I remember reading > about someone saying that having both SM/MOD and FM/MOD makes the ANS > Forth Standard weaker than having only one... I didn't understand > why. I think the main objection to what ANSI has done to division is not so much this one particular thing but rather what it says about the approach that the ANSI team is taking. The real issue is how the ANSI team is going about creating standards. This newsgroup is interesting reading. Some of the articles are written by two people who I will call J and M. J, a user of Forth, is very concerned about how the standards are shaping up -- it seems to him that the ANSI team is doing things that are destined to result in a weak standard. He expresses his worries in the form of analogies: I am concerned because what the ANSI team seems to be doing looks like this...". M, a member of the ANSI team, immediately posts a reply ostensibly to deny the analogy -- but he then goes on to provide ample evidence to confirm J's worst fears. This has been repeated several times. As a result, it seems quite likely that users (rather than vendors) of Forth have just cause to worry. Let's look at division. Here is the way in which the ordinary signed division operation is obtained from UM/MOD (copied from F83): >R S>D R> ?DUP IF DUP >R 2DUP XOR >R >R DABS R@ ABS UM/MOD SWAP R> ?NEGATE SWAP R> 0< IF NEGATE OVER IF 1- R@ ROT - SWAP THEN THEN R> DROP THEN SWAP DROP If everyone would use this sequence whenever division is required in their application, all would be well. We could glance at it and tell immediately what kind of division is being used. But this will not happen. Instead programmers will define / somewhere (probably in a file which is automatically loaded into their system). They will use the symbol / for division -- but it now will be a programmer-dependent word. Apparently the ANSI team, insofar as they have any interest in portability at all, seems to be thinking in terms of entire applications. What is more likely to be beneficial for the future of Forth is the ability of programmers to exchange individual words or application fragments. Currently, when looking at a fragment in Forth Dimensions, JFAR, etc., one must know if the code is in Forth-79 or Forth-83. Once this is known, the meaning of a collection of basic words (like /, ', PICK, ROLL, etc) are known. A compromise which makes basic words programmer dependent increases the difficulty of understanding application fragments. It is a very bad idea to let the meaning of fundamental words float. There should be absolute agreement on the meaning of the 100-150 words needed to generate the Forth language. Vendor eccentricity and "value added" features should be at a higher level. These statements are really not revolutionary. Both Shakespeare and Hemmingway agree on the meaning of "the", "is", "be", etc. Their contribution to writing does not consist in changing the meaning of fundamental English words. Allowing everyone to choose their own meaning for basic words can only have one effect: it will make it harder to communicate. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093