Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: gforth too bloated ? Date: Thu, 15 May 2014 17:39:40 -0400 Organization: Aioe.org NNTP Server Lines: 72 Message-ID: References: <4b4ea6f6-3b09-434a-a501-ff31190b9f4a@googlegroups.com> <2014May10.123904@mips.complang.tuwien.ac.at> <7qadnesZfp6twfPOnZ2dnUVZ_qGdnZ2d@supernews.com> <2014May11.141024@mips.complang.tuwien.ac.at> <2014May13.184005@mips.complang.tuwien.ac.at> <47qdnXip89VGwe_OnZ2dnUVZ_jadnZ2d@supernews.com> <2014May14.140323@mips.complang.tuwien.ac.at> <7xha4sl4hf.fsf@ruckus.brouhaha.com> <2014May15.162231@mips.complang.tuwien.ac.at> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:30404 On Thu, 15 May 2014 10:22:31 -0400, Anton Ertl wrote: > "Rod Pemberton" writes: >> If that's the case, a word LOCAL , functioning similar to VARIABLE , >> but which allocates space on the stack, would be better. Wouldn't it? > > Better than what? For what purpose? > Well, I started to say better syntax: LOCAL x LOCAL y defined globally like VARIABLE x VARIABLE y. At first, I didn't see the point of needing braces { } to delimit defining 'x' and 'y'. Now, I'm guessing that 'x' and 'y' aren't global, but 'x' and 'y' have local scope limited to the defining Forth word. So, 'x' and 'y' in 2DUP are different from those in DUP SWAP DROP and also different for each instance of 2DUP. Therefore, these Forth locals are just like the named function parameters used in C. In which case, locals are providing a name for parameters to Forth words, but are being named after the fact. Now that the Forth parameters are named, an optimizer can relocate them wherever it wants: stack, memory, or register. Since they're temporary, they can be allocated and free'd the same was as C does in it's procedure calling conventions. If that understanding is correct, that's an interesting way to introduce optimizations which C has, such as registers, into Forth. It would also mean that the braces { } delimit the parameter list. I'm assuming that older, non-optimizing Forths will just define a temporary variable with the address location for the item on the stack. But, I'm not sure how older Forths would handle destroying or freeing the variable at the end-of-use, without major internal changes to the interpreter. Where is the garbage collection in an interpreted Forth? ... I can also see the braces syntax being a slight implementation issue for older Forths too. The { brace would need to be some type of looping word to fetch the name of each local to be defined. That could be a problem too. E.g., in my interpreted Forth, looping words are not available until almost all other words have been defined. I.e., the need for looping could restrict implementation and usage of locals until most of the dictionary was complete, as in my case. That partially defeats the purpose of locals. So, it still might be better to use a single Forth word instead of delimiters to indicate locals. Then, a definition which works on simple Forths might be more forthcoming. Perhaps, LOCAL within the colon definition could be used: : 2DUP ( x y -- x y x y ) LOCAL x LOCAL y x y x y ; The standard stack comment placed between the end of the locals and the definition body could be used prevent confusion. : 2DUP LOCAL x LOCAL y ( x y -- x y x y ) x y x y ; Or, some other comment: : 2DUP ( x y -- x y x y ) LOCAL x LOCAL y ( body ) x y x y ; I'd say that if locals of any form are widely adopted, it should definately improve optimizing Forths and help with conversion of Forth to C. But, I'm uncertain as to how difficult or easy it would be to implement this within an interpreted Forth. Currently, I think it would have some issues as mentioned above (looping, garbage collection). I.e., this seems to be a feature that preferences modern Forths. Rod Pemberton