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

Groups > comp.lang.forth > #21374

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>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.

Ok, so the "ticking combined words is non-standard" argument is
irrelevant.  So we want to support ticking combined words and passing
the resulting xt to EXECUTE and COMPILE,.

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

If you want to extract the interpretation semantics and compilation
semantics from an xt, no problem, but don't break the relationship
between EXECUTE and "COMPILE,", because that's not only useful, but
has been used.  If you want to extract the compilation semantics from
an xt created by ticking, you have to add a new mechanism for that.

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

All systems but one implement COMPILE, as specified.  And AFAIK the
user-written interpreter works on all of them AFAIK.  So they are not
just compatible with one particular implementation.

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

It's not pretty, but it works.  And FIND sure is not the only obsolete
dinosaur in a Forth system that's not pretty.

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

Well, at least you admit that it contradicts the standard in letter.
I say that it also contradicts it in spirit and intention.

In any case, the relation between EXECUTE and "COMPILE," has been used
in real programs, it's a really bad idea to change "COMPILE," just
because the FIND that goes with the current "COMPILE," offends your
sense of aesthetics.

>But the solution for CREATE DOES> was too clumsy to use

Please elaborate on that.

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

It might be reasonable if "COMPILE," did not already have a different
meaning.

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

We don't break existing programs.

>My mind still boggles why you expect a word called "COMPILE," to give you 
>*interpretation* semantics.

I expect it to compile the semantics represented by the xt (and that's
what the standard says).  If the xt comes from ', that's the
interpretation semantics.  If it's from a :NONAME definition, it's the
execution semantics.

You have known COMPILE, for 19 years, and you used it outside the
user-written text interpreter, e.g., in mini-OOF.  Don't pretend to be
surprised at how it works.


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

csiph-web