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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-11 10:32 +0000 |
| Message-ID | <o551h0$6g5$1@dont-email.me> |
| In reply to | #53942 |
On 1/11/2017 07:38, minforth@arcor.de wrote: > Am Mittwoch, 11. Januar 2017 00:35:04 UTC+1 schrieb Alex: >> On 1/10/2017 23:23, Albert van der Horst wrote: >>> In article <o53ntd$r6m$1@dont-email.me>, Alex <alex@rivadpm.com> >>> wrote: >>>> On 1/10/2017 21:12, Albert van der Horst wrote: >>>>> In article <o52u7v$otl$1@dont-email.me>, Alex >>>>> <alex@rivadpm.com> wrote: >>>>>> On 1/10/2017 14:19, Albert van der Horst wrote: >>>>> <SNIP> >>>>>> That's fine. Those that have a name have an NT. No special >>>>>> magic is claimed for naming XTs with no names. >>>>> >>>>> No. We can have NT's with two XT's and no name. >>>>> >>>>>> Alex >>>> >>>> You'll have to provide an example, since an NT is (currently) >>>> only obtainable by the Forth2012 TRAVERSE-WORDLIST, which can >>>> only return NTs where there is a name in a wordlist; and the >>>> yet to be codifed FIND-NAME, which requires the name as input. >>> >>> You're talking about portable use of NT's, apparently. An >>> all-pervasive concept can't be contained. >>> >> >> So it's not possible to standardise your version of NTs? That's not >> helpful. >> >>>> -- Alex >> >> >> -- Alex > > That is too harsh IMO. A standard reference implementation might be > helpful for understanding, but it must not be enforced. I'm not suggesting it be enforced, I'm suggesting it be explained (which is what standards do). > > My take on this is that an NT is a synonym for the dictionary entry > (could be header location, or pointer to name string, or a hash value > if you don't store name strings there). So there are many ways to > Rome. > Which is fine, since no-one is suggesting (least of all me) that the NT has a specific implementation. But how it might include Albert's name token for something with no name is a little mystifying, and I've asked for but not got a clarifying example. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-11 12:52 +0100 |
| Message-ID | <o5569q$7og$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53944 |
In article <o551h0$6g5$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/11/2017 07:38, minforth@arcor.de wrote: <SNIP> >Which is fine, since no-one is suggesting (least of all me) that the NT >has a specific implementation. But how it might include Albert's name >token for something with no name is a little mystifying, and I've asked >for but not got a clarifying example. In ciforth there are dummy dea's that serve as a starting point for wordlist linked list. A more convincing example where dea's are decoupled from names is the configurationfile for my com-4e5 configuration file. : ~OP HELP ; <ESC> LATEST >NFA @ CELL+ C! \ F1 : ~OQ next-speed-talk sbc set-port-defaults " " send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F3 : ~OS close-connection BYE ; : ~[15~ "HEX" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F5 : ~[17~ "DECIMAL" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F6 : ~[18~ "OK HEX U. DECIMAL" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F7 : ~[19~ ".S" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F8 : ~[20~ "1 2 3 " send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F9 The names of the definitions are patched such that the inner interpreter directly understands function keys (F1 .. F9). (Headers in ciforth are uniform CDFLS code/data/flag/link/name/source) > >-- >Alex -- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-11 13:23 +0000 |
| Message-ID | <o55bih$as7$1@dont-email.me> |
| In reply to | #53945 |
On 1/11/2017 11:52, Albert van der Horst wrote: > In article <o551h0$6g5$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 1/11/2017 07:38, minforth@arcor.de wrote: > <SNIP> >> Which is fine, since no-one is suggesting (least of all me) that the NT >> has a specific implementation. But how it might include Albert's name >> token for something with no name is a little mystifying, and I've asked >> for but not got a clarifying example. > > In ciforth there are dummy dea's that serve as a starting point for > wordlist linked list. > A more convincing example where dea's are decoupled from names is > the configurationfile for my com-4e5 configuration file. > > : ~OP HELP ; <ESC> LATEST >NFA @ CELL+ C! \ F1 > : ~OQ next-speed-talk sbc set-port-defaults " " send-one-line ; > <ESC> LATEST >NFA @ CELL+ C! \ F3 > : ~OS close-connection BYE ; > : ~[15~ "HEX" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F5 > : ~[17~ "DECIMAL" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F6 > : ~[18~ "OK HEX U. DECIMAL" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F7 > : ~[19~ ".S" send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F8 > : ~[20~ "1 2 3 " send-one-line ; <ESC> LATEST >NFA @ CELL+ C! \ F9 > > The names of the definitions are patched such that the inner interpreter > directly understands function keys (F1 .. F9). > So they have names, it's just that they're modifed & non-printable names. I'm failing to see your point here. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-11 06:08 -0800 |
| Message-ID | <36cb660d-5224-4a0a-8be0-df6aefe82847@googlegroups.com> |
| In reply to | #53944 |
Am Mittwoch, 11. Januar 2017 11:32:32 UTC+1 schrieb Alex: > > Which is fine, since no-one is suggesting (least of all me) that the NT > has a specific implementation. But how it might include Albert's name > token for something with no name is a little mystifying, and I've asked > for but not got a clarifying example. > > -- > Alex Could live in headers of :NONAME words
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-11 14:39 +0000 |
| Message-ID | <o55fvu$u1m$1@dont-email.me> |
| In reply to | #53947 |
On 1/11/2017 14:08, minforth@arcor.de wrote: > Am Mittwoch, 11. Januar 2017 11:32:32 UTC+1 schrieb Alex: >>> Which is fine, since no-one is suggesting (least of all me) that the NT >> has a specific implementation. But how it might include Albert's name >> token for something with no name is a little mystifying, and I've asked >> for but not got a clarifying example. >> >> -- >> Alex > > Could live in headers of :NONAME words > What headers? :NONAME words & quotations don't need to have them; they're bare XTs, and all you can do with an XT in Forth is either EXECUTE or COMPILE, it . -- Alex
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-11 23:00 -0800 |
| Message-ID | <5b231b45-2054-424e-bc81-cc0757db54c5@googlegroups.com> |
| In reply to | #53936 |
Le mardi 10 janvier 2017 16:24:14 UTC+1, Alex a écrit : > >>> > >>> All of the following names are better than "name token": dea, word, > >>> token, object, forth object, opaque token, word header > >> > >> That's for debate. I'm happy with name token. > > > > We are at the point of introducing a new concept. The name we choose > > now will remain forever. Take that inconsideration. > > It's already been done. See TRAVERSE-WORDLIST which introduced the > concept. http://www.forth200x.org/traverse-wordlist.html > Just read this document. Sorry but confusing... Before reading it, what I had in mind was : 1) A word is a Forth defintion 2) A name is the string corresponding to a word name. But it seems that this document uses "name" as a synonym of "word". Or as a synonym of a Forth definition ? Or just as node into a word list ? Is a "name token" a concept only related to word lists and its nodes or does it represent a word ? A forth definition ? If dedicated to word lists, fine, but that is not the same concept we are talking about and you can't refer to this document as an "already done" concept. If not dedicated to word lists and is intended to represent a Forth definition, "name token" is, imo, a bad choice for this concept. Any Albert proposals is better. Funny : "NAME>STRING returns the name of the word nt" So this returns the name of a name, right ? Franck
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-12 13:55 +0000 |
| Message-ID | <o581oo$ji5$1@dont-email.me> |
| In reply to | #53951 |
On 1/12/2017 07:00, franck.bensusan@gmail.com wrote: > Le mardi 10 janvier 2017 16:24:14 UTC+1, Alex a écrit : >>>>> >>>>> All of the following names are better than "name token": dea, >>>>> word, token, object, forth object, opaque token, word header >>>> >>>> That's for debate. I'm happy with name token. >>> >>> We are at the point of introducing a new concept. The name we >>> choose now will remain forever. Take that inconsideration. >> >> It's already been done. See TRAVERSE-WORDLIST which introduced the >> concept. http://www.forth200x.org/traverse-wordlist.html >> > > Just read this document. Sorry but confusing... > > Before reading it, what I had in mind was : 1) A word is a Forth > defintion 2) A name is the string corresponding to a word name. > > But it seems that this document uses "name" as a synonym of "word". > Or as a synonym of a Forth definition ? Or just as node into a word > list ? From the standard: word: Depending on context, either 1) the name of a Forth definition; or 2) a parsed sequence of non-space characters, which could be the name of a Forth definition. It encompasses more than just the name; for instance, we can execute a word. More correctly, its execution token, but in this case we understand what is meant. We definitely can't execute its name. > > Is a "name token" a concept only related to word lists and its nodes > or does it represent a word ? A forth definition ? A name token is a token that represents a named word. Each named word has one and only one name token. The standard doesn't define the nature of NT, just that it is exactly one cell in size. It doesn't define "node" either. > > If dedicated to word lists, fine, but that is not the same concept we > are talking about and you can't refer to this document as an "already > done" concept. It was adopted into the Forth 2012 standard. That may not be to your taste, but it's there. > > If not dedicated to word lists and is intended to represent a Forth > definition, "name token" is, imo, a bad choice for this concept. Any > Albert proposals is better. He didn't make a proposal, but offered up a list of synonyms. dea, word, token, object, forth object, opaque token, word header DEA is an acronym; I'm not sure what it means. If A is for Address, then that's an implementation detail too far. They don't need to be addresses. Word has a defined meaning in the standard. A name token is not a word. Token is ambiguous as it's also used for execution token, which is also an opaque token. Object is not correct since the name token has no behaviours. Word header explicitly mentions header, implies it's a pointer. That's an implementation detail. A name token doesn't need to be a pointer to a header. > > Funny : "NAME>STRING returns the name of the word nt" > > So this returns the name of a name, right ? What it actually says is NAME>STRING returns the string addr count, the definition name of the word represented by nt. The Forth 2012 standard says (https://forth-standard.org/standard/tools/NAMEtoSTRING) NAME>STRING returns the name of the word nt in the character string c-addr u. We should discuss that, not an incorrect paraphrase. > > Franck > -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-12 14:06 +0000 |
| Message-ID | <o582dm$ls8$1@dont-email.me> |
| In reply to | #53953 |
On 1/12/2017 13:55, Alex wrote: > On 1/12/2017 07:00, franck.bensusan@gmail.com wrote: >> >> Funny : "NAME>STRING returns the name of the word nt" >> >> So this returns the name of a name, right ? > > What it actually says is > > NAME>STRING returns the string addr count, the definition name of the > word represented by nt. > > The Forth 2012 standard says > (https://forth-standard.org/standard/tools/NAMEtoSTRING) > > NAME>STRING returns the name of the word nt in the character string > c-addr u. > > We should discuss that, not an incorrect paraphrase. Apologies. Early send & bad edit and should have said: There's an implication that tokens are representational. So the sentence should be read as meaning; NAME>STRING returns the name of the word [represented by] nt in the character string c-addr u. This doesn't cause me any recursive heartburn with "name of a name" since it doesn't say that. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-13 06:29 -0800 |
| Message-ID | <cd2f4fde-6a2d-4c12-ad7d-23131d365714@googlegroups.com> |
| In reply to | #53954 |
Le jeudi 12 janvier 2017 15:06:15 UTC+1, Alex a écrit : > On 1/12/2017 13:55, Alex wrote: > > On 1/12/2017 07:00, franck.bensusan@gmail.com wrote: > > >> > >> Funny : "NAME>STRING returns the name of the word nt" > >> > >> So this returns the name of a name, right ? > > > > What it actually says is > > > > NAME>STRING returns the string addr count, the definition name of the > > word represented by nt. > > > > The Forth 2012 standard says > > (https://forth-standard.org/standard/tools/NAMEtoSTRING) > > > > NAME>STRING returns the name of the word nt in the character string > > c-addr u. > > > > We should discuss that, not an incorrect paraphrase. > > Apologies. Early send & bad edit and should have said: > > There's an implication that tokens are representational. So the sentence > should be read as meaning; > > NAME>STRING returns the name of the word [represented by] nt in the > character string c-addr u. > > This doesn't cause me any recursive heartburn with "name of a name" > since it doesn't say that. > > -- > Alex No problem. It was just to point out that when we say that a name is a named word, there can be a confusion with a word's name. For instance : - PARSE-NAME returns a string ( caddr u ) - FIND-NAME returns a named word represented by a nt. Can we agree that the "NAME" used into those words are not the same concepts, not represented by the same types ? That's the only thing I'am trying to point out. Franck
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-13 14:52 +0000 |
| Message-ID | <o5apfu$rlh$1@dont-email.me> |
| In reply to | #53970 |
On 1/13/2017 14:29, franck.bensusan@gmail.com wrote: > > It was just to point out that when we say that a name is > a named word, there can be a confusion with a word's name. > > For instance : > - PARSE-NAME returns a string ( caddr u ) > - FIND-NAME returns a named word represented by a nt. > > Can we agree that the "NAME" used into those words are not > the same concepts, not represented by the same types ? I see, you're saying that x-NAME is returing a different thing; a string in the case of PARSE-NAME and an NT in the case of FIND-NAME. FIND-NAME is in gforth. I'm not sure about other Forths. What would you call FIND-NAME? NAME>TOKEN for example? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-14 12:23 +0000 |
| Message-ID | <2017Jan14.132359@mips.complang.tuwien.ac.at> |
| In reply to | #53970 |
franck.bensusan@gmail.com writes:
>It was just to point out that when we say that a name is
>a named word, there can be a confusion with a word's name.
>
>For instance :
>- PARSE-NAME returns a string ( caddr u )
>- FIND-NAME returns a named word represented by a nt.
>
>Can we agree that the "NAME" used into those words are not=20
>the same concepts, not represented by the same types ?
Yes. What we have in Forth-2012 is
PARSE-NAME ( -- c-addr u )
NAME>INTERPRET ( nt -- xt )
NAME>COMPILE ( nt -- x xt )
NAME>STRING ( nt -- c-addr u )
Of course the NAME in the NAME>... words refers to an NT, while
PARSE-NAME does not produce an NT; this is less than ideal, but the
damage is already done. Now what should the NT-producing word be
called? FIND-NAME has been in Gforth since before 0.4.0 (1998), and
it fits with the usage in the NAME>... words, but if we standardize
the same functionality with a different name, that's fine with me.
BTW: The reason why PARSE-NAME is called that, is that the original
proposal was for PARSE-WORD, but there were two conflicting behaviours
for that name. So PARSE-NAME was chosen as a replacement. Think of
it as parsing a word name.
- 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 | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-12 15:47 +0100 |
| Message-ID | <1mzqwhq.gf64g416zhc74N%awegel@arcor.de> |
| In reply to | #53953 |
Alex <alex@rivadpm.com> wrote: > > If not dedicated to word lists and is intended to represent a Forth > > definition, "name token" is, imo, a bad choice for this concept. Any > > Albert proposals is better. > > He didn't make a proposal, but offered up a list of synonyms. > > dea, word, token, object, forth object, opaque token, word header > > DEA is an acronym; I'm not sure what it means. If A is for Address, then > that's an implementation detail too far. They don't need to be addresses. DE = dictionary entry Hey - i got another possible term: LT = lexical token Reason: They're lexical. They were even found in the "lexicon". One might argue that this term is too broad, because there are -at least potentially- other kinds of lexical tokens. Numerals for example are candidates, on the other hand they don't have tokens, so maybe they don't interfere conceptually here. On the yet-other hand, numbers and other literals could also make use of a ..>COMPILE and ..>INTERPRET mechanism, because they need differing behaviours for those two cases too. PS: No, i didn't propose them here just because they contain "lex" as in "alex".
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-12 15:09 +0000 |
| Message-ID | <o58654$3t7$1@dont-email.me> |
| In reply to | #53957 |
On 1/12/2017 14:47, Alexander Wegel wrote: > Alex <alex@rivadpm.com> wrote: > >>> If not dedicated to word lists and is intended to represent a Forth >>> definition, "name token" is, imo, a bad choice for this concept. Any >>> Albert proposals is better. >> >> He didn't make a proposal, but offered up a list of synonyms. >> >> dea, word, token, object, forth object, opaque token, word header >> >> DEA is an acronym; I'm not sure what it means. If A is for Address, then >> that's an implementation detail too far. They don't need to be addresses. > > DE = dictionary entry Thanks. Then DEA is definitely a non-starter since that implies a pointer to a structure. A name token is an opaque value, returned by only 1 word so far; TRAVERSE-WORDLIST. The non-standard but commonly available FIND-NAME also returns an NT. You can do 3 standard defined things with a anem token; get a string, and get the interpretation and compilation XTs. That's it. > > Hey - i got another possible term: > > LT = lexical token > > Reason: They're lexical. They were even found in the "lexicon". It's based on the Greek for "word". In Comp Sci terms, wikipedia (not to be taken as gospel, but helpful nonetheless) says A token or lexical token is a structure representing a lexeme [a string of characters which forms a syntactic unit] that explicitly indicates its categorization for the purpose of parsing. > > One might argue that this term is too broad, because there are -at least > potentially- other kinds of lexical tokens. Yes. > > Numerals for example are candidates, on the other hand they don't have > tokens, so maybe they don't interfere conceptually here. There's nothng to prevent numbers from being "first class citizens" and for them to have execution tokens and correspondingly a name token. There was some discussion on clf a number of years ago around this intriguing possibility. > > On the yet-other hand, numbers and other literals could also make use of > a ..>COMPILE and ..>INTERPRET mechanism, because they need differing > behaviours for those two cases too. > > PS: No, i didn't propose them here just because they contain "lex" as in > "alex". > Thanks for bursting my bubble ;) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-12 20:23 +0100 |
| Message-ID | <1mzr1ik.dg9et4red4laN%awegel@arcor.de> |
| In reply to | #53958 |
Alex <alex@rivadpm.com> wrote: > On 1/12/2017 14:47, Alexander Wegel wrote: > > Alex <alex@rivadpm.com> wrote: > > > >>> If not dedicated to word lists and is intended to represent a Forth > >>> definition, "name token" is, imo, a bad choice for this concept. Any > >>> Albert proposals is better. > >> > >> He didn't make a proposal, but offered up a list of synonyms. > >> > >> dea, word, token, object, forth object, opaque token, word header > > Hey - i got another possible term: > > > > LT = lexical token > > > > Reason: They're lexical. They were even found in the "lexicon". > > It's based on the Greek for "word". In Comp Sci terms, wikipedia (not to > be taken as gospel, but helpful nonetheless) says > > A token or lexical token is a structure representing a lexeme [a string > of characters which forms a syntactic unit] that explicitly indicates > its categorization for the purpose of parsing. Ok, looking at wikipedia, i think "symbol" is a better fit.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-12 21:21 +0000 |
| Message-ID | <o58ru3$ppk$1@dont-email.me> |
| In reply to | #53960 |
On 1/12/2017 19:23, Alexander Wegel wrote: > Alex <alex@rivadpm.com> wrote: > >> On 1/12/2017 14:47, Alexander Wegel wrote: >>> Alex <alex@rivadpm.com> wrote: >>> >>>>> If not dedicated to word lists and is intended to represent a Forth >>>>> definition, "name token" is, imo, a bad choice for this concept. Any >>>>> Albert proposals is better. >>>> >>>> He didn't make a proposal, but offered up a list of synonyms. >>>> >>>> dea, word, token, object, forth object, opaque token, word header > >>> Hey - i got another possible term: >>> >>> LT = lexical token >>> >>> Reason: They're lexical. They were even found in the "lexicon". >> >> It's based on the Greek for "word". In Comp Sci terms, wikipedia (not to >> be taken as gospel, but helpful nonetheless) says >> >> A token or lexical token is a structure representing a lexeme [a string >> of characters which forms a syntactic unit] that explicitly indicates >> its categorization for the purpose of parsing. > > Ok, looking at wikipedia, i think "symbol" is a better fit. > It might be. Interestingly, we're discussing what it is called, rather than what it is. The encourages me to think that the concept of the name token is sound. Perhaps it's time for FIND-NAME ( c-addr u – nt | 0 ) to supercede FIND. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-13 03:45 +0100 |
| Message-ID | <o59evn$h3c$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53961 |
In article <o58ru3$ppk$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/12/2017 19:23, Alexander Wegel wrote: <SNIP> >It might be. Interestingly, we're discussing what it is called, rather >than what it is. The encourages me to think that the concept of the name >token is sound. I'm glad that at last you admit that the concept of a dea is sound, because of course it is the same concept. Now we are only bickering over the names, but that ship has sailed given the 2012 standard, I know that. > >Perhaps it's time for FIND-NAME ( c-addr u – nt | 0 ) to supercede FIND. Prior art: ciforth has that under the name FOUND and FIND is a loadable extension since ages. It makes no sense to have improvements and not let it gravitate towards Forth's core. I hope it is clear that >BODY (for created words) should work on a dea (nt) and not on an xt where we even not know whether it is an implementation behaviour or a compilation behaviour. It is of course equally late to change that. "AAP" FIND-NAME NAME>COMPILATION-XT >BODY \ niet fraai P.S. The name object is not bad for something like a Forth word that has behaviours and also data attached. It is cowardness to let the OO-maffia claim such common a word and tell us we can't use it because they have multiple inheritance glued to its meaning. > >-- >Alex -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-13 02:55 -0600 |
| Message-ID | <WqCdnecItfSAC-XFnZ2dnUU7-WWdnZ2d@supernews.com> |
| In reply to | #53964 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > > I hope it is clear that >BODY (for created words) should work on a > dea (nt) and not on an xt where we even not know whether it is an > implementation behaviour or a compilation behaviour. No, it's really not clear. The principle that the XT is a unique handle for a word is well-establshed. > P.S. The name object is not bad for something like a Forth word > that has behaviours and also data attached. It is cowardness to > let the OO-maffia claim such common a word and tell us we can't use > it because they have multiple inheritance glued to its meaning. That's true, and it doesn't bother the C standards people who use the word "object" in many places. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-13 14:29 +0000 |
| Message-ID | <o5ao4f$e8j$1@dont-email.me> |
| In reply to | #53964 |
On 1/13/2017 02:45, Albert van der Horst wrote: > In article <o58ru3$ppk$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 1/12/2017 19:23, Alexander Wegel wrote: > <SNIP> >> It might be. Interestingly, we're discussing what it is called, rather >> than what it is. The encourages me to think that the concept of the name >> token is sound. > > I'm glad that at last you admit that the concept of a dea is sound, > because of course it is the same concept. I never said otherwise. However, I prefer it to be an opaque token, rather than a "dictionary entry address", which might lead some to think that the entry has (or should have) a fixed format. I don't believe we want to go back to NFA LFA CFA PFA and so on. > Now we are only bickering over the names, but that ship has sailed > given the 2012 standard, I know that. > >> >> Perhaps it's time for FIND-NAME ( c-addr u – nt | 0 ) to supercede FIND. > > Prior art: ciforth has that under the name FOUND and FIND is a loadable > extension since ages. > It makes no sense to have improvements and not let it gravitate > towards Forth's core. FOUND is the past tense of FIND; it seems a little unnatural to use such a tense. > > I hope it is clear that >BODY (for created words) should work on a > dea (nt) and not on an xt where we even not know whether it is an > implementation behaviour or a compilation behaviour. > It is of course equally late to change that. > > "AAP" FIND-NAME NAME>COMPILATION-XT >BODY \ niet fraai Only XTs have a body (and then only for CREATE & its children); the NT can't, since (a) it may be associated with more than one XT (b) you can't EXECUTE or COMPILE, an NT. I don't understand the rest about behaviours. > > P.S. The name object is not bad for something like a Forth word > that has behaviours and also data attached. It is cowardness to > let the OO-maffia claim such common a word and tell us we can't use > it because they have multiple inheritance glued to its meaning. That's fine, but then we have a problem in naming objects that do have multiple inheritance etc. Avoiding ambiguity would seem to be easy, so why overload the word? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2017-01-13 16:11 +0100 |
| Message-ID | <o5aqmo$540$1@newsreader4.netcologne.de> |
| In reply to | #53969 |
On 1/13/2017 3:29 PM, Alex wrote: [snip] > On 1/13/2017 02:45, Albert van der Horst wrote: >> P.S. The name object is not bad for something like a Forth word >> that has behaviours and also data attached. It is cowardness to >> let the OO-maffia claim such common a word and tell us we can't use >> it because they have multiple inheritance glued to its meaning. > > That's fine, but then we have a problem in naming objects that do have > multiple inheritance etc. Avoiding ambiguity would seem to be easy, so > why overload the word? These things should correctly be called (class) "instances" or "instance objects". The term "Object" per se is generic and may of course also be used for some abstract forth thingy.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-13 17:26 +0100 |
| Message-ID | <o5av36$ksn$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53969 |
In article <o5ao4f$e8j$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/13/2017 02:45, Albert van der Horst wrote: >> In article <o58ru3$ppk$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >>> On 1/12/2017 19:23, Alexander Wegel wrote: >> <SNIP> >>> It might be. Interestingly, we're discussing what it is called, rather >>> than what it is. The encourages me to think that the concept of the name >>> token is sound. >> >> I'm glad that at last you admit that the concept of a dea is sound, >> because of course it is the same concept. > >I never said otherwise. However, I prefer it to be an opaque token, >rather than a "dictionary entry address", which might lead some to think >that the entry has (or should have) a fixed format. I don't believe we >want to go back to NFA LFA CFA PFA and so on. I think "AAP" NAME>XT >BODY brings that time back. That would be great progress for Forth implementations to have a uniform header. IN 1993 (tforth) and 2000 I did away with LINK>LINK LINK>NAME NAME>BODY BODY>CFA LINK>NEXT introducing a single token to represent a word and never looked back. Uniform headers are internal and need not be mentionned in the standard. > >> Now we are only bickering over the names, but that ship has sailed >> given the 2012 standard, I know that. >> >>> >>> Perhaps it's time for FIND-NAME ( c-addr u – nt | 0 ) to supercede FIND. >> >> Prior art: ciforth has that under the name FOUND and FIND is a loadable >> extension since ages. >> It makes no sense to have improvements and not let it gravitate >> towards Forth's core. > >FOUND is the past tense of FIND; it seems a little unnatural to use such >a tense. Is it? We could've had `` FIND DROP '' and then `` "DROP" FOUND '' is totally analogous to INCLUDED. I like the more functional ring to it. It is not passed tense, it is a completed action. It solidly implies that the word doesn't scan ahead. >-- >Alex Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 3 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