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.
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?
In kForth (32/64), the sequence
0 SET-ORDER
leaves the Forth system in a non-recoverable state, and I have to use
Ctrl-C to break out back to the OS shell. This appears to be true in
Gforth as well, although Gforth traps Ctrl-C, so maybe one has to kill
the process from another shell.
IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.
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.
- anton
IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.
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?
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.
...
One possible use case:
: turnkey ( -- ) 0 set-order
also Target definitions
also Minimal also
;
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
;
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.
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.
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.
--
Gerry
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.
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.
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.
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
No need to specify useless behaviours. u=0 in REPRESENT wasn't specified as the TC couldn't imagine a use for it. Which was just as well as there was
a use for it the TC apparently overlooked.
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
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)--
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.
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
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?
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.
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.
--
Krishna
On 30/06/2024 12:17 am, Krishna Myneni wrote:search order and violating the notion of a minimum search order would mean loss of data from a lengthy computation or data acquisition.
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
Under what circumstances is 0 SET-ORDER executed inadvertently?
On 6/29/24 21:21, dxf wrote:...
Under what circumstances is 0 SET-ORDER executed inadvertently?
One example: assume you have a value containing the number of wordlists
0 value Nwid
and it is not properly set. Then doing,
wid1 wid2 ... widn Nwid SET-ORDER
FORTH-WORDLIST 1 SET-ORDER should bring you "back to life".
IOW the question is whether FORTH-WORDLIST and SET-ORDER
should be findable even when the search-order is empty.
Probably classified as "implementation-defined option".
FORTH-WORDLIST 1 SET-ORDER should bring you "back to life".
IOW the question is whether FORTH-WORDLIST and SET-ORDER
should be findable even when the search-order is empty.
Probably classified as "implementation-defined option".
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.
Krishna Myneni wrote:
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.
IMHO, the committee should refrain from adding restrictions
that only serve to make systems 'not standard' because of non-issues.
-marcel
On 2024-07-01 05:49, Krishna Myneni wrote:
On 6/30/24 15:37, minforth wrote:
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.
Do you mean it's confusing that the search order can contain fewer word
lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?
On 7/1/24 04:02, Ruvim wrote:
On 2024-07-01 05:49, Krishna Myneni wrote:
On 6/30/24 15:37, minforth wrote:
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.
Do you mean it's confusing that the search order can contain fewer word
lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?
I wonder if the original proposal for SET-ORDER meant to say "minimal" >instead of "minimum", for argument -1, thereby leading to the inference
that the words FORTH-WORDLIST and SET-ORDER always be present in the
search order. We need to check where else in the standard the term
"minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum"
with "minimal" would avoid some confusion.
--
Krishna
Krishna Myneni wrote:+1
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.
IMHO, the committee should refrain from adding restrictions
that only serve to make systems 'not standard' because of non-issues.
-marcel--
I have a minimal system and opt out of the "optional search order wordset". So SET-ORDER is not present.
What gives?
On 1/07/2024 8:13 pm, Krishna Myneni wrote:else in the standard the term "minimum search order" appears.
On 7/1/24 04:02, Ruvim wrote:
On 2024-07-01 05:49, Krishna Myneni wrote:
On 6/30/24 15:37, minforth wrote:
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.
If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search order is the empty search order, i.e. zero wordlists.
Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?
I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.
In the rationale A.16 the phrase "default search order" is used along with an explanation.
On 2024-07-01 14:13, Krishna Myneni wrote:...
On 7/1/24 04:02, Ruvim wrote:
On 2024-07-01 05:49, Krishna Myneni wrote:
I wonder if the original proposal for SET-ORDER meant to say "minimal"
instead of "minimum", for argument -1, thereby leading to the
inference that the words FORTH-WORDLIST and SET-ORDER always be
present in the search order. We need to check where else in the
standard the term "minimum search order" appears.
In Forth-94:
<http://lars.nocrew.org/dpans/dpans16.htm>
<http://lars.nocrew.org/dpans/dpansa16.htm>
<http://lars.nocrew.org/dpans/a0002.htm>
For the specification of SET-ORDER with argument -1 replacing
"minimum" with "minimal" would avoid some confusion.
Wiktionary says that they are synonyms: <https://en.wiktionary.org/wiki/minimum#Adjective>
On 3/07/2024 11:04 am, Krishna Myneni wrote:
On 7/1/24 06:02, dxf wrote:order is the empty search order, i.e. zero wordlists.
On 1/07/2024 8:13 pm, Krishna Myneni wrote:
On 7/1/24 04:02, Ruvim wrote:
On 2024-07-01 05:49, Krishna Myneni wrote:
On 6/30/24 15:37, minforth wrote:
My "implementation-defined option" 0 SET-ORDER locks everyone out. >>>>>>> Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them >>>>>>> on purpose.
If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search
inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the
Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?
I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the
term "minimum search order" appears.
"primitive search-order" used at the beginning of A.16, here and only here. There is no explanation of what constitutes a primitive search
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.
In the rationale A.16 the phrase "default search order" is used along with an explanation.
I'm searching at the Forth 2012 standard document and I don't find "default search order" anywhere within it. Worse, I find the phrase,
order.
SET-ORDER."
The phrase "minimum search order" is used five times in the document:
-- 16.4.1.1 Implementation-defined options
-- twice in the specification of SET-ORDER
-- twice in the specification of ONLY
In both the specification of SET-ORDER and ONLY, the standard states, "The minimum search order shall include the words FORTH-WORDLIST and
What is one expected to do with 'FORTH-WORDLIST and SET-ORDER'? It's information like this
that's lacking, leaving it to the user's imagination. Nor will one get clarification from
200x since by this time principal users have a vested interest in leaving things ambiguous.
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.
And if the term "minimum search order" is renamed to "small search order" (as an
example), will this solve the problem?
On 2024-09-21 23:37, Anthony Howe wrote:
On 2024-07-01 05:02, Ruvim wrote:
And if the term "minimum search order" is renamed to "small search order" (as
an example), will this solve the problem?
Minimum functional search order?
Good idea!
Similar variants:
- minimum usable search order
- minimum operable search order
- minimum operative search order
- minimum operational search order
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 504 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:00:44 |
| Calls: | 9,895 |
| Calls today: | 4 |
| Files: | 13,797 |
| Messages: | 6,297,202 |
| Posted today: | 2 |