Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 16 Aug 2013 05:59:04 -0500 User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Fri, 16 Aug 2013 11:59:02 +0100 Subject: LOCALS| and {: From: Ian van Breda Newsgroups: comp.lang.forth Message-ID: Thread-Topic: LOCALS| and {: Thread-Index: Ac6ab53PJxKg1VQ9TSGtWlVRfNOI/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Lines: 60 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-4ctjKFvC68UiAc2Er+Ju5kumuo627ClyyhtQYFNyGWjaYZKUlKjDfO0HtcTaLsm8bE7k1gkYHBifBO2!VD2jT5eivWT/EMgnBeKWS/CRxuXRB8BE0qYUnW5XCaqwS/pxsHSMR7SMfqVb1hxZLrsy X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3756 Xref: csiph.com comp.lang.forth:25242 In the Forth standards proposal a new form of LOCALS| is introduced in the form of {: . See the Forth Standards Committee, Forth 200x Draft 11.1, 29th February, 2012. I have found the use of LOCALS| invaluable, partly because it greatly simplifies stack manipulation and partly because it allows intermediate values to be named, considerably improving documentation and software maintenance. Having got used to using LOCALS| it is somewhat confusing to find that names are reversed in {: . Although not explicitly stated, it appears that {: :} is intended to be used at the front of definitions. It is suggested that LOCALS| also be divided between 'arg' values and 'val' values. However, using a | as a separator is more difficult in LOCALS| as it is also used as a terminator. An easy way out is to use a || as separator between arg values and val values. For example, in the code snippet for my definition, PROCESS-PRODUCTION, there are three arguments, of which one is a modification of the initial stack arguments \ Setting derives-lambda flags \ Expects: index for enclosing nonterminal; production index; index \ for start of production in GrammarTable : PROCESS-PRODUCTION ( n-index1 n-index2 n-index3 -- ) ProductionLambdas [[ SWAP ]] \ Address of production flag LOCALS| productionLambda grammarIndex hostIndex || setPattern grammarAddress nontermLambda | Normally, this would need three zeroes preceding the three val variables 0 0 0 LOCALS| setPattern grammarAddress nontermLambda productionLambda grammarIndex hostIndex | The order for the three val values is immaterial. The advantages of this: (1) The number of uninitialized variables are unlimited while the number of initialised locals can still be up to eight - plenty for normal use. (2) There are no limitations on the number of rows allowed for the names of the variables - I like to use full names for the variables so often cover more that one line. (3) There are often some stack operations before any LOCALS| are defined. (4) In its incarnation on the return stack (system-specific), it is faster in execution, as the val variables need not be put on the stack explicitly. (5) This brings both {: and LOCALS| into line with each other. (6) Not all the arguments in a LOCALS| list need be named explicitly. One definition that is useful is +TO which increments a variable LOCALS| variable. moveCount BufferCount + TO BufferCount is better as moveCount +TO BufferCount This is particularly in counting of indefinite loops. Ian van Breda