Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #132291
| From | Ruvim <ruvim.pinka@gmail.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: single-xt approach in the standard |
| Date | 2024-09-23 01:15 +0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <vcq1e5$25spg$7@dont-email.me> (permalink) |
| References | <vcbn5e$3etuk$1@dont-email.me> <1a3ebf77c1ed8926d455a268e1309fe0@www.novabbs.com> <vcbuog$3etuk$3@dont-email.me> <nnd$0f2e6033$478228ed@d9a7750878a12d98> |
On 2024-09-22 13:53, albert@spenarnc.xs4all.nl wrote: > In article <vcbuog$3etuk$3@dont-email.me>, > Ruvim <ruvim.pinka@gmail.com> wrote: >> On 2024-09-17 16:15, mhx wrote: >>> On Tue, 17 Sep 2024 10:54:37 +0000, Ruvim wrote: >>> >>>> Do you think that the Forth standard should recognize the classic >>>> single-xt approach as possible for implementing a standard Forth system? >>>> >>>> The classic single-xt approach implies that only one execution token >>>> (xt) is associated with a name token (nt), and only one name token is >>>> associated with a word (a named Forth definition). And words whose >>>> compilation semantics differ form default compilation semantics are >>>> implemented as immediate words. >>> [...] >> >> The single-xt approach was used in Forth systems long before Forth-94. >> Should this approach be possible for a standard system? >> >> There is a point of view (which I don't share) that it is impossible to >> implement the standard word `s"` (from the File word set) in a standard >> *program*. I.e., that the following definition for `s"` is not standard >> compliant: >> >> : s" ( "ccc" -- sd | ) >> [char] " parse >> state @ if postpone sliteral exit then >> dup >r allocate throw tuck r@ move r> >> ; immediate > > /*****************************************************************************/ > /* This is not true. */ > /*****************************************************************************/ > > I have demonstrated that it is possible to make numbers state smart > (the excursion to S" serves only to muddy the waters) where > the definition of number or S" doesn't contain a reference to STATE. It seems, you have misunderstood what I said. I have said "in a standard *program*", not "in a standard system". This is important for standard libraries that may need to define or redefine some standard words. Here by standard library I mean a standard program that, when loaded, does not make the standard system non-standard. See also "4.2.2 Other program documentation", that says: | A program shall also document: | - whether a Standard System exists after the program is loaded. >>> What some of my customers tried is, by using standard words, associate >>> generated code sequences with an xt (nearly impossible), >> >>> or infer an nt from an xt (which is not 1-to-n [n>=3], and asymmetrical). >> >> Even in some classic single-xt systems, one xt can be associated with >> many nt. (of course, what is now "nt" was known as "NFA"). > > I cringe on this formulation. This is what the standard says. Namely, the section "3.1.3.5 Execution tokens" says: "Different definitions may have the same execution token if the definitions are equivalent". For example: 1 constant a 1 constant b ' a ' b = . It is possible for a standard system to print "-1" when interpreting this program. [...] -- Ruvim
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 14:54 +0400
Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-17 11:20 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 15:59 +0400
Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-17 14:58 -0400
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-18 13:39 +1000
Standardization process (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 11:07 +0400
Re: Standardization process dxf <dxforth@gmail.com> - 2024-09-18 20:16 +1000
Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 14:51 +0400
Re: Standardization process dxf <dxforth@gmail.com> - 2024-09-18 23:39 +1000
Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 18:41 +0400
Re: Standardization process Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 15:59 +0400
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 12:44 +0400
Re: single-xt approach in the standard Gerry Jackson <do-not-use@swldwa.uk> - 2024-09-18 21:59 +0100
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-19 10:17 +0200
Standard testsuite (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-19 12:24 +0400
Re: Standard testsuite (was: single-xt approach in the standard) albert@spenarnc.xs4all.nl - 2024-09-19 10:54 +0200
Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-17 12:15 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 17:04 +0400
Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-17 13:58 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-17 18:55 +0400
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-17 17:22 +0200
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-21 12:51 +1000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-21 15:42 +0400
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-22 12:15 +1000
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 07:54 +0000
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 12:05 +0200
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-23 13:34 +1000
Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-23 10:45 -0400
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-24 14:50 +1000
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-25 10:35 +1000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 20:57 +0400
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 17:13 +0000
Semantics as observable behavior (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 23:53 +0400
Re: Semantics as observable behavior (was: single-xt approach in the standard) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 21:04 +0000
Re: Semantics as observable behavior Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 02:01 +0400
Re: Semantics as observable behavior Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 11:36 +0400
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 21:34 +0200
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 00:02 +0400
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 09:40 +0200
Re: single-xt approach in the standard minforth@gmx.net (minforth) - 2024-09-23 08:42 +0000
Re: single-xt approach in the standard dxf <dxforth@gmail.com> - 2024-09-23 15:28 +1000
Standard compliance for systems (was: single-xt approach in the standard) Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 10:56 +0400
Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-22 16:49 +1100
Re: Standard compliance for systems minforth@gmx.net (minforth) - 2024-11-22 10:11 +0000
Re: Standard compliance for systems mhx@iae.nl (mhx) - 2024-11-22 11:35 +0000
Re: Standard compliance for systems minforth@gmx.net (minforth) - 2024-11-22 13:11 +0000
Re: Standard compliance for systems mhx@iae.nl (mhx) - 2024-11-22 15:26 +0000
Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-23 11:54 +1100
Re: Standard compliance for systems albert@spenarnc.xs4all.nl - 2024-11-23 14:09 +0100
Re: Standard compliance for systems dxf <dxforth@gmail.com> - 2024-11-24 12:02 +1100
Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-21 14:47 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-21 23:18 +0400
Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-22 12:09 +0000
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 14:28 +0000
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 21:20 +0200
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-22 11:53 +0200
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 01:15 +0400
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 10:36 +0200
Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-23 09:32 +0000
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-23 13:57 +0200
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-23 17:02 +0000
Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-23 19:20 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 14:16 +0400
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-23 16:52 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-25 11:27 +0400
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-17 17:18 +0200
Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-17 15:12 -0400
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-17 19:25 +0000
Re: single-xt approach in the standard Anthony Howe <achowe@snert.com> - 2024-09-24 07:08 -0400
Re: single-xt approach in the standard Stephen Pelc <stephen@vfxforth.com> - 2024-09-17 23:04 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 10:10 +0400
Re: single-xt approach in the standard mhx@iae.nl (mhx) - 2024-09-18 06:38 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-19 12:26 +0400
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 14:34 +0400
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 16:41 +0400
Re: single-xt approach in the standard Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-18 18:43 +0200
Re: single-xt approach in the standard albert@spenarnc.xs4all.nl - 2024-09-19 10:36 +0200
Re: single-xt approach in the standard Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-20 14:58 +0200
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-17 21:15 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-18 12:15 +0400
Re: single-xt approach in the standard peter.m.falth@gmail.com (PMF) - 2024-09-21 21:28 +0000
Re: single-xt approach in the standard anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-22 07:23 +0000
Re: single-xt approach in the standard Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 21:34 +0400
csiph-web