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

Groups > comp.lang.forth > #21385

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Anton Ertl wrote:
> I would not be so sure about what the users expect.  They may surprise
> us.  And you think so, too, because whenever I call your "this does
> not happen" bluff by suggesting that we enforce the restriction, you
> fold.

Your suggestion is to forbit ticking words with special compilation 
semantics.  That's nonsense.  Let's say we enforce the restriction by having 
IS complain when you assign a word with non-standard compilation semantics 
to it.  For colon words, that's possible.  For non-colon words, that's not 
possible.

> But that's just one place that need to be "fixed" if "COMPILE," is
> changed as you propose.  There are many programs where "COMPILE," is
> used, and they would all have to be checked, and many would have to be
> "fixed".  And to add insult to injury, the result would be bigger and
> slower.

We are still talking about the case that people have words with special 
compilation semantics (of which there are only a few in the system, usually 
parsing words like S", TO, IS, or something like DOES>, and maybe they 
defined some themselves) and use them inside this part of their programs?

>>Are you grumpy, because I removed your solution to state-smart words from
>>the system?  I didn't like it from the beginning, and I was quite grumpy
>>when you introduced it, if you remember it.
> 
> Yes, you removed my solution after about two months and replaced it
> with your solution.  Why should I be grumpy about that now, 17 years
> later?

I'm not talking about the code, I'm talking about having multiple xts for 
one word.  That's what you had introduced, and that didn't go away until 
recently.

> While some posters here are notorious for insinuating that others have
> secret agenda for their opinions, don't think that leads to productive
> discussions, so let's not adopt that style.
> 
> I have already stated what's behind my position: I consider the
> relative between EXECUTE and "COMPILE," to be an important feature
> that has to be preserved.  Changing implementation approaches is fine,
> changing what "COMPILE," does is not.

And my position is that this relation does not really exist (which is why it 
is not meantioned in Gforth's glossary you wrote), never did, and therefore 
not worth to keep.  I don't change what COMPILE, does - compiling the word 
that is represented by the xt - I just change how it does it.

>>It didn't solve my problems,
>>which is mostly stuff in the BerndOOF code - state-smart CREATE DOES>
>>words.
> 
> Please explain the problem in more detail (and in a way that even I
> can follow).  Isn't this about overloading resolution?  Wouldn't
> preludes work better?

It's in general about parsing words, which in an OOP system change the scope 
and the objects used.  A prelude system can change the scope, but changing 
the objects used is difficult, because that requires cleanup (pop the 
current object from the return stack) after the next word went through the 
compiler.  That's why BerndOOF has parsing words plus a user-written 
compiler.

A recognizer with a dot-parser would be doable, but then requires a syntax 
change.  IMHO, recognizers are saner approaches at parsing words.  Or, let's 
face it, the current approaches really didn't solve the parsing word 
problems, they just pushed them back and forward, and then now sidewards, 
but they are still there.

>>It did solve the problem of a few words, like TO, S" and IS.
> 
> The longer this discussion goes, the more I think that we should do
> with as few combined words as possible, and phase the few out as soon
> as possible.  But if they are here to stay, and gain wider usage, it's
> all the more important that they work correctly with "COMPILE,".

Whatever "correctly" is.  Should they work correctly with the Mitch-Bradley 
text interpreter, or with the standard words for COMPILE,?  I'd prefer them 
to work correctly with the Mitch-Bradley text interpreter, because that text 
interpreter is real and widely used, and the original motivation of 
COMPILE,.  These words never worked "correctly" wrt. tick them and compile, 
them on many systems, so that's not something we should worry too much 
about.  They all worked correctly with Mitch's text interpreter, because 
that's how system implementers implement their text interpreter.

We can remove S", TO and IS with recognizers, and in fact that already has 
been done in git Gforth, though there still are possibilities to confuse the 
system.  Like

: "the cr ." I'm there to confuse the system" ;

"the quick brown fox jumps over the lazy dog" type
I'm there to confuse the system
:3: Undefined word
"the >>>quick<<< brown fox jumps over the lazy dog" type

>>I'm
>>implementing this, because my need isn't satisfied by your solution -
>>neither was MPE's need, which is why they implemented that smart COMPILE,
>>15 years ago.
> 
> What is MPE's need that makes their COMPILE, necessary?

A lot of primitives attach their respective code generator with comp: into 
the smart compile,.  And by adding that feature, they found out that they 
could use it for all other compiler macros, as well, which is why IF in VFX 
is non-immediate.

> My impression is that it is an implementation choice, like the source
> inliner used to be, and that their code would work fine with a correct
> COMPILE, (with some other adjustments in the text interpreter).  Also,
> my impression is that their current header structure and their
> COMPILE, are significantly younger than VFX and were introduced with
> the newer inliner.

Stephen said they introduced that in 1998.  I don't have any VFX that old 
flying around, but the changelog in Ndp387.fth indicate that most of it was 
written in 2000, so that's very likely true.  The changes afterwards are 
only minor maintenance stuff, and not some complete overhaul for a smart 
compile, - which would have shown up in the changelog, as that is a very 
substantial change.

>>As a result, it might break some of your code, but not having it
>>makes MPE's code impossible.  Go try and test it, and report the problems
>>so that we can find solutions.
> 
> What "MPE's code"?

Look at e.g. their Ndp387.fth floating point package; that's delivered as 
source code.  They use oc: <name> instead of comp: after the definition 
itself, allowing them to separate compiler and interpreter definitions.  oc: 
is an internal, undocumented word, which is why Gforth only is compatible 
with VFX when you use comp:.

>>So if we fall back to your solution, we have not only to take out the
>>smart COMPILE,, but also the recognizers, or at least the interpreter >R
>>R>, which is also very useful, because you can interactively try code that
>>is using the return stack, as long as it fits into one line.
> 
> Ok, the interpreted >R R> is an interesting point.  But since
> "COMPILE," does not come into play when interpreting >R R>, why do you
> think that changing "COMPILE," is required to support this feature.

Well, before having a monotoken system with smart COMPILE, the recognizers 
returned a nt and a table that contained three methods for interpreting, 
compiling and postponing the nt.  That worked for everything but for >R and 
R>.  The trick to make those work was to move the return stack entry to the 
local stack in the interpreting method, but that caused problems with 
interactive words that do return stack trickery like [DO] [LOOP].

So what I needed was a token that can execute directly, but still gives me 
every information for compiling and postponing it.  Result: monotoken system 
(going a bit further than VFX, as the immediate flag is directly available).  
Consequence of monotoken system together with Mitch Bradley's text 
interpreter: Different COMPILE, semantics (but not different from what has 
been documented in Gforth, just different from the standard - actually, I 
would say that it now fits the description).

-- 
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 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 12:03 +0000
  Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 18:47 +0100
    Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 16:40 +0000
      Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-01 02:12 +0200
        Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-01 16:58 +0000
          Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 04:20 +0200
            Re: Difficulty with Brad Rodriguez' screenful "Elizabeth D. Rather" <erather@forth.com> - 2013-04-01 16:39 -1000
            Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 14:15 +0000
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 21:12 +0200
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 13:58 +0000
          Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 04:17 -0500
            Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 15:35 +0000
              Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 16:36 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 04:10 +0200
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 04:03 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 21:14 +0200
        Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-03 16:13 +0000
          Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 11:54 -0500
          Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 22:24 +0200
            Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-04-04 11:53 +0000
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 18:13 +0200
            Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 15:53 +0000
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 22:11 +0200
                Re: Difficulty with Brad Rodriguez' screenful Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-04-04 21:35 +0100
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 23:06 +0200
                Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-04-05 10:57 +0000
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:47 +0000
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:28 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-06 03:35 +0200
                Re: Difficulty with Brad Rodriguez' screenful "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:50 -0400
                Re: Difficulty with Brad Rodriguez' screenful "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:49 -0400
                Re: Difficulty with Brad Rodriguez' screenful m.a.m.hendrix@tue.nl - 2013-04-05 02:49 -0700
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:55 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-05 22:05 +0200

csiph-web