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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-13 17:27 +0100 |
| Message-ID | <o5av6f$kti$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53974 |
In article <o5av36$ksn$1@cherry.spenarnc.xs4all.nl>,
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>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 must be
I think
"AAP" FIND-NAME 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
>
--
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-13 17:01 +0000 |
| Message-ID | <o5b131$7ff$1@dont-email.me> |
| In reply to | #53974 |
On 1/13/2017 16:26, Albert van der Horst wrote: > 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. There's no suggestion that you can do this; it's NAME>INTERPRET and NAME>COMPILE, not NAME>XT and >BODY points you at the data associated with the XT generated by CREATE; that is nothing to do with the header or NT, but is to do with the XT. In my Forth, >BODY goes nowhere near the header to do its job. : >BODY ( xt -- data ) 1+ @ ; > > 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. Your first statement appears to contradict the second? > >> >>> 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. I beg to differ. It's a strawman to claim "we could have"; we don't have. Your observation about scanning ahead is equivalent to suggesting that SWAP DUP DROP might swap DUP and DROP, so we should call it SWAPPED as it's a "completed action". -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-14 15:35 +0000 |
| Subject | nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <2017Jan14.163551@mips.complang.tuwien.ac.at> |
| In reply to | #53974 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <o5ao4f$e8j$1@dont-email.me>, Alex <alex@rivadpm.com> wrote:
>>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.
No. In fig-Forth (where these words come from) there was a 1:1:1:1
relationship between NFA, LFA, CFA, PFA: Forth definitions were
represented with one structure, and instead of jumping from one field
to the next, these days one would just have one token, and use that as
launch platform to get to all the fields.
However, in Forth-2012, we have SYNONYM, :NONAME, S"/TO/IS/ACTION-OF,
and words where >BODY is guaranteed to work, and words where it isn't,
so the 1:1:1:1 model does no longer fit, even for the standard
features; in addition, systems have things like separated headers, and
beheaded definitions.
So, we no longer have one structure which can be represented by one
token; instead, we have some interconnected concepts, and the
conversion words are there for following these connections. And
therefore, a less fragile version of the sequence above would be:
:noname ( -- addr|0 )
s" aap" find-name dup if name>interpret dup if >body then then ;
And that assumes that AAP is a CREATEd word (unfortunately, we have no
standard way to test this).
Even a system that tries to unify nt and xt (e.g., VFX, or the
development version of Gforth) does not behave like you might expect
from fig-Forth-with-a-word-token; the following code uses the xt and nt
interchangeably:
: foo ." foo" ;
synonym bar foo
' bar name>string type
\ outputs "foo" on development Gforth
\ outputs garbage on VFX 4.72 build 560
' foo ' bar = .
\ outputs -1 on both systems
: fni-helper ( c-addr u nt1 nt -- c-addr u nt f )
>r drop 2dup r@ name>string compare r> swap ;
: find-name-in ( c-addr u wid -- nt | 0 )
0 ['] fni-helper rot traverse-wordlist ( c-addr u nt )
>r r@ name>string compare 0= r> and ;
s" foo" forth-wordlist find-name-in .
\ outputs 0 on VFX 4.72, probably because NAME>STRING does not work
\ so the following is only with the development Gforth:
s" foo" forth-wordlist find-name-in s" bar" forth-wordlist find-name-in = .
\ outputs 0
s" foo" forth-wordlist find-name-in name>string type
\ outputs "foo"
s" bar" forth-wordlist find-name-in name>string type
\ outputs "bar"
s" foo" forth-wordlist find-name-in dup name>interpret = .
\ outputs -1 (i.e., nt=xt for FOO)
s" bar" forth-wordlist find-name-in dup name>interpret = .
\ outputs 0 (i.e., nt<>xt for BAR)
s" foo" forth-wordlist find-name-in execute
\ outputs "foo"
s" bar" forth-wordlist find-name-in execute
\ produces an "illegal instruction" exception
These are just some of the interesting cases involving SYNONYM, there
is more stuff for :NONAME and S"/TO/IS/ACTION-OF.
Bottom line: Forth headers are now more complex than in fig-Forth
times, and even systems that try to unify nt and xt don't implement
NAME>INTERPRET as a NOP. You may wish to make Forth great again by
having one token to rule them all, but while that sounds attractive,
the devil is in the details.
>Is it? We could've had `` FIND DROP '' and then `` "DROP" FOUND '' is totally
>analogous to INCLUDED.
But what we have is C" DROP" FIND, and FOUND then is not analogous to
INCLUDED.
- 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 | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-14 13:58 -0800 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <f8a4cede-1273-40dc-8b4e-a8af68364f10@googlegroups.com> |
| In reply to | #54005 |
On Saturday, 14 January 2017 18:34:44 UTC+1, Anton Ertl wrote: > Even a system that tries to unify nt and xt (e.g., VFX, or the > development version of Gforth) does not behave like you might expect > from fig-Forth-with-a-word-token; the following code uses the xt and nt > interchangeably: VFX does not try to unify xt and nt. There is a particular need for nt in TRAVERSE-WORDLIST and friends. An xt is (IMHO) an opaque type (we can make no assumptions about what it means) from which we can derive all the data we need about a word. The new nts are there to permit us to traverse wordlists. They (nts) should also be opaque types. Stephen
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-14 14:52 -0800 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <02599021-30fd-4d15-8c14-406d0b0e437b@googlegroups.com> |
| In reply to | #54011 |
On Saturday, January 14, 2017 at 2:58:52 PM UTC-7, ste...@mpeforth.com wrote: > On Saturday, 14 January 2017 18:34:44 UTC+1, Anton Ertl wrote: > > Even a system that tries to unify nt and xt (e.g., VFX, or the > > development version of Gforth) does not behave like you might expect > > from fig-Forth-with-a-word-token; the following code uses the xt and nt > > interchangeably: > > VFX does not try to unify xt and nt. > > There is a particular need for nt in TRAVERSE-WORDLIST and friends. > An xt is (IMHO) an opaque type (we can make no assumptions about > what it means) from which we can derive all the data we need about a > word. The new nts are there to permit us to traverse wordlists. They (nts) > should also be opaque types. > > Stephen In Straight Forth I don't have an NT --- that is a very bad idea --- I only have an XT. I do have a lot of words that take an XT as a parameter: GET-IMMEDIATE ( xt -- flag ) \ is the word immediate? SET-IMMEDIATE ( flag xt -- ) GET-SMUDGE ( xt -- flag ) \ is the word smudged? SET-SMUDGE ( flag xt -- ) GET-SMUDGE-READY ( xt -- flag ) \ will END-MODULE smudge the word? SET-SMUDGE-READY ( flag xt -- ) GET-WID ( xt -- wid ) \ what word-list is the word in? SET-WID ( wid xt -- ) GET-NAME ( xt -- ) \string: -- name SET-NAME ( xt -- ) \string: name -- It is a bad idea to have an NT because then you get an address to a struct and you have to know what fields are in the struct, and there is potential for catastrophe when storing into the dictionary at the wrong place. Also, there is this: LATEST ( -- xt ) \ the xt of the latest word compiled All of this seems super-simple and ultra-obvious to me. Why is this controversial? How did ANS-Forth get completely screwed up?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-15 14:00 +0000 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <2017Jan15.150039@mips.complang.tuwien.ac.at> |
| In reply to | #54011 |
stephen@mpeforth.com writes:
>On Saturday, 14 January 2017 18:34:44 UTC+1, Anton Ertl wrote:
>> Even a system that tries to unify nt and xt (e.g., VFX, or the
>> development version of Gforth) does not behave like you might expect
>> from fig-Forth-with-a-word-token; the following code uses the xt and nt
>> interchangeably:
>
>VFX does not try to unify xt and nt.
Sorry about that misunderstanding on my side.
>There is a particular need for nt in TRAVERSE-WORDLIST and friends.
>An xt is (IMHO) an opaque type (we can make no assumptions about
>what it means) from which we can derive all the data we need about a
>word. The new nts are there to permit us to traverse wordlists. They (nts)
>should also be opaque types.
There is one position, advocated by Bernd Paysan, Albert van der Horst
(and, I had thought, you, but apparently I was mistaken), that a word
should be represented by one token from which everything about the
word can be derived. This position leads to a Forth system that uses
that token as both nt and xt where possible.
There is another position that points out that we don't have a 1:1
relation between dictionary entries, xts and bodies, thanks to
SYNONYM, :NONAME, S"/TO/IS/ACTION-OF, and the restrictions on >BODY.
So even if you implement nts and xts such that they are the same value
for simple words like
: foo ." foo" ;
they will then be different for other cases, such as
synonym bar foo
So you need to separate nt and xt conceptually even if you unify them
in the implementation of many words.
The question then becomes: does the implementation unification provide
a benefit? Does it have drawbacks? A drawback that I can think of is
that you won't notice it right away if you forget NAME>INTERPRET: When
applied to simple words the code will work as expected, but it will
fail when applied to, e.g., synonyms. Is there any benefit to balance
this drawback?
Anyway, I looked at why my FIND-NAME-IN code (which does not rely on
nt=xt) did not work on VFX, and found that that's because VFX stores
the names in upper case; so I adapted FIND-NAME-IN for VFX:
: fni-helper ( c-addr u nt1 nt -- c-addr u nt f )
>r drop 2dup r@ name>string icompare r> swap ;
: find-name-in ( c-addr u wid -- nt | 0 )
0 ['] fni-helper rot traverse-wordlist ( c-addr u nt )
>r r@ name>string icompare 0= r> and ;
When I now do
: foo ." foo" ;
synonym bar foo
s" foo" get-current find-name-in cr dup . name>string type
s" bar" get-current find-name-in cr dup . name>string type
it outputs:
135006933 FOO
135006981 BAR
and when I do
' foo .
' bar .
I get
135006960
135006960
So, on VFX, too, the nts of synonyms differ even when the xts are the
same; this is as it should be, because we want to be able to get to
the name of a synonym from the nt.
- 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-15 16:51 +0100 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <o5g5qa$932$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54025 |
In article <2017Jan15.150039@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >stephen@mpeforth.com writes: >>On Saturday, 14 January 2017 18:34:44 UTC+1, Anton Ertl wrote: >>> Even a system that tries to unify nt and xt (e.g., VFX, or the >>> development version of Gforth) does not behave like you might expect >>> from fig-Forth-with-a-word-token; the following code uses the xt and nt >>> interchangeably: >> >>VFX does not try to unify xt and nt. > >Sorry about that misunderstanding on my side. > >>There is a particular need for nt in TRAVERSE-WORDLIST and friends. >>An xt is (IMHO) an opaque type (we can make no assumptions about >>what it means) from which we can derive all the data we need about a >>word. The new nts are there to permit us to traverse wordlists. They (nts) >>should also be opaque types. > >There is one position, advocated by Bernd Paysan, Albert van der Horst >(and, I had thought, you, but apparently I was mistaken), that a word >should be represented by one token from which everything about the >word can be derived. This position leads to a Forth system that uses >that token as both nt and xt where possible. > >There is another position that points out that we don't have a 1:1 >relation between dictionary entries, xts and bodies, thanks to >SYNONYM, :NONAME, S"/TO/IS/ACTION-OF, and the restrictions on >BODY. >So even if you implement nts and xts such that they are the same value >for simple words like > >: foo ." foo" ; > >they will then be different for other cases, such as > >synonym bar foo > >So you need to separate nt and xt conceptually even if you unify them >in the implementation of many words. If you take the same stand as Python this problem becomes clearer. There is but one de/nt/object. An alias means it has however two names. The correspondance between the name and the object is given by a dictionary, a hash or a linked list, whatever. The same object may occur in more than one hash. It is to be decided whether a SYNONYM makes a deep or a shallow copy. A deep copy means that all properties of an object are copied. Its DOES> code and its pointer to a BODY. This means that the DOES> code of a SYNONYM can be changed, without changing the original. Or not. At least we now have a framework where we can discuss matters like this. <SNIP> >- anton 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-15 16:04 +0000 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <2017Jan15.170422@mips.complang.tuwien.ac.at> |
| In reply to | #54027 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>There is but one de/nt/object. An alias means it has however two names.
In VFX and Gforth, the synonym has a different nt from the original.
This is as it should be, because you can apply NAME>STRING to an nt,
and then you should get different strings for the original and for the
synonym.
>It is to be decided whether a SYNONYM makes a deep or a shallow copy.
>A deep copy means that all properties of an object are copied.
Certainly, as far as the body or contents of a variable or deferred
word are concerned, all synonyms are references to the same
body/contents (i.e., shallow copying). For immediacy, the standard
does not allow applying IMMEDIATE to a synonym (to avoid the question
of whether immediacy is shared between original and synonym or not);
for DOES>, it's probably not allowed (see the discussion on
<http://forth-standard.org/standard/tools/SYNONYM>).
- 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-15 13:47 -0800 |
| Subject | Re: nt=xt? (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <f40d73bc-ae38-41a0-b1ac-08e8db6a00fc@googlegroups.com> |
| In reply to | #54025 |
On Sunday, January 15, 2017 at 7:52:32 AM UTC-7, Anton Ertl wrote: > There is another position that points out that we don't have a 1:1 > relation between dictionary entries, xts and bodies, thanks to > SYNONYM, :NONAME, S"/TO/IS/ACTION-OF, and the restrictions on >BODY. > So even if you implement nts and xts such that they are the same value > for simple words like > > : foo ." foo" ; > > they will then be different for other cases, such as > > synonym bar foo > > So you need to separate nt and xt conceptually even if you unify them > in the implementation of many words. The Forth-200x committee is still struggling with this simple problem! I have SYNONYM FAST-SYNONYM and ALIAS in the novice-package (to be released in a few days). : const create , does> @ ; ok 12345 const nnn ok nnn . 12345 ok ' nnn >body @ . 12345 ok get-current alias xxx nnn ok xxx . 12345 ok ' xxx >body @ . 12345 ok ALIAS is like SYNONYM except that it supports >BODY which SYNONYM doesn't --- there is a slight performance cost though. FAST-SYNONYM is like SYNONYM except that it only works in compilation mode --- it provides slightly better performance. After I figured out the disambiguifiers, code like this became easy. The reason why you are still struggling with the problem is that you refuse to support the disambiguifiers (because shining a spotlight on ANS-Forth's ambiguous FIND will offend Elizabeth Rather).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-14 12:39 +0000 |
| Message-ID | <2017Jan14.133930@mips.complang.tuwien.ac.at> |
| In reply to | #53964 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Now we are only bickering over the names, but that ship has sailed
>given the 2012 standard, I know that.
...
>I hope it is clear that >BODY (for created words) should work on a
>dea (nt) and not on an xt
That ship has sailed in Forth-94 (and already Forth-83 describes >BODY
as taking a "compilation address", i.e., what became an xt in
Forth-94). And you actually know it:
>It is of course equally late to change that.
So why make a fuss?
>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.
Sure, you can be brave Humpty-Dumpty, and deviate from common usage
(which does not require multiple inheritance, c.f., Java), but that
ship has sailed, too, including in the Forth world; note that
Rodriguez and Poehlman listed 17 object-oriented Forth extensions in
1996.
- 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 | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-01-12 22:14 -0800 |
| Message-ID | <7239c533-6840-4694-a8cc-0aa699ea3859@googlegroups.com> |
| In reply to | #53961 |
> Perhaps it's time for FIND-NAME ( c-addr u – nt | 0 ) to supercede FIND. +1 from my side. amforth has search-name ( c-addr u wid -- nt | 0 ) and find-name ( c-addr u -- nt | 0 ) that uses the search order stack.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-14 13:45 +0000 |
| Message-ID | <2017Jan14.144539@mips.complang.tuwien.ac.at> |
| In reply to | #53951 |
franck.bensusan@gmail.com writes:
>Le mardi 10 janvier 2017 16:24:14 UTC+1, Alex a =C3=A9crit=C2=A0:
>> http://www.forth200x.org/traverse-wordlist.html
>>=20
>
>Just read this document. Sorry but confusing...
>
>Before reading it, what I had in mind was :=20
>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".=20
>Or as a synonym of a Forth definition ?
>Or just as node into a word list ?=20
I don't know which usages of "name" confused you in the CfV. I just
looked at the occurences of "name" in the CfV, and it's clear to me
from the context what they refer to: When not further qualified as
"name token" or "name string", "name" usually refers to the name
string of a named definition; in the voting instructions "name" refers
to the name of the voter.
>Is a "name token" a concept only related to word lists and its nodes or doe=
>s it
>represent a word ? A forth definition ?=20
A name token represents a named definition. There is no point in
having a named definition outside a wordlist, and named definitions
are inserted in wordlists at the latest when they are complete. There
is also no standard way to get at the nt of a named definition outside
the wordlist (and FIND-NAME and FIND-NAME-IN would not add one). So
yes, there is a strong connection between nts and wordlists.
>Funny :
>"NAME>STRING returns the name of the word nt"
>
>So this returns the name of a name, right ?
More precise would be: "NAME>STRING returns the name string of the
named definition represented by nt." But I think the existing
description is clear enough for most Forthers, and if it's really
unclear to you, you can ask here or on forth-standard.org.
- 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 | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-14 08:51 -0800 |
| Message-ID | <2a62b78b-c87b-4ebd-87c9-a5fbbb783e57@googlegroups.com> |
| In reply to | #54001 |
Le samedi 14 janvier 2017 16:32:42 UTC+1, Anton Ertl a écrit : > > I don't know which usages of "name" confused you in the CfV. I just > looked at the occurences of "name" in the CfV, and it's clear to me > from the context what they refer to: When not further qualified as > "name token" or "name string", "name" usually refers to the name > string of a named definition; in the voting instructions "name" refers > to the name of the voter. > The usage of "name" that confused me in the CfV is into the words introduced : NAME>INTERPRET NAME>COMPILE NAME>STRING Here, NAME is no further qualified so, as you say, it should refer to the name string of a definition (as in PARSE-NAME). But this is not the case : they are not qualified but refer to another concept (a named definition). The most confusing being "NAME>STRING". A name is already a string, so is it a "nop" word ? What is this STRING concept ? But this is still better than a strange "NAME>NAME" (the name it should have if the concepts are applied ). Franck
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-14 09:23 -0800 |
| Message-ID | <24da3430-0cae-4b9d-8ab1-01b2967d817a@googlegroups.com> |
| In reply to | #54003 |
Am Samstag, 14. Januar 2017 17:51:09 UTC+1 schrieb franck....@gmail.com: > But this is still better > than a strange "NAME>NAME" (the name it should have if the concepts are > applied ). > > Franck HEAR>HEAR ;-)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-14 18:02 +0000 |
| Message-ID | <2017Jan14.190209@mips.complang.tuwien.ac.at> |
| In reply to | #54003 |
franck.bensusan@gmail.com writes:
>Le samedi 14 janvier 2017 16:32:42 UTC+1, Anton Ertl a =C3=A9crit=C2=A0:
>>=20
>> I don't know which usages of "name" confused you in the CfV. I just
>> looked at the occurences of "name" in the CfV, and it's clear to me
>> from the context what they refer to: When not further qualified as
>> "name token" or "name string", "name" usually refers to the name
>> string of a named definition; in the voting instructions "name" refers
>> to the name of the voter.
>>=20
>
>The usage of "name" that confused me in the CfV is into the words
>introduced :
>NAME>INTERPRET
>NAME>COMPILE
>NAME>STRING
You want to make us beliebve that you are confused by these words not
being called
NAME-TOKEN>INTERPRETATION-XT
NAME-TOKEN>COMPILATION-SEMANTICS-EXECUTABLE-THINGY
NAME-TOKEN>NAME-STRING-OF-A-NAMED-DEFINITION
While I like word names of most words being mnemonic rather than the
Thinking-Forth-compliant SNAP, SNIP, and GRIP, you don't need to spell
out everything in the word name; you have the documentation for that.
And yes, NAME as part of a word name follows the convention of NAME
indicating an NT for these words, and for FIND-NAME and
FIND-NAME-IN/SEARCH-NAME. So PARSE-NAME does not follow that
convention; tough luck.
- 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 | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-09 23:42 -0800 |
| Message-ID | <b4dfc80f-ae2c-420c-9f91-f019df5d053f@googlegroups.com> |
| In reply to | #53900 |
Le lundi 9 janvier 2017 18:12:41 UTC+1, Anton Ertl a écrit : > minforth@arcor.de writes: > >Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: > >>=20 > >> Take a look at > >>=20 > >> http://forth-standard.org/standard/tools/NAMEtoINTERPRET > >> http://forth-standard.org/standard/tools/NAMEtoCOMPILE > >>=20 > >> Now we just need to standardize FIND-NAME ( c-addr u =E2=80=93 nt | 0 ) a= > >nd > >> FIND-NAME-IN ( c-addr u wid -- nt | 0 ). > >>=20 > > > >Sorry for my being blind. But where is the definition of "nt" ? > > http://forth-standard.org/standard/tools > > in section 15.3.1: > > |A name token is a single-cell value that identifies a named word. > The question is : is having a name is a fondamental characteristic of a word or not ? If not, a "named word" means somethings. Otherwise... If a word has always a name, what about : - wt : word token - >INTERPRET ( wt -- ) - >COMPILE ( wt -- ) - >EXECUTE ( wt -- ) - FIND-WORD ( s -- wt ) \ If FIND must continue to return a xt And, perhap's : - Make NONAME obsolete - Have quotations, that are used to defined anonymous code and replace NONAME. - Quotations are not words, have nothing to do with the dictionary which holds only words and don't have wt, just xt.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 09:36 +0000 |
| Message-ID | <o529rh$f2v$1@dont-email.me> |
| In reply to | #53918 |
On 1/10/2017 07:42, franck.bensusan@gmail.com wrote: > Le lundi 9 janvier 2017 18:12:41 UTC+1, Anton Ertl a écrit : >> minforth@arcor.de writes: >>> Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: >>>> =20 >>>> Take a look at >>>> =20 >>>> http://forth-standard.org/standard/tools/NAMEtoINTERPRET >>>> http://forth-standard.org/standard/tools/NAMEtoCOMPILE >>>> =20 >>>> Now we just need to standardize FIND-NAME ( c-addr u =E2=80=93 nt | 0 ) a= >>> nd >>>> FIND-NAME-IN ( c-addr u wid -- nt | 0 ). >>>> =20 >>> >>> Sorry for my being blind. But where is the definition of "nt" ? >> >> http://forth-standard.org/standard/tools >> >> in section 15.3.1: >> >> |A name token is a single-cell value that identifies a named word. >> > > The question is : is having a name is a fondamental characteristic > of a word or not ? It is the characteristic of a named word. That means there are unnamed words (which you refer to later). > > If not, a "named word" means somethings. Otherwise... > > > If a word has always a name, what about : > > - wt : word token > - >INTERPRET ( wt -- ) > - >COMPILE ( wt -- ) > - >EXECUTE ( wt -- ) > - FIND-WORD ( s -- wt ) \ If FIND must continue to return a xt All that has done is replace X (named words) with Y (word token) where Y might as well be the XT since it's an opaque value; so we're no further forward. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-10 03:55 -0800 |
| Message-ID | <51ef50aa-6700-4568-90f7-5bd9a2e383bc@googlegroups.com> |
| In reply to | #53921 |
Le mardi 10 janvier 2017 10:36:17 UTC+1, Alex a écrit : > On 1/10/2017 07:42, franck.bensusan@gmail.com wrote: > > Le lundi 9 janvier 2017 18:12:41 UTC+1, Anton Ertl a écrit : > >> minforth@arcor.de writes: > >>> Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: > >>>> =20 > >>>> Take a look at > >>>> =20 > >>>> http://forth-standard.org/standard/tools/NAMEtoINTERPRET > >>>> http://forth-standard.org/standard/tools/NAMEtoCOMPILE > >>>> =20 > >>>> Now we just need to standardize FIND-NAME ( c-addr u =E2=80=93 nt | 0 ) a= > >>> nd > >>>> FIND-NAME-IN ( c-addr u wid -- nt | 0 ). > >>>> =20 > >>> > >>> Sorry for my being blind. But where is the definition of "nt" ? > >> > >> http://forth-standard.org/standard/tools > >> > >> in section 15.3.1: > >> > >> |A name token is a single-cell value that identifies a named word. > >> > > > > The question is : is having a name is a fondamental characteristic > > of a word or not ? > > It is the characteristic of a named word. That means there are unnamed > words (which you refer to later). > > > > > If not, a "named word" means somethings. Otherwise... > > > > > > If a word has always a name, what about : > > > > - wt : word token > > - >INTERPRET ( wt -- ) > > - >COMPILE ( wt -- ) > > - >EXECUTE ( wt -- ) > > - FIND-WORD ( s -- wt ) \ If FIND must continue to return a xt > > All that has done is replace X (named words) with Y (word token) imo a word has a name... (but that is surely debatable). > where Y might as well be the XT since it's an opaque value; so we're > no further forward. > There is still a difference with an xt : unlike FIND, FIND-WORD is not STATE dependent and is not dependent of the word semantics.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 13:40 +0000 |
| Message-ID | <o52o5h$vq$1@dont-email.me> |
| In reply to | #53928 |
On 1/10/2017 11:55, franck.bensusan@gmail.com wrote: > Le mardi 10 janvier 2017 10:36:17 UTC+1, Alex a écrit : >> On 1/10/2017 07:42, franck.bensusan@gmail.com wrote: >>> Le lundi 9 janvier 2017 18:12:41 UTC+1, Anton Ertl a écrit : >>>> minforth@arcor.de writes: >>>>> Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: >>>>>> =20 >>>>>> Take a look at >>>>>> =20 >>>>>> http://forth-standard.org/standard/tools/NAMEtoINTERPRET >>>>>> http://forth-standard.org/standard/tools/NAMEtoCOMPILE >>>>>> =20 >>>>>> Now we just need to standardize FIND-NAME ( c-addr u =E2=80=93 nt | 0 ) a= >>>>> nd >>>>>> FIND-NAME-IN ( c-addr u wid -- nt | 0 ). >>>>>> =20 >>>>> >>>>> Sorry for my being blind. But where is the definition of "nt" ? >>>> >>>> http://forth-standard.org/standard/tools >>>> >>>> in section 15.3.1: >>>> >>>> |A name token is a single-cell value that identifies a named word. >>>> >>> >>> The question is : is having a name is a fondamental characteristic >>> of a word or not ? >> >> It is the characteristic of a named word. That means there are unnamed >> words (which you refer to later). >> >>> >>> If not, a "named word" means somethings. Otherwise... >>> >>> >>> If a word has always a name, what about : >>> >>> - wt : word token >>> - >INTERPRET ( wt -- ) >>> - >COMPILE ( wt -- ) >>> - >EXECUTE ( wt -- ) >>> - FIND-WORD ( s -- wt ) \ If FIND must continue to return a xt >> >> All that has done is replace X (named words) with Y (word token) > > imo a word has a name... (but that is surely debatable). > > >> where Y might as well be the XT since it's an opaque value; so we're >> no further forward. >> > > There is still a difference with an xt : unlike FIND, FIND-WORD > is not STATE dependent and is not dependent of the word semantics. > That's a good point, and one that is covered in http://www.forth200x.org/traverse-wordlist.html; see the REMARKS section. As an aside, it isn't, but the name of a nameless XT could be defined as the null string. I'm not sure of the value of such a thing however. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2017-01-10 06:40 -0800 |
| Message-ID | <f8a61765-05a8-4440-b9ec-0f4220a3b15e@googlegroups.com> |
| In reply to | #53930 |
Le mardi 10 janvier 2017 14:40:32 UTC+1, Alex a écrit : > On 1/10/2017 11:55, franck.bensusan@gmail.com wrote: > > Le mardi 10 janvier 2017 10:36:17 UTC+1, Alex a écrit : > >> On 1/10/2017 07:42, franck.bensusan@gmail.com wrote: > >>> Le lundi 9 janvier 2017 18:12:41 UTC+1, Anton Ertl a écrit : > >>>> minforth@arcor.de writes: > >>>>> Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: > >>>>>> =20 > >>>>>> Take a look at > >>>>>> =20 > >>>>>> http://forth-standard.org/standard/tools/NAMEtoINTERPRET > >>>>>> http://forth-standard.org/standard/tools/NAMEtoCOMPILE > >>>>>> =20 > >>>>>> Now we just need to standardize FIND-NAME ( c-addr u =E2=80=93 nt | 0 ) a= > >>>>> nd > >>>>>> FIND-NAME-IN ( c-addr u wid -- nt | 0 ). > >>>>>> =20 > >>>>> > >>>>> Sorry for my being blind. But where is the definition of "nt" ? > >>>> > >>>> http://forth-standard.org/standard/tools > >>>> > >>>> in section 15.3.1: > >>>> > >>>> |A name token is a single-cell value that identifies a named word. > >>>> > >>> > >>> The question is : is having a name is a fondamental characteristic > >>> of a word or not ? > >> > >> It is the characteristic of a named word. That means there are unnamed > >> words (which you refer to later). > >> > >>> > >>> If not, a "named word" means somethings. Otherwise... > >>> > >>> > >>> If a word has always a name, what about : > >>> > >>> - wt : word token > >>> - >INTERPRET ( wt -- ) > >>> - >COMPILE ( wt -- ) > >>> - >EXECUTE ( wt -- ) > >>> - FIND-WORD ( s -- wt ) \ If FIND must continue to return a xt > >> > >> All that has done is replace X (named words) with Y (word token) > > > > imo a word has a name... (but that is surely debatable). > > > > > >> where Y might as well be the XT since it's an opaque value; so we're > >> no further forward. > >> > > > > There is still a difference with an xt : unlike FIND, FIND-WORD > > is not STATE dependent and is not dependent of the word semantics. > > > > That's a good point, and one that is covered in > http://www.forth200x.org/traverse-wordlist.html; see the REMARKS section. > > As an aside, it isn't, but the name of a nameless XT could be defined as > the null string. I'm not sure of the value of such a thing however. > > -- > Alex I have just spent 10 minutes thinking about the concept of name of the nameless... Thanks for the trip :)
[toc] | [prev] | [next] | [standalone]
Page 4 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