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

Groups > comp.lang.forth > #21322

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Anton Ertl wrote:
> Do you suggest that ticking combined words should produce an error?

No, that would be silly.  Only with the --pedantic switch.  Ticking a 
combined word gives you something with is beyond the standard.  That's it.  
It's not an error to do something that is beyond the scope of the standard.  
Especially not in a GNU system.  The thing you should do as implementer of a 
GNU system is to fill this hole with something that makes the system better 
than any random standard system.

Ticking a combined word should give you a token that can be used to extract 
both the interpretation semantics (with EXECUTE) and the compilation 
semantics (with COMPILE,), because that's useful.

> What about FINDing a combined word?  Wherever the xt comes from that
> we pass to EXECUTE or COMPILE, the equivalence must hold.

FINDing a combined word is not beyond the standard, but the thing you can do 
with the xt is limited:  STATE has to be false to find the interpretation 
semantics, then you are entitled to EXECUTE it.  STATE has to be true to 
find the compilation semantics, and depending on the resulting immediacy 
flag, you can either EXECUTE it (if it was immediate), or COMPILE, it (if it 
wasn't) to get the compilatin semantics.

> 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.

But then it returns different things for FIND, and if you don't follow all 
these implicit rules which are *not* written into the standard, you fall 
flat on your face.

>>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 spec and the intention is only compatible for one particular 
implementation which didn't exist at the time of the writing of the 
standard.  And it does so by implementing this weird behavior that FIND is 
state-smart, and returns different things depending on state.

>>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.

That doesn't make any sense.  , is the code generator, and so is COMPILE,.  
The interpretation semantics is only an accidential coincidence, following 
the most popular implementation strategy in 1994.

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

A state-smart FIND which returns different Xts is clearly not 
"appropriately" in my book.

>>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.

For me, a) is out, because monotoken systems have too many advantages.  The 
ANS TC deliberately proposes to play with different approaches to solve the 
state-smart problem, and yours is just too ugly.  The better approaches 
contradict the standard in letter, but certainly not in spirit and 
intention.

>>> 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.

But the solution for CREATE DOES> was too clumsy to use, which was the 
reason why e.g. BerndOOF continued to use state-smart words.

>>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.

The middle one does not really work.  We have fixed a few special-
compilation semantics words, but haven't fixed the larger code base that 
uses state-smart in CREATE DOES> words.  Now with the monotoken approach, 
that is much easier.

>>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.

Come on, Anton, you have lectured Andrew Haley what a GNU project is going 
to do in that case: Something reasonable, not something silly.  Enforcing 
the restriction is silly, because you still can use the xt for good.  The 
IMHO reasonable thing for ticking special compilation semantics words is to 
return an xt which does perform the interpretation semantics with EXECUTE 
and the compilation semantics with COMPILE,.  VFX example (doesn't all work 
with Gforth yet):

: test [ ' if compile, ' s" compile, True" ] type else ." False" then ;  ok
true test True ok

This looks reasonable.  In current git Gforth, you still can't tick IF, but 
you can do

: test if [ ' s" compile, True" ] type else ." False" then ;

> Or do we just wait until the bugs show up, like for STATE-smartness.

I'm certainly waiting for you to try the monotoken Gforth and find the bugs.  
In any case, this is a GNU project, and we take what standards tell us as 
suggestion, not as order to obey.  There may be some conflicts when a team 
member is the chair of the current standard effort ;-).

My mind still boggles why you expect a word called "COMPILE," to give you 
*interpretation* semantics.  It would be called INTERP, if it was intented 
to do so.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

Thread

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