GEnie@willett.UUCP (ForthNet articles from GEnie) (12/22/89)
Message 73 Thu Dec 21, 1989 R.BERKEY [Robert] at 01:08 PST To: Zafar Essak ZE> ...feel strongly that if ( " ) returned the address of the ZE> count it would be more useful. Yes, but address and length operands decouple the data structure from words that manage it, and allow one common, portable, general-purpose string descriptor. SKIP and SCAN for example, must have address and length. My preference is to have one common string descriptor in the standard, and another name for the single operand " . Just last week I EDITALLed through a megabyte of application code and renamed each of the " to $" in preparation for adding the address and length " . ZE> ... I got...rationalizations how (block 0) provided a great ZE> place for comments. The only Forth I've known that had blocks starting with 1 was my mistaken first attempt at a fig-FORTH. The problem only appears with operating system Forth's, as boot or object code gets put in block 0 on the standalone systems. At Dysan, we kludged around the problem by storing -1 in BLK when block 0 was being interpreted. Pygmy's approach in mapping file blocks onto one master set of block numbers has a certain elegance. ZE> But I am still not clear from BASIS 10 if BLOCKS will be ZE> numbered from 0 up or from 1. Good point. X3.J14 has deleted the Forth-83 specifications that there are known block numbers 0-31, with other available block numbers documented. I'm hesitant to guess why. Robert Berkey ------------ ----- This message came from GEnie via willett through a semi-automated program. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)
Category 10, Topic 35 Message 74 Fri Dec 22, 1989 R.BERKEY [Robert] at 07:42 PST To: Roedy Green RG> 7.0340 2>R RG> Remove the editor's note on why DO parms are backwards... I agree, even if for a different reason. What the 2>R rationale doesn't quite say is that DO has been implemented on pre-1983 system's as: : DO COMPILE 2>R ; IMMEDIATE with the parameter's for DO having been set long before this 1981 implementation was noticed. Upon learning of 2>R , I at first thought that the parameters were backwards, a kludge to save a few bytes by not having a (DO) . Later I realized that they aren't backwards. Looking at how the numbers appear in memory, this version maintains the double number. Another way to describe this is that 2>R can be implemented using 2@ and 2! . If the rationale given in BASIS was the reason for this order of parameters now being standardized, I'd be opposed to it: because standardizing a word designed for obsolete loops that speed optimize on DO is standardizing garbage. Anyway, thanks for your comments about the 2>R rationale. Robert Berkey ----- This message came from GEnie via willett through a semi-automated program. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'