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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-07 15:53 +0000 |
| Message-ID | <2017Jan7.165345@mips.complang.tuwien.ac.at> |
| In reply to | #53769 |
awegel@arcor.de (Alexander Wegel) writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Anyway, the normative text of Forth-94/2012 makes this ambiguous, so
>> by the text of the standard a standard program must not FIND the
>> system's IF (not even in compile state).
>
>I think the rationale behind these restrictions becomes clear in
>D.6.7 Immediacy, where there is an explanation why ' and ['] are not
>permitted with compiling words:
>They don't return immediacy information, just a bare execution token.
>(FIND which doesn't have that shortcoming isn't ruled out there.)
>
>The good thing is: I'm not attempting to "obtain an execution token",
>but to "obtain an execution-token + immediacy-flag pair", so the
>paragraph in 4.1.2 doesn't apply. It even makes sense this way ;D
That's too much language-lawyering for my taste (plus I doubt that
many agree with this reasoning, which would make C" IF" FIND standard,
but appending a DROP to it non-standard despite the stack being
non-empty).
My take on it is that the wording in 4.1.2 is too restrictive for
FIND, especially given the intent of the '94 and 2012 committees to
have user-defined interpreters written in Forth, and we should fix
that.
>BTW: Find is ruled out in 4.1.2 in a rather generic list (starting with
>E.g., ending with etc.) while there are only ~4 candidate words in the
>whole standard (' ['] FIND SEARCH-WORDLIST) - it might be normative, but
>seems a bit huh-hasty or imprecise to me.
Yes; the non-exhaustive formulation is probably intended to include
any such words that are added later; being overly restrictive is the
bigger problem.
- 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-07 18:20 +0100 |
| Message-ID | <1mzhtnd.1n633t2k1i8orN%awegel@arcor.de> |
| In reply to | #53812 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> awegel@arcor.de (Alexander Wegel) writes:
> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >> Anyway, the normative text of Forth-94/2012 makes this ambiguous, so
> >> by the text of the standard a standard program must not FIND the
> >> system's IF (not even in compile state).
> >
> >I think the rationale behind these restrictions becomes clear in
> >D.6.7 Immediacy, where there is an explanation why ' and ['] are not
> >permitted with compiling words:
> >They don't return immediacy information, just a bare execution token.
> >(FIND which doesn't have that shortcoming isn't ruled out there.)
> >
> >The good thing is: I'm not attempting to "obtain an execution token",
> >but to "obtain an execution-token + immediacy-flag pair", so the
> >paragraph in 4.1.2 doesn't apply. It even makes sense this way ;D
>
> That's too much language-lawyering for my taste
Well - there's a smiley. It's a case where lawyering language caused the
problem (by mistakenly treating FIND like the words that return
insufficient information) and apparently no system follows it anyway(?),
so i was delighted that my (admittedly stretched) interpretation of the
original language actually corrects this. :-)
> (plus I doubt that
> many agree with this reasoning, which would make C" IF" FIND standard,
> but appending a DROP to it non-standard despite the stack being
> non-empty).
Which would make perfect sense, because (as i mentioned) the xt alone is
incomplete information then.
> My take on it is that the wording in 4.1.2 is too restrictive for
> FIND, especially given the intent of the '94 and 2012 committees to
> have user-defined interpreters written in Forth, and we should fix
> that.
I'm all for it.
> >BTW: Find is ruled out in 4.1.2 in a rather generic list (starting with
> >E.g., ending with etc.) while there are only ~4 candidate words in the
> >whole standard (' ['] FIND SEARCH-WORDLIST) - it might be normative, but
> >seems a bit huh-hasty or imprecise to me.
>
> Yes; the non-exhaustive formulation is probably intended to include
> any such words that are added later;
Which by itself makes more trouble than sense, because words added later
are purely hypothetical.
> being overly restrictive is the
> bigger problem.
Yup.
The problem comes from the fact that one xt isn't neccessarily enough to
fully represent a word (a quick thought: 2 xts would be better).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-08 16:33 +0000 |
| Message-ID | <2017Jan8.173359@mips.complang.tuwien.ac.at> |
| In reply to | #53814 |
awegel@arcor.de (Alexander Wegel) writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> awegel@arcor.de (Alexander Wegel) writes:
>> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> >> Anyway, the normative text of Forth-94/2012 makes this ambiguous, so
>> >> by the text of the standard a standard program must not FIND the
>> >> system's IF (not even in compile state).
>> >
>> >I think the rationale behind these restrictions becomes clear in
>> >D.6.7 Immediacy, where there is an explanation why ' and ['] are not
>> >permitted with compiling words:
>> >They don't return immediacy information, just a bare execution token.
>> >(FIND which doesn't have that shortcoming isn't ruled out there.)
>> >
>> >The good thing is: I'm not attempting to "obtain an execution token",
>> >but to "obtain an execution-token + immediacy-flag pair", so the
>> >paragraph in 4.1.2 doesn't apply. It even makes sense this way ;D
>>
>> That's too much language-lawyering for my taste
>
>Well - there's a smiley. It's a case where lawyering language caused the
>problem (by mistakenly treating FIND like the words that return
>insufficient information) and apparently no system follows it anyway(?),
A system can do anything when encountering an ambiguous condition, so
every system "follows it", because there are no requirements for "it".
>> (plus I doubt that
>> many agree with this reasoning, which would make C" IF" FIND standard,
>> but appending a DROP to it non-standard despite the stack being
>> non-empty).
>
>Which would make perfect sense, because (as i mentioned) the xt alone is
>incomplete information then.
That way madness lies. If you see the standard as discussion subject
for language lawyers, such an interpretation may be of interest, but
system implementors and programmers need something that's more direct.
>> Yes; the non-exhaustive formulation is probably intended to include
>> any such words that are added later;
>
>Which by itself makes more trouble than sense, because words added later
>are purely hypothetical.
Not if you are on the standards committee. We have actually added
NAME>INTERPRET in Forth-2012, but this word explicitly covers the
attempt to use it on a word without interpretation semantics.
>The problem comes from the fact that one xt isn't neccessarily enough to
>fully represent a word (a quick thought: 2 xts would be better).
Take a look at
http://forth-standard.org/standard/tools/NAMEtoINTERPRET
http://forth-standard.org/standard/tools/NAMEtoCOMPILE
Now we just need to standardize FIND-NAME ( c-addr u – nt | 0 ) and
FIND-NAME-IN ( c-addr u wid -- nt | 0 ).
- 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-08 20:02 +0100 |
| Message-ID | <1mzjq6t.d3lry01n7s6dpN%awegel@arcor.de> |
| In reply to | #53858 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > awegel@arcor.de (Alexander Wegel) writes: > >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > > >> awegel@arcor.de (Alexander Wegel) writes: > >> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> >> Anyway, the normative text of Forth-94/2012 makes this ambiguous, so > >> >> by the text of the standard a standard program must not FIND the > >> >> system's IF (not even in compile state). > >> > > >> >I think the rationale behind these restrictions becomes clear in > >> >D.6.7 Immediacy, where there is an explanation why ' and ['] are not > >> >permitted with compiling words: > >> >They don't return immediacy information, just a bare execution token. > >> >(FIND which doesn't have that shortcoming isn't ruled out there.) > >> > > >> >The good thing is: I'm not attempting to "obtain an execution token", > >> >but to "obtain an execution-token + immediacy-flag pair", so the > >> >paragraph in 4.1.2 doesn't apply. It even makes sense this way ;D > >> > >> That's too much language-lawyering for my taste > > > >Well - there's a smiley. It's a case where lawyering language caused the > >problem (by mistakenly treating FIND like the words that return > >insufficient information) and apparently no system follows it anyway(?), > > A system can do anything when encountering an ambiguous condition, so > every system "follows it", because there are no requirements for "it". Sorry - meant to say "apparently no system disallows finding (by using FIND) a word that doesn't have execution semantics". > >> (plus I doubt that > >> many agree with this reasoning, which would make C" IF" FIND standard, > >> but appending a DROP to it non-standard despite the stack being > >> non-empty). > > > >Which would make perfect sense, because (as i mentioned) the xt alone is > >incomplete information then. > > That way madness lies. If you see the standard as discussion subject > for language lawyers, such an interpretation may be of interest, but > system implementors and programmers need something that's more direct. And they might need a way to find words like IF, ;, ['], etc. . Is there *any* reason to declare use of FIND for compile-only words ambiguous (given that its done at compile time)? Or does madness lie there too? What's the reason then that FIND may return different addresses depending on whether the compiler is on or off, if it doesn't mean the distinction between a words compilation- and interpretation semantics? > >> Yes; the non-exhaustive formulation is probably intended to include > >> any such words that are added later; > > > >Which by itself makes more trouble than sense, because words added later > >are purely hypothetical. > > Not if you are on the standards committee. For users of the 94 standard, they are. Further standardization will lead to a new document which will have its own set of special cases, but that's not part of the existing standard. > We have actually added > NAME>INTERPRET in Forth-2012, but this word explicitly covers the > attempt to use it on a word without interpretation semantics. > > >The problem comes from the fact that one xt isn't neccessarily enough to > >fully represent a word (a quick thought: 2 xts would be better). > > Take a look at > > http://forth-standard.org/standard/tools/NAMEtoINTERPRET > http://forth-standard.org/standard/tools/NAMEtoCOMPILE Ok, this gives even more flexibility by returning the semantic eqv. of a closure. The mention of traditional systems there acknowledges that it used to be good enough to know whether a word is immediate or not. > Now we just need to standardize FIND-NAME ( c-addr u â•" nt | 0 ) and > FIND-NAME-IN ( c-addr u wid -- nt | 0 ). Well, yes. This "now" still belongs to the future.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-09 17:53 +0000 |
| Message-ID | <2017Jan9.185327@mips.complang.tuwien.ac.at> |
| In reply to | #53865 |
awegel@arcor.de (Alexander Wegel) writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Is there *any* reason to declare use of FIND for compile-only words
>ambiguous (given that its done at compile time)?
No, it was actually intended that people should be able to write
user-defined text interpreters using FIND, so making FINDing IF
ambiguous was a mistake.
>What's the reason then that FIND may return different addresses
>depending on whether the compiler is on or off, if it doesn't mean the
>distinction between a words compilation- and interpretation semantics?
There is no other reason.
>> >> Yes; the non-exhaustive formulation is probably intended to include
>> >> any such words that are added later;
>> >
>> >Which by itself makes more trouble than sense, because words added later
>> >are purely hypothetical.
>>
>> Not if you are on the standards committee.
>
>For users of the 94 standard, they are.
Once a standard revision is finished, one can write a commented
version that elucidates it to its users by, e.g., enumerating all the
words covered in that sentence.
>Further standardization will lead to a new document which will have its
>own set of special cases, but that's not part of the existing standard.
Actually, Forth-94 did not fall finished from heaven, but was also
developed over a significant number of meetings, so even within a
standard there is a reason to phrase things in a robust non-exhaustive
way rather than a brittle, exhaustive way. Of course, there is also a
reason to phrase it in a concreate, exhaustive way rather than an
abstract non-exhaustive one. So one has to balance these reasons
against each other.
>> We have actually added
>> NAME>INTERPRET in Forth-2012, but this word explicitly covers the
>> attempt to use it on a word without interpretation semantics.
>>
>> >The problem comes from the fact that one xt isn't neccessarily enough to
>> >fully represent a word (a quick thought: 2 xts would be better).
>>
>> Take a look at
>>
>> http://forth-standard.org/standard/tools/NAMEtoINTERPRET
>> http://forth-standard.org/standard/tools/NAMEtoCOMPILE
>
>Ok, this gives even more flexibility by returning the semantic eqv. of a
>closure.
You mean the x result of NAME>COMPILE? Looks like that at first
sight, but we have had that kind of thing in Gforth for 20 years, and
have not found a use for deviating from the scheme of returning an xt
and the xt of EXECUTE or COMPILE,.
- 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-09 20:22 +0100 |
| Message-ID | <1mzloy3.1u557beela829N%awegel@arcor.de> |
| In reply to | #53902 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > awegel@arcor.de (Alexander Wegel) writes: > >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >Is there *any* reason to declare use of FIND for compile-only words > >ambiguous (given that its done at compile time)? > > No, it was actually intended that people should be able to write > user-defined text interpreters using FIND, so making FINDing IF > ambiguous was a mistake. > > >What's the reason then that FIND may return different addresses > >depending on whether the compiler is on or off, if it doesn't mean the > >distinction between a words compilation- and interpretation semantics? > > There is no other reason. > > >> >> Yes; the non-exhaustive formulation is probably intended to include > >> >> any such words that are added later; > >> > > >> >Which by itself makes more trouble than sense, because words added later > >> >are purely hypothetical. > >> > >> Not if you are on the standards committee. > > > >For users of the 94 standard, they are. > > Once a standard revision is finished, one can write a commented > version that elucidates it to its users by, e.g., enumerating all the > words covered in that sentence. Makes sense. Does it exist somewhere? > >Further standardization will lead to a new document which will have its > >own set of special cases, but that's not part of the existing standard. > > Actually, Forth-94 did not fall finished from heaven, but was also > developed over a significant number of meetings, so even within a > standard there is a reason to phrase things in a robust non-exhaustive > way rather than a brittle, exhaustive way. Of course, there is also a > reason to phrase it in a concreate, exhaustive way rather than an > abstract non-exhaustive one. So one has to balance these reasons > against each other. > > >> We have actually added > >> NAME>INTERPRET in Forth-2012, but this word explicitly covers the > >> attempt to use it on a word without interpretation semantics. > >> > >> >The problem comes from the fact that one xt isn't neccessarily enough to > >> >fully represent a word (a quick thought: 2 xts would be better). > >> > >> Take a look at > >> > >> http://forth-standard.org/standard/tools/NAMEtoINTERPRET > >> http://forth-standard.org/standard/tools/NAMEtoCOMPILE > > > >Ok, this gives even more flexibility by returning the semantic eqv. of a > >closure. > > You mean the x result of NAME>COMPILE? No, both x and xt returned by NAME>COMPILE together. > Looks like that at first > sight, but we have had that kind of thing in Gforth for 20 years, and > have not found a use for deviating from the scheme of returning an xt > and the xt of EXECUTE or COMPILE,. There would be an opportunity there to use all kinds of "filters" on the xt, such as inline compile, or decrypt, ... ... but these are just some quick unchecked ideas about the general ability to specify an explicit xt as the compiler. > - anton
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-09 08:04 -0800 |
| Message-ID | <a5649fcd-b10f-4ffb-9b49-d05ac6e309a7@googlegroups.com> |
| In reply to | #53858 |
Am Sonntag, 8. Januar 2017 18:02:05 UTC+1 schrieb Anton Ertl: > > Take a look at > > http://forth-standard.org/standard/tools/NAMEtoINTERPRET > http://forth-standard.org/standard/tools/NAMEtoCOMPILE > > Now we just need to standardize FIND-NAME ( c-addr u – nt | 0 ) and > FIND-NAME-IN ( c-addr u wid -- nt | 0 ). > Sorry for my being blind. But where is the definition of "nt" ? Guessing it means name token as opaque something, in most systems some word header field ?? Currently I am experimenting with a FIND-NAME that returns execution tokens and flags. Used for normal ticking words. But FIND is state-dependent (returns compilation tokens when STATE is <> 0. Makes life easy for POSTPONE and a nicely small outer interpreter loop. So what should those monster words NAME>INTERPRET NAME>COMPILE / FIND-NAME-IN then be useful for ???
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-09 17:04 +0000 |
| Message-ID | <2017Jan9.180413@mips.complang.tuwien.ac.at> |
| In reply to | #53897 |
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.
>Guessing it means name token as opaque something, in most systems some word=
> header field ??
Correct.
>So what should those monster words NAME>INTERPRET NAME>COMPILE / FIND-NAME-=
>IN then be useful for ???
For getting interpretation semantics (NAME>INTERPRET), compilation
semantics (NAME>COMPILE), and for finding a named word in a wordlist
(FIND-NAME-IN). Of course, if you use them all the time, you will
prefer to introduce Thinking-Forth-comformant synonyms for these
words, maybe SNAP, SNIP, and GRIP.
- 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-09 20:22 +0100 |
| Message-ID | <1mzlpoe.lnhx6oswvqblN%awegel@arcor.de> |
| In reply to | #53900 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >So what should those monster words NAME>INTERPRET NAME>COMPILE / FIND-NAME-= > >IN then be useful for ??? Man - first these ambisexual standard fags just produce such huge bloated names and then they disallow using small letters to save space. No wonder forth is still stuck in 18th century. > For getting interpretation semantics (NAME>INTERPRET), compilation > semantics (NAME>COMPILE), and for finding a named word in a wordlist > (FIND-NAME-IN). Of course, if you use them all the time, you will > prefer to introduce Thinking-Forth-comformant synonyms for these > words, maybe SNAP, SNIP, and GRIP. I prefer TICK, TRICK and TRACK, unless they are already standardified. Guess i better add this: ;-)))
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-10 01:41 +0100 |
| Message-ID | <o51akk$5kg$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53900 |
In article <2017Jan9.180413@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >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. That must be "identifies a word". Name token is actually wrong in that it contains "name". That makes one feel obliged to repeat that in "named word". A better name would be "dictionary entry address" (ciforth) or forth object (oforth). Like Lisp, most languages now recognize that there are "objects" in a language that can but need not be identified by name. Modern languages (Python) have a somewhat loose connections between the two like hash tables. Although one needs a name to find an object, there can be several "objects" that have the same name as in : something something CR ; So we must be able to say: the dea of the first 'something' is different from the dea of the second 'something'. Name token sounds very weird in the above sentence. Bearable is : The word identified by the first 'something' is different from the word identified by the second 'something'. Replace word by "named word" in the last sentence and it becomes very strange. > >>Guessing it means name token as opaque something, in most systems some word= >> header field ?? > >Correct. All of the following names are better than "name token": dea, word, token, object, forth object, opaque token, word header > >>So what should those monster words NAME>INTERPRET NAME>COMPILE / FIND-NAME-= >>IN then be useful for ??? > >For getting interpretation semantics (NAME>INTERPRET), compilation >semantics (NAME>COMPILE), and for finding a named word in a wordlist >(FIND-NAME-IN). Of course, if you use them all the time, you will >prefer to introduce Thinking-Forth-comformant synonyms for these >words, maybe SNAP, SNIP, and GRIP. Forths that can change the name of a forth object AAP would have to do "XXX" `AAP NAME>NAME NAME! how weird is that! [Using back-quote here to arrive at the dea/name-token/whatever] Once the opaque token is accepted, it is natural to just use >INTERPRET >COMPILE etc. What, if not an opaque Forth object, could >xxx words work on? > >- 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 | minforth@arcor.de |
|---|---|
| Date | 2017-01-09 22:16 -0800 |
| Message-ID | <a6cad6c1-daf4-4fb5-a05c-61c07eed9e1b@googlegroups.com> |
| In reply to | #53911 |
Am Dienstag, 10. Januar 2017 01:31:37 UTC+1 schrieb Albert van der Horst: > how weird is that! The thing seems really overdone in Forth 2012. It is meant well, but piling introspection and overloading and hidden late binding (comes with non-immediate TOs) on top of each other is totally against Forth's KISS spirit. Anton's careful reading of the standard that COMPILE, should not include compiling the compilation semantics is in the same bag. While it has merit to be conservative in order to "protect" legacy code, sometimes it would be better to be more progressive in order cleanse things out (mark them as obsolete) that had been smart hacks in their time, but were never meant to become standardized in the beginning.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 09:44 +0000 |
| Message-ID | <o52aag$gjj$1@dont-email.me> |
| In reply to | #53911 |
On 1/10/2017 00:41, Albert van der Horst wrote: > In article <2017Jan9.180413@mips.complang.tuwien.ac.at>, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> 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. > > That must be "identifies a word". Name token is actually wrong in > that it contains "name". That makes one feel obliged to repeat that > in "named word". A better name would be "dictionary entry address" > (ciforth) or forth object (oforth). Like Lisp, most languages now > recognize that there are "objects" in a language that can but need > not be identified by name. Modern languages (Python) have a somewhat > loose connections between the two like hash tables. Although one > needs a name to find an object, there can be several "objects" that > have the same name as in : something something CR ; So we must be > able to say: the dea of the first 'something' is different from the > dea of the second 'something'. Name token sounds very weird in the > above sentence. Bearable is : The word identified by the first > 'something' is different from the word identified by the second > 'something'. Replace word by "named word" in the last sentence and it > becomes very strange. Not really. also myvoc definitions previous : x x cr ; There are two words X and two name tokens that can be obtained with FIND-NAME. Without the ALSO etc there is only one X, and the name token refers to it. The same is true of XTs returned by FIND. > >> >>> Guessing it means name token as opaque something, in most systems >>> some word= header field ?? >> >> Correct. > > 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. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-10 15:19 +0100 |
| Message-ID | <o52qhp$8bq$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53922 |
In article <o52aag$gjj$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/10/2017 00:41, Albert van der Horst wrote: <SNIP> >> .............................. Name token sounds very weird in the >> above sentence. Bearable is : The word identified by the first >> 'something' is different from the word identified by the second >> 'something'. Replace word by "named word" in the last sentence and it >> becomes very strange. > >Not really. Let's try it, shall we? The nametoken identified by the first 'something' is different from the nametoken identified by the second 'something'. >also myvoc definitions previous >: x x cr ; > >There are two words X and two name tokens that can be obtained with >FIND-NAME. Without the ALSO etc there is only one X, and the name token >refers to it. The same is true of XTs returned by FIND. > > <SNIP> >> >> 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. A consequence of the generality is that the forth object may have no compilation behaviour, may have an associate body (create) or not, and sometimes, no name. In ciforth the user is entitled to change the name of a forth object. There is nothing strange about that, unless the forth object is a ... name token. We have enough idiosyncracies in Forth already, name token will break the camel's back. There are no tokens in Forth until now. Why not just call it a token? > >-- >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]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 15:24 +0000 |
| Message-ID | <o52u7v$otl$1@dont-email.me> |
| In reply to | #53934 |
On 1/10/2017 14:19, Albert van der Horst wrote: > In article <o52aag$gjj$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 1/10/2017 00:41, Albert van der Horst wrote: > <SNIP> >>> .............................. Name token sounds very weird in the >>> above sentence. Bearable is : The word identified by the first >>> 'something' is different from the word identified by the second >>> 'something'. Replace word by "named word" in the last sentence and it >>> becomes very strange. >> >> Not really. > > Let's try it, shall we? > The nametoken identified by the first 'something' is different from > the nametoken identified by the second 'something'. Replace name token (the aggultionation nametoken is pretty much alien to English) with NT. Then your confusion may be seen as one of constructing an overly complex sentence. "The first X has a different NT (or name token) from the second declaration of X." is better. > >> also myvoc definitions previous >> : x x cr ; >> >> There are two words X and two name tokens that can be obtained with >> FIND-NAME. Without the ALSO etc there is only one X, and the name token >> refers to it. The same is true of XTs returned by FIND. >> >> > <SNIP> >>> >>> 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 > > A consequence of the generality is that the forth object may have no > compilation behaviour, may have an associate body (create) or not, and > sometimes, no name. That's fine. Those that have a name have an NT. No special magic is claimed for naming XTs with no names. > > In ciforth the user is entitled to change the name of a forth object. > There is nothing strange about that, unless the forth object is a ... > name token. > > We have enough idiosyncracies in Forth already, name token will > break the camel's back. > > There are no tokens in Forth until now. Why not just call it a token? XT is execution token; it's been named as such since Adam was a boy. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 15:35 +0000 |
| Message-ID | <o52ust$rhg$1@dont-email.me> |
| In reply to | #53936 |
On 1/10/2017 15:24, Alex wrote: > the aggultionation nametoken . ^^^^^^^^^^^^^^ I meant agglutination. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-10 22:12 +0100 |
| Message-ID | <o53iob$4v5$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53936 |
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 -- 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-10 22:42 +0000 |
| Message-ID | <o53ntd$r6m$1@dont-email.me> |
| In reply to | #53938 |
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. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-11 00:23 +0100 |
| Message-ID | <o53qdg$5el$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53939 |
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. >-- >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-10 23:35 +0000 |
| Message-ID | <o53r08$7gi$1@dont-email.me> |
| In reply to | #53940 |
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
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-10 23:38 -0800 |
| Message-ID | <7a89349a-81f6-4dc7-a4a0-7c99c46c38be@googlegroups.com> |
| In reply to | #53941 |
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. 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.
[toc] | [prev] | [next] | [standalone]
Page 2 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