Groups > comp.lang.forth > #38642 > unrolled thread

SET-COMPILER

Started by	JennyB <jennybrien@googlemail.com>
First post	2015-04-27 01:34 -0700
Last post	2015-05-03 20:38 +0200
Articles	20 on this page of 124 — 11 participants

Back to article view | Back to comp.lang.forth

  SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 01:34 -0700
    Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-27 14:52 +0000
      Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 21:17 +0200
      Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-28 09:41 -0700
    Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 16:53 +0100
      Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:02 +0100
        Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:23 -0700
      Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 10:02 -0700
        Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 17:15 +0000
          Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 23:38 +0200
    Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 14:52 +0000
      Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 17:09 +0100
        Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 16:54 +0000
          Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-28 09:11 +0000
            Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-28 04:28 -0700
              Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-29 13:49 -0700
                Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-30 00:13 +0200
                Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 06:32 +0000
                  Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-30 05:22 -0700
                    Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 15:27 +0000
                      Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 19:16 +0100
                        Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-04-30 21:08 +0000
                          Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-04-30 23:05 +0100
                            Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 15:47 -0700
                              Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-01 12:29 +0100
                          Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:25 +0000
                      Re: SET-COMPILER hughaguilar96@gmail.com - 2015-04-30 17:07 -0700
                      Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 02:40 -0700
                        Re: SET-COMPILER stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 10:24 +0000
                        Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:55 +0200
                          Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-02 01:32 -0700
                            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:27 +0000
                              Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 08:36 -0700
                                Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:44 +0000
                        Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:37 +0000
                    Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 01:33 +0200
                      Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 03:15 -0700
                        Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 12:47 +0000
                          Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-01 10:29 -0700
                            Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-01 20:32 +0000
                            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:51 +0000
                      Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:29 +0000
                    Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 14:59 +0000
                Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:11 +0000
            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 12:04 +0000
      Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-28 03:22 +0200
        Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:09 +0000
          Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:30 +0000
            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:58 +0000
          Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-02 20:42 +0200
            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:28 +0000
            Re: SET-COMPILER Mark Wills <markwills1970@gmail.com> - 2015-05-06 04:14 -0700
      Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-04-27 23:57 -0700
        Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 11:41 +0000
          Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:51 +0000
            Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 17:00 +0000
              Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 11:19 +0100
                Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-03 07:30 -0700
                  Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:45 +0200
                    Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-03 21:48 +0200
                  Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 22:03 +0100
                    Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-05 22:56 +0000
                      PREFIX JennyB <jennybrien@googlemail.com> - 2015-05-06 02:30 -0700
                        Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:23 +0000
                          Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 16:44 +0100
                            Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 16:03 +0000
                              Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 17:40 +0100
                          Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:44 +0000
                            Re: PREFIX Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 22:05 +0200
                              Re: PREFIX Bernd Linsel <bl1@gmx.com> - 2015-05-07 04:23 +0200
                                Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:48 +0000
                                Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:04 +0000
                            Re: PREFIX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:55 +0000
                        Re: PREFIX "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 14:20 +0100
                        Re: PREFIX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-06 19:41 +0000
                    Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 12:29 +0000
                      Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-06 15:07 +0100
                    Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-09 03:02 -0700
                      Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-09 17:23 +0100
                    Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 08:07 +0100
                      Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-11 11:20 +0100
                        Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 10:05 -0700
                          Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 18:34 +0100
                            Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-12 12:07 -0700
                              Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-12 22:11 +0200
                                Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:35 +0100
                                  Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 01:31 +0200
                                    Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:20 +0000
                                      Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-13 12:20 -0700
                                        Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-13 22:24 +0100
                                        Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:26 +0000
                                          Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:00 -0700
                                        Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 08:06 -0700
                                          Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 17:21 +0100
                                            Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:31 -0700
                                              Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 19:41 +0100
                                                Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-14 11:49 -0700
                                            Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 09:41 +0000
                                              Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:19 +0100
                                                Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 14:42 +0000
                                            Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-15 10:37 -0700
                                              Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 23:00 +0100
                                                Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 13:52 +0000
                                                  Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-16 19:24 +0100
                                                    Re: Recognizer RfD was Re: SET-COMPILER Matthias Trute <matthias.trute@gmail.com> - 2015-05-16 13:26 -0700
                                                      Re: Recognizer RfD was Re: SET-COMPILER Coos Haak <chforth@hccnet.nl> - 2015-05-17 00:27 +0200
                                                    Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-17 10:03 +0000
                                                      Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-17 23:25 +0100
                                          Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 10:02 +0000
                                            Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-15 12:35 +0100
                                              Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 15:33 +0000
                                          Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 14:01 +0000
                                        Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:14 +0000
                                    Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 17:07 +0000
                                      Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:27 +0200
                                        Re: Recognizer RfD was Re: SET-COMPILER hughaguilar96@gmail.com - 2015-05-13 19:23 -0700
                                    Re: Recognizer RfD was Re: SET-COMPILER JennyB <jennybrien@googlemail.com> - 2015-05-14 01:08 -0700
                                Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 14:30 +0000
                                  Re: Recognizer RfD was Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 03:40 +0200
                                    Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 13:26 +0000
                              Re: Recognizer RfD was Re: SET-COMPILER "Alex McDonald" <blog@rivadpm.com> - 2015-05-12 21:33 +0100
                              Re: Recognizer RfD was Re: SET-COMPILER albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:36 +0000
                                Re: Recognizer RfD was Re: SET-COMPILER anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-13 16:06 +0000
                Re: SET-COMPILER Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-03 20:38 +0200

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →

#38727

From	"Alex McDonald" <blog@rivadpm.com>
Date	2015-04-30 19:16 +0100
Message-ID	<mhtrfp$l2c$1@dont-email.me>
In reply to	#38726

on 30/04/2015 16:27:33,  wrote:
> On Thu, 30 Apr 2015 05:22:46 -0700 (PDT), JennyB
> <jennybrien@googlemail.com> wrote:
> 
>>COMPILER, performs the compiling action set by SET-COMPILER or IMMEDIATE
> 
> Assuming that you mean COMPILE, there's a wrinkle here which is one
> cause of confusion between the standard and my understanding of how
> traditional Forth works in the text interpreter. The text interpreter
> usually includes code of the form:
> 
> find ?dup if
> 0< state @ and
> if  compile,  else  execute  then
> else
> ...
> then
> 
> This form makes COMPILE, independent of IMMEDIATE. If COMPILE, is
> independent of IMMEDIATE, then COMPILE, can be used to compile
> anything with defined compilation behaviour, including IMMEDIATE
> words themselves. If COMPILE, has to execute IMMEDIATE words, then
> you can't POSTPONE them without introducing a piece of magic.
> I'm opposed to magic. I'm also opposed to anything that conceptually
> breaks the traditional Forth interpreter loop.
> 
> Conceptually, Forth should remain a simple language.

Conceptually, COMPILE, is just , with added doobries to support non-ITC
Forths. In other words, a text interpreter that detects STATE & IMMEDIATE
and consequently does EXECUTE is the only reason we have different
behaviour while compiling. Or am I missing something here?

> 
> Stephen
> 
>

[toc] | [prev] | [next] | [standalone]

#38733

From	stephen@mpeforth.com (Stephen Pelc)
Date	2015-04-30 21:08 +0000
Message-ID	<5542992c.805492379@news.eternal-september.org>
In reply to	#38727

On Thu, 30 Apr 2015 19:16:25 +0100, "Alex McDonald" <blog@rivadpm.com>
wrote:

>Conceptually, COMPILE, is just , with added doobries to support non-ITC
>Forths. In other words, a text interpreter that detects STATE & IMMEDIATE
>and consequently does EXECUTE is the only reason we have different
>behaviour while compiling. Or am I missing something here?

Yes.
1) Native code optimised Forths.
2) The ANS definition of separate compilation and interpretation
behaviours.

Stephen

P.S. EuroForth 2015 is in Bath ... or are you staying north of the
border.


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#38734

From	"Alex McDonald" <blog@rivadpm.com>
Date	2015-04-30 23:05 +0100
Message-ID	<mhu8th$k4d$1@dont-email.me>
In reply to	#38733

on 30/04/2015 22:08:06, Stephen wrote:
> EuroForth 2015

Interesting. I may very well attend, since my partner would like to see
Bath.

[toc] | [prev] | [next] | [standalone]

#38735

From	hughaguilar96@gmail.com
Date	2015-04-30 15:47 -0700
Message-ID	<9937dac0-dd3b-4e7a-adc4-46cb98c643d3@googlegroups.com>
In reply to	#38734

On Thursday, April 30, 2015 at 3:05:36 PM UTC-7, Alex McDonald wrote:
> on 30/04/2015 22:08:06, Stephen wrote:
> > EuroForth 2015
> 
> Interesting. I may very well attend, since my partner would like to see
> Bath.

Would that be John Passaniti?

[toc] | [prev] | [next] | [standalone]

#38744

From	"Alex McDonald" <blog@rivadpm.com>
Date	2015-05-01 12:29 +0100
Message-ID	<mhvo03$62g$1@dont-email.me>
In reply to	#38735

on 30/04/2015 23:47:54,  wrote:
> On Thursday, April 30, 2015 at 3:05:36 PM UTC-7, Alex McDonald wrote:
>> on 30/04/2015 22:08:06, Stephen wrote:
>> > EuroForth 2015
>>
>> Interesting. I may very well attend, since my partner would like to see
>> Bath.
> 
> Would that be John Passaniti?
> 

No, Bath. It's a town in England.

[toc] | [prev] | [next] | [standalone]

#38775

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-05-02 15:25 +0000
Message-ID	<2015May2.172522@mips.complang.tuwien.ac.at>
In reply to	#38733

stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 30 Apr 2015 19:16:25 +0100, "Alex McDonald" <blog@rivadpm.com>
>wrote:
>
>>Conceptually, COMPILE, is just , with added doobries to support non-ITC
>>Forths. In other words, a text interpreter that detects STATE & IMMEDIATE
>>and consequently does EXECUTE is the only reason we have different
>>behaviour while compiling. Or am I missing something here?
>
>Yes.
>1) Native code optimised Forths.

They are exactly the reason why we now use COMPILE, instead of ",".
And SET-COMPILER is fine for that purpose.

>2) The ANS definition of separate compilation and interpretation
>behaviours.

To do that properly, you need something other than SET-COMPILER.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38738

From	hughaguilar96@gmail.com
Date	2015-04-30 17:07 -0700
Message-ID	<e678985c-f3c7-452c-a1ff-ddac3a3f7488@googlegroups.com>
In reply to	#38726

On Thursday, April 30, 2015 at 8:27:22 AM UTC-7, Stephen Pelc wrote:
> On Thu, 30 Apr 2015 05:22:46 -0700 (PDT), JennyB
> <jennybrien@googlemail.com> wrote:
> 
> >COMPILER, performs the compiling action set by SET-COMPILER or IMMEDIATE
> 
> Assuming that you mean COMPILE, there's a wrinkle here which is one
> cause of confusion between the standard and my understanding of how
> traditional Forth works in the text interpreter. The text interpreter
> usually includes code of the form:
> 
>     find ?dup if
>       0< state @ and
>       if  compile,  else  execute  then
>     else
>       ...
>     then
> 
> This form makes COMPILE, independent of IMMEDIATE. If COMPILE, is
> independent of IMMEDIATE, then COMPILE, can be used to compile
> anything with defined compilation behaviour, including IMMEDIATE
> words themselves. If COMPILE, has to execute IMMEDIATE words, then
> you can't POSTPONE them without introducing a piece of magic.
> I'm opposed to magic. I'm also opposed to anything that conceptually
> breaks the traditional Forth interpreter loop.

This is why my trick for disambiguifying ANS-Forth works. All of those words like IF that you have as non-immediate become immediate --- presto chango!. I don't even have to know ahead of time if they were originally non-immediate or immediate (I can't know in gForth because FIND aborts rather than return the xt and the flag that indicates non-immediate or immediate or not-found) --- my trick works for both non-immediate and immediate, without me knowing which I've got.

: if  state @ 0= abort" *** no interpretation semantics for: IF ***"
     postpone if ; immediate

All of these words should have just been defined in the ANS-Forth standard as being immediate --- how simple would that have been?

What actually happened is that their definition said: "interpretation semantics for this word are undefined." And, we have section (4.1.2) with the ominous heading: "Ambiguous Conditions." One of the many ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." So, pretty much anything is legal when ' or FIND is used on them --- VFX's FIND returns an xt and says it is non-immediate which would seem to make a good candidate for EXECUTE but then EXECUTE aborts --- gForth's FIND itself aborts rather than return anything. In both cases, the programmer has to just know a-priori that these words are "ambiguous" and have to be special-cased.

This is beyond stupid --- this looks like sabotage to me, for the purpose of preventing common programmers from writing their own outer-interpreter, for the purpose of preventing common programmers from writing a cross-compiler --- there is really no hint of a positive benefit to this bizarre imposition of ambiguity on all of these words.

Anyway, I disambiguified all of those gratuitously ambiguous words, and I will include this in my next novice-package upgrade.

> Conceptually, Forth should remain a simple language.

One of the things that attracted me to Forth originally, was that Forth doesn't have syntax. You just have two kinds of words: non-immediate and immediate. Now however, words like IF have become a part of the language in that they are special-cased by the system ( COMPILE, in VFX, or FIND in gForth) to behave differently from either non-immediate or immediate words --- that is syntax.

But you should know all of this already --- you are on the Forth-200x committee --- you are supposed to know basic Forth concepts.

I figured out to work-around this gratuitous ambiguity with my disambiguifiers, but it took me since 2009 until now to figure it out. I don't know if I would have figured it out in 1994 when I was writing MFX. Fortunately, I didn't have to, because I was using UR/Forth rather than any ANS-Forth system (ANS-Forth came out that year, but no ANS-Forth compiler existed until SwiftForth came out in 1997, and no usable ANS-Forth compiler existed until several years after that). I was getting paid to write MFX --- if I had been using ANS-Forth, and if I had not figured out how to disambuify ANS-Forth in a timely manner (like within a week or two), I would have been fired, and MFX (and the MiniForth) would have never come to fruition --- I think the purpose of all this weirdness in the ANS-Forth document is to baffle the programmers and cause them to fail at their programming jobs.

This baffling weirdness might be why Forth lost popularity when ANS-Forth became the standard, do you think?

[toc] | [prev] | [next] | [standalone]

#38741

From	JennyB <jennybrien@googlemail.com>
Date	2015-05-01 02:40 -0700
Message-ID	<d911a8b5-7cd2-4977-a3c9-a06681e89522@googlegroups.com>
In reply to	#38726

On Thursday, 30 April 2015 16:27:22 UTC+1, Stephen Pelc  wrote:
> On Thu, 30 Apr 2015 05:22:46 -0700 (PDT), JennyB
> <jennybrien@googlemail.com> wrote:
> 
> >COMPILER, performs the compiling action set by SET-COMPILER or IMMEDIATE
> 
> Assuming that you mean COMPILE, 

Yes.  Typo.

> there's a wrinkle here which is one
> cause of confusion between the standard and my understanding of how
> traditional Forth works in the text interpreter. The text interpreter
> usually includes code of the form:
> 
>     find ?dup if
>       0< state @ and
>       if  compile,  else  execute  then
>     else
>       ...
>     then
> 
> This form makes COMPILE, independent of IMMEDIATE. 

In that COMPILE, never encounters an IMMEDIATE word. The only sensible case 
I can think of is if COMPILE, is used in the definition of [COMPILE]. There 
it really does have to be a dumb interp-compile.

> is independent of IMMEDIATE, then COMPILE, can be used to compile
> anything with defined compilation behaviour, including IMMEDIATE
> words themselves. If COMPILE, has to execute IMMEDIATE words, then
> you can't POSTPONE them without introducing a piece of magic.
> I'm opposed to magic. I'm also opposed to anything that conceptually
> breaks the traditional Forth interpreter loop.
> 
> Conceptually, Forth should remain a simple language.

Then the specification of SET-COMPILER, if it were to be a Standard word, would be:

Set the compilation behaviour of the latest definition to perform xt.
It is a error to use both SET-COMPILER and IMMEDAITE on the same definition. 

If SET-COMPILER is present, the meaning of COMPILE, is extended to perform the compiling  behaviour set for the definition by SET-COMPILER.

Then all existing definitions will work unchanged with the new version of 
[COMPILE,] except that if you have [COMPILE] defined using COMPILE, you 
should change it to make sure it always compiles the xt, ignoring any 
compilation behaviour set.

[toc] | [prev] | [next] | [standalone]

#38743

From	stephen@mpeforth.com (Stephen Pelc)
Date	2015-05-01 10:24 +0000
Message-ID	<5543525e.852902472@news.eternal-september.org>
In reply to	#38741

On Fri, 1 May 2015 02:40:19 -0700 (PDT), JennyB
<jennybrien@googlemail.com> wrote:

>Then the specification of SET-COMPILER, if it were to be a Standard word, would be:
>
>Set the compilation behaviour of the latest definition to perform xt.
>It is a error to use both SET-COMPILER and IMMEDAITE on the same definition. 

Not necessarily. It is not the job of the standard to prevent silly
people being silly.

>If SET-COMPILER is present, the meaning of COMPILE, is extended to perform
>the compiling  behaviour set for the definition by SET-COMPILER.
>
>Then all existing definitions will work unchanged with the new version of 
>[COMPILE,] except that if you have [COMPILE] defined using COMPILE, you 
>should change it to make sure it always compiles the xt, ignoring any 
>compilation behaviour set. 

[COMPILE] is now obsolete in Forth2012. In VFX Forth [COMPILE] is
still present along ith its twin [INTERP].

: [COMPILE]     \ "<spaces>name" --
\ *G Compile the *\b{compilation} action of the next word in the input
\ ** stream. *\fo{[COMPILE]} ignores the *\fo{IMMEDIATE} state of
\ ** the word. Its operation is mostly superceded by *\fo{POSTPONE}.
\ ** See also *\fo{[INTERP]} below.
  ' compile,
; IMMEDIATE

: [INTERP]	\ "<spaces>name" --
\ *G Compile the *\b{interpretation} action of the next word in
\ ** the input stream. *\fo{[INTERP]} is necessary when you want
\ ** the interpretation behaviour of words such as *\fo{S"} to
\ ** be compiled.
\ ** See also *\fo{[COMPILE]} above.
  ' postpone literal  postpone execute
; immediate

And yes, IMMEDIATE does have its uses, even if expressed as
a special case.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#38758

From	Bernd Paysan <bernd.paysan@gmx.de>
Date	2015-05-01 22:55 +0200
Message-ID	<mi0p6s$9or$1@dont-email.me>
In reply to	#38741

JennyB wrote:

> Set the compilation behaviour of the latest definition to perform xt.

It's "compilation semantics".

> It is a error to use both SET-COMPILER and IMMEDAITE on the same
> definition.

We write "an ambiguous condition exist" if any.  The wordings "it is an 
error" in SUBSTITUTE already are causing us headaches now ;-).  It may or 
may not be an error if the output buffer is the same as the input buffer, 
depending on the implementation.

> If SET-COMPILER is present, the meaning of COMPILE, is extended to perform
> the compiling  behaviour set for the definition by SET-COMPILER.

The standard usually gets complicated when you allow different options to 
coexist.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38763

From	JennyB <jennybrien@googlemail.com>
Date	2015-05-02 01:32 -0700
Message-ID	<110965f1-5d6f-4494-9cd9-010cb94bc06b@googlegroups.com>
In reply to	#38758

On Friday, 1 May 2015 21:55:56 UTC+1, Bernd Paysan  wrote:
> JennyB wrote:
> 
> > Set the compilation behaviour of the latest definition to perform xt.
> 
> It's "compilation semantics".
> 
> > It is a error to use both SET-COMPILER and IMMEDAITE on the same
> > definition.
> 
> We write "an ambiguous condition exist" if any.  The wordings "it is an 
> error" in SUBSTITUTE already are causing us headaches now ;-).  It may or 
> may not be an error if the output buffer is the same as the input buffer, 
> depending on the implementation.
> 

OK, I should have said 'FIND returns -1' just in case you are setting a word 
that has already been set immediate.  Whoever sets it last wins.

At this stage the immediacy flag seems a bit like the monastery cat*

> > If SET-COMPILER is present, the meaning of COMPILE, is extended to perform
> > the compiling  behaviour set for the definition by SET-COMPILER.
> 
> The standard usually gets complicated when you allow different options to 
> coexist.

I was trying to get at the idea that if you don't use SET-COMPILER and you 
don't want it, than you don't need to extend the meaning of COMPILE,

For default words there is no difference. What does it means to compile the 
interpretation semantics of an immediate word? What else have we got to do
that?

foo is a true immediate     ['] foo EXECUTE or [COMPILE] foo or POSTPONE foo 
foo is a compile-only       POSTPONE foo
foo is dual                 ['] foo EXECUTE or 
                            [COMPILE] foo (possibly) for i.s.
                            POSTPONE foo for c.s.

So you don't actually need COMPILE, unless you do don't know the xt until runtime.  In that case you are actually defining a compiler.  Not just a text interpreter, a full compiler.  In that case, wouldn't it be good to think about implementing the full COMPILE, ? It would be rather nice to have a word that meant 'do with this xt whatever the compiler does.'

* The Monastery Cat.
  The monks once had a kitten that they loved very much but, because it was 
so playful, they used to put it in a basket when they went to meditate.
The cat grew up and got slower, but they still put it in the basket every day.

Eventually, the cat died.

And the monks got another cat to put in the basket.

[toc] | [prev] | [next] | [standalone]

#38780

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-05-02 16:27 +0000
Message-ID	<2015May2.182747@mips.complang.tuwien.ac.at>
In reply to	#38763

JennyB <jennybrien@googlemail.com> writes:
>I was trying to get at the idea that if you don't use SET-COMPILER and you=
>=20
>don't want it, than you don't need to extend the meaning of COMPILE,
>
>For default words there is no difference.

You may be confusing SET-COMPILER (which changes COMPILE, and should
not make any difference except in performance) with SET-COMPSEM (which
changes NAME>COMPILE and other compilation-semantics-related words).

SET-COMPILER is very appropriate for words with default compilation
semantics like +.  It is the mechanism used to specify the specific
implementation of this word in the code generator.

> What does it means to compile the=
>=20
>interpretation semantics of an immediate word?

Once you are at "interpretation semantics", immediacy no longer plays
a role.  If you do NAME>INTERPRET COMPILE, you get what Stephen Pelc
calls "interp-compile,", i.e., you append the interpretation semantics
of the word to the current definition.

>So you don't actually need COMPILE, unless you do don't know the xt until r=
>untime.  In that case you are actually defining a compiler.  Not just a tex=
>t interpreter, a full compiler.  In that case, wouldn't it be good to think=
> about implementing the full COMPILE, ? It would be rather nice to have a w=
>ord that meant 'do with this xt whatever the compiler does.'

It's unclear what you mean by that.  A common usage (use 2) of
COMPILE, is to mean "I want to have the same semantics as EXECUTEing
this xt would give me now, but I want it appended to the current
definition".  I don't know if you call this usage "a full compiler".
The other thing we have is compilation semantics.  For words with
default compilation semantics like +, there is no difference, but for
other words there is.  That's why we cannot use SET-COMPILER for both,
but need SET-COMPSEM in addition.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38794

From	JennyB <jennybrien@googlemail.com>
Date	2015-05-03 08:36 -0700
Message-ID	<979de975-5fe0-4028-89cd-2f211abe297c@googlegroups.com>
In reply to	#38780

On Saturday, 2 May 2015 17:44:25 UTC+1, Anton Ertl  wrote:

> A common usage (use 2) of
> COMPILE, is to mean "I want to have the same semantics as EXECUTEing
> this xt would give me now, but I want it appended to the current
> definition".  I don't know if you call this usage "a full compiler".
> The other thing we have is compilation semantics.  For words with
> default compilation semantics like +, there is no difference, but for
> other words there is.  That's why we cannot use SET-COMPILER for both,
> but need SET-COMPSEM in addition.
> 

I've been looking back at old uses of STATE-smart code and (apart from toy 
examples that don't compile anything) it seems that they all compile code to 
append the interpretation semantics, and therefore they are all suitable uses 
for SET-COMPILER; they just compile optimised code based on the assumption 
that some of the parameters are available at compile-time.

For example:

Interpretation:  S" needs the parsed input to return   addr n
Compilation:     the input is there - no need to parse at run-time

Parsing TO
Interpretation:   TO needs to parse to get an address and storage method
Compilation:      the input is there - no need to parse at run-time

Flag-setting TO
Interpretation:  Just sets the flag
Compilation:     No need to optimise.

Flag-reading VALUE
Interpretation:   Must read the flag
Compilation:      Reads current setting - no need to read at run-time

Of course things will go wrong when expectations are not met, but how is any of this different from constant-folding or other optimisations?

[toc] | [prev] | [next] | [standalone]

#38815

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-05-04 16:44 +0000
Message-ID	<2015May4.184419@mips.complang.tuwien.ac.at>
In reply to	#38794

JennyB <jennybrien@googlemail.com> writes:
>On Saturday, 2 May 2015 17:44:25 UTC+1, Anton Ertl  wrote:
>
>> A common usage (use 2) of
>> COMPILE, is to mean "I want to have the same semantics as EXECUTEing
>> this xt would give me now, but I want it appended to the current
>> definition".  I don't know if you call this usage "a full compiler".
>> The other thing we have is compilation semantics.  For words with
>> default compilation semantics like +, there is no difference, but for
>> other words there is.  That's why we cannot use SET-COMPILER for both,
>> but need SET-COMPSEM in addition.
>> 
>
>I've been looking back at old uses of STATE-smart code and (apart from toy 
>examples that don't compile anything) it seems that they all compile code to 
>append the interpretation semantics, and therefore they are all suitable uses 
>for SET-COMPILER; they just compile optimised code based on the assumption 
>that some of the parameters are available at compile-time.
>
>
>For example:
>
>Interpretation:  S" needs the parsed input to return   addr n
>Compilation:     the input is there - no need to parse at run-time

S" is an example that cannot be implemented as word with default
compilation semantics.  If it could, nobody would try to implement it
as STATE-smart word.

You are right that there is a system to many of these words; a
division into parse-time, a possible delay eliment (e.g., sliteral),
and a run-time element (nothing for S", but TYPE for .").

It would be possible to organize the text interpreter and words along
this system but that would be even more involved than anything up to
now.  The advantage would be that we could use S" in postpone mode.
But I think that recognizers are a better solution than words like S".

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38777

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2015-05-02 15:37 +0000
Message-ID	<2015May2.173703@mips.complang.tuwien.ac.at>
In reply to	#38741

JennyB <jennybrien@googlemail.com> writes:
>In that COMPILE, never encounters an IMMEDIATE word. The only sensible case 
>I can think of is if COMPILE, is used in the definition of [COMPILE]. There 
>it really does have to be a dumb interp-compile.

And most other uses of COMPILE, outside text interpreters, e.g.,
object-oriented packages and macros.

>> Conceptually, Forth should remain a simple language.
>
>Then the specification of SET-COMPILER, if it were to be a Standard word, would be:
>
>Set the compilation behaviour of the latest definition to perform xt.

It would be SET-COMPSEM's task to set the compilation semantics.

>If SET-COMPILER is present, the meaning of COMPILE, is extended to perform the compiling  behaviour set for the definition by SET-COMPILER.

That is SET-COMPILER's task.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#38737

From	Bernd Paysan <bernd.paysan@gmx.de>
Date	2015-05-01 01:33 +0200
Message-ID	<mhue23$4fq$1@dont-email.me>
In reply to	#38725

JennyB wrote:

> If the xt is a single point of reference (as it has to be for SET-COMPILER
> to work) is there any reason why there should not be a a 1:1
> correspondence of xt to wordname, and the nt used by TRAVERSE-WORDLIST be
> the xt?

Remaining reason: SYNONYMs.  I suppose that a synonym has the same xt as its 
original definition, but a different name.  So you want TRAVERSE-WORDLIST to 
encounter both names, but not the same xt twice.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#38742

From	JennyB <jennybrien@googlemail.com>
Date	2015-05-01 03:15 -0700
Message-ID	<c7b17bbd-21a9-4da7-a210-fdf6c6a675de@googlegroups.com>
In reply to	#38737

On Friday, 1 May 2015 00:33:23 UTC+1, Bernd Paysan  wrote:
> JennyB wrote:
> 
> > If the xt is a single point of reference (as it has to be for SET-COMPILER
> > to work) is there any reason why there should not be a a 1:1
> > correspondence of xt to wordname, and the nt used by TRAVERSE-WORDLIST be
> > the xt?
> 
> Remaining reason: SYNONYMs.  I suppose that a synonym has the same xt as its 
> original definition, but a different name.  So you want TRAVERSE-WORDLIST to 
> encounter both names, but not the same xt twice.
> 
Synonym is a bit of a monster. If there was the entitlement to tick any 
word, then I think CLONE would be preferable. 

I seem to remember some wording that the xts may or may not be identical, 
but I can't see any mention in 14.4.

As far as I can see, the only way to have them identical is in a Forth with 
separated headers (new header, same xt pointer)

[toc] | [prev] | [next] | [standalone]

#38745

From	albert@spenarnc.xs4all.nl (Albert van der Horst)
Date	2015-05-01 12:47 +0000
Message-ID	<554375fc$0$21239$e4fe514c@dreader37.news.xs4all.nl>
In reply to	#38742

In article <c7b17bbd-21a9-4da7-a210-fdf6c6a675de@googlegroups.com>,
JennyB  <jennybrien@googlemail.com> wrote:
>On Friday, 1 May 2015 00:33:23 UTC+1, Bernd Paysan  wrote:
>> JennyB wrote:
>>
>> > If the xt is a single point of reference (as it has to be for SET-COMPILER
>> > to work) is there any reason why there should not be a a 1:1
>> > correspondence of xt to wordname, and the nt used by TRAVERSE-WORDLIST be
>> > the xt?
>>
>> Remaining reason: SYNONYMs.  I suppose that a synonym has the same xt as its
>> original definition, but a different name.  So you want TRAVERSE-WORDLIST to
>> encounter both names, but not the same xt twice.
>>
>Synonym is a bit of a monster. If there was the entitlement to tick any
>word, then I think CLONE would be preferable.

So this is what it is all about! SYNONYM is necessary
because   `` 'APE ALIAS MONKEY '' may not work, because nobody
knows what 'APE is, and already it is split into the ' APE and ['] APE
cases. and APE may not even have a clearcut xt.

Then SYNONYM get's entangled in the c/i/whatnot behaviour.
I'm not sure whether I want to get invovled in this.


>
>I seem to remember some wording that the xts may or may not be identical,
>but I can't see any mention in 14.4.
>
>As far as I can see, the only way to have them identical is in a Forth with
>separated headers (new header, same xt pointer)

I use the headers as an xt in ciforth, sacrificing some speed for simplicity.
When that is outlawed, I'll become an outlaw. Or just claim to adhere to ISO 94.

>

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#38752

From	JennyB <jennybrien@googlemail.com>
Date	2015-05-01 10:29 -0700
Message-ID	<b12ceae4-02e4-4037-91c7-65f07cfa1d64@googlegroups.com>
In reply to	#38745

On Friday, 1 May 2015 13:47:57 UTC+1, Albert van der Horst  wrote:
> In article <c7b17bbd-21a9-4da7-a210-fdf6c6a675de@googlegroups.com>,
> JennyB  <jennybrien@googlemail.com> wrote:

> So this is what it is all about! SYNONYM is necessary
> because   `` 'APE ALIAS MONKEY '' may not work, because nobody
> knows what 'APE is, and already it is split into the ' APE and ['] APE
> cases. and APE may not even have a clearcut xt.

That's pretty much it. The silly thing is, that to make a tick that doesn't 
return certain words it /has/ to find them and then abort.  They can't be 
actually invisible, because then the search might find a namesake that was 
defined earlier.  Dual-wordlist Forths are interseting, but they can never 
be fully Standard. I thought we thrashed that question out back in the '90s, 
and I'm amazed the reference to cmForth is still in the Appendix.

> 
> I use the headers as an xt in ciforth, sacrificing some speed for simplicity.
> When that is outlawed, I'll become an outlaw. Or just claim to adhere to ISO 94.
> 

Thanks for that!  

Stephen was saying that xt was an opaque type, and I just wasn't getting it; 
I thought it almost had to be the code entry point, and then I saw
 difficulties in doing SET-COMPILER on Forths with separate header and code 
space.  

The sacrifice of speed need not be too bad.  Where the xt is known at 
compile-time, the call could be compiled directly; where it is being fetched from data space there in an extra indirection, but you could remove even that by storing it to a deferred word (IS doing the conversion to a 'real' xt).

There's really no excuse for not allowing /any/ definition to be ticked, or returned by FIND IF ... and its name and compilation behaviour found later from that unique name/xt token alone. 

Then we have in all cases:

  interp-execute       token EXECUTE
  comp-execute         token >comp EXECUTE
  interp-compile,      token LITERAL POSTPONE EXECUTE
  comp-compile,        token >comp 2LITERAL POSTPONE EXECUTE

I think...

[toc] | [prev] | [next] | [standalone]

#38756

From	albert@spenarnc.xs4all.nl (Albert van der Horst)
Date	2015-05-01 20:32 +0000
Message-ID	<5543e2db$0$21226$e4fe514c@dreader37.news.xs4all.nl>
In reply to	#38752

In article <b12ceae4-02e4-4037-91c7-65f07cfa1d64@googlegroups.com>,
JennyB  <jennybrien@googlemail.com> wrote:
>On Friday, 1 May 2015 13:47:57 UTC+1, Albert van der Horst  wrote:
>> In article <c7b17bbd-21a9-4da7-a210-fdf6c6a675de@googlegroups.com>,
>> JennyB  <jennybrien@googlemail.com> wrote:
>
>> So this is what it is all about! SYNONYM is necessary
>> because   `` 'APE ALIAS MONKEY '' may not work, because nobody
>> knows what 'APE is, and already it is split into the ' APE and ['] APE
>> cases. and APE may not even have a clearcut xt.
>
>That's pretty much it. The silly thing is, that to make a tick that doesn't
>return certain words it /has/ to find them and then abort.  They can't be
>actually invisible, because then the search might find a namesake that was
>defined earlier.  Dual-wordlist Forths are interseting, but they can never
>be fully Standard. I thought we thrashed that question out back in the '90s,
>and I'm amazed the reference to cmForth is still in the Appendix.
>
>>
>> I use the headers as an xt in ciforth, sacrificing some speed for simplicity.
>> When that is outlawed, I'll become an outlaw. Or just claim to adhere
>to ISO 94.
>>
>
>Thanks for that!
>
>Stephen was saying that xt was an opaque type, and I just wasn't getting it;
>I thought it almost had to be the code entry point, and then I saw
> difficulties in doing SET-COMPILER on Forths with separate header and code
>space.
>
>The sacrifice of speed need not be too bad.  Where the xt is known at
>compile-time, the call could be compiled directly; where it is being
>fetched from data space there in an extra indirection, but you could
>remove even that by storing it to a deferred word (IS doing the
>conversion to a 'real' xt).

The introspection ability of such a system is very good. That means
a separate optimizing compiler can be added pretty easily.
First the need must arise, of course.

>
>There's really no excuse for not allowing /any/ definition to be ticked,
>or returned by FIND IF ... and its name and compilation behaviour found
>later from that unique name/xt token alone.

All properties can be found from the dea (what you guys call name token,
which I hate because a noname definition has a dea like anything else.)
The name dea was coined in 1994 when I was working on tForth (transputer
Forth) the LFA>CFA PFA>LFA >BODY BODY> drove me crazy and I decided that
there should be one thingy to pass around to identify a definition.
(dictionary entry address)

>
>Then we have in all cases:
>
>  interp-execute       token EXECUTE
>  comp-execute         token >comp EXECUTE
>  interp-compile,      token LITERAL POSTPONE EXECUTE
>  comp-compile,        token >comp 2LITERAL POSTPONE EXECUTE
>
>I think...

ciforth :
    'something
 then one of :
    >CFA @
    >DFA @
    >LFA @
    >NFA @
    >FFA @
    >SFA @

e.g. any words name can be printed, like so
'DROP >NFA @ $@ TYPE
DROP OK

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →

csiph-web

SET-COMPILER

Contents

#38727

#38733

#38734

#38735

#38744

#38775

#38738

#38741

#38743

#38758

#38763

#38780

#38794

#38815

#38777

#38737

#38742

#38745

#38752

#38756