Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #21314

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Not completely.  Bernd's position is not that you have one token that
>> allows you to find the various things, but that you have the xt, and
>> EXECUTEing it gives you the interpretation semantics and COMPILE,ing
>> it gives you the compilation semantics.  That's contrary to the
>> specification in Forth-94 and Forth-200x, and it breaks existing
>> programs (*), 
>
>No, it breaks constructed examples that tick things like S", IS, or TO, 
>which are non-standard anyways.  Note that the rational of FIND explains why 
>you can't tick a word without interpretation semantics, which exclused core-
>S" from being ticked (and any other compile-only word - you already asked 
>the TC for that).  The tickability of File-S" to be ticked is very likely an 
>oversight, when IS and TO have been clearly identified as non-tickable and 
>non-postponeable.

Do you suggest that ticking combined words should produce an error?
What about FINDing a combined word?  Wherever the xt comes from that
we pass to EXECUTE or COMPILE, the equivalence must hold.

>And you really, really should reread the mail from Mitch Bradley: COMPILE, 
>was added late, didn't go through much review, and was for a single porpose: 
>To have this
>
>FIND .. 0> IF EXECUTE ELSE COMPILE, THEN
>
>user-written compiler, you can only make COMPILE, perform the compilation 
>semantics of non-immediate words on a monotoken system.  There is no other 
>way to meet the intention of the ANS Forth TC,  though it contradicts their 
>written spec.

Gforth 0.7.0 meets the intention of the ANS Forth TC nicely, and it
does not contradict their written spec.  The user-written text
interpreter works, and it satisfies the written spec.

>Which then must be buggy.  The spec is the implementation of 
>the intention, and *it can have bugs*.

Since the spec and the intention are compatible, there is no bug.

>The idea behind COMPILE, is to have something that replaces the , of a 
>traditional ITC system, and the thinking didn't go much beyond that.

Yes, so we used to use "," to compile the semantics performed by
EXECUTE, i.e., we had an equivalence of "," being equivalent to

[compile] literal compile execute

And now we have COMPILE, which is equivalent to

postpone literal postpone execute

And that's good.

>So in contrast to your allegation, I just asked the TC member which did that 
>thing, what he wanted to do, he responded with the code above, and therefore 
>my statement that the spec is wrong is based on facts.  You want to 
>introduce a new word for performing the compilation semantics of non-
>immediate words, which will break real standard code, all code that has this 
>Mitch-Bradly-interpreter in it.

No, defining FIND appropriately (like Gforth has been doing for years)
is sufficient.

>So IMHO there are two possible solutions:
>
>a) a monotoken system is not possible within the Forth200x standard, or
>
>b) we just fix the bug in COMPILE,.

b) is out, so, if you are right, that leaves us with a).  Fine with
me.

>> so Bernd claims that the specifications and the programs are
>> buggy.
>
>The problem you don't want to acknowledge is that you can't have both: The 
>intention of Mitch Bradley to have COMPILE, as heart of a user-written 
>compiler, *and* it not doing the compilation semantics, as you propose.  

Gforth has demonstrated for many years that you can have both.

>Either you break Mitch Bradley's code (which has been found in the wild, and 
>was the primary reason to introduce COMPILE, at all), or you have to depart 
>from the monotoken approach and have two different tokens returned by FIND, 
>depending on state (that's what Gforth did before), or, third option: you go 
>STATE-smart.

The middle one is the least problematic one.

>Yes, because you should not do that.  Actually, you should not even tick a 
>"combined word", and when you get the xt from FIND, it depends on the 
>immediate flag whether you are entitled to EXECUTE or COMPILE, it to access 
>standard semantics.

That's an interesting restriction you propose here.  But I expect that
if ticking some words does not work, some people will use FIND
instead, and will not heed your restriction (I vividly remember a
posting by Michael Gassanenko who encountered and worked around the
Gforth restriction that ' IF or somesuch gives an error).  How do you
suggest enforcing your restriction.  Or do we just wait until the bugs
show up, like for STATE-smartness.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 03:46 +0100
  Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 09:42 +0000
    Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 17:04 +0100
      Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-19 17:54 +0000
        Re: Difficulty with Brad Rodriguez' screenful Brad Eckert <hwfwguy@gmail.com> - 2013-03-19 13:30 -0700
        Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 22:33 +0100
  Re: Difficulty with Brad Rodriguez' screenful albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-19 13:03 +0000
    Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-19 14:56 +0000
      Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 21:55 +0100
        Re: Difficulty with Brad Rodriguez' screenful Alex McDonald <blog@rivadpm.com> - 2013-03-19 14:16 -0700
          Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 02:09 +0100
        Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 16:44 +0000
          Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 22:07 +0200
            Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 14:45 +0000
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 20:16 +0200
    Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 20:35 +0100

csiph-web