Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53228 > unrolled thread
| Started by | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| First post | 2016-12-09 09:25 -0800 |
| Last post | 2017-01-07 15:37 +0000 |
| Articles | 20 on this page of 171 — 22 participants |
Back to article view | Back to comp.lang.forth
Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:25 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:30 -0800
Re: Ideal Stack Machine Instruction Set trans <transfire@gmail.com> - 2016-12-09 10:23 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 16:37 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 17:01 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-10 09:07 -0800
Re: Ideal Stack Machine Instruction Set Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-01 21:40 -0500
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 21:06 -1000
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-03 17:22 -0800
Re: Ideal Stack Machine Instruction Set Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-04 10:09 +0100
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-04 11:59 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-04 10:56 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-04 23:58 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-04 20:06 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:12 -0600
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:43 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 16:38 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 19:17 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 18:26 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 01:56 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 16:33 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:02 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 08:04 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:04 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 01:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 22:16 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:44 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 15:19 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:24 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:35 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 22:12 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 22:42 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 00:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 23:35 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-10 23:38 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 10:32 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 12:52 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 13:23 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-11 06:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 14:39 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-11 23:00 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 13:55 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 14:06 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-13 06:29 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:52 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:23 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 15:47 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 15:09 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 20:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 21:21 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 03:45 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-13 02:55 -0600
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:29 +0000
Re: Ideal Stack Machine Instruction Set Bernd Linsel <bl1@gmx.com> - 2017-01-13 16:11 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:26 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:27 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 17:01 +0000
nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 15:35 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) stephen@mpeforth.com - 2017-01-14 13:58 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-14 14:52 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 14:00 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-15 16:51 +0100
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 16:04 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-15 13:47 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:39 +0000
Re: Ideal Stack Machine Instruction Set Matthias Trute <matthias.trute@gmail.com> - 2017-01-12 22:14 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 13:45 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-14 08:51 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-14 09:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 18:02 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-09 23:42 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:36 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 03:55 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 13:40 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 06:40 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:45 +0100
Re: Ideal Stack Machine Instruction Set Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-06 08:19 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:57 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:34 -0800
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-08 17:08 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-02 16:49 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 14:52 -0800
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2016-12-09 14:56 -0800
Re: Ideal Stack Machine Instruction Set Brad Eckert <hwfwguy@gmail.com> - 2016-12-23 13:13 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 06:58 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 09:32 -0600
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:11 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 12:41 -0600
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-06 21:31 -1000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 13:28 -0800
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-07 23:00 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 14:37 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 00:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 18:50 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 14:28 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:34 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 06:27 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-10 00:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 10:01 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-10 13:12 +0100
Re: Ideal Stack Machine Instruction Set stephen@mpeforth.com - 2017-01-08 07:23 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:41 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:41 +0000
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-07 18:56 -1000
TO implementation (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 14:02 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 10:51 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 15:27 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-08 13:36 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 18:20 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 03:56 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 15:15 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 13:34 -0600
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 14:04 -0800
Re: TO implementation stephen@mpeforth.com - 2017-01-15 14:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:42 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:56 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-16 14:25 +0100
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 11:30 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 02:00 +0100
Re: TO implementation albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-17 12:59 +0100
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 14:38 +0100
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 15:47 +0000
Re: TO implementation hughaguilar96@gmail.com - 2017-01-17 10:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 17:02 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 06:00 +0100
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 22:19 -0500
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 08:57 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:26 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:49 -0500
Re: TO implementation minforth@arcor.de - 2017-01-20 00:27 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-20 12:20 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-26 22:42 -0500
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 08:33 +0000
Re: TO implementation minforth@arcor.de - 2017-01-27 03:59 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:40 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 05:55 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 14:46 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 11:03 -0600
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:22 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 03:54 -0600
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 13:51 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:50 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 02:05 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:15 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 18:40 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:55 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:17 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:53 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 17:03 +0100
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-08 17:51 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 18:30 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-08 10:51 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:06 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:31 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:56 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:26 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-06 17:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:37 +0000
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 15:56 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <e2848fbb-50a1-4d9a-b035-af23dae8dd7c@googlegroups.com> |
| In reply to | #54040 |
On Sunday, January 15, 2017 at 3:24:03 PM UTC-7, ste...@mpeforth.com wrote:
> > TO does require parsing at compile-time (it has to be immediate to do this)
> > so it can determine if the word following is actually a VALUE or a local variable
> > --- this needs to be checked at compile-time --- that is the problem with
> > having syntax, that it requires a lot of checking at compile-time to determine
> > if the syntax is legal.
> >
> > VFX makes all the words in the standard that had traditionally been immediate,
> > such as IF etc., non-immediate. This is just bizarre! I call these "fake-immediate"
> > words --- they appear to be non-immediate, but COMPILE, special-cases them
> > internally so they execute at compile-time like immediate words. So, you are still
> > doing parsing at compile-time.
>
> The VFX version of TO neither parses nor is IMMEDIATE. There is no special-casing
> in COMPILE,
This is total bullshit!
Look at this (VFX without the novice-package and its disambiguifiers):
c" to" find .s
DATA STACK
top
-1 FFFF:FFFF
4263508 0041:0E54
ok-2
drop ok-1
constant 'to ok
1234 value vvv ok
: test2 [ 'to execute ] vvv ; ok
5678 test2 ok
vvv . 5678 ok
: test3 [ 'to compile, ] vvv ; ok
3456 test3 ok
vvv . 3456 ok
We see here that EXECUTE works at compile-time on the xt of TO despite the fact that TO is non-immediate and is not supposed to execute at compile-time.
We also see that COMPILE, works at compile-time on the xt of TO despite the fact that you just said that COMPILE, doesn't special-case the xt of TO --- so how does it execute at compile-time then???
The other words that need to be disambiguified are similar:
c" if" find .s
DATA STACK
top
-1 FFFF:FFFF
4234784 0040:9E20
ok-2
drop ok-1
constant 'if ok
: test [ 'if execute ] 5 else 6 then ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : test [ 'if execute ] 5 else 6 then ;
^
: test [ 'if compile, ] 5 else 6 then ; ok
1 test . 5 ok
0 test . 6 ok
The primary difference is that EXECUTE does not work at compile-time, but instead we get an abort with an error-message.
We still see, however, that COMPILE, is special-casing the xt of IF so that it will execute at compile-time despite the fact that it is non-immediate.
Your intimidation doesn't work on me! I just test this stuff and figure it out for myself --- this is how I came to invent the disambiguifiers (actually already invented by both Anton Ertl and Bernd Paysan, although they won't admit that now).
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-16 14:25 +0100 |
| Subject | Re: TO implementation |
| Message-ID | <1mzy5hx.gg7lja1z02hnN%awegel@arcor.de> |
| In reply to | #54044 |
<hughaguilar96@gmail.com> wrote: > > The VFX version of TO neither parses nor is IMMEDIATE. There is no > > special-casing in COMPILE, > > This is total bullshit! > > Look at this (VFX without the novice-package and its disambiguifiers): > > c" to" find .s > DATA STACK > top > -1 FFFF:FFFF > 4263508 0041:0E54 > ok-2 > drop ok-1 > constant 'to ok > 1234 value vvv ok > : test2 [ 'to execute ] vvv ; ok > 5678 test2 ok > vvv . 5678 ok > : test3 [ 'to compile, ] vvv ; ok > 3456 test3 ok > vvv . 3456 ok > > We see here that EXECUTE works at compile-time on the xt of TO despite the > fact that TO is non-immediate and is not supposed to execute at compile-time. As usual you're jumping to conclusions, and -also as usual- you're totally wrong. It would really be nice if you would break your habit of blaming your comprehension problems on others right away. Better try to learn how to think. (Hint: Sometimes it requires to give things a *second* thought!)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-16 11:30 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <40bf4063-18ad-4e12-9b32-e3d5851b94d2@googlegroups.com> |
| In reply to | #54057 |
On Monday, January 16, 2017 at 6:25:18 AM UTC-7, Alexander Wegel wrote:
> <hughaguilar96@gmail.com> wrote:
>
> > > The VFX version of TO neither parses nor is IMMEDIATE. There is no
> > > special-casing in COMPILE,
> >
> > This is total bullshit!
> >
> > Look at this (VFX without the novice-package and its disambiguifiers):
> >
> > c" to" find .s
> > DATA STACK
> > top
> > -1 FFFF:FFFF
> > 4263508 0041:0E54
> > ok-2
> > drop ok-1
> > constant 'to ok
> > 1234 value vvv ok
> > : test2 [ 'to execute ] vvv ; ok
> > 5678 test2 ok
> > vvv . 5678 ok
> > : test3 [ 'to compile, ] vvv ; ok
> > 3456 test3 ok
> > vvv . 3456 ok
> >
> > We see here that EXECUTE works at compile-time on the xt of TO despite the
> > fact that TO is non-immediate and is not supposed to execute at compile-time.
>
> As usual you're jumping to conclusions, and -also as usual- you're
> totally wrong.
Here is yet another example:
c" if" find .s
DATA STACK
top
-1 FFFF:FFFF
4234784 0040:9E20
ok-2
drop ok-1
constant 'if ok
: my-if 'if compile, ; immediate ok
: test4 my-if 5 else 6 then ; ok
1 test4 ok-1
. 5 ok
0 test4 ok-1
. 6 ok
ok
: test5 my-if 5 repeat ;
Err# -57005 ERR: Windows exception
-> : test5 my-if 5 repeat ;
^
: test6 my-if 5 ;
Err# -22 ERR: Control structure mismatch.
-> : test6 my-if 5 ;
^
Here we see COMPILE, being given the xt for IF which is supposedly non-immediate, yet it executes at compile-time like an immediate word. It compiles code for IF and it aborts at compile-time with an error-message when the control-structures don't match.
So, COMPILE, is obviously special-casing the xt of IF --- it is not compiling it like the xt of a typical non-immediate word --- it is executing it.
VFX is incompatible with the other ANS-Forth compilers. My disambiguifiers fix this though --- given the disambiguifiers, all of the ANS-Forth compilers become compatible, at least in regards to how FIND works, and programs can be written that will run unmodified on any of them.
I seem to be the only person who cares about portability of ANS-Forth programs --- the vendors, such as Stephen Pelc, are actively striving to prevent portability so they can trap their customers in vendor lock-in --- this is why a standard that has the committee packed with corporate employees is destined to fail at supporting portability of programs, which is the purpose of having a standard.
> It would really be nice if you would break your habit of blaming your
> comprehension problems on others right away. Better try to learn how to
> think. (Hint: Sometimes it requires to give things a *second* thought!)
It would really be nice if you would shut the hell up --- brown-noser! --- you disgust the world, and you make the entire Forth community look stupid.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-17 02:00 +0100 |
| Subject | Re: TO implementation |
| Message-ID | <1mzyzeu.vqy54w1yw68naN%awegel@arcor.de> |
| In reply to | #54061 |
<hughaguilar96@gmail.com> wrote: > On Monday, January 16, 2017 at 6:25:18 AM UTC-7, Alexander Wegel wrote: > > <hughaguilar96@gmail.com> wrote: > > > > > On Sunday, January 15, 2017 at 3:24:03 PM UTC-7, ste...@mpeforth.com > > > wrote: > > > > The VFX version of TO neither parses nor is IMMEDIATE. There is no > > > > special-casing in COMPILE, > > > > > > This is total bullshit! > > > > > > Look at this (VFX without the novice-package and its disambiguifiers): > > > > > > c" to" find .s > > > DATA STACK > > > top > > > -1 FFFF:FFFF > > > 4263508 0041:0E54 > > > ok-2 > > > drop ok-1 > > > constant 'to ok > > > 1234 value vvv ok > > > : test2 [ 'to execute ] vvv ; ok > > > 5678 test2 ok > > > vvv . 5678 ok > > > > > > : test3 [ 'to compile, ] vvv ; ok > > > 3456 test3 ok > > > vvv . 3456 ok The fact that any of the tests above work should be prove enough that TO does *not* parse. (This violates the 1994 ansi standard which explicitly states that TO parses, but that wasn't the question.) Actually it has no idea what follows it, but leaves a message (-selector) for a subsequent value(-object). It's only at the end of the definition that a dangling TO (without a value following it) gets detected: : t to 1 2 3 ; Err# -402 ERR: Unconsumed operator at end of definition > > > We see here that EXECUTE works at compile-time on the xt of TO despite the > > > fact that TO is non-immediate and is not supposed to execute at > > > compile-time. ..And *it* does not execute at compile time. A word being immediate means that *the same word* gets executed when compiling (because that's all that can be expressed with immediacy). This is one reason why ans-forth was moving away from the immediacy concept (which is just a simplistic implementation scheme for smart compilers) towards explicitly specifying (standard and special) compilation semantics of words, leaving more freedom for implementing advanced compilers. So: Yes, it's not just the "standard compiler" acting when TO gets compiled, but no: TO is not immediate. Leaves to be said that there really is no special-casing in compile, which would be a rather inflexible approach anyway. Conclusion: what Steven wrote is not "total bullshit".
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-17 12:59 +0100 |
| Subject | Re: TO implementation |
| Message-ID | <o5l0uu$1nk$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54062 |
In article <1mzyzeu.vqy54w1yw68naN%awegel@arcor.de>, Alexander Wegel <awegel@arcor.de> wrote: <SNIP> > >A word being immediate means that *the same word* gets executed when >compiling (because that's all that can be expressed with immediacy). > >This is one reason why ans-forth was moving away from the immediacy >concept (which is just a simplistic implementation scheme for smart >compilers) towards explicitly specifying (standard and special) >compilation semantics of words, leaving more freedom for implementing >advanced compilers. The advanced compilers only differ from the immediacy compilers, that words marked "compiling" (was IMMEDIATE) are not supposed to be run in interpret mode (you can get rid of STATE, but you can't get rid of interpret mode). Likewise words marked "interpreting" are not supposed to run in compilation mode, but if they can be compiled in compilation mode:"their interpretation behaviour is added to the current definition". But you were never supposed to do different! Trespassing was always illegal! In other words nothing changes, except that tricks using STATE are explicitly forbidden. In Forth to forbid something makes no sense, because people do it anyway. An implementor may feel the need to use something like STATE internally. Guess what? In Forth everybody is an implementor. 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]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-17 14:38 +0100 |
| Subject | Re: TO implementation |
| Message-ID | <1mzzzpl.133stk61ebu1yjN%awegel@arcor.de> |
| In reply to | #54074 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <1mzyzeu.vqy54w1yw68naN%awegel@arcor.de>, > Alexander Wegel <awegel@arcor.de> wrote: > > <SNIP> > > > >A word being immediate means that *the same word* gets executed when > >compiling (because that's all that can be expressed with immediacy). > > > >This is one reason why ans-forth was moving away from the immediacy > >concept (which is just a simplistic implementation scheme for smart > >compilers) towards explicitly specifying (standard and special) > >compilation semantics of words, leaving more freedom for implementing > >advanced compilers. > > The advanced compilers only differ from the immediacy compilers, > that words marked "compiling" (was IMMEDIATE) are not supposed to > be run in interpret mode (you can get rid of STATE, but you can't > get rid of interpret mode). Likewise words marked "interpreting" > are not supposed to run in compilation mode, but if they can be > compiled in compilation mode:"their interpretation behaviour is added > to the current definition". In vfx, a word can bring its own compiler. This is different from simply restricting a word to interpret or compile time. What do you mean by "marked compiling/interpreting"? There are words without defined interpretation or compilation semantics - do you mean that? (Anyway, the reason why i wrote my post is merely to counter Hughs assertion that what Stephen wrote was "total bullshit", which is simply not true.)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-17 15:47 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan17.164742@mips.complang.tuwien.ac.at> |
| In reply to | #54074 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <1mzyzeu.vqy54w1yw68naN%awegel@arcor.de>,
>Alexander Wegel <awegel@arcor.de> wrote:
>
><SNIP>
>>
>>A word being immediate means that *the same word* gets executed when
>>compiling (because that's all that can be expressed with immediacy).
>>
>>This is one reason why ans-forth was moving away from the immediacy
>>concept (which is just a simplistic implementation scheme for smart
>>compilers) towards explicitly specifying (standard and special)
>>compilation semantics of words, leaving more freedom for implementing
>>advanced compilers.
The main reason for specifying compilation semantics probably was
cmForth, which used the compiler vocabulary for compile-time execution
words like IF, (if present) for words with unusual combinations of
interpretation and compilation semantics (in Forth-94 S" and TO are in
this category, not sure which words of this kind cmForth has), and
also for native-code generation (with a bit of optimization).
The reason for not specifying whether some words are immediate or not
probably also has quite a bit to do with cmForth (FIND on a
cmForth-like system would report all the native-code generating words
as immediate), but there were also other reasons: Some systems had an
immediate LEAVE, some a non-immediate one.
Forth-94 also introduced COMPILE, to allow standard programs to
compile on non-ITC systems (ITC systems just used "," to compile
words).
At the time, cmForth was deemed advanced, and I guess people expected
other systems to use similar compilation techniques. Looking back, no
standard system has picked up this approach (probably because it does
not combine well with the search order). Instead, looking at Gforth,
SwiftForth, and VFX, they all have built the native-code generation
and optimization into COMPILE, (which is the best place for that).
VFX also tries to do non-default compilation semantics through
COMPILE, (which is the wrong place for that). So in contrast to the
cmForth, where FIND would have reported normal words as immediate,
VFX's FIND reports words with non-default compilation semantics as
non-immediate in order to get the text interpreter to COMPILE, the
resulting xt, which then performs the compilation semantics of this
word. This approach works in text-interpreters, and but for some
other uses of COMPILE, (such as early binding in OO packages) it
produces the wrong results; fortunately, one normally does not use the
xt of S" or TO as a method in an OO package.
>The advanced compilers only differ from the immediacy compilers,
>that words marked "compiling" (was IMMEDIATE) are not supposed to
>be run in interpret mode (you can get rid of STATE, but you can't
>get rid of interpret mode).
Not sure what you mean with "immediacy compilers". The thing about
'marked "compiling"' sounds like it is coming from Forth-83 (or
earlier).
Some compilers give an error or warning when text-interpreting (in
interpretation state) a word without interpretation semantics, some do
some more-or-less clever thing, and some do what they would do when
text-interpreting the word in compilation state. That seems to be
pretty independent of whether the compiler uses native-code generation
and how sophisticated that code generation is.
>Likewise words marked "interpreting"
>are not supposed to run in compilation mode, but if they can be
>compiled in compilation mode:"their interpretation behaviour is added
>to the current definition".
There re no words without compilation semantics in Forth-94 or
Forth-2012.
>In other words nothing changes, except that tricks using STATE
>are explicitly forbidden.
I have no idea what you are referring to. Can you give an example?
> In Forth to forbid something makes
>no sense, because people do it anyway.
Yes, there is certainly some truth in that observation, and lots of
examples come to my mind.
Wrt. the problems of STATE-smartness, I gave examples where that
produces the wrong result, and a frequent reaction was "Then don't do
that." But of course, that does not prevent people from falling into
the trap unawares.
Wrt the discussion in the subject, a TO implementation that sometimes
behaves like a flag-setting implementation and sometimes deviates from
that behaviour due to "optimization", and just forbids the usages
where the behaviour is different is not a good idea.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-17 10:24 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <0e552092-a262-4288-acc6-313be9e01b64@googlegroups.com> |
| In reply to | #54079 |
On Tuesday, January 17, 2017 at 10:03:52 AM UTC-7, Anton Ertl wrote: > The main reason for specifying compilation semantics probably was > cmForth, which used the compiler vocabulary for compile-time execution > words like IF, (if present) for words with unusual combinations of > interpretation and compilation semantics (in Forth-94 S" and TO are in > this category, not sure which words of this kind cmForth has), and > also for native-code generation (with a bit of optimization). I have never seen any indication that Charles Moore wanted cmForth to be ANS-Forth compliant --- he was ignoring ANS-Forth --- this was just wishful thinking on Elizabeth Rather's part, that he could be brought into the fold. > The reason for not specifying whether some words are immediate or not > probably also has quite a bit to do with cmForth (FIND on a > cmForth-like system would report all the native-code generating words > as immediate), but there were also other reasons: Some systems had an > immediate LEAVE, some a non-immediate one. The words in the standard should have been defined as immediate or non-immediate so as to avoid ambiguity --- a SwiftForth programmer assumes they are immediate, and a VFX programmer assumes they are non-immediate, and their programs aren't portable. LEAVE should have been defined as being immediate. On the very few systems in which it is non-immediate, it could be written like this: : <leave> ... ; : leave ['] <leave> compile, ; immediate It would be a good idea to smudge <LEAVE> afterward, but ANS-Forth failed to provide a way to smudge particular words. > Forth-94 also introduced COMPILE, to allow standard programs to > compile on non-ITC systems (ITC systems just used "," to compile > words). COMPILE, was a good idea --- the use of , in Forth-83 was a major mistake --- note however, that Forth-83 came out one year after Charles Moore was kicked out of Forth Inc., so Charles Moore wasn't to blame for this mistake. > At the time, cmForth was deemed advanced, and I guess people expected > other systems to use similar compilation techniques. Looking back, no > standard system has picked up this approach (probably because it does > not combine well with the search order). Instead, looking at Gforth, > SwiftForth, and VFX, they all have built the native-code generation > and optimization into COMPILE, (which is the best place for that). I don't do optimization in COMPILE, --- my COMPILE, just builds an intermediate data-structure representing the code, and then at ; this data-structure is optimized and converted into executable code --- COMPILE, is short and simple. > VFX also tries to do non-default compilation semantics through > COMPILE, (which is the wrong place for that). So in contrast to the > cmForth, where FIND would have reported normal words as immediate, > VFX's FIND reports words with non-default compilation semantics as > non-immediate in order to get the text interpreter to COMPILE, the > resulting xt, which then performs the compilation semantics of this > word. This approach works in text-interpreters, and but for some > other uses of COMPILE, (such as early binding in OO packages) it > produces the wrong results; fortunately, one normally does not use the > xt of S" or TO as a method in an OO package. The standard is supposed to standardize behavior, not implementation --- but here we have implementation exposed to the end user.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-16 17:02 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <ed863142-332b-4837-abd9-2213d4f43699@googlegroups.com> |
| In reply to | #54061 |
On Monday, January 16, 2017 at 12:31:00 PM UTC-7, hughag...@gmail.com wrote:
> c" if" find .s
> DATA STACK
> top
> -1 FFFF:FFFF
> 4234784 0040:9E20
> ok-2
> drop ok-1
> constant 'if ok
>
> : my-if 'if compile, ; immediate ok
> : test4 my-if 5 else 6 then ; ok
> 1 test4 ok-1
> . 5 ok
> 0 test4 ok-1
> . 6 ok
Above it was shown that COMPILE, works on the xt of IF --- here we try EXECUTE on it:
: mif 'if execute ; immediate ok
: test7 mif 5 else 6 then ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : test7 mif 5 else 6 then ;
^
This does not work under VFX. But here is the same thing in SwiftForth:
c" if" find .s
45823 1 <-Top ok
drop ok
constant 'if ok
: mif 'if execute ; immediate ok
: test7 mif 5 else 6 then ; ok
1 test7 . 5 ok
0 test7 . 6 ok
That works in SwiftForth. But this does not work in SwiftForth:
: my-if 'if compile, ; immediate ok
: test8 my-if 5 else 6 then ; Control structure mismatch
VFX and SwiftForth each compile and execute code that does not compile and execute under the other --- they are incompatible.
The user is required to manually test whether words are immediate or non-immediate --- that is what my disambiguifiers do --- they rely on POSTPONE that internally tests whether words are immediate or non-immediate.
Without the disambiguifiers, the programmer will write code that is compiler-specific --- with the disambiguifiers, the programmer will write code that is portable between compilers --- the purpose of a standard is to support portable code, and this is only possible in ANS-Forth with disambiguifiers.
Disambiguifiers are the heart and soul of ANS-Forth programming! Nobody can claim to know anything about ANS-Forth unless they have disambiguifiers --- the reason why Stephen Pelc refuses to accept the disambiguifiers is either because he doesn't know anything about ANS-Forth, or because he is purposely striving to trap his customers in vendor lock-in (the latter being the more likely) --- instead, Stephen Pelc relies on intimidation (telling me: "Do try to keep up.") and on giving his sycophants big internet-expert status in exchange for attacking me (Alex Wegel, Alex McDonald, Julien Fondren, Andrew Haley, John Passaniti, etc.).
ANS-Forth is a cult --- ANS-Forth is founded entirely upon intimidation of Forth programmers --- ANS-Forth has no technical merit whatsoever; it is just a toy language written by an idiot salesperson as a marketing gimmick.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-17 06:00 +0100 |
| Subject | Re: TO implementation |
| Message-ID | <1mzz7mo.1s7g20pvzto6N%awegel@arcor.de> |
| In reply to | #54063 |
<hughaguilar96@gmail.com> wrote: > On Monday, January 16, 2017 at 12:31:00 PM UTC-7, hughag...@gmail.com wrote: > > c" if" find .s > > DATA STACK > > top > > -1 FFFF:FFFF > > 4234784 0040:9E20 > > ok-2 > > drop ok-1 > > constant 'if ok > > > > : my-if 'if compile, ; immediate ok > > : test4 my-if 5 else 6 then ; ok > > 1 test4 ok-1 > > . 5 ok > > 0 test4 ok-1 > > . 6 ok > > Above it was shown that COMPILE, works on the xt of IF --- here we try EXECUTE > on it: > > : mif 'if execute ; immediate ok > : test7 mif 5 else 6 then ; > Err# -14 ERR: Attempt to interpret a compile only definition. > -> : test7 mif 5 else 6 then ; > ^ > > This does not work under VFX. But here is the same thing in SwiftForth: > > c" if" find .s > 45823 1 <-Top ok > drop ok > constant 'if ok > : mif 'if execute ; immediate ok > : test7 mif 5 else 6 then ; ok > 1 test7 . 5 ok > 0 test7 . 6 ok > > That works in SwiftForth. But this does not work in SwiftForth: > > : my-if 'if compile, ; immediate ok > : test8 my-if 5 else 6 then ; Control structure mismatch > > VFX and SwiftForth each compile and execute code that does not compile > and execute under the other --- they are incompatible. LOL. I would rather conclude that you know how to throw away information (hint: the immediacy flag). Here's a version that doesn't, and for that reason, works better: : asfound, 0< if compile, else execute then ; c" if" find 2constant 'if \ don't throw away immediacy info : ya-if 'if asfound, ; immediate : test9 ya-if 5 else 6 then ; 1 test9 . 0 test9 . > The user is required to manually test whether words are immediate or > non-immediate Manually - not really. But simply ignoring it won't always cut it either. > --- that is what my disambiguifiers do --- they rely on > POSTPONE that internally tests whether words are immediate or non-immediate. Well, that's why "the user" normaly relies on postpone too. > Without the disambiguifiers, the programmer will write code that is > compiler-specific > --- with the disambiguifiers, the programmer will write code that is > portable between compilers --- the purpose of a standard is to support > portable code, and this is only possible in ANS-Forth with > disambiguifiers. BS > Disambiguifiers are the heart and soul of ANS-Forth programming! > Nobody can claim to know anything about ANS-Forth unless they have > disambiguifiers --- Where's the smileys? > [..] > and on giving his sycophants big internet-expert status in exchange > for attacking me (Alex Wegel, I guess this fantasy makes it easier for you to stop thinking about why someone really attacked you (or interfered with one of *your* attacks).
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-15 22:19 -0500 |
| Subject | Re: TO implementation |
| Message-ID | <20170115221901.6a57e261@_> |
| In reply to | #54030 |
On Sun, 15 Jan 2017 13:34:47 -0600 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > STATE sucks. So do all mechanisms which cause words to behave > differently depending on whether they are called by the interpeter or > the compiler. I think I have been fairly consistent about this. Yet, STATE is CORE and required for certain words: http://forth-standard.org/standard/core/STATE STATE seems to be required for the recently discussed SYNONYM too, at least in the online version of the standard which provides an implementation of SYNONYM using STATE: http://forth-standard.org/standard/tools/SYNONYM Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-16 08:57 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <3-adnU4X6vqiQuHFnZ2dnUU7-fednZ2d@supernews.com> |
| In reply to | #54052 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > On Sun, 15 Jan 2017 13:34:47 -0600 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> STATE sucks. So do all mechanisms which cause words to behave >> differently depending on whether they are called by the interpeter or >> the compiler. I think I have been fairly consistent about this. > > Yet, STATE is CORE and required for certain words: Yes, of course. That's what sucks the most. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-19 11:26 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan19.122645@mips.complang.tuwien.ac.at> |
| In reply to | #54052 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>Yet, STATE is CORE and required for certain words:
>http://forth-standard.org/standard/core/STATE
For which words is it required?
>STATE seems to be required for the recently discussed SYNONYM too, at
>least in the online version of the standard which provides an
>implementation of SYNONYM using STATE:
>http://forth-standard.org/standard/tools/SYNONYM
Whatever implementations of standard words do internally is up to the
system. The implementation you refer to comes with a bunch of caveats:
|The implementation below is imperfect and specific to VFX Forth
So, it may work for VFX or it may not work for some cases even there,
but it does not say anything about the necessity of STATE for
implementing SYNONYM. E.g., here is the current implementation of
SYNONYM on Gforth:
: Synonym ( "name" "oldname" -- ) \ Forth200x
Header ['] on vtcopy
parse-name find-name dup A,
dup compile-only? IF compile-only THEN name>int lastcfa !
['] s>int set->int ['] s>comp set->comp ['] s-to set-to reveal ;
Look, Rod, no STATE.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-19 20:49 -0500 |
| Subject | Re: TO implementation |
| Message-ID | <20170119204949.1f41c0ee@_> |
| In reply to | #54159 |
On Thu, 19 Jan 2017 11:26:45 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > So, it may work for VFX or it may not work for some cases even there, > but it does not say anything about the necessity of STATE for > implementing SYNONYM. E.g., here is the current implementation of > SYNONYM on Gforth: > > : Synonym ( "name" "oldname" -- ) \ Forth200x > Header ['] on vtcopy > parse-name find-name dup A, > dup compile-only? IF compile-only THEN name>int lastcfa ! > ['] s>int set->int ['] s>comp set->comp ['] s-to set-to reveal ; > > Look, Rod, no STATE. > That is clearly free of explicit use of STATE, but not necessarily independent of indirect use of STATE via another Forth word executed from SYNONYM, e.g., perhaps via set->comp. STATE is core and must be set during compilation. Is STATE being set during compilation here? STATE is core and should be. Gforth would need to set STATE somewhere during execution of SYNONYM, either directly or indirectly, to be in compliance. If STATE is being set for compilation, then SYNONYM is not independent of STATE and usage of STATE is just being hidden by behind another Forth word. If I display STATE after each and every word in SYNONYM, will I see the value of STATE change? If not, does STATE's value change at some point during the execution of SYNONYM? If not, why not? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-20 00:27 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <09fcb1a6-6d5b-4d0d-b22b-e2498229966d@googlegroups.com> |
| In reply to | #54192 |
Am Freitag, 20. Januar 2017 02:49:05 UTC+1 schrieb Rod Pemberton: > On Thu, 19 Jan 2017 11:26:45 GMT > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > > > So, it may work for VFX or it may not work for some cases even there, > > but it does not say anything about the necessity of STATE for > > implementing SYNONYM. E.g., here is the current implementation of > > SYNONYM on Gforth: > > > > : Synonym ( "name" "oldname" -- ) \ Forth200x > > Header ['] on vtcopy > > parse-name find-name dup A, > > dup compile-only? IF compile-only THEN name>int lastcfa ! > > ['] s>int set->int ['] s>comp set->comp ['] s-to set-to reveal ; > > > > Look, Rod, no STATE. > > > > That is clearly free of explicit use of STATE, but not necessarily > independent of indirect use of STATE via another Forth word executed > from SYNONYM, e.g., perhaps via set->comp. STATE is core and must be > set during compilation. Is STATE being set during compilation here? > STATE is core and should be. Gforth would need to set STATE somewhere > during execution of SYNONYM, either directly or indirectly, to be in > compliance. If STATE is being set for compilation, then SYNONYM is not > independent of STATE and usage of STATE is just being hidden by behind > another Forth word. If I display STATE after each and every word in > SYNONYM, will I see the value of STATE change? If not, does STATE's > value change at some point during the execution of SYNONYM? If not, > why not? > > > Rod Pemberton Phew ... and rolling eyes. KISS, that is not. ;-) When you have dual-xt headers SYNONYM is just a header copy with another name.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-20 12:20 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan20.132002@mips.complang.tuwien.ac.at> |
| In reply to | #54195 |
minforth@arcor.de writes:
>Am Freitag, 20. Januar 2017 02:49:05 UTC+1 schrieb Rod Pemberton:
>> On Thu, 19 Jan 2017 11:26:45 GMT
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>
>> > So, it may work for VFX or it may not work for some cases even there,
>> > but it does not say anything about the necessity of STATE for
>> > implementing SYNONYM. E.g., here is the current implementation of
>> > SYNONYM on Gforth:
>> >
>> > : Synonym ( "name" "oldname" -- ) \ Forth200x
>> > Header ['] on vtcopy
>> > parse-name find-name dup A,
>> > dup compile-only? IF compile-only THEN name>int lastcfa !
>> > ['] s>int set->int ['] s>comp set->comp ['] s-to set-to reveal ;
>> >
>> > Look, Rod, no STATE.
>> >
>>
>> That is clearly free of explicit use of STATE, but not necessarily
>> independent of indirect use of STATE via another Forth word executed
>> from SYNONYM, e.g., perhaps via set->comp. STATE is core and must be
>> set during compilation. Is STATE being set during compilation here?
>> STATE is core and should be. Gforth would need to set STATE somewhere
>> during execution of SYNONYM, either directly or indirectly, to be in
>> compliance. If STATE is being set for compilation, then SYNONYM is not
>> independent of STATE and usage of STATE is just being hidden by behind
>> another Forth word. If I display STATE after each and every word in
>> SYNONYM, will I see the value of STATE change? If not, does STATE's
>> value change at some point during the execution of SYNONYM? If not,
>> why not?
>>
>>
>> Rod Pemberton
>
>Phew ... and rolling eyes. KISS, that is not. ;-)
Right, the author of this code has a penchant for (too?) clever
optimizations.
>When you have dual-xt headers SYNONYM is just a header copy with another name.
Yes, that would be a straightforward way, given an appropriate header
implementation. But one goal of the header organization that gave us
the code above is to have nt=xt, at least for ordinary words. So with
this header organization, if you just copy all the fields, you get a
word with another copy of the body, which is not so great for words
with state in the body, such as CREATEd words, VALUEs, VARIABLEs, or
DEFERred words.
So what happens in the SYNONYM implementation above:
Header
First an header stub for newname is created
['] on vtcopy
The header implementation is inspired by prototype-based
object-oriented systems, so this code sets up to behave like a colon
definition by using ON (a colon definition) as a prototype.
parse-name find-name dup A,
This gets the nt of oldname and stores it in the place where the code
field would be in a normal word.
dup compile-only? IF compile-only THEN name>int lastcfa !
This copies the compile-only flag from oldname to newname, and sets
lastcfa to point to the interpretation semantics xt of oldname.
['] s>int set->int
This sets the behaviour of NAME>INTERPRET to be S>INT, and S>INT
fetches the contents of the code field (i.e., the nt of oldname) and
then performs NAME>INTERPRET for oldname.
['] s>comp set->comp
Likewise for NAME>COMPILE.
['] s-to set-to
This sets the TO behaviour to access the nt of oldname and then
perform the to behaviour of oldname.
reveal ;
This makes the newname header visible.
Concerning Rod Pemberton's claims about STATE: No, none of these words
calls STATE; that would serve no useful purpose, and if it called
STATE, that would likely be a bug.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-26 22:42 -0500 |
| Subject | Re: TO implementation |
| Message-ID | <20170126224235.4455c904@_> |
| In reply to | #54201 |
On Fri, 20 Jan 2017 12:20:02 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > No, none of these words calls STATE; that would serve no useful > purpose, This is how I see it. Is STATE required by ANS to be implemented? Yes. Is STATE required by ANS to be set during compilation? Yes. Does the example you posted compile a word? Yes. Does the example you posted use and set STATE as required? No. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-27 08:33 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan27.093346@mips.complang.tuwien.ac.at> |
| In reply to | #54448 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>On Fri, 20 Jan 2017 12:20:02 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> No, none of these words calls STATE; that would serve no useful
>> purpose,
...
>Is STATE required by ANS to be set during compilation? Yes.
No.
>Does the example you posted use and set STATE as required? No.
There is no such requirement. What the standard says is that : and ]
set STATE to compilation state (and ;, ;CODE and [ set it to
interpretation state), and that the text interpreter uses STATE to
select between the interpretation and compilation semantics of the
words it parses.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-27 03:59 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <04a07563-9cf2-482c-819c-1480c0dda79b@googlegroups.com> |
| In reply to | #54201 |
Am Freitag, 20. Januar 2017 14:08:08 UTC+1 schrieb Anton Ertl: > minforth@arcor.de writes: > >Am Freitag, 20. Januar 2017 02:49:05 UTC+1 schrieb Rod Pemberton: > >> On Thu, 19 Jan 2017 11:26:45 GMT > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> > >> > So, it may work for VFX or it may not work for some cases even there, > >> > but it does not say anything about the necessity of STATE for > >> > implementing SYNONYM. E.g., here is the current implementation of > >> > SYNONYM on Gforth: > >> > > >> > : Synonym ( "name" "oldname" -- ) \ Forth200x > >> > Header ['] on vtcopy > >> > parse-name find-name dup A, > >> > dup compile-only? IF compile-only THEN name>int lastcfa ! > >> > ['] s>int set->int ['] s>comp set->comp ['] s-to set-to reveal ; > >> > > >> > Look, Rod, no STATE. > >> > > >> > >> That is clearly free of explicit use of STATE, but not necessarily > >> independent of indirect use of STATE via another Forth word executed > >> from SYNONYM, e.g., perhaps via set->comp. STATE is core and must be > >> set during compilation. Is STATE being set during compilation here? > >> STATE is core and should be. Gforth would need to set STATE somewhere > >> during execution of SYNONYM, either directly or indirectly, to be in > >> compliance. If STATE is being set for compilation, then SYNONYM is not > >> independent of STATE and usage of STATE is just being hidden by behind > >> another Forth word. If I display STATE after each and every word in > >> SYNONYM, will I see the value of STATE change? If not, does STATE's > >> value change at some point during the execution of SYNONYM? If not, > >> why not? > >> > >> > >> Rod Pemberton > > > >Phew ... and rolling eyes. KISS, that is not. ;-) > > Right, the author of this code has a penchant for (too?) clever > optimizations. > > >When you have dual-xt headers SYNONYM is just a header copy with another name. > > Yes, that would be a straightforward way, given an appropriate header > implementation. But one goal of the header organization that gave us > the code above is to have nt=xt, at least for ordinary words. So with > this header organization, if you just copy all the fields, you get a > word with another copy of the body, which is not so great for words > with state in the body, such as CREATEd words, VALUEs, VARIABLEs, or > DEFERred words. > > So what happens in the SYNONYM implementation above: > > Header > > First an header stub for newname is created > > ['] on vtcopy > > The header implementation is inspired by prototype-based > object-oriented systems, so this code sets up to behave like a colon > definition by using ON (a colon definition) as a prototype. > > parse-name find-name dup A, > > This gets the nt of oldname and stores it in the place where the code > field would be in a normal word. > > dup compile-only? IF compile-only THEN name>int lastcfa ! > > This copies the compile-only flag from oldname to newname, and sets > lastcfa to point to the interpretation semantics xt of oldname. > > ['] s>int set->int > > This sets the behaviour of NAME>INTERPRET to be S>INT, and S>INT > fetches the contents of the code field (i.e., the nt of oldname) and > then performs NAME>INTERPRET for oldname. > > ['] s>comp set->comp > > Likewise for NAME>COMPILE. > > ['] s-to set-to > > This sets the TO behaviour to access the nt of oldname and then > perform the to behaviour of oldname. > > reveal ; > > This makes the newname header visible. > > Concerning Rod Pemberton's claims about STATE: No, none of these words > calls STATE; that would serve no useful purpose, and if it called > STATE, that would likely be a bug. > > - 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 2016: http://www.euroforth.org/ef16/ Thanks Anton, I appreciate your taking time for the explanation. Indeed copying headers requires clear separation of headers from bodies. For embedded programming headers and code bodies might even reside in different machines. Therefore for all words using some introspection or late binding, some kind of back-reference from bodies to their headers would be required which is ugly. I am guessing that is what might the proposed word FIND-NAME (returning an nt of the separated dictionary adress space) become a necessity, as FIND returns only an xt (in the umbilical target's address space). BR Andreas
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-19 11:40 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan19.124055@mips.complang.tuwien.ac.at> |
| In reply to | #54030 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> So what's the point of your implementation approach?
>
>The assertion was that TO requires parsing. My counter-assertion is
>that it doesn't. That is all. It doesn't require parsing for basic
>functionality, and it doesn't require parsing for performance.
The question is if the cure is not worse than the disease. For
performance it certainly looks to me like it is.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web