Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #131609 > unrolled thread

0 SET-ORDER why?

Back to article view | Back to comp.lang.forth

Contents

  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 1 of 4  [1] 2 3 4  Next page →

#131609 — 0 SET-ORDER why?

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.

---
16.6.1.2197

SET-ORDER ( widn . . . wid1 n – – )
Set the search order to the word lists identified by widn . . . wid1. 
Subsequently, word list wid1 will be searched first, and word list widn 
searched last.

If n is zero, empty the search order.

If n is minus one, set the search order to the implementation-defined 
minimum search order. The minimum search order shall include the words 
FORTH-WORDLIST and SET-ORDER.

A system shall allow n to be at least eight.
---

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.

See the examples below.

-- Krishna Myneni


=== kForth example ===
kForth-64 v 0.4.5	 (Build: 2024-03-30)
Copyright (c) 1998--2023 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw imss
Provided under the GNU Affero General Public License, v3.0 or later


Ready!
order    \ upon startup without command line args
[Forth]  Root   ok

\ set to the system's minimum search order (see 16.6.2.1965)
only
  ok
order
Root   ok  \ minimum search order only contains the root wordlist

\ words in the root wordlist
words
5 words.
ORDER          SET-ORDER      FORTH-WORDLIST FORTH          WORDS
  ok

\ we can recover with the word FORTH (16.6.2.1590)
forth
  ok
order
[Forth]  Root   ok  \ back to startup state


only
  ok
order
Root   ok

\ What does 0 SET-ORDER do?
0 set-order
  ok
order   \ the word ORDER is no longer in the search order

ORDER
Line 10:  VM Error(-13): Undefined word
order
forth   \ the word FORTH is no longer in the search order

FORTH
Line 11:  VM Error(-13): Undefined word
forth
bye

BYE     \ we can't get back to OS shell without Ctrl-C
Line 12:  VM Error(-13): Undefined word
bye
=== end of kForth example ===

=== Gforth example ===
Gforth 0.7.9_20220120
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type 
`authors'
Copyright © 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
   ok
order Forth Forth Root     Forth  ok  \ on startup

only  ok   \ minimum search order ?
order Root Root     Forth  ok

\ words in the Root wordlist
words
order set-order forth-wordlist Forth words  ok
forth  ok
order Forth Root     Forth  ok  \ recovered but different from startup

only  ok
order Root Root     Forth  ok
0 set-order  ok
order    \ ORDER is no longer in the search order
*the terminal*:11:1: error: Undefined word
 >>>order<<<
Backtrace:
kernel/int.fs:321:10:                    0 $7F0DAB00C3A0 throw

forth   \ FORTH is no longer in the search order
*the terminal*:12:1: error: Undefined word
 >>>forth<<<
Backtrace:
kernel/int.fs:321:10:                    0 $7F0DAB00C3A0 throw

bye     \ BYE is no longer in the search order
*the terminal*:13:1: error: Undefined word
 >>>bye<<<
Backtrace:
kernel/int.fs:321:10:                    0 $7F0DAB00C3A0 throw

\ Ctrl-C does not return to OS shell (trapped by Gforth)
*the terminal*:13:1: error: User interrupt                         |o: 
  Forth
 >>>bye<<<
Backtrace:
kernel/input.fs:216:30:                  0 $7F0DAB019438 throw
kernel/input.fs:216:36:                  1 $7F0DAB00E348 get-input-colored
except.fs:83:2:                          2 $7F0DAB024DD8 execute  [catch 
frame]
kernel/int.fs:654:5:                     3 $7F0DAB00DE38 catch
                                          4 $7F0DB903FFC0
kernel/int.fs:658:5:                     5 $7F0DAB00DEA0 bt-rp0-catch
=== end of Gforth example ===

[toc] | [next] | [standalone]

#131610

IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.

[toc] | [prev] | [next] | [standalone]

#131613

In article <5c21b9a70973cda8da6fac285f5b2137@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:
>IMO, it is a simple security mechanism against other users
>breaking out of an application program and taking control
>of the shell.

I don't think so. The requirement to have FORTH-WORDLIST and SET-ORDER
means that you run the system normally after using this, including the
repl QUIT.
The intention of the standard that the minimum search order contains
a method to get the system under control. `FORTH' is way better than
manipulations with wordlists.
I cheated in ciforth. FORTH puts the FORTH-WORDLIST on top and is
a regular vocabulary/namespace.
 In fact it is equivalent to
 : FORTH GET-ORDER 1+ >R FORTH-WORDLIST R>  SET-ORDER ;

So the ONLY namespace contains prefixes (handles numbers and strings)
and the word FORTH to recover.
FORTH and ONLY are named wordlist/ vocabularies.

To seal off in ciforth you can do:
'FORTH HIDDEN ONLY
From now on only numbers and strings are recognized.

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]

#131616

On 6/25/24 20:19, minforth wrote:
> IMO, it is a simple security mechanism against other users
> breaking out of an application program and taking control
> of the shell.

That seems like a security concern for people who generate executables 
and don't want users returning to the Forth shell, which would be useful 
to commercial vendors who don't want users to have the full capability 
of the Forth environment.

ISTM such a use does not warrant formal standardization in a language, 
if that was the intent of specifically providing a way to disable the 
Forth shell.


--
Krishna

[toc] | [prev] | [next] | [standalone]

#131611

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.

Is your question: "What potential uses does an empty search order
have?" ?

I have seen postings that suggest to use EVALUATE for converting
untrusted input into a number.  There is of course no security
precautions in these postings, but at the very least one could empty
the search order before the EVALUATE and restore it after the EVALUATE
(with the EVALUATE being wrapped with CATCH).  I thought about writing
out the source code, but the main things that would demonstrate is how
inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
stack items are, and how inconvenient the arbitrary number of stack
items produced by EVALUATE is.

Of course, with recognizer sequences, the better way is to use a
recognizer sequence that only contains the number recognizers you
want, no need to mess with the search order.

>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.

In Gforth you can leave the text interpreter in the traditional Unix
way of doing Ctrl-D at the start of a line.

Restoring an empty search order to some more usable default by the
system CATCH handler would be a potential convenience feature, but I
have not experienced an empty search order as a problem yet, and I
don't remember users asking for such a feature, either.  And it would
only catch

0 SET-ORDER

but not the functionally equivalent

WORDLIST 1 SET-ORDER

So why nerf one and not the other?

- 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]

#131612

On 26/06/2024 5:49 pm, 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.
> 
>> 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.
> 
> Is your question: "What potential uses does an empty search order
> have?" ?
> 
> I have seen postings that suggest to use EVALUATE for converting
> untrusted input into a number.  There is of course no security
> precautions in these postings, but at the very least one could empty
> the search order before the EVALUATE and restore it after the EVALUATE
> (with the EVALUATE being wrapped with CATCH).  I thought about writing
> out the source code, but the main things that would demonstrate is how
> inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
> stack items are, and how inconvenient the arbitrary number of stack
> items produced by EVALUATE is.
> 
> Of course, with recognizer sequences, the better way is to use a
> recognizer sequence that only contains the number recognizers you
> want, no need to mess with the search order.
> 
>> 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.
> 
> In Gforth you can leave the text interpreter in the traditional Unix
> way of doing Ctrl-D at the start of a line.
> 
> Restoring an empty search order to some more usable default by the
> system CATCH handler would be a potential convenience feature, but I
> have not experienced an empty search order as a problem yet, and I
> don't remember users asking for such a feature, either.  And it would
> only catch
> 
> 0 SET-ORDER
> 
> but not the functionally equivalent
> 
> WORDLIST 1 SET-ORDER
> 
> So why nerf one and not the other?

So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

"Yes, Zathras understand. ..... No, Zathras not understand, but Zathras do.
 Zathras good at doings, not understandings."

[toc] | [prev] | [next] | [standalone]

#131619

On 2024-06-26 12:50, dxf wrote:
> On 26/06/2024 5:49 pm, 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.
>>
>>> 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.
>>
>> Is your question: "What potential uses does an empty search order
>> have?" ?
>>
>> I have seen postings that suggest to use EVALUATE for converting
>> untrusted input into a number.  There is of course no security
>> precautions in these postings, but at the very least one could empty
>> the search order before the EVALUATE and restore it after the EVALUATE
>> (with the EVALUATE being wrapped with CATCH).  I thought about writing
>> out the source code, but the main things that would demonstrate is how
>> inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
>> stack items are, and how inconvenient the arbitrary number of stack
>> items produced by EVALUATE is.
>>
>> Of course, with recognizer sequences, the better way is to use a
>> recognizer sequence that only contains the number recognizers you
>> want, no need to mess with the search order.
>>
>>> 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.
>>
>> In Gforth you can leave the text interpreter in the traditional Unix
>> way of doing Ctrl-D at the start of a line.
>>
>> Restoring an empty search order to some more usable default by the
>> system CATCH handler would be a potential convenience feature, but I
>> have not experienced an empty search order as a problem yet, and I
>> don't remember users asking for such a feature, either.  And it would
>> only catch
>>
>> 0 SET-ORDER
>>
>> but not the functionally equivalent
>>
>> WORDLIST 1 SET-ORDER
>>
>> So why nerf one and not the other?
> 
> So after all that you don't have an explanation either?  You implemented
> it as instructed in the event someone finds a use.


I think, in this case it's better to specify behavior than to declare an 
ambiguous condition.

Then the empty search order is the expected result by *induction*. It 
would be strange to specify any other behavior in this case.



One possible use case:

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

It's found in
<https://github.com/eswartz/emul/blob/master/v9t9/v9t9-c/tools/Forth/site-forth/cross.fs>


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
   ;

Where:

   : compilation ( -- flag )  state @ 0<> ;
   : enter-compilation ( -- )  ] ;
   : leave-compilation ( -- )  postpone [ ;

   : execute-interpreting ( i*x xt -- j*x )
     compilation 0= if execute exit then
     leave-compilation execute enter-compilation
   ;
   : execute-compiling ( i*x xt -- j*x )
     compilation if execute exit then
     enter-compilation execute leave-compilation
   ;



BTW, I just realized that the words "execute-interpreting"
and "execute-compiling" are similar to well known word
"execute-parsing".



--
Ruvim

[toc] | [prev] | [next] | [standalone]

#131620

On 26/06/2024 11:36 pm, Ruvim wrote:
> On 2024-06-26 12:50, dxf wrote:
>> ...
>> So after all that you don't have an explanation either?  You implemented
>> it as instructed in the event someone finds a use.
> 
> 
> I think, in this case it's better to specify behavior than to declare an ambiguous condition.

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.

> Then the empty search order is the expected result by *induction*. It would be strange to specify any other behavior in this case.
> 
> One possible use case:
> 
>   : turnkey ( -- ) 0 set-order
>     also Target definitions
>     also Minimal also
>   ;
> 
> It's found in
> <https://github.com/eswartz/emul/blob/master/v9t9/v9t9-c/tools/Forth/site-forth/cross.fs>
> ...

That seems useful.

[toc] | [prev] | [next] | [standalone]

#131628

On 27/06/2024 04:19, dxf wrote:
> 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.

What was this use of REPRESENT

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#131630

On 28/06/2024 8:10 am, Gerry Jackson wrote:
> On 27/06/2024 04:19, dxf wrote:
>> 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.
> 
> What was this use of REPRESENT

Displaying single digit fractions to 0 decimal places e.g. 0.9 and 0.4

REPRESENT should handle this case but few do.  An exception is:

 VFX Forth 64 for Windows x64
  © MicroProcessor Engineering Ltd, 1998-2023 

0.9e pad 0 represent 2drop . pad 1 dump 1 
0000:0000:01C2:EB00  31 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  1000000000000000
 ok
0.4e pad 0 represent 2drop . pad 1 dump 1 
0000:0000:01C2:EB00  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  0000000000000000
 ok

Had ANS TC been aware of the need they would almost certainly have specified it.

[toc] | [prev] | [next] | [standalone]

#131633

On 2024-06-27 07:19, dxf wrote:
> On 26/06/2024 11:36 pm, Ruvim wrote:
>> On 2024-06-26 12:50, dxf wrote:
>>> ...
>>> So after all that you don't have an explanation either?  You implemented
>>> it as instructed in the event someone finds a use.
>>
>>
>> I think, in this case it's better to specify behavior than to declare an ambiguous condition.
> 
> No need to specify useless behaviours.

Even behavior that is useless in practice should be sometimes specified 
to ensure *consistency* and expected effects.

BTW, do you think 0 PICK and 0 ROLL are useless?


> u=0 in REPRESENT wasn't specified as
> the TC couldn't imagine a use for it.

<https://forth-standard.org/standard/float/REPRESENT>

Of course, it's specified. It's specified for any u, including 0.
For example:
   "The character string shall consist of the u most significant digits"

If u is zero, the string must consist of zero digits.

Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.

Probably, "represent" may return false at the top if u is zero.


> Which was just as well as there was
> a use for it the TC apparently overlooked.

What is the problem anyway that the behavior is specified for
"0 SET-ORDER"?  What are bad consequences for systems or for users?


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#131635

On 28/06/2024 7:51 pm, Ruvim wrote:
> On 2024-06-27 07:19, dxf wrote:
>> On 26/06/2024 11:36 pm, Ruvim wrote:
>>> On 2024-06-26 12:50, dxf wrote:
>>>> ...
>>>> So after all that you don't have an explanation either?  You implemented
>>>> it as instructed in the event someone finds a use.
>>>
>>>
>>> I think, in this case it's better to specify behavior than to declare an ambiguous condition.
>>
>> No need to specify useless behaviours.
> 
> Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
> 
> BTW, do you think 0 PICK and 0 ROLL are useless?

No, because I've used them (at least in the case of PICK :)

>> u=0 in REPRESENT wasn't specified as
>> the TC couldn't imagine a use for it.
> 
> <https://forth-standard.org/standard/float/REPRESENT>
> 
> Of course, it's specified. It's specified for any u, including 0.
> For example:
>   "The character string shall consist of the u most significant digits"
> 
> If u is zero, the string must consist of zero digits.

Spec says:

   "u most significant digits of the significand"

Do you have a definition for '0 most significant digits of the significand' ?
I don't.  Nor did ANS provide one.

> 
> Gforth throws exception  -262, but is should not.
> sp-forth/4 handles this case correctly.
> 
> Probably, "represent" may return false at the top if u is zero.

No.  The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest.  Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

> ... 
> 
> What is the problem anyway that the behavior is specified for
> "0 SET-ORDER"?  What are bad consequences for systems or for users?

It would be a problem if there were no use for it.  It's not clear to me
that we're there yet.

[toc] | [prev] | [next] | [standalone]

#131636

On 2024-06-28 16:19, dxf wrote:
> On 28/06/2024 7:51 pm, Ruvim wrote:
>> On 2024-06-27 07:19, dxf wrote:
>>> On 26/06/2024 11:36 pm, Ruvim wrote:
>>>> On 2024-06-26 12:50, dxf wrote:
>>>>> ...
>>>>> So after all that you don't have an explanation either?  You implemented
>>>>> it as instructed in the event someone finds a use.
>>>>
>>>>
>>>> I think, in this case it's better to specify behavior than to declare an ambiguous condition.
>>>
>>> No need to specify useless behaviours.
>>
>> Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
>>
>> BTW, do you think 0 PICK and 0 ROLL are useless?
> 
> No, because I've used them (at least in the case of PICK :)
> 
>>> u=0 in REPRESENT wasn't specified as
>>> the TC couldn't imagine a use for it.
>>
>> <https://forth-standard.org/standard/float/REPRESENT>
>>
>> Of course, it's specified. It's specified for any u, including 0.
>> For example:
>>    "The character string shall consist of the u most significant digits"
>>
>> If u is zero, the string must consist of zero digits.
> 
> Spec says:
> 
>     "u most significant digits of the significand"
> 
> Do you have a definition for '0 most significant digits of the significand' ?
> I don't.  Nor did ANS provide one.

It's seems obvious to me: 0 digits means the empty string.


>>
>> Gforth throws exception  -262, but is should not.
>> sp-forth/4 handles this case correctly.
>>
>> Probably, "represent" may return false at the top if u is zero.
> 
> No.  The logical extrapolation of u approaching zero is that the number
> is progressively rounded until it is either 0 or 1 according to which was
> closest.

"the significand represented as a decimal fraction", so each digit is 
chosen from {0,1, ..., 9}.

> Many implementations actually do this internally but screw up at
> the interface because neither implementer nor ANS knew what u=0 should do.

It's a problem of particular implementations.

The result is the empty string, and this is independent of how you 
round. Then you don't have to round at all.


It reminds me of the choice between lazy evaluation and eager evaluation.

If the lazy evaluation approach, if the result does not depend on a 
parameter in a certain case, then the parameter is not computed at all.

In the eager evaluation approach, computation of the result may never 
halt because computation of an *unneeded* parameter is never halt in a 
certain case.




>> ...
>>
>> What is the problem anyway that the behavior is specified for
>> "0 SET-ORDER"?  What are bad consequences for systems or for users?
> 
> It would be a problem if there were no use for it.  It's not clear to me
> that we're there yet.
> 

Well, this case can be found useful.


But, in general, what's wrong if a consistent and expected behavior is 
specified for a case that is not used in real programs?


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#131639

On 28/06/2024 11:48 pm, Ruvim wrote:
> On 2024-06-28 16:19, dxf wrote:
>> On 28/06/2024 7:51 pm, Ruvim wrote:
>>> On 2024-06-27 07:19, dxf wrote:
>>>> On 26/06/2024 11:36 pm, Ruvim wrote:
>>>>> On 2024-06-26 12:50, dxf wrote:
>>>>>> ...
>>>>>> So after all that you don't have an explanation either?  You implemented
>>>>>> it as instructed in the event someone finds a use.
>>>>>
>>>>>
>>>>> I think, in this case it's better to specify behavior than to declare an ambiguous condition.
>>>>
>>>> No need to specify useless behaviours.
>>>
>>> Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
>>>
>>> BTW, do you think 0 PICK and 0 ROLL are useless?
>>
>> No, because I've used them (at least in the case of PICK :)
>>
>>>> u=0 in REPRESENT wasn't specified as
>>>> the TC couldn't imagine a use for it.
>>>
>>> <https://forth-standard.org/standard/float/REPRESENT>
>>>
>>> Of course, it's specified. It's specified for any u, including 0.
>>> For example:
>>>    "The character string shall consist of the u most significant digits"
>>>
>>> If u is zero, the string must consist of zero digits.
>>
>> Spec says:
>>
>>     "u most significant digits of the significand"
>>
>> Do you have a definition for '0 most significant digits of the significand' ?
>> I don't.  Nor did ANS provide one.
> 
> It's seems obvious to me: 0 digits means the empty string.

REPRESENT does two things:
- Round the number to produce another number
- Convert the resulting number to a string

u=0 fails on the first step as there's no such thing as a number rounded to
zero significant digits.  The resulting string is thus undefined.

>>>
>>> Gforth throws exception  -262, but is should not.
>>> sp-forth/4 handles this case correctly.
>>>
>>> Probably, "represent" may return false at the top if u is zero.
>>
>> No.  The logical extrapolation of u approaching zero is that the number
>> is progressively rounded until it is either 0 or 1 according to which was
>> closest.
> 
> "the significand represented as a decimal fraction", so each digit is chosen from {0,1, ..., 9}.

That refers to the resulting number after rounding.  There's no difficulty
representing 1.0 as a fraction and adjusted exponent.

>> Many implementations actually do this internally but screw up at
>> the interface because neither implementer nor ANS knew what u=0 should do.
> 
> It's a problem of particular implementations.

It's a problem if they think ANS wanted them to return an empty string.

[toc] | [prev] | [next] | [standalone]

#131655

On 29/06/2024 3:08 am, dxf wrote:
> On 28/06/2024 11:48 pm, Ruvim wrote:
>> On 2024-06-28 16:19, dxf wrote:
>>> On 28/06/2024 7:51 pm, Ruvim wrote:
>>>> ...
>>>> If u is zero, the string must consist of zero digits.
>>>
>>> Spec says:
>>>
>>>     "u most significant digits of the significand"
>>>
>>> Do you have a definition for '0 most significant digits of the significand' ?
>>> I don't.  Nor did ANS provide one.
>>
>> It's seems obvious to me: 0 digits means the empty string.
> 
> REPRESENT does two things:
> - Round the number to produce another number
> - Convert the resulting number to a string
> 
> u=0 fails on the first step as there's no such thing as a number rounded to
> zero significant digits.  The resulting string is thus undefined.

Since posting the above I discovered the issue had been put to 200x with the
following response: 

  "So with u=0 zero characters must be written to c-addr. Any implementation
   that writes something there is buggy. An exception for u=0 is also a bug
   (and in case of Gforth this bug will be fixed).

   There is no basis for any claim that the u=0 case is unclear or unspecified.
   And unsurprisingly, the person who claimed so presented no argument that
   would support such a claim."

Presumably that was a reference to me.  I consider the rationale I gave above
to be quite solid - unbreakable in fact.

It's good to know VFX' REPRESENT is "buggy" according to 200x.  I'll be keen
to see whether they fix it.

[toc] | [prev] | [next] | [standalone]

#131642

On 28/06/2024 7:51 pm, Ruvim wrote:
> ... 
> Gforth throws exception  -262, but is should not.
> sp-forth/4 handles this case correctly.

Attempting to do u=0 on Windows Gforth (2020) results in the entire app
crashing.  AFAIK its REPRESENT is based on ecvt() so anything is possible
when fed with an illegal parameter.

I believe SP-Forth uses one of my REPRESENT implementations from ~2004.
It doesn't surprise me you got that result :)  For those interested a superior
implementation can be found below.  Included is a forth floating point output
package so good I've not needed REPRESENT since.

Represent35.txt

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

[toc] | [prev] | [next] | [standalone]

#131621

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

[toc] | [prev] | [next] | [standalone]

#131622

In article <v5ioud$2ii4l$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> 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.
>
>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.

I'm more and more convinced that the ciforth solution to make ONLY
a wordlist and stick all the number stuff (plus strings, say denotations) there
is ideal.
Add the rule that you simply cannot the remove the minimal search order,
which may perfect sense.
The only non-ISO aspect is that FORTH-WORDLIST and SET-ORDER is missing.
This is just as well, implementing SET-ORDER politically correctly
would bloat the ciforth kernel with 20%, at least that is my impression
from the discussion here.

And besides shuffling the wordlists searched for is a terrible idea.
I have not seen a use case for that.
Think of python. If you import all with *, at least the underlying
assumption is that the libraries contain no conflicting names
such that the order doesn't matter. Imagine that you can somehow
"unimport integral *" .
The idea from ENVRIONMENT that was supposed to find out portably what
facilities are to be loaded. No sensible use case.

A sensible use of wordlist is e.g.
ALSO INLINING
INCLUDE modulo.frt
PREVIOUS
This adds INLINING to the search order to have all the operators of
modulo calculations automatically inlined: +m -m *m ^m .
Then back off.
Or adding the ASSEMBLER namespace temporarily to add code words.

Or a word like IMPORT that makes an alias from a named wordlist
into the current wordlist (assuming current=context).

>--
>Gerry
>

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]

#131624

One should not forget that the linear search-order concept has
a long history (CONTEXT et al) and has served mostly well for
many small Forth applications. So be gracious towards some
ambiguities.

More modern languages with a wider application spectrum need
more elaborated namespace management. Should anyone invest brain
and time into a novel Forth namespace management concept, search
trees (instead of today's global search-order list) would be a
good place to start with.

This would facilitate early binding, modules, public/private
library handling etc. Of course these things are not new and
already there, but without common basis - and so everyone is
cooking their own soup.

[toc] | [prev] | [next] | [standalone]

#131623

On 27/06/2024 2:14 pm, 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.

( orig from ANS)
: ALSO  ( -- )  GET-ORDER  OVER SWAP 1+ SET-ORDER ;

( smarter)
: ALSO  ( -- )
  GET-ORDER  DUP IF OVER ELSE FORTH-WORDLIST THEN
  SWAP 1+ SET-ORDER ;

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web