Path: csiph.com!aioe.org!.POSTED!not-for-mail From: "HAA" Newsgroups: comp.lang.forth Subject: Re: EXIT THEN Date: Fri, 24 Mar 2017 11:49:46 +1100 Organization: Aioe.org NNTP Server Lines: 54 Message-ID: References: <9a0a1112-55ff-45ee-9ac6-01313e562614@googlegroups.com><20170321083339.2646a6bf@t530.lan> <6b6e981c-9ec0-415f-a1d0-d38abe8436ce@googlegroups.com> NNTP-Posting-Host: uImxOM2IVFS6ri12mc+gUw.user.gioia.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 5.00.2615.200 Xref: csiph.com comp.lang.forth:56208 Alex wrote: > On 3/22/2017 22:52, HAA wrote: > > Alex wrote: > >> On 3/22/2017 13:48, HAA wrote: > >>> ... > > > >>>> > >>>> I leave the various implementations to your imagination (or lack of). As > >>>> does the standard. > >>> > >>> Don't leave it to me. You're the one with the imagination. You turn it into > >>> reality :) > >> > >> I am. I've been working for some time on an SSA based optimizer. It's > >> not a trivial exercise, but it is achievable (and as an intellectual > >> exercise, it is an immensely interesting challenge). > > > > So you're going to 'solve' the problem of the bad specification that is ANS > > CASE with a great big fancy optimizer. This is deserving of a Darwin Award. > > > > No, of course that's not my goal. > > CASE is just one example of where high level constructs (and it's pretty > true of any language) and in Forth, low level constructs too, don't map > effectively onto the computer architectures we have. Forth is a two > stack zero address operand language, but most processors are multiple > operand register based and many don't have built in stacks, far less two. > > Constructs like (qv OF) OVER = IF DROP are inefficient on a register > based machine when naively compiled, so code rewriting (which is what > optimizing compilers do) is something that can pay enormous dividends. Dividends come in various forms e.g. technical and political. ANS CASE wasn't defined for technical excellence, it was defined to secure a political outcome - namely accommodating as many existing CASE implementations as possible. > ... > There's nothing wrong with the specification of CASE/ENDCASE. It's just > tough (but not impossible) to generate decent code with the simple code > generation tools we currently have. Implement ANS CASE by whatever means you wish but understand the specification was based on political considerations. I reject any CASE specification that mandates ENDOF. And I might add, so does Forth.