Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.szaf.org!news.gnuher.de!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: Bernd Paysan Newsgroups: comp.lang.forth Subject: Re: State and the standard ... Date: Tue, 05 Mar 2013 00:14:31 +0100 Organization: 1&1 Internet AG Lines: 44 Message-ID: References: <5131e181.1497895969@192.168.0.50> <51327902$0$621$e4fe514c@dreader34.news.xs4all.nl> <2013Mar3.155647@mips.complang.tuwien.ac.at> <1c9a5027-6d8f-48b6-a82c-0cc76b256892@i5g2000vbk.googlegroups.com> NNTP-Posting-Host: p5dcd6160.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: online.de 1362438872 3209 93.205.97.96 (4 Mar 2013 23:14:32 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Mon, 4 Mar 2013 23:14:32 +0000 (UTC) User-Agent: KNode/4.10 Xref: csiph.com comp.lang.forth:20262 Mark Wills wrote: > Can we not think of the problem 'the other way around' for a minute? > Maybe it would be useful. > > We're pointing the finger at "state-smart" (using the conventional > meaning ;-) words because we cannot differentiate interpretation > semantics from compilation sematics via tick. Actually, the problem goes a bit deeper, it is the xt returned by ' and FIND. This xt is the problem, it does not allow straight-forward access to its interpretation and compilation semantics. Especially since the immediate flag is lost, the xt does not know if it is immediate or not. Smart COMPILE, fixes that. But then, it somewhat changes the meaning of COMPILE,. > Therefore, simply standardise a new word, something like 'I (which > means 'tick the *interpretation* behaviour/address/cfa/whatever' of > the word. Or COMP' for ticking the compilation behavior, as ' always did return the xt for the interpretation semantics. > Of course, this has implications on the underlying architecture, and > raises further questions. Now the dictionary (presumably) must be able > to store pointers to both the compilation (for regular ') and > interpretation semantics (for 'I ). Furthermore, what happens if the > word has no interpretation sematics? Do you return the compilation > sematics as a default, or return a 0 to expressly indicate that there > are no interpretation semantics? All open for argument. The dual-token approach with ' for interpretation semantics and COMP' for compilation semantics has already been tried out, it's Anton's approach at solving the problem; it is in Gforth since quite some time. It wasn't a full solution, since it required adding another type, the "name token", which still had all relevant informations, and converting that to an xt, these informations were lost. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/