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

Groups > comp.lang.forth > #21415

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

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

Why not?

>> 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 we?  It's hard to tell.  In one place you say 'Nobody is ticking
S", so changing COMPILE, will not cause problems', and elsewhere you

1) Say that you need to be able to define defining words for words
with special compilation semantics, i.e., we would get many more words
with special compilation semantics.

2) You eliminate the COMPILE, from DEFERS to avoid the problems.

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

It exists, and has existed even before "COMPILE," (in Forth-83 the
same relationship existed between EXECUTE and ","), it's specified in
the standard, and it's used by existing programs such as DEFERS before
you "fixed" it and mini-OOF.  And there's an example of it's use in
the Gforth manual, too:
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Advanced-macros-Tutorial.html>:

>I don't change what COMPILE, does - compiling the word 
>that is represented by the xt - I just change how it does it.

: my-s" [ ' S" compile, ] ;
my-s" abcd" type

Gforth 0.7.0 does:
: my-s" [ ' S" compile, ] ;  ok
my-s" abcd" type abcd ok

Does the changed "COMPILE," do the same?

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

Would having a prelude and a postlude work?

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

Yes.

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

Correctly as specified in the standard.  That's not in conflict with
Mitch Bradleys text interpreter working (as demonstrated by many
systems).

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

The relationship between "COMPILE," and EXECUTE was preserved even for
these words on most systems.

But yes, doing things with ' S" would produce unintended results in
some cases on many systems.  So, if it was only ' S", we could just
leave this as a hole (or maybe close it by not allowing to tick S").
But if the usage of combined words becomes wider, as you intend, then
saying that you cannot tick these words, or that you cannot pass the
xt produced by ' to COMPILE, is no longer an option; we would have two language features that don't work together.  That's bad language design.

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

Fine.

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

That's an implementation choice.  They also once made an
implementation choice to use a source inliner.

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

Given that they use the OC: stuff of words like FDUP FSWAP etc. that
have default compilation semantics, (assuming that they call that code
on COMPILE, and that code is written correctly), the relationship
between EXECUTE and COMPILE, is preserved in this code.  So this code
is completely compatible with a correct COMPILE,.

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

Why did it not work for >R and R>?

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