Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Ruvim Newsgroups: comp.lang.forth Subject: Re: Recognizers and cross compiling Date: Mon, 6 Jul 2020 09:51:27 +0300 Organization: A noiseless patient Spider Lines: 78 Message-ID: References: <2020Jun28.191450@mips.complang.tuwien.ac.at> <866853e2-60a6-4a14-b72b-87bc22175739o@googlegroups.com> <2020Jul2.191532@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 6 Jul 2020 06:51:27 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="055f843bc45fc604a2924b34a532ed1f"; logging-data="18203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18b7WL4xVXHzK1imvWCZdKP" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cancel-Lock: sha1:VAGbDey7Lbpf9i8LKz4/UEDte98= In-Reply-To: Content-Language: en-US Bytes: 4966 On 2020-07-05 22:09, aph@littlepinkcloud.invalid wrote: > Ruvim wrote: >>> >>> Why? Of course you have to lay out the dictionary on the target >>> system, but you can also have a wordlist on the host in which each >>> entry in this wordlist is a constant that points to the address on the >>> target. This is how it was done decades ago, and it still works >>> today. Why complicate things? >> >> I can guess, it was done decades ago in some system dependent way. > > Some of it was system dependent, but not this part. > >> But the Recognizer API (when it is standardized) provides a portable >> way of reuse the Forth text interpreter of the host system. >> >> Yes, we can have a wordlist on the host with the shadow definitions >> (that are created in parallel). But each entry is not an arbitrary >> address that we want, but a definition in the host system and the >> corresponding xt in the host system. >> >> The Forth text interpreter of the host system can get xt of a shadow >> definition, but how it can compiler it into the target dictionary? > > There is no need to use the text interpreter of the host system. Well, if you don't use this text interpreter, why do you want to use a wordlist of the host system as a mapping to the target wordlist? > Doing > so complicates the whole business: a better factoring (IMO, YMMV, &c.) > has two text interpreters, one for host words and one for target > words. It's better to separate words than to use a single word with > vectoring in the middle. It seems you missed my point in the first message by this subject (see news:rdeq20$a1m$1@dont-email.me). You compare the different approaches (i.e, one interpreter vs two interpreters), but I compare the same approach having the recognizers and without them. There are many approaches in Forth cross compiling. I don't compare them, what is better or isn't. I only pointed out that *some* of them can benefit from using recognizers. Particularly, recognizers can help if otherwise we want to implement a special Forth text interpreter for the target compilation and also re-implement EVALUATE and INCLUDED. Perhaps, the approach I have in my mind is different from yours. By my experience, the text interpreter that generates code for the target system should resolve names in the host dictionary as well as in the target dictionary. Namely, during cross compilation, the immediate words should be taken from the special cross-compiling wordlist in the host system, all other ordinary words — from the target dictionary. > The text interpreter itself is far simpler than the cross compiler as > a whole, and so I fail to see the motivation to use the interpreter on > the host. Using recognizers instead of just writing another > interpreter loop is pointless. Yes, the text interpreter itself is a very simple thing. But if you want INCLUDE or EVALUATE uses the new interpreter, you have to re-implement them and also INCLUDED, REFILL, SOURCE, PARSE, PARSE-NAME, and all the words that use them, e.g. "\", "(", "[IF]", etc. So it is not only another interpreter loop, but also the full corresponding layer of a Forth system. Now it should not look so pointless to use the recognizers. -- Ruvim