Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38642 > unrolled thread
| 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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-27 01:34 -0700 |
| Subject | SET-COMPILER |
| Message-ID | <54c266b4-17d8-4d0d-adc6-8b7ab0bcc0f4@googlegroups.com> |
What is the stack for SET-COMPILER? Can it be applied to arbitrary xt, or, like IMMEDIATE, does it only change the most recent definition?
It seems confusing to me to have rules for the interpretation and compilation behavior of Standard words that user-defined don't follow.
At present:
All user-defined words are tickable and return an xt that can be EXECUTEd. Whether it is designed to be executed while interpreting or while compiling, or both, is the user's decision.
FIND returns the xt and a flag - 1 if the word is to be executed while compiling (IMMEDIATE), or -1 otherwise, in which case the compiler does whatever it is designed to do with COMPILE, which may or may not include fairly complex optimising.
IMMEDIATE is presently the only way for the user define special compiling behavior. If you want a word to word during interpretation and its compiling behavior in inappropriate, then you have two choices:
Write two separate words, one for interpreting and one for compiling, and use them appropriately.
Wrap them into one STATE-smart word and live with the gotcha of depending on run-time STATE.
So we want a way for the user to define early-binding compiling behavior for non-IMMEDIATE words (IMMEDIATE words, by definition, already define early-binding compiling behavior - unless they are STATE-smart) without breaking the familiar rules.
So:
SET-COMPILER doesn't make sense on IMMEDIATE words, :NONAMEs, or, I would guess, on SYNONYMs.
Ticking produces the same xt as before.
Xt COMPILE, executes the xt set by SET-COMPILER, or performs the default compiler action otherwise.
POSTPONE does the equivalent of xt LITERAL ['] COMPILE, COMPILE, just as it would on any other non-IMMEDIATE word. When run, this produces the same result as compile-action-xt COMPILE, which it would have done if compile-action were an IMMEDIATE word.
All right so far? What else am I missing?
[toc] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-27 14:52 +0000 |
| Message-ID | <553e472a.522354512@news.eternal-september.org> |
| In reply to | #38642 |
On Mon, 27 Apr 2015 01:34:27 -0700 (PDT), JennyB
<jennybrien@googlemail.com> wrote:
>What is the stack for SET-COMPILER? Can it be applied to arbitrary xt, or, like IMMEDIATE,
>does it only change the most recent definition?
This is the most recent glossary entry for SET-COMPILER in VFX Forth.
: set-compiler \ xt --
\ Set xt as the compiler of the LATEST definition.
\ The word whose xt is given to SET-COMPILER receives the
\ xt of the word it is to compile ( xt -- ). This is
\ done so that information can be extracted from the word.
>It seems confusing to me to have rules for the interpretation and compilation
>behavior of Standard words that user-defined don't follow.
I agree. What SET-COMPILER can do is to remove the need for IMMEDIATE
words, especially state-smart words.
Because the ANS and Forth-2012 standards only declare that a very few
standard words must be IMMEDIATE, programmers cannot rely on words
such as IF being IMMEDIATE. The only reason that some words in VFX
are immediate is for standards compliance. A trial version with no
IMMEDIATE words worked fine.
>So:
>SET-COMPILER doesn't make sense on IMMEDIATE words,
More that IMMEDIATE words don't make sense when you have SET-COMPILER.
SET-COMPILER is a reaction to the ANS and Forth-2012 standards
recognising that some words have special compilation behaviour,
which in earlier Forths was implemented using state-smart
IMMEDIATE words. A classic example of this is IF.
Here's the definition of SYNONYM from VFX Forth:
: SynComp, \ xt --
\ Compile a child of SYNONYM.
>body @ compile,
;
: Synonym \ "<new-name>" "<curdef>" --
\ *G Create a new definition which redirects to an existing one.
\ ** Normal dictionary searches for *\i{<new-name>} will return
\ ** the xt of *\i{<curdef>}.
create
hide ' reveal dup , immediate?
if immediate endif
['] SynComp, set-compiler
$010 latest set-bit \ set header's alias bit
interp>
@ execute
;
Note that SYNONYM applies SET-COMPILER even to IMMEDIATE words.
Child words with the alias bit set return the original xt.
INTERP> in used instead of DOES> to
a) suppress a particular part of the code generator,
b) emphasise that the INTERP> clause only applies to interpretation
of the child.
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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-27 21:17 +0200 |
| Message-ID | <mhm1v8$f1j$1@dont-email.me> |
| In reply to | #38649 |
Stephen Pelc wrote: > Note that SYNONYM applies SET-COMPILER even to IMMEDIATE words. > Child words with the alias bit set return the original xt. > > INTERP> in used instead of DOES> to > a) suppress a particular part of the code generator, > b) emphasise that the INTERP> clause only applies to interpretation > of the child. I had the same problem when I added SET-COMPILER to Gforth, as DOES> does two things: First a SET-COMPILER to create optimizing code for these words, and second, modify the CFA. INTERP> would only modify the CFA. I did something different: Keep DOES>, and let it check if it's still CREATE's compiler. If so, replace the compiler xt, otherwise, leave it as is. -- 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-28 09:41 -0700 |
| Message-ID | <7d46d35c-c8ea-412c-be8f-1193f4a257be@googlegroups.com> |
| In reply to | #38649 |
On Monday, April 27, 2015 at 7:52:00 AM UTC-7, Stephen Pelc wrote:
> On Mon, 27 Apr 2015 01:34:27 -0700 (PDT), JennyB
> <jennybrien@googlemail.com> wrote:
>
> >What is the stack for SET-COMPILER? Can it be applied to arbitrary xt, or, like IMMEDIATE,
> >does it only change the most recent definition?
>
> This is the most recent glossary entry for SET-COMPILER in VFX Forth.
>
> : set-compiler \ xt --
> \ Set xt as the compiler of the LATEST definition.
> \ The word whose xt is given to SET-COMPILER receives the
> \ xt of the word it is to compile ( xt -- ). This is
> \ done so that information can be extracted from the word.
This is just Stephen Pelc saying RTFM --- he wants to trap everybody in vendor lock-in by tricking them into using non-standard VFX-specific code when it is not necessary.
> >It seems confusing to me to have rules for the interpretation and compilation
> >behavior of Standard words that user-defined don't follow.
>
> I agree. What SET-COMPILER can do is to remove the need for IMMEDIATE
> words, especially state-smart words.
>
> Because the ANS and Forth-2012 standards only declare that a very few
> standard words must be IMMEDIATE, programmers cannot rely on words
> such as IF being IMMEDIATE. The only reason that some words in VFX
> are immediate is for standards compliance. A trial version with no
> IMMEDIATE words worked fine.
It didn't work fine. This was already discussed thoroughly here:
https://groups.google.com/forum/#!topic/comp.lang.forth/oXXQAGDKP7w
Note the title of the thread: "Bug in VFX --- IF doesn't work"
That is not "working fine."
> >So:
> >SET-COMPILER doesn't make sense on IMMEDIATE words,
>
> More that IMMEDIATE words don't make sense when you have SET-COMPILER.
> SET-COMPILER is a reaction to the ANS and Forth-2012 standards
> recognising that some words have special compilation behaviour,
> which in earlier Forths was implemented using state-smart
> IMMEDIATE words. A classic example of this is IF.
>
> Here's the definition of SYNONYM from VFX Forth:
>
> : SynComp, \ xt --
> \ Compile a child of SYNONYM.
> >body @ compile,
> ;
>
> : Synonym \ "<new-name>" "<curdef>" --
> \ *G Create a new definition which redirects to an existing one.
> \ ** Normal dictionary searches for *\i{<new-name>} will return
> \ ** the xt of *\i{<curdef>}.
> create
> hide ' reveal dup , immediate?
> if immediate endif
> ['] SynComp, set-compiler
> $010 latest set-bit \ set header's alias bit
> interp>
> @ execute
> ;
>
> Note that SYNONYM applies SET-COMPILER even to IMMEDIATE words.
> Child words with the alias bit set return the original xt.
>
> INTERP> in used instead of DOES> to
> a) suppress a particular part of the code generator,
> b) emphasise that the INTERP> clause only applies to interpretation
> of the child.
In that thread I figured out a work-around for the bug in VFX (that comes from the bug in ANS-Forth). I was able to write SYNONYM SYNONYM-FAST and ALIAS in ANS-Forth. In didn't need any of this VFX-specific nonsense such as SET-COMPILER INTERP> etc. (I don't even know what that stuff does, nor do I care). My ALIAS words of CREATE DOES> words work with >BODY --- they don't return the same xt when ticked, but working with >BODY is just as good from a practical standpoint.
Here is the solution yet again (Stephen keeps ignoring this, because he wants to avoid ANS-Forth compatibility in VFX). This requires the novice package for a few words (FIELD etc.), but the novice package is all ANS-Forth, so this is also ANS-Forth:
: to postpone to ; immediate
: +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate
: ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate
: ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate
: abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate
: begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate
: do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate
: does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate
: else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate
: I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate
: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate
: J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate
: leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate
: literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate
: loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate
: postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate
: r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate
: r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate
: recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate
: repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate
: s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate
: then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate
: unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate
: until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate
: while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate
: [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate
: ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate
: [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate
: 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate
: 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate
: 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate
: ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate
: again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate
: c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate
: case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate
: compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate
: endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate
: endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate
: of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate
exist? [compile] [if] \ SwiftForth doesn't have [COMPILE]
: [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate
[then]
: 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate
: fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate
: (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate
: locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate
: ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate
: ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate
: cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate
: cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate
: sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
\ All of the above words are provided for working around the bug in ANS-Forth in which they either
\ lack an xt value (for example: ; in Gforth) or they have an xt value that aborts when executed (for example: IF in VFX).
\ Note that S" and C" are both state-smart in VFX, but this is in violation to ANS-Forth that says they have no interpretation semantics.
\ I don't allow them to work in interpretation mode --- this doesn't matter anyway, because I redefine them later in the novice-package.
: :synonym { xt flg str wid -- }
\ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if xt compile, ;, exit then
true abort" *** :SYNONYM given an invalid xt ***" ;
: :synonym-fast-check ( -- )
state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;
: :synonym-fast { xt flg str wid -- }
\ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if postpone :synonym-fast-check
xt lit, postpone compile, ;, immediate exit then
true abort" *** :SYNONYM-FAST given an invalid xt ***" ;
: 'find ( -- xt flg ) \ stream: name
\ FLG is 1 for immediate and -1 for non-immediate
bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;
: synonym { wid | new -- } \ stream: new-name old-name
\ the new word is compiled into the WID word-list
bl parse <hstr> to new
'find new wid :synonym
new dealloc ;
: synonym-fast { wid | new -- } \ stream: new-name old-name
\ the new word is compiled into the WID word-list
bl parse <hstr> to new
'find new wid :synonym-fast
new dealloc ;
\ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
\ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.
1234512345 constant alias-id
\ an arbitrary number used to identify alias'd definitions
0
w field alias.xt
w field alias.adr
w field alias.id
constant alias-struct
: alias ( wid -- ) \ stream: new-name old-name
\ the new word is compiled into the WID word-list
get-current swap set-current create set-current
here >r alias-struct allot
'find if immediate then r@ alias.xt !
r@ r@ alias.adr !
alias-id r@ alias.id !
rdrop
does>
alias.xt @ execute ;
\ ALIAS does the same thing as SYNONYM but has the advantage that >BODY will work on it.
\ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).
: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if
r> alias.xt @ >body exit then then
r> ;
\ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-27 16:53 +0100 |
| Message-ID | <mhlm02$rh2$1@dont-email.me> |
| In reply to | #38642 |
on 27/04/2015 09:34:24, JennyB wrote: > What is the stack for SET-COMPILER? Can it be applied to arbitrary xt, > or, like IMMEDIATE, does it only change the most recent definition? From some of MPE's documentation; : set-compiler cc/i \ xt -- Set the code generator field of the last word defined. : COMP: cc/i \ -- Set up code generator field and start a :NONAME definition to perform compilation actions for the last word defined. > > It seems confusing to me to have rules for the interpretation and > compilation behavior of Standard words that user-defined don't follow. > > At present: > > All user-defined words are tickable and return an xt that can be > EXECUTEd. Whether it is designed to be executed while interpreting or > while compiling, or both, is the user's decision. > > FIND returns the xt and a flag - 1 if the word is to be executed while > compiling (IMMEDIATE), or -1 otherwise, in which case the compiler > does whatever it is designed to do with COMPILE, which may or may not > include fairly complex optimising. Assumes FIND while compiling returns the compilation semantics? See below. > > IMMEDIATE is presently the only way for the user define special > compiling behavior. If you want a word to word during interpretation > and its compiling behavior in inappropriate, then you have two > choices: > > Write two separate words, one for interpreting and one for compiling, > and use them appropriately. > > Wrap them into one STATE-smart word and live with the gotcha of > depending on run-time STATE. > > So we want a way for the user to define early-binding compiling > behavior for non-IMMEDIATE words (IMMEDIATE words, by definition, > already define early-binding compiling behavior - unless they are > STATE-smart) without breaking the familiar rules. > > So: > SET-COMPILER doesn't make sense on IMMEDIATE words, :NONAMEs, or, I > would guess, on SYNONYMs. IMMEDIATE would appear to be :noname compile, ; set-compiler > > Ticking produces the same xt as before. Which? FIND allows different XTs for compilation & interpretation, and the TC never answered RFI 8. > > Xt COMPILE, executes the xt set by SET-COMPILER, or performs the > default compiler action otherwise. > > POSTPONE does the equivalent of xt LITERAL ['] COMPILE, COMPILE, just > as it would on any other non-IMMEDIATE word. When run, this produces > the same result as compile-action-xt COMPILE, which it would have done > if compile-action were an IMMEDIATE word. > > All right so far? What else am I missing? > [COMPILE] is presumably redundant since immediacy is no longer relevant.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-27 17:02 +0100 |
| Message-ID | <mhlmh5$tre$1@dont-email.me> |
| In reply to | #38651 |
on 27/04/2015 16:53:36, "Alex McDonald" wrote: > on 27/04/2015 09:34:24, JennyB wrote: [added to say] >> >> POSTPONE does the equivalent of xt LITERAL ['] COMPILE, COMPILE, just That may be wrong; I suspect what is required is a definition based on compilation semantics and not the execution semantics that you get with COMPILE,
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-27 10:23 -0700 |
| Message-ID | <4a704c94-6b4e-4015-9bc4-5462be55428c@googlegroups.com> |
| In reply to | #38653 |
On Monday, 27 April 2015 17:02:43 UTC+1, Alex McDonald wrote: > on 27/04/2015 16:53:36, "Alex McDonald" wrote: > > on 27/04/2015 09:34:24, JennyB wrote: > > [added to say] > >> > >> POSTPONE does the equivalent of xt LITERAL ['] COMPILE, COMPILE, just > > That may be wrong; I suspect what is required is a definition based on > compilation semantics and not the execution semantics that you get with > COMPILE, As far as I can see, it's the usual definition for default words. It works for other words because COMPILE, executes the behavior set by SET-COMPILER.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-27 10:02 -0700 |
| Message-ID | <e7b0b9c3-d352-4ef8-b443-51643e605c3d@googlegroups.com> |
| In reply to | #38651 |
On Monday, 27 April 2015 16:53:36 UTC+1, Alex McDonald wrote: > on 27/04/2015 09:34:24, JennyB wrote: See Stephen's glossary of SET-COMPILER above. (Thanks, Stephen) > : COMP: cc/i \ -- Set up code generator field and start a :NONAME > definition to perform compilation actions for the last word defined. > > > > > It seems confusing to me to have rules for the interpretation and > > compilation behavior of Standard words that user-defined don't follow. > > > > At present: > > > > All user-defined words are tickable and return an xt that can be > > EXECUTEd. Whether it is designed to be executed while interpreting or > > while compiling, or both, is the user's decision. > > > > FIND returns the xt and a flag - 1 if the word is to be executed while > > compiling (IMMEDIATE), or -1 otherwise, in which case the compiler > > does whatever it is designed to do with COMPILE, which may or may not > > include fairly complex optimising. > > Assumes FIND while compiling returns the compilation semantics? See > below. > No. Unless my understanding of Anton's Forth is badly wrong, for any definition the user can make using only Standard words, FIND will return the same xt whether interpreting or compiling. I'm not concerned about what it does for supplied words. I /am/ concerned that the requirement to allow it to return different values has led to a lot of complexity and confusion in the wording of the Standard. The concession was originally made to try to accommodate Forths that used a separate wordlist for compiler word. We discovered many years ago that those could not be made compatible in any case. Anton's can, but only by adding restrictions that don't make sense under other implementations. > IMMEDIATE would appear to be > > :noname compile, ; set-compiler > Since SET-COMPILER takes the xt as a parameter : IMMEDIATE ['] EXECUTE SET-COMPILER ; For all practical purposes. FIND and SEARCH-WORDLIST now return -1 for all user words, but legacy interpreters will still work as expected. > > > > Ticking produces the same xt as before. > > Which? FIND allows different XTs for compilation & interpretation, and > the TC never answered RFI 8. That's the complexity and confusion I mentioned above. I meant that a word returns the same xt when ticked whether or not SET-COMPILER has been applied to it. > [COMPILE] is presumably redundant since immediacy is no longer relevant. isn't [COMPILE] already obsolescent?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-01 17:15 +0000 |
| Message-ID | <2015May1.191536@mips.complang.tuwien.ac.at> |
| In reply to | #38655 |
JennyB <jennybrien@googlemail.com> writes:
>The concession was originally made to try to acco=
>mmodate Forths that used a separate wordlist for compiler word. We discove=
>red many years ago that those could not be made compatible in any case.
The separate-wordlist approach can be made compatible, but in the
presence of the search-order wordset other implementations are
simpler.
Don't let Bernd's "concession" spin trick you. If it was just a
concession, they would have worded the standard as containing
state-smart words with appropriate ambiguous conditions to allow
cmForth. But since they introduced all the interpretation semantics
and compilation semantics wording that fits cmForth better than
state-smart Forths, I think they (at least those who penned this
wording) recognized the potential of cmForth-like (or dual-xt, as
Bernd Paysan calls them) approaches. STATE-smartness was certainly
known to have problems much earlier (that's why we have ' and [']
since Forth-83).
>Since SET-COMPILER takes the xt as a parameter
>
> : IMMEDIATE ['] EXECUTE SET-COMPILER ;
>
>For all practical purposes. FIND and SEARCH-WORDLIST now return -1 for all=
> user words, but legacy interpreters will still work as expected.=20
Unfortunately, this does not work as the standard specifies:
: foo ." foo" ; immediate
: [compile,] compile, ; immediate
: bar [ ' foo ] [compile,] ; \ should just compile
bar \ should print "foo"
works correctly even on VFX by default. When I add your IMMEDIATE,
the definition of BAR prints "foo" and the execution prints nothing.
And this has traditionally always worked, even in Forth-83 (with ","
instead of COMPILE,) and fig-Forth (with IIRC FIND instead of ').
One conclusion is that conflating compilation semantics with COMPILE,
behaviour is too dangerous for even knowledgable users like you.
Alternatively, let us consider a scenario where we really embrace the
conflation of COMPILE, and compilation semantics by having such a
SET-COMPILER, and doing everything (including IMMEDIATE) with it. No
need for immediate or compile-only flags, just one xt, we can have
words with funky combinations of interpretation and compilation
semantics (but beware of what you do with the xts of such words; you
cannot use-2 them), and the text interpreter even becomes simpler:
find if
state @ if compile, else execute then
then
No need to check the immediate flag.
The cost: It will break some code like the one above; most systems
would have to change their implementation.
>isn't [COMPILE] already obsolescent?
Yes.
- 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]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-01 23:38 +0200 |
| Message-ID | <mi0rmj$il9$1@dont-email.me> |
| In reply to | #38753 |
Anton Ertl wrote: > Don't let Bernd's "concession" spin trick you. If it was just a > concession, they would have worded the standard as containing > state-smart words with appropriate ambiguous conditions to allow > cmForth. At that time, there were struggles between Forth Inc. (who didn't have STATE in their system, nor did they have dual-xt), fig-Forth like Forths (which did, but no dual-xt) and cmForth (which had dual-wordlists and therefore dual-xt, but didn't work together with the search order wordset). I'm pretty sure the TC didn't anticipate your questions, which is why RFI 8 is still pending. There's little evidence that the old TC did make that as a conscious decision what you want to read into the standard. In any case, the old TC disbanded, and we are now in charge. Everything that goes into the Forth20xx effort is our decision. -- 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-27 14:52 +0000 |
| Message-ID | <2015Apr27.165232@mips.complang.tuwien.ac.at> |
| In reply to | #38642 |
JennyB <jennybrien@googlemail.com> writes:
>It seems confusing to me to have rules for the interpretation and compilation behavior of Standard words that user-defined don't follow.
User-defined words also follow the rules laid out in the standard.
>At present:
>
> All user-defined words are tickable and return an xt that can be EXECUTEd. Whether it is designed to be executed while interpreting or while compiling, or both, is the user's decision.
Sure, what they are designed to do is up to the programmer. All
user-defined words have both interpretation and compilation semantics.
> FIND returns the xt and a flag - 1 if the word is to be executed while compiling (IMMEDIATE), or -1 otherwise, in which case the compiler does whatever it is designed to do with COMPILE, which may or may not include fairly complex optimising.
>
>IMMEDIATE is presently the only way for the user define special compiling behavior. If you want a word to word during interpretation and its compiling behavior in inappropriate, then you have two choices:
>
> Write two separate words, one for interpreting and one for compiling, and use them appropriately.
>
> Wrap them into one STATE-smart word and live with the gotcha of depending on run-time STATE.
>
>So we want a way for the user to define early-binding compiling behavior for non-IMMEDIATE words (IMMEDIATE words, by definition, already define early-binding compiling behavior - unless they are STATE-smart) without breaking the familiar rules.
>
>So:
>SET-COMPILER doesn't make sense on IMMEDIATE words, :NONAMEs, or, I would guess, on SYNONYMs.
You are conflating two very different things: optimization and
compilation semantics. You are not alone in this mistake, and I'll
explore here why.
Let's start with optimization. Optimization means it does the same
semantics, but more efficiently.
As an example, let's take a simple example of a simple word: 2DUP
: 2dup over over ;
Now suppose your compiler does not do inlining by itself, so when you write
: foo ... 2dup ... ;
it will compile a call to your colon definition. You want it to
expand this into OVER OVER instead. So you tell COMPILE, to generate
over over instead of a call to 2DUP:
: 2dup over over ;
comp: drop postpone over postpone over ;
(This is VFX syntax); and this works even if you disable inlining:
[-sin
: foo 2dup ;
see foo
So in this case the COMP: provides a new implementation of the same
compilation semantics as the original word. In other words: this
implementation of 2DUP has the default compilation semantics, just a
more efficient implementation. You can do the code generation of all
the primitives of a native-code compiler with such a mechanism. And
that (implementing what COMPILE, would otherwise do, only more
efficiently) is the only thing that you should do with a mechanism
that changes what COMPILE, does with a word, such as COMP: or
SET-COMPILER.
Unfortunately, this is not where the story ends. As you write, there
are those who want words that do one thing when text-interpreted in
interpret state and another thing when text-interpreted in compile
state; such words are even in the standard (e.g., S"). Now once they
have a mechanism such as COMP:, they get the idea to use it not only
for optimization, but also for changing compilation semantics. This
idea comes from the observation that text interpreters tend to work as
follows:
find state @ if \ compile state?
if 0< if \ non-immediate?
compile,
else
execute
then
else
execute
then
So the idea of misusing COMP: for implementing arbitrary combinations
of interpretation and compilation semantics is this:
: foo
interpretation-semantics-of-foo ;
comp: drop compilation-semantics-of-foo ;
This will work as intended in the text interpreter outlined above: It
will perform the intended interpretation semantics when
text-interpreted in interpretation state, and it will perform the
intended compilation semantics when text-interpreted in compilation
state.
However, COMPILE, is not only used in the text interpreter. It is
used in other contexts, in particular in contexts where it is a a kind
of delayed EXECUTE (examples: early binding in OOP packages, or macros
with xt parameters). If you change what semantics COMPILE, compiles
for an xt, these uses break.
Now Bernd tells me that I should not worry, that nobody will use the
xts of words like FOO in these contexts. However, given the immense
creativity of Forth programmers in exploiting various aspects of Forth
systems, I don't find this at all reassuring.
My conclusion: Let's get rid of words with arbitrary combinations of
interpretation an compilation semantics. In the meantime, dual-xt
words are the right way to implement them.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-27 17:09 +0100 |
| Message-ID | <mhlmu8$vi1$1@dont-email.me> |
| In reply to | #38652 |
on 27/04/2015 15:52:33, wrote: > However, COMPILE, is not only used in the text interpreter. It is > used in other contexts, in particular in contexts where it is a a kind > of delayed EXECUTE (examples: early binding in OOP packages, or macros > with xt parameters). If you change what semantics COMPILE, compiles > for an xt, these uses break. Is there a simple example of this that you can provide?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-27 16:54 +0000 |
| Message-ID | <2015Apr27.185417@mips.complang.tuwien.ac.at> |
| In reply to | #38654 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 27/04/2015 15:52:33, wrote:
>> However, COMPILE, is not only used in the text interpreter. It is
>> used in other contexts, in particular in contexts where it is a a kind
>> of delayed EXECUTE (examples: early binding in OOP packages, or macros
>> with xt parameters). If you change what semantics COMPILE, compiles
>> for an xt, these uses break.
>
>Is there a simple example of this that you can provide?
: compile1, postpone literal postpone execute ;
\ should do the same thing as COMPILE,
: S0" [ ' s" compile, ] ;
: S1" [ ' s" compile1, ] ;
s0" bla" type
s1" bla" type
Both S0" and S1" should work the same way. In Gforth and SwiftForth
they do, in VFX S0" works differently.
This example is admittedly contrived.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-28 09:11 +0000 |
| Message-ID | <553f4b89.589009542@news.eternal-september.org> |
| In reply to | #38656 |
On Mon, 27 Apr 2015 16:54:17 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >"Alex McDonald" <blog@rivadpm.com> writes: >>on 27/04/2015 15:52:33, wrote: >>> However, COMPILE, is not only used in the text interpreter. It is >>> used in other contexts, in particular in contexts where it is a a kind >>> of delayed EXECUTE (examples: early binding in OOP packages, or macros >>> with xt parameters). If you change what semantics COMPILE, compiles >>> for an xt, these uses break. >> >>Is there a simple example of this that you can provide? > >: compile1, postpone literal postpone execute ; Please provide a version of POSTPONE that does not use COMPILE, so that we can avoid an infinite loop. Yes, I know about the time frames. >\ should do the same thing as COMPILE, >: S0" [ ' s" compile, ] ; >: S1" [ ' s" compile1, ] ; >s0" bla" type >s1" bla" type > >Both S0" and S1" should work the same way. In Gforth and SwiftForth >they do, in VFX S0" works differently. > >This example is admittedly contrived. The ugliness in the definitions of S0" and S1" is a result of there being no standard way to access the interpretation and compilation behaviour of S" separately. The simple Forth-like solution to this problem is to provide the facilities. We end up with interp-execute comp-execute interp-compile, comp-compile, as the four primitives. EXECUTE and COMPILE, map onto two of these (probably). With such a solution the need for the contrived code above disappears, we can live with a single xt if our system permits it, and readability is improved. 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]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-28 04:28 -0700 |
| Message-ID | <112dd93d-77e1-4990-9eef-1c999baff0d1@googlegroups.com> |
| In reply to | #38684 |
On Tuesday, 28 April 2015 10:11:17 UTC+1, Stephen Pelc wrote:
> The ugliness in the definitions of S0" and S1" is a result of there
> being no standard way to access the interpretation and compilation
> behaviour of S" separately. The simple Forth-like solution to this
> problem is to provide the facilities. We end up with
> interp-execute
> comp-execute
> interp-compile,
> comp-compile,
> as the four primitives. EXECUTE and COMPILE, map onto two of these
> (probably).
>
Let's see if I've got this right:
COMP, = do default
MYCOMP = do user-defined compilation
For a :noname, or default definition
xt EXECUTE
xt COMP,
xt COMP,
xt LITERAL ['] COMP, COMP,
For an immediate definition
EXECUTE
EXECUTE
COMP,
COMP,
For a definition with user-defined compilation
EXECUTE
MYCOMP,
COMP,
LITERAL ['] MYCOMP COMP,
?
If so, it would seen that VFX's COMPILE, does comp-execute rather than interp-compile. Classic COMPILE, does both for default words, but only interp-compile (and also comp-compile) for immediate words.
Note that with VFX-Compile, immediate words are a special case of user-defined words, since xt LITERAL ['] EXECUTE COMP, is equivalent to xt COMP.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-29 13:49 -0700 |
| Message-ID | <3e40bcfe-5d8c-45c2-bb5d-8292dfc1a666@googlegroups.com> |
| In reply to | #38687 |
On Tuesday, 28 April 2015 12:28:51 UTC+1, JennyB wrote:
> On Tuesday, 28 April 2015 10:11:17 UTC+1, Stephen Pelc wrote:
>
> > The ugliness in the definitions of S0" and S1" is a result of there
> > being no standard way to access the interpretation and compilation
> > behaviour of S" separately. The simple Forth-like solution to this
> > problem is to provide the facilities. We end up with
> > interp-execute
> > comp-execute
> > interp-compile,
> > comp-compile,
> > as the four primitives. EXECUTE and COMPILE, map onto two of these
> > (probably).
> >
>
> Let's see if I've got this right:
>
> COMP, = do default
> MYCOMP = do user-defined compilation
>
> For a :noname, or default definition
>
> xt EXECUTE
> xt COMP,
> xt COMP,
> xt LITERAL ['] COMP, COMP,
>
> For an immediate definition
>
> EXECUTE
> EXECUTE
> COMP,
> COMP,
>
> For a definition with user-defined compilation
>
> EXECUTE
> MYCOMP,
> COMP,
> LITERAL ['] MYCOMP COMP,
>
> ?
>
> If so, it would seen that VFX's COMPILE, does comp-execute rather than
interp-compile. Classic COMPILE, does both for default words, but only
interp-compile (and also comp-compile) for immediate words.
>
> Note that with VFX-Compile, immediate words are a special case of user-defined
words, since xt LITERAL ['] EXECUTE COMP, is equivalent to xt COMP.
Hmmm.
If COMPILE, is interp-compile then it can't be used with words lacking
interpretation semantics. Which leaves the true INTERMEDIATEs such as (,
and dual words, which the Standard doesn't properly address.
What is the use case for applying interp-compile to either?
It looks as if a COMPILE, that does comp-execute can enable Forth to finally
get rid of immediacy. SET-COMPILER 'cooks' the xt, attaching a compiling
action to it.
But the SET-COMPILER syntax could also work with FIND.
Here's a toy implimentation for a Forth with separate headers
: HEADER \ xt ++ create a default header
CREATE , ;
: SET-COMPILER \ xt -- compiling action of latest definition
, IMMEDIATE
DOES> 2@ EXECUTE ;
: FIND FIND DUP IF
1= STATE @ AND IF EXIT THEN ; \ compiling xt
SWAP >BODY @ SWAP \ interpreting xt
THEN ;
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-30 00:13 +0200 |
| Message-ID | <mhrl09$fvm$1@dont-email.me> |
| In reply to | #38720 |
JennyB wrote:
> But the SET-COMPILER syntax could also work with FIND.
Hm, you can implement SET-COMPILER with a deferred COMPILE, like in Gforth
0.7.3:
: set-compiler ( xt -- ) >r lastxt >r
:noname r> ]] dup literal = IF [[ r> compile, ]] ELSE [[
action-of compile, compile, ]] THEN ; [[ is compile, ;
Let's test it:
:noname ." compile" ; : test ." interpret" ; set-compiler ok
test interpret ok
] test [ compile ok
It's not extremely efficient, but you can do it.
--
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]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-30 06:32 +0000 |
| Message-ID | <5541c643.751499497@news.eternal-september.org> |
| In reply to | #38720 |
On Wed, 29 Apr 2015 13:49:07 -0700 (PDT), JennyB <jennybrien@googlemail.com> wrote: >If COMPILE, is interp-compile then it can't be used with words lacking >interpretation semantics. Which leaves the true INTERMEDIATEs such as (, >and dual words, which the Standard doesn't properly address. > >What is the use case for applying interp-compile to either? For making a system easy to use - basically for convenience. A classic is a system that supports interpretation of S". Then you may need to reuse the interpretation behaviour of S" in another parsing word. Now you want/need to be able to compile the interpretation behaviour of S". To make life easy, we have a word [INTERP] <name> (by comparison with the old [COMPILE]) such that [INTERP] compiles the interpretation behaviour of whatever it encounters. >It looks as if a COMPILE, that does comp-execute can enable Forth to finally >get rid of immediacy. SET-COMPILER 'cooks' the xt, attaching a compiling >action to it. > >But the SET-COMPILER syntax could also work with FIND. >Here's a toy implimentation for a Forth with separate headers > > : HEADER \ xt ++ create a default header > CREATE , ; > : SET-COMPILER \ xt -- compiling action of latest definition > , IMMEDIATE > DOES> 2@ EXECUTE ; > > : FIND FIND DUP IF > 1= STATE @ AND IF EXIT THEN ; \ compiling xt > SWAP >BODY @ SWAP \ interpreting xt > THEN ; XTs were designed as single point of reference to a word. The four words > > interp-execute > > comp-execute > > interp-compile, > > comp-compile, preserve that. Because it's Forth we're talking about, we have to accept that words implementing behaviours also have xts, but we should not be fooled into thinking that the xts of these behaviours are part of the original word. 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]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-04-30 05:22 -0700 |
| Message-ID | <ab1a7ce7-1cb3-4031-b868-87d3b891b2b9@googlegroups.com> |
| In reply to | #38723 |
On Thursday, 30 April 2015 07:32:19 UTC+1, Stephen Pelc wrote:
> On Wed, 29 Apr 2015 13:49:07 -0700 (PDT), JennyB
> <jennybrien@googlemail.com> wrote:
>
> >If COMPILE, is interp-compile then it can't be used with words lacking
> >interpretation semantics. Which leaves the true INTERMEDIATEs such as (,
> >and dual words, which the Standard doesn't properly address.
> >
> >What is the use case for applying interp-compile to either?
>
> For making a system easy to use - basically for convenience. A
> classic is a system that supports interpretation of S". Then you
> may need to reuse the interpretation behaviour of S" in another
> parsing word. Now you want/need to be able to compile the
> interpretation behaviour of S". To make life easy, we
> have a word [INTERP] <name> (by comparison with the old [COMPILE])
> such that [INTERP] compiles the interpretation behaviour of whatever
> it encounters.
Yes, of course! If we don't want to add more words to the Standard, that's exactly what [COMPILE] does, isn't it? It appends the xt's behaviour to the definition, regardless of any special compiling action that might be associated with it.
I was wondering if it was ever necessary to do that with an xt on the stack, but in that case LITERAL POSTPONE EXECUTE makes the intention clear. In any case you probably don't want to be compiling a call to a word that performs a compiler action unless you know beforehand what that action is.
>
> >It looks as if a COMPILE, that does comp-execute can enable Forth to finally
> >get rid of immediacy. SET-COMPILER 'cooks' the xt, attaching a compiling
> >action to it.
> >
> >But the SET-COMPILER syntax could also work with FIND.
> >Here's a toy implimentation for a Forth with separate headers
> >
> > : HEADER \ xt ++ create a default header
> > CREATE , ;
> > : SET-COMPILER \ xt -- compiling action of latest definition
> > , IMMEDIATE
> > DOES> 2@ EXECUTE ;
> >
> > : FIND FIND DUP IF
> > 1= STATE @ AND IF EXIT THEN ; \ compiling xt
> > SWAP >BODY @ SWAP \ interpreting xt
> > THEN ;
>
> XTs were designed as single point of reference to a word. The four
> words
> > > interp-execute
> > > comp-execute
> > > interp-compile,
> > > comp-compile,
> preserve that. Because it's Forth we're talking about, we have
> to accept that words implementing behaviours also have xts, but
> we should not be fooled into thinking that the xts of these
> behaviours are part of the original word.
>
I'm beginning to think of them as 'raw' (default compiler behaviour) or 'cooked.' With Anton's scheme you can only get a cooked xt easily using FIND while compiling, and if you let that loose on the stack you have no Standard way to get from there to the original.
Whereas if COMPILE, = comp-execute, then
xt interp-execute EXECUTE
xt comp-execute COMPILE,
xt interp-compile, LITERAL POSTPONE EXECUTE
xt comp-compile, LITERAL POSTPONE COMPILE,
Which places a restriction on writing portable code for systems that don't implement SET-COMPILER is that COMPILE, must only be used on words with default compiling behaviour, and we can treat the whole immediate flag business as obsolescent.
For this to work we need to be able to get an xt for every system and user word, and from that alone to get any associated compiling behaviour.
That simplifies the specification considerably:
All words can be ticked to return an xt that, when EXECUTEs, performs its 'raw' behaviour. FIND returns the same xt.
(At present a Standard system that wishes to do otherwise has to abort or
change the returned xt once the 'wrong' word has been found. It cannot
simply make the word invisible to search in either compile or interpret
state.)
IMMEDIATE sets the xt's compiling behaviour to execute itself,
on legacy systems sets a flag RETURNED by FIND and SEARCH-WORDLIST
so that EXECUTE can be used instead of COMPILE,
SET-COMPILER sets the compiling action of the latest definition
to the given xt. It does not set the immediate flag.
COMPILER, performs the compiling action set by SET-COMPILER or IMMEDIATE
System words with no defined interpretation behaviour may be implemented
using IMMEDIATE, or by setting the specified compilation; therefore in portable code they may not EXECUTEd except in the circumstances given above, in which case the code must also provide a branch to COMPILE, if the legacy immediate flag is not set.
You notice no reference to STATE or interpretation semantics! ;)
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?
Given that, or a word >NAME, then:
: COMP-DUAL 2@ EXECUTE ;
: DUAL \ xt comp-xt ++ ; create a dual definition
CREATE 2, ['] comp-dual SET-COMPILER DOES> @ EXECUTE ;
: CLONE \ xt ++ ; create a synonym for xt
>NAME NAME>COMPILE DUAL ;
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-30 15:27 +0000 |
| Message-ID | <55423861.780713961@news.eternal-september.org> |
| In reply to | #38725 |
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.
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]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web