Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #131609 > unrolled thread
| Started by | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| First post | 2024-06-25 18:25 -0500 |
| Last post | 2024-09-23 00:21 +0400 |
| Articles | 20 on this page of 67 — 11 participants |
Back to article view | Back to comp.lang.forth
0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-25 18:25 -0500
Re: 0 SET-ORDER why? minforth@gmx.net (minforth) - 2024-06-26 01:19 +0000
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-26 11:12 +0200
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-26 05:54 -0500
Re: 0 SET-ORDER why? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-06-26 07:49 +0000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-26 18:50 +1000
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-06-26 17:36 +0400
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-27 13:19 +1000
Re: 0 SET-ORDER why? Gerry Jackson <do-not-use@swldwa.uk> - 2024-06-27 23:10 +0100
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-28 11:56 +1000
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-06-28 13:51 +0400
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-28 22:19 +1000
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-06-28 17:48 +0400
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-29 03:08 +1000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-01 18:45 +1000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-29 13:27 +1000
Re: 0 SET-ORDER why? Gerry Jackson <do-not-use@swldwa.uk> - 2024-06-27 05:14 +0100
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-27 11:05 +0200
Re: 0 SET-ORDER why? minforth@gmx.net (minforth) - 2024-06-27 13:00 +0000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-27 22:41 +1000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-27 14:09 -0500
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-27 14:22 -0500
Re: 0 SET-ORDER why? Gerry Jackson <do-not-use@swldwa.uk> - 2024-06-27 23:08 +0100
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-27 18:44 -0500
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-28 15:51 +1000
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-28 10:04 +0200
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-29 09:09 -0500
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-30 12:22 +0200
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-06-28 14:20 +0400
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-28 21:45 +0200
Recognizer protocol (was: 0 SET-ORDER why?) Ruvim <ruvim.pinka@gmail.com> - 2024-06-29 02:27 +0400
Re: 0 SET-ORDER why? Gerry Jackson <do-not-use@swldwa.uk> - 2024-07-04 07:26 +0100
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-26 11:18 +0200
Re: 0 SET-ORDER why? minforth@gmx.net (minforth) - 2024-06-26 10:36 +0000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-26 06:13 -0500
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-26 05:56 -0500
Re: 0 SET-ORDER why? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-06-28 15:50 +0000
Re: 0 SET-ORDER why? Hans Bezemer <the.beez.speaks@gmail.com> - 2024-06-28 18:39 +0200
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-29 09:17 -0500
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-06-30 12:21 +1000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-30 11:10 -0500
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-30 11:16 -0500
Re: 0 SET-ORDER why? minforth@gmx.net (minforth) - 2024-06-30 17:38 +0000
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-06-30 20:25 +0200
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-30 13:31 -0500
Re: 0 SET-ORDER why? minforth@gmx.net (minforth) - 2024-06-30 20:37 +0000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-06-30 20:49 -0500
Re: 0 SET-ORDER why? mhx@iae.nl (mhx) - 2024-07-01 07:06 +0000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-07-01 05:06 -0500
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-07-01 13:35 +0200
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-07-01 13:02 +0400
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-07-01 05:13 -0500
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-01 21:02 +1000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-02 15:56 +1000
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-07-02 20:04 -0500
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-03 12:32 +1000
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-07-03 11:59 +0200
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-04 00:46 +1000
Re: 0 SET-ORDER why? albert@spenarnc.xs4all.nl - 2024-07-01 13:39 +0200
Re: 0 SET-ORDER why? sjack@dontemail.me (sjack) - 2024-07-02 14:29 +0000
Re: 0 SET-ORDER why? dxf <dxforth@gmail.com> - 2024-07-03 00:52 +1000
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-07-02 17:42 +0400
Re: 0 SET-ORDER why? Krishna Myneni <krishna.myneni@ccreweb.org> - 2024-07-02 20:17 -0500
Re: 0 SET-ORDER why? Anthony Howe <achowe@snert.com> - 2024-09-21 15:37 -0400
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-09-22 21:52 +0400
Re: 0 SET-ORDER why? Anthony Howe <achowe@snert.com> - 2024-09-22 14:02 -0400
Re: 0 SET-ORDER why? Ruvim <ruvim.pinka@gmail.com> - 2024-09-23 00:21 +0400
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-27 14:09 -0500 |
| Message-ID | <v5kde0$2sasd$1@dont-email.me> |
| In reply to | #131621 |
On 6/26/24 23:14, Gerry Jackson wrote: > On 26/06/2024 14:36, Ruvim wrote: >> One possible use case: >> >> : turnkey ( -- ) 0 set-order >> also Target definitions >> also Minimal also >> ; > > ALSO duplicates the wordlist at the head of the search order. If the > search order is empty there is nothing to duplicate. Therefore ALSO > applied to an empty search order ought to be an ambiguous condition. > > Presumably the above definition works because a target wordlist replaces > whatever garbage ALSO leaves in the search order. So the definition > might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. > Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above > justification for 0 SET-ORDER. > Good analysis showing that 1) The definition of TURNKEY is flawed. 2) 0 SET-ORDER is not necessary. > But having said that it is better for 0 SET-ORDER to do what is natural > instead of yet another ambiguous condition. > > > Another possible use case: > > > > : s-to-n ( addr u -- n ) > > depth >r > > get-order n>r 0 set-order > > ['] evaluate ['] execute-interpreting catch > > nr> set-order > > depth 1- r> <> if -12 throw then > > ; > > This is a better use case e.g. if BASE is greater than decimal 10 > converting an alphanumeric string to a number could clash with a word in > the dictionary. Having an empty search order eliminates that possibility. > This use case is convoluted and there may be a better of dealing with the anticipated problem. If not, we should consider what's missing in Forth allowing us to solve the problem more directly. No one has pointed to a need for 0 SET-ORDER in interpretation state, and there is no to undo its use in interpretation state in a standard. Furthermore an empty search order contradicts the concept of a minimum search order. The solutions are: 1) leave everything as is, and live with the contradiction and the hazard of performing 0 SET-ORDER in interpretation state. 2) make SET-ORDER state-smart, and live with the contradiction. This will potentially break code. 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. Am I missing any other options? Personally, I favor 3) -- throwing an error when zero is an argument to SET-ORDER. -- Krishna Personally 2)
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-27 14:22 -0500 |
| Message-ID | <v5ke5a$2sasd$2@dont-email.me> |
| In reply to | #131625 |
On 6/27/24 14:09, Krishna Myneni wrote: > On 6/26/24 23:14, Gerry Jackson wrote: >> On 26/06/2024 14:36, Ruvim wrote: >>> One possible use case: >>> >>> : turnkey ( -- ) 0 set-order >>> also Target definitions >>> also Minimal also >>> ; >> >> ALSO duplicates the wordlist at the head of the search order. If the >> search order is empty there is nothing to duplicate. Therefore ALSO >> applied to an empty search order ought to be an ambiguous condition. >> >> Presumably the above definition works because a target wordlist >> replaces whatever garbage ALSO leaves in the search order. So the >> definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. >> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above >> justification for 0 SET-ORDER. >> > > Good analysis showing that > > 1) The definition of TURNKEY is flawed. > > 2) 0 SET-ORDER is not necessary. > > >> But having said that it is better for 0 SET-ORDER to do what is >> natural instead of yet another ambiguous condition. >> >> > Another possible use case: >> > >> > : s-to-n ( addr u -- n ) >> > depth >r >> > get-order n>r 0 set-order >> > ['] evaluate ['] execute-interpreting catch >> > nr> set-order >> > depth 1- r> <> if -12 throw then >> > ; >> >> This is a better use case e.g. if BASE is greater than decimal 10 >> converting an alphanumeric string to a number could clash with a word >> in the dictionary. Having an empty search order eliminates that >> possibility. >> > > This use case is convoluted and there may be a better of dealing with > the anticipated problem. If not, we should consider what's missing in > Forth allowing us to solve the problem more directly. > > > No one has pointed to a need for 0 SET-ORDER in interpretation state, > and there is no to undo its use in interpretation state in a standard. > Furthermore an empty search order contradicts the concept of a minimum > search order. > > The solutions are: > > 1) leave everything as is, and live with the contradiction and the > hazard of performing 0 SET-ORDER in interpretation state. > > 2) make SET-ORDER state-smart, and live with the contradiction. This > will potentially break code. > > 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. > > Am I missing any other options? > > Personally, I favor 3) -- throwing an error when zero is an argument to > SET-ORDER. > Edits: No one has pointed to a need for 0 SET-ORDER in interpretation state, and there is no standard way to undo its use in interpretation state. 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. This will break existing code where zero is an argument to SET-ORDER. Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have ever used it in a definition. -- KM
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <do-not-use@swldwa.uk> |
|---|---|
| Date | 2024-06-27 23:08 +0100 |
| Message-ID | <v5knsk$2tvp8$1@dont-email.me> |
| In reply to | #131626 |
On 27/06/2024 20:22, Krishna Myneni wrote: > On 6/27/24 14:09, Krishna Myneni wrote: >> On 6/26/24 23:14, Gerry Jackson wrote: >>> On 26/06/2024 14:36, Ruvim wrote: >>>> One possible use case: >>>> >>>> : turnkey ( -- ) 0 set-order >>>> also Target definitions >>>> also Minimal also >>>> ; >>> >>> ALSO duplicates the wordlist at the head of the search order. If the >>> search order is empty there is nothing to duplicate. Therefore ALSO >>> applied to an empty search order ought to be an ambiguous condition. >>> >>> Presumably the above definition works because a target wordlist >>> replaces whatever garbage ALSO leaves in the search order. So the >>> definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. >>> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above >>> justification for 0 SET-ORDER. >>> >> >> Good analysis showing that >> >> 1) The definition of TURNKEY is flawed. >> >> 2) 0 SET-ORDER is not necessary. >> >> >>> But having said that it is better for 0 SET-ORDER to do what is >>> natural instead of yet another ambiguous condition. >>> >>> > Another possible use case: >>> > >>> > : s-to-n ( addr u -- n ) >>> > depth >r >>> > get-order n>r 0 set-order >>> > ['] evaluate ['] execute-interpreting catch >>> > nr> set-order >>> > depth 1- r> <> if -12 throw then >>> > ; >>> >>> This is a better use case e.g. if BASE is greater than decimal 10 >>> converting an alphanumeric string to a number could clash with a word >>> in the dictionary. Having an empty search order eliminates that >>> possibility. >>> >> >> This use case is convoluted and there may be a better of dealing with >> the anticipated problem. >> It has been a real problem, years ago I compiled some preset data in Hex (before the $ prefix was standardised). Something like A5 c, 13 c, D0 c, ... and the application worked on a number of systems and then crashed on another standard system. On investigation I found that D0 was a defined word in that system - hence a crash. OK the $ prefix solves that but not the general problem e.g. BASE = #24 say >> If not, we should consider what's missing in >> Forth allowing us to solve the problem more directly. >> >> >> No one has pointed to a need for 0 SET-ORDER in interpretation state, >> and there is no to undo its use in interpretation state in a standard. >> Furthermore an empty search order contradicts the concept of a minimum >> search order. >> >> The solutions are: >> >> 1) leave everything as is, and live with the contradiction and the >> hazard of performing 0 SET-ORDER in interpretation state. I favour this, there are other ways of achieving the effect of 0 SET-ORDER in interpretation mode, for example 1) WORDLIST 1 SET-ORDER 2) Using PREVIOUS on a search order of FORTH-WORDLIST only (assuming FORTH-WORDLIST contains PREVIOUS) 3) ... I suspect trying to ban every possibility isn't worth it >> >> 2) make SET-ORDER state-smart, and live with the contradiction. This >> will potentially break code. >> >> 3) disallow zero as an argument to SET-ORDER e.g. throw an error for >> zero. >> >> Am I missing any other options? >> >> Personally, I favor 3) -- throwing an error when zero is an argument >> to SET-ORDER. >> > > Edits: > > No one has pointed to a need for 0 SET-ORDER in interpretation state, > and there is no standard way to undo its use in interpretation state. > > 3) disallow zero as an argument to SET-ORDER e.g. throw an error for > zero. This will break existing code where zero is an argument to SET-ORDER. > > Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have > ever used it in a definition. > > -- > KM > -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-27 18:44 -0500 |
| Message-ID | <v5ktgo$2vh04$1@dont-email.me> |
| In reply to | #131627 |
On 6/27/24 17:08, Gerry Jackson wrote: > On 27/06/2024 20:22, Krishna Myneni wrote: ... >>> The solutions are: >>> >>> 1) leave everything as is, and live with the contradiction and the >>> hazard of performing 0 SET-ORDER in interpretation state. > > I favour this, there are other ways of achieving the effect of > 0 SET-ORDER in interpretation mode, for example > > 1) WORDLIST 1 SET-ORDER > > 2) Using PREVIOUS on a search order of FORTH-WORDLIST only (assuming > FORTH-WORDLIST contains PREVIOUS) > > 3) ... > > I suspect trying to ban every possibility isn't worth it > Since SET-ORDER is a standardized word and changing its behavior would break existing code, it's not the right approach anyway. The options 2--3 are really for suggesting another word which has the behavior of SET-ORDER except for the zero arg case. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-06-28 15:51 +1000 |
| Message-ID | <667e4f74$1@news.ausics.net> |
| In reply to | #131626 |
On 28/06/2024 5:22 am, Krishna Myneni wrote: > On 6/27/24 14:09, Krishna Myneni wrote: >> On 6/26/24 23:14, Gerry Jackson wrote: >>> On 26/06/2024 14:36, Ruvim wrote: >>>> One possible use case: >>>> >>>> : turnkey ( -- ) 0 set-order >>>> also Target definitions >>>> also Minimal also >>>> ; >>> >>> ALSO duplicates the wordlist at the head of the search order. If the search order is empty there is nothing to duplicate. Therefore ALSO applied to an empty search order ought to be an ambiguous condition. >>> >>> Presumably the above definition works because a target wordlist replaces whatever garbage ALSO leaves in the search order. So the definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. >>> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above justification for 0 SET-ORDER. >>> >> >> Good analysis showing that >> >> 1) The definition of TURNKEY is flawed. >> >> 2) 0 SET-ORDER is not necessary. >> >> >>> But having said that it is better for 0 SET-ORDER to do what is natural instead of yet another ambiguous condition. >>> >>> > Another possible use case: >>> > >>> > : s-to-n ( addr u -- n ) >>> > depth >r >>> > get-order n>r 0 set-order >>> > ['] evaluate ['] execute-interpreting catch >>> > nr> set-order >>> > depth 1- r> <> if -12 throw then >>> > ; >>> >>> This is a better use case e.g. if BASE is greater than decimal 10 converting an alphanumeric string to a number could clash with a word in the dictionary. Having an empty search order eliminates that possibility. >>> >> >> This use case is convoluted and there may be a better of dealing with the anticipated problem. If not, we should consider what's missing in Forth allowing us to solve the problem more directly. >> >> >> No one has pointed to a need for 0 SET-ORDER in interpretation state, and there is no to undo its use in interpretation state in a standard. Furthermore an empty search order contradicts the concept of a minimum search order. >> >> The solutions are: >> >> 1) leave everything as is, and live with the contradiction and the hazard of performing 0 SET-ORDER in interpretation state. >> >> 2) make SET-ORDER state-smart, and live with the contradiction. This will potentially break code. >> >> 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. >> >> Am I missing any other options? >> >> Personally, I favor 3) -- throwing an error when zero is an argument to SET-ORDER. >> > > Edits: > > No one has pointed to a need for 0 SET-ORDER in interpretation state, > and there is no standard way to undo its use in interpretation state. > > 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. This will break existing code where zero is an argument to SET-ORDER. > > Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have ever used it in a definition. It appears this topic has come up before: https://groups.google.com/g/comp.lang.forth/c/Kku0wXJ8zMs/m/CgWkZ7Kl_EMJ Other posts I've seen suggest Mitch Bradley may have been behind GET-ORDER SET-ORDER (originally a fix for ONLY/ALSO). May be worth contacting him.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-06-28 10:04 +0200 |
| Message-ID | <nnd$07f26f86$612e2929@ca2a9592545c69cd> |
| In reply to | #131625 |
In article <v5kde0$2sasd$1@dont-email.me>, Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >On 6/26/24 23:14, Gerry Jackson wrote: >> On 26/06/2024 14:36, Ruvim wrote: >>> One possible use case: >>> >>> : turnkey ( -- ) 0 set-order >>> also Target definitions >>> also Minimal also >>> ; >> >> ALSO duplicates the wordlist at the head of the search order. If the >> search order is empty there is nothing to duplicate. Therefore ALSO >> applied to an empty search order ought to be an ambiguous condition. >> >> Presumably the above definition works because a target wordlist replaces >> whatever garbage ALSO leaves in the search order. So the definition >> might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. >> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above >> justification for 0 SET-ORDER. >> > >Good analysis showing that > >1) The definition of TURNKEY is flawed. > >2) 0 SET-ORDER is not necessary. > > >> But having said that it is better for 0 SET-ORDER to do what is natural >> instead of yet another ambiguous condition. >> >> > Another possible use case: >> > >> > : s-to-n ( addr u -- n ) >> > depth >r >> > get-order n>r 0 set-order >> > ['] evaluate ['] execute-interpreting catch >> > nr> set-order >> > depth 1- r> <> if -12 throw then >> > ; >> >> This is a better use case e.g. if BASE is greater than decimal 10 >> converting an alphanumeric string to a number could clash with a word in >> the dictionary. Having an empty search order eliminates that possibility. >> > >This use case is convoluted and there may be a better of dealing with >the anticipated problem. If not, we should consider what's missing in >Forth allowing us to solve the problem more directly. > > >No one has pointed to a need for 0 SET-ORDER in interpretation state, >and there is no to undo its use in interpretation state in a standard. >Furthermore an empty search order contradicts the concept of a minimum >search order. > >The solutions are: > >1) leave everything as is, and live with the contradiction and the >hazard of performing 0 SET-ORDER in interpretation state. > >2) make SET-ORDER state-smart, and live with the contradiction. This >will potentially break code. > >3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. > >Am I missing any other options? 4) Use wordlists as a pure stack. Also ASSEMBLER .. PREVIOUS. Define the minumum search order as only handling numbers and other constants. Declare SET-ORDER and GET-ORDER obsolete. > >Personally, I favor 3) -- throwing an error when zero is an argument to >SET-ORDER. > >-- >Krishna > >Personally > > >2) -- Don't praise the day before the evening. One swallow doesn't make spring. You must not say "hey" before you have crossed the bridge. Don't sell the hide of the bear until you shot it. Better one bird in the hand than ten in the air. First gain is a cat purring. - the Wise from Antrim -
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-29 09:09 -0500 |
| Message-ID | <v5p4ir$3utd9$1@dont-email.me> |
| In reply to | #131632 |
On 6/28/24 03:04, albert@spenarnc.xs4all.nl wrote: > In article <v5kde0$2sasd$1@dont-email.me>, > Krishna Myneni <krishna.myneni@ccreweb.org> wrote: ... >> The solutions are: >> >> 1) leave everything as is, and live with the contradiction and the >> hazard of performing 0 SET-ORDER in interpretation state. >> >> 2) make SET-ORDER state-smart, and live with the contradiction. This >> will potentially break code. >> >> 3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. >> >> Am I missing any other options? > > 4) Use wordlists as a pure stack. Also ASSEMBLER .. PREVIOUS. > Define the minumum search order as only handling numbers and other constants. > Declare SET-ORDER and GET-ORDER obsolete. > The whole Search Order word set is clunky and has a cobbled together feel about it. It is also difficult to integrate a named modules system into which provides Public/Private definitions into the standard words e.g. making ORDER list the names of the modules isn't easy. A stack model for the search order may be the way to go. It would be more intuitive to Forth users than having to remember ONLY ALSO PREVIOUS etc. Currently the standard defines what a minimum search order should contain but then promptly disregards it by standardizing 0 SET-ORDER. This is dangerous in interpretation mode, and, while it may have uses in compilation mode, within a definition where the prior search order can be restored (or not), the notion of a well-defined minimum search order should be a strong guarantee to the Forth programmer and not allowed to be violated easily. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-06-30 12:22 +0200 |
| Message-ID | <nnd$56a17670$6eff2ad9@36d7c0208a73e472> |
| In reply to | #131643 |
In article <v5p4ir$3utd9$1@dont-email.me>, Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >On 6/28/24 03:04, albert@spenarnc.xs4all.nl wrote: >> In article <v5kde0$2sasd$1@dont-email.me>, >> Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >... >The whole Search Order word set is clunky and has a cobbled together >feel about it. It is also difficult to integrate a named modules system >into which provides Public/Private definitions into the standard words >e.g. making ORDER list the names of the modules isn't easy. > >A stack model for the search order may be the way to go. It would be >more intuitive to Forth users than having to remember ONLY ALSO PREVIOUS >etc. > >Currently the standard defines what a minimum search order should >contain but then promptly disregards it by standardizing 0 SET-ORDER. >This is dangerous in interpretation mode, and, while it may have uses in >compilation mode, within a definition where the prior search order can >be restored (or not), the notion of a well-defined minimum search order >should be a strong guarantee to the Forth programmer and not allowed to >be violated easily. I have taken the liberty to replace VOCABULARY with NAMESPACE in ciforth. NAMESPACE is a named wordlist that pushes itself to the search order. If you formulate it an archaic way, "ALSO is put in the body of the CREATE DOES> word NAMESPACE." In fact in this approach, `ALSO is all but superfluous. It is from the time, one had merely two slots for wordlists. Wordlist's , namespaces that have itself no name, are so akward. >-- >Krishna Groetjes Albert -- Don't praise the day before the evening. One swallow doesn't make spring. You must not say "hey" before you have crossed the bridge. Don't sell the hide of the bear until you shot it. Better one bird in the hand than ten in the air. First gain is a cat purring. - the Wise from Antrim -
[toc] | [prev] | [next] | [standalone]
| From | Ruvim <ruvim.pinka@gmail.com> |
|---|---|
| Date | 2024-06-28 14:20 +0400 |
| Message-ID | <v5m2po$3811n$2@dont-email.me> |
| In reply to | #131621 |
On 2024-06-27 08:14, Gerry Jackson wrote:
> On 26/06/2024 14:36, Ruvim wrote:
>> One possible use case:
>>
>> : turnkey ( -- ) 0 set-order
>> also Target definitions
>> also Minimal also
>> ;
>
> ALSO duplicates the wordlist at the head of the search order. If the
> search order is empty there is nothing to duplicate. Therefore ALSO
> applied to an empty search order ought to be an ambiguous condition.
Agree. This code is formally incorrect.
An ambiguous condition should be declared for ALSO
when the search order is empty.
I collect such cases at
<https://github.com/ForthHub/standard-evolution/issues/5>
Then a proposal should be prepared.
>
> Presumably the above definition works because a target wordlist replaces
> whatever garbage ALSO leaves in the search order. So the definition
> might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
> justification for 0 SET-ORDER.
As I later discovered, this "turnkey" is from Gforth, and it was corrected:
<https://github.com/forthy42/gforth/blob/ba915873/cross.fs#L4570>
> But having said that it is better for 0 SET-ORDER to do what is natural
> instead of yet another ambiguous condition.
>
> > Another possible use case:
> >
> > : s-to-n ( addr u -- n )
> > depth >r
> > get-order n>r 0 set-order
> > ['] evaluate ['] execute-interpreting catch
> > nr> set-order
> > depth 1- r> <> if -12 throw then
> > ;
There is a mistake (due to additions in my old example)
A corrected variant:
: s-to-n ( addr u -- x )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order throw
depth 1+ r> <> if -12 throw then
;
>
> This is a better use case e.g. if BASE is greater than decimal 10
> converting an alphanumeric string to a number could clash with a word in
> the dictionary. Having an empty search order eliminates that possibility.
>
> Incidentally another possibility is that if ['] EVALUATE is replaced in
> the above definition with ['] SOME-RECOGNISER, that could be the basis
> for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
> recogniser fails restore the search order and try again.
My position is that no recognizer can have side effects (other then
items on the data stack and/or floating-point stack).
Although, this approach can be used to *implement* SOME-RECOGNISER.
--
Ruvim
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-06-28 21:45 +0200 |
| Message-ID | <nnd$7870c3ff$439130c9@777992005d4c8114> |
| In reply to | #131634 |
In article <v5m2po$3811n$2@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote: >On 2024-06-27 08:14, Gerry Jackson wrote: >> On 26/06/2024 14:36, Ruvim wrote: >>> One possible use case: >>> >>> : turnkey ( -- ) 0 set-order >>> also Target definitions >>> also Minimal also >>> ; >> >> ALSO duplicates the wordlist at the head of the search order. If the >> search order is empty there is nothing to duplicate. Therefore ALSO >> applied to an empty search order ought to be an ambiguous condition. > >Agree. This code is formally incorrect. > >An ambiguous condition should be declared for ALSO >when the search order is empty. > >I collect such cases at ><https://github.com/ForthHub/standard-evolution/issues/5> > >Then a proposal should be prepared. > > >> >> Presumably the above definition works because a target wordlist replaces >> whatever garbage ALSO leaves in the search order. So the definition >> might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO. >> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above >> justification for 0 SET-ORDER. > >As I later discovered, this "turnkey" is from Gforth, and it was corrected: ><https://github.com/forthy42/gforth/blob/ba915873/cross.fs#L4570> > > >> But having said that it is better for 0 SET-ORDER to do what is natural >> instead of yet another ambiguous condition. >> >> > Another possible use case: >> > >> > : s-to-n ( addr u -- n ) >> > depth >r >> > get-order n>r 0 set-order >> > ['] evaluate ['] execute-interpreting catch >> > nr> set-order >> > depth 1- r> <> if -12 throw then >> > ; > >There is a mistake (due to additions in my old example) > >A corrected variant: > > : s-to-n ( addr u -- x ) > depth >r > get-order n>r 0 set-order > ['] evaluate ['] execute-interpreting catch > nr> set-order throw > depth 1+ r> <> if -12 throw then > ; > > >> >> This is a better use case e.g. if BASE is greater than decimal 10 >> converting an alphanumeric string to a number could clash with a word in >> the dictionary. Having an empty search order eliminates that possibility. >> >> Incidentally another possibility is that if ['] EVALUATE is replaced in >> the above definition with ['] SOME-RECOGNISER, that could be the basis >> for an ANS/FORTH 2012 compatible way of implementing recognisers. If the >> recogniser fails restore the search order and try again. > > >My position is that no recognizer can have side effects (other then >items on the data stack and/or floating-point stack). I second that. Moreover the items would have to be the same in interpret and compilation mode. At least as a starting point, otherwise Forth degenerates to a tangled web of special purpose interpreters. > >Although, this approach can be used to *implement* SOME-RECOGNISER. > > >-- >Ruvim -- Don't praise the day before the evening. One swallow doesn't make spring. You must not say "hey" before you have crossed the bridge. Don't sell the hide of the bear until you shot it. Better one bird in the hand than ten in the air. First gain is a cat purring. - the Wise from Antrim -
[toc] | [prev] | [next] | [standalone]
| From | Ruvim <ruvim.pinka@gmail.com> |
|---|---|
| Date | 2024-06-29 02:27 +0400 |
| Subject | Recognizer protocol (was: 0 SET-ORDER why?) |
| Message-ID | <v5ndch$3d9d8$1@dont-email.me> |
| In reply to | #131640 |
On 2024-06-28 23:45, albert@spenarnc.xs4all.nl wrote: > In article <v5m2po$3811n$2@dont-email.me>, > Ruvim <ruvim.pinka@gmail.com> wrote: >> On 2024-06-27 08:14, Gerry Jackson wrote: [...] >> A corrected variant: >> >> : s-to-n ( addr u -- x ) >> depth >r >> get-order n>r 0 set-order >> ['] evaluate ['] execute-interpreting catch >> nr> set-order throw >> depth 1+ r> <> if -12 throw then >> ; >> >> >>> >>> This is a better use case e.g. if BASE is greater than decimal 10 >>> converting an alphanumeric string to a number could clash with a word in >>> the dictionary. Having an empty search order eliminates that possibility. >>> >>> Incidentally another possibility is that if ['] EVALUATE is replaced in >>> the above definition with ['] SOME-RECOGNISER, that could be the basis >>> for an ANS/FORTH 2012 compatible way of implementing recognisers. If the >>> recogniser fails restore the search order and try again. >> >> >> My position is that no recognizer can have side effects (other then >> items on the data stack and/or floating-point stack). > I second that. My rationale: "Recognizer protocol", 2020-07-04 <news:rdpu54$pfn$1@dont-email.me> <https://groups.google.com/g/comp.lang.forth/c/yuNZEvq8EqA/m/-FcvRcwRAQAJ> > Moreover the items would have to be the same in > interpret and compilation mode. Agreed. Rationale: 1. In most use cases the result of recognizing does not depend on STATE (and when it depends, like in cmForth, it can be made independent). 2. One useful thing about recognizers is that they can be used for more than just the purpose of lexeme translation. If we would need to only translate lexemes (i.e., to compile or interpret a lexeme depending on STATE) — no need to separate the step of recognizing. 3. If we recognize a lexeme not for further immediate translation, and the result may depend on STATE, we will need to change STATE before recognizing (or use some helpers to indicate our intention). This only complicates some use cases and does not simplify anything. > At least as a starting point, otherwise Forth degenerates to a > tangled web of special purpose interpreters. -- Ruvim
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <do-not-use@swldwa.uk> |
|---|---|
| Date | 2024-07-04 07:26 +0100 |
| Message-ID | <v65far$2krm8$1@dont-email.me> |
| In reply to | #131634 |
On 28/06/2024 11:20, Ruvim wrote: > On 2024-06-27 08:14, Gerry Jackson wrote: >> On 26/06/2024 14:36, Ruvim wrote: >>> One possible use case: >>> >>> : turnkey ( -- ) 0 set-order >>> also Target definitions >>> also Minimal also >>> ; >> >> ALSO duplicates the wordlist at the head of the search order. If the >> search order is empty there is nothing to duplicate. Therefore ALSO >> applied to an empty search order ought to be an ambiguous condition. > > Agree. This code is formally incorrect. > > An ambiguous condition should be declared for ALSO > when the search order is empty. > > I collect such cases at > <https://github.com/ForthHub/standard-evolution/issues/5> > > Then a proposal should be prepared. Another ambiguous condition that should be added is the execution of DEFINITIONS when the search order is empty -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-06-26 11:18 +0200 |
| Message-ID | <nnd$6bfc25dd$5b8770c4@3adbd9e6773ea8b4> |
| In reply to | #131611 |
In article <2024Jun26.094910@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >>word set)? It can leave a Forth system in a non-recoverable state. > >So what? There are lots of ways to put a Forth system in a >non-recoverable state. > >>Sentences are separated for emphasis: "If n is zero, empty the search >>order." Why? > >Why not? It's what I would expect from 0 SET-ORDER anyway. 0 SET-ORDER puts the minimum search order in place. Then there are FORTH-WORDLIST and SET-ORDER present to get the system under control. Am I mistaken? <SNIP> >- anton Groetjes Albert -- Don't praise the day before the evening. One swallow doesn't make spring. You must not say "hey" before you have crossed the bridge. Don't sell the hide of the bear until you shot it. Better one bird in the hand than ten in the air. First gain is a cat purring. - the Wise from Antrim -
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-06-26 10:36 +0000 |
| Message-ID | <ebffc18d228df43ac5460b6c814ade4d@www.novabbs.com> |
| In reply to | #131614 |
You described -1 SET-ORDER , whereas 0 SET-ORDER empties.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-26 06:13 -0500 |
| Message-ID | <v5gt51$23lka$3@dont-email.me> |
| In reply to | #131614 |
On 6/26/24 04:18, albert@spenarnc.xs4all.nl wrote: > In article <2024Jun26.094910@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >>> word set)? It can leave a Forth system in a non-recoverable state. >> >> So what? There are lots of ways to put a Forth system in a >> non-recoverable state. >> >>> Sentences are separated for emphasis: "If n is zero, empty the search >>> order." Why? >> >> Why not? It's what I would expect from 0 SET-ORDER anyway. > > 0 SET-ORDER puts the minimum search order in place. > Then there are FORTH-WORDLIST and SET-ORDER present to get > the system under control. Am I mistaken? > According to Anton's interpretation you are mistaken. 0 SET-ORDER empties the search order, which is commonly taken to be understood as nothing exists in the search order. Of course this contradicts the notion in the standard of a "minimum search order which contains the words FORTH-WORDLIST and SET-ORDER". -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-26 05:56 -0500 |
| Message-ID | <v5gs5j$23lka$2@dont-email.me> |
| In reply to | #131611 |
On 6/26/24 02:49, Anton Ertl wrote: > Krishna Myneni <krishna.myneni@ccreweb.org> writes: >> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >> word set)? It can leave a Forth system in a non-recoverable state. > > So what? There are lots of ways to put a Forth system in a > non-recoverable state. > ... By design? No. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-06-28 15:50 +0000 |
| Message-ID | <2024Jun28.175045@mips.complang.tuwien.ac.at> |
| In reply to | #131617 |
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>On 6/26/24 02:49, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
>>> word set)? It can leave a Forth system in a non-recoverable state.
>>
>> So what? There are lots of ways to put a Forth system in a
>> non-recoverable state.
>> ...
>
>By design? No.
Does it matter?
If the user accidentially puts the Forth system in a non-recoverable
state, there is no difference between "by design" (e.g., 0 SET-ORDER)
and "by doing non-standard things".
If the user intentionally puts the Forth system in a non-recoverable
state (e.g.,
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Crash-Course-Tutorial.html>),
it does not matter, either.
- 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: https://forth-standard.org/
EuroForth 2024: https://euro.theforth.net
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2024-06-28 18:39 +0200 |
| Message-ID | <nnd$0542b810$2ece0e61@915d86f03c2448ce> |
| In reply to | #131637 |
On 28-06-2024 17:50, Anton Ertl wrote: > Krishna Myneni <krishna.myneni@ccreweb.org> writes: >> On 6/26/24 02:49, Anton Ertl wrote: >>> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>>> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >>>> word set)? It can leave a Forth system in a non-recoverable state. >>> >>> So what? There are lots of ways to put a Forth system in a >>> non-recoverable state. >>> ... >> >> By design? No. > > Does it matter? > > If the user accidentially puts the Forth system in a non-recoverable > state, there is no difference between "by design" (e.g., 0 SET-ORDER) > and "by doing non-standard things". > > If the user intentionally puts the Forth system in a non-recoverable > state (e.g., > <https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Crash-Course-Tutorial.html>), > it does not matter, either. > > - anton Interesting challenge! 4tH supports all these words, so I should at least be able to compile it. But no: 4tH message: Undefined name at word 5 It cannot compile, because CATCH isn't *defined* - it's a builtin. It has no address to point to. So I change it slightly: : (catch) catch ; : (quit) quit ; 0 0 ! here execute ' (catch) >body 20 erase abort ' (quit) >body 20 erase And yes, it compiles cleanly. However, when executing: Executing; Word 9: Bad variable Because you're not allowed to anything write at that address. You can read it though. Let's remove it.. Executing; Word 8: Stack empty Yeah, EXECUTE requires an execution token. The stack is empty. If we skip that one too, it runs! That is because "10" and "14" are addresses in the 256 byte TIB, which is located in the Character Segment. That's where ERASE does its job. So that's harmless.. That was fun! Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2024-06-29 09:17 -0500 |
| Message-ID | <v5p51t$3utd9$2@dont-email.me> |
| In reply to | #131637 |
On 6/28/24 10:50, Anton Ertl wrote: > Krishna Myneni <krishna.myneni@ccreweb.org> writes: >> On 6/26/24 02:49, Anton Ertl wrote: >>> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>>> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >>>> word set)? It can leave a Forth system in a non-recoverable state. >>> >>> So what? There are lots of ways to put a Forth system in a >>> non-recoverable state. >>> ... >> >> By design? No. > > Does it matter? > Yes, it matters. Not everyone uses Forth to develop and use turnkey applications. Some of us rely on the Forth environment itself as the application interface, where definitions in a precise search order *are* the interface. Inadvertently emptying the search order and violating the notion of a minimum search order would mean loss of data from a lengthy computation or data acquisition. -- Krishna
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-06-30 12:21 +1000 |
| Message-ID | <6680c10c$1@news.ausics.net> |
| In reply to | #131644 |
On 30/06/2024 12:17 am, Krishna Myneni wrote: > On 6/28/24 10:50, Anton Ertl wrote: >> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>> On 6/26/24 02:49, Anton Ertl wrote: >>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>>>> Why is 0 a valid argument to SET-ORDER (from the optional Search-Order >>>>> word set)? It can leave a Forth system in a non-recoverable state. >>>> >>>> So what? There are lots of ways to put a Forth system in a >>>> non-recoverable state. >>>> ... >>> >>> By design? No. >> >> Does it matter? >> > > Yes, it matters. Not everyone uses Forth to develop and use turnkey applications. Some of us rely on the Forth environment itself as the application interface, where definitions in a precise search order *are* the interface. Inadvertently emptying the search order and violating the notion of a minimum search order would mean loss of data from a lengthy computation or data acquisition. Under what circumstances is 0 SET-ORDER executed inadvertently?
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web