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

Groups > comp.lang.forth > #21380

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Anton Ertl wrote:

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

Yes.  But the "ticking combined word is non-standard" is relevant in so far 
that your use of COMPILE, is non-standard, while the other use of COMPILE, 
(the Mitch-Bradley-Compiler one) is standard, at least by stated intention 
of the TC member which added COMPILE, to the standard.

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

No, the relationship between EXECUTE and COMPILE, is that of Mitch Bradley's 
compiler - that's the intention of COMPILE,.  Therefore, we can't add a new 
mechanism for that, because there already is one, and adding a new one will 
break existing code, which uses the existing relationship.  Remember: For 
immediate words (flag comes from FIND and is unavailable from tick, which is 
ugly), you EXECUTE the word to obtain the compilation semantics, and for 
non-immediate words, you COMPILE, it.  If COMPILE, does something else than 
the compilation semantics for non-immediate words, it breaks code.

The point here is: This step breaks some code.  Your suggestion is to break 
standard code and keep non-standard code intact.  My position is to break 
the non-standard code, and keep the standard code intact.  The semantics to 
postpone the interpretation semantics is useful, and one unquestioned 
standard way to achieve that was ['] <word> execute.

We have COMPILE, for 20 years.  You use it for something it wasn't made for, 
and then suggest to break the code which use it for what it was made for.

> 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, the user-written interpreter works everywhere, except in the fictional 
system you suggest.  The one system that does not implement COMPILE, as 
specified is VFX, and it does not break the user-written interpreter, but 
the thing you want from COMPILE, the compiling the interpretation semantics 
of combined words.

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

I want to get rid of the obsolete ugly dinosaurs, and you propose that they 
have to stay...

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

I've asked Mitch Bradley, and he responded with that user-written compiler 
as the spirit and intention for COMPILE,.  He also explained that COMPILE, 
was a late addition, and did not get the same attention and scrutinity as 
other things.

Therefore, you have been proven wrong in your statements already last year.  
But you aren't willing to accept defeat.  The standard is not god-send, it 
is made by people, people who you can ask, and who respond to questions.  
And that's what I did.  And I got my answer.  You got it, too.  But you 
continue to ignore it.

> In any case, the relation between EXECUTE and "COMPILE," has been used
> in real programs,

AFAIK, the programs that do use this relation in the sense that breaks with 
the new system aren't real world, but constructed by you.  Pointer please, 
including results from running on git Gforth vs. Gforth 0.7.x.

> it's a really bad idea to change "COMPILE," just
> because the FIND that goes with the current "COMPILE," offends your
> sense of aesthetics.

It just moves the problem, without solving it.  Instead of having ugly 
state-smart words, we now have an ugly FIND, and an approach, which makes it 
next to impossible to find a standard replacement for it.

>>But the solution for CREATE DOES> was too clumsy to use
> 
> Please elaborate on that.

There's this intcomp.fs, which was never used by anybody except for the 
examples.

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

It didn't.  Gforth's documentation of COMPILE, written by user anton:

\G  Compile the word represented by the execution token @i{xt}
\G  into the current definition.

Nobody really cared about the precise words in the standard, because 
everybody, including you yourself, knew that COMPILE, was for compiling.  
Now you make up some counter-factual stories that COMPILE, is intented for 
something else, ignoring the inventor of COMPILE,.

Let's go back to the standard:  COMPILE, starts with this strange 
"Interpretation: Interpretation semantics for this word are undefined."  
There's no reason why it should be undefined.  And then it continues "Append 
the execution semantics of the definition represented by xt to the execution 
semantics of the current definition."

My conclusing of reading the standard is that "execution semantics" is a 
wildcard thing, and not really properly defined; as it does not always mean 
"EXECUTE the xt".  One outstanding example:  EXIT is "executed" (3.2.3.3.).  
As a typical EXIT e.g. in Gforth is immediate, executing EXIT would just 
compile ;S; in VFX executing EXIT just tells you that you executed a 
compile-only word, which throws an error.  The standard clearly tells you 
that EXIT has no interpretation semantics, so EXECUTE-ing it is certainly 
non-standard.  So the standard means something else here.

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

We do.  We did break some of my existing programs when we took out the 
state-smart LITERAL, which started the whole discussion about state-
smartness.  Sometimes, breaking bad programs which rely on idiosyncracies 
isn't wrong.  This LITERAL was designed for words that either push a literal 
in interpreter mode, or compile it in compilation mode, like ASCII.

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

That's the thinking that the xts have to be different for different 
semantics.  There's no such thing in the standard.  ' foo EXECUTE gives you 
the interpretation semantics of foo.

> If it's from a :NONAME definition, it's the
> execution semantics.

I've some problems with :NONAME definitions that are used as state-smart 
early bound methods in BerndOOF (early bound methods are just aliases).  
Replaing the state-smartness there is a piece of cake with the new system: 
Add a comp: part to the :noname, and remove the immedate bit from the alias 
declaration.

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

I'm not surprised at how it works.  It works as it is specified in Gforth.  
Back then, when you wrote the glossary entry, and now.  The standard with 
its not very well written definition of COMPILE, is only a guidance.

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