Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Forth philosophy Date: Thu, 12 Jun 2014 07:33:57 -0400 Organization: Aioe.org NNTP Server Lines: 72 Message-ID: References: <0JCdneuVOuwhbgXOnZ2dnUVZ_oadnZ2d@supernews.com> <85udnU8yV9DHrgTOnZ2dnUVZ_tadnZ2d@supernews.com> 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:31450 On Thu, 12 Jun 2014 00:58:01 -0400, Elizabeth D. Rather wrote: > On 6/11/14 6:24 PM, rickman wrote: >> I agree. Sometimes I wonder if Rod really believes the things he says >> or if he is just free associating and then working to defend his >> statement like playing a game of go. > > Well, I'm sure the fact that he wrote his Forth in C influenced his > opinion. I don't see why. As I've stated many times to Hugh who doesn't bother to remember this either, I've not used the classic method of implementing Forth in C: switch(). My implementation uses ITC with an interpreter in C. It's virtually identical to implementing a Forth in assembly. I.e., if I had implemented it in assembly, it wouldn't be different, or not much. > Some of the code he showed us here is pretty tortured, [...] I think that's a mischaracterization. First, it's wasn't C code that was posted and "tortured" as I think you've implied here ... Second, the one "tortured" Forth example was due to a failed attempt to relocate a few high-level Forth words to be defined much earlier in the dictionary. Once the failed optimization was backed out and removed, the resulting Forth code was identical to what I had months before. The failed optimization wouldn't have even been possible if it had been revealed that my Forth was missing an certain implementation detail. The issue for that was discussed in depth here some months earlier, which you might've considered to be "tortured" too. > [...] partly because he didn't have Forth programming background [...] I don't believe that has anything to do with it. Lack of any serious documentation on Forth implementation details has been a far bigger hindrance, IMO. As you should recall, everything I've implemented passes Hayes core tests (about 2/3rds), except one: nul terminated strings, which can be fixed with the addition of a single byte. I know one of my loop constructs is broken, but I must leave that for the future. +LOOP has no way to obtain an "overflow bit" from C ... Many of the high-level definitions match widely available definitions for well known Forth words. Some of this was by happenstance, i.e., only one way or one best way or simple, and others were because I searched c.l.f. for standardized, commonly known, and widely used definitions for compatibility. As you may recall, I've also tested a bunch of Forths for compatibility of functionality on different issues. My stack words are a bit odd at the moment because I was defining them in Forth to reduce C dependence and using some lower-level primitives to do so. But, they can be backed out and reverted quickly and in the future. > [...] but mostly because of requirements imposed by C. So far, there are only a few serious issues with C, IMO. One issue affects the layout of primitives in the dictionary, but only the primitives since they're setup in C. Most of my primitives, currently, are non-Forth words, but a few are Forth words, so this doesn't generally create any problem. Another issue restricts what values can be placed in the CFA, i.e., must call a C function and can't arbitrarily just jump into any Forth word. Those are the only two serious issues that I recall. Rod Pemberton