Deutsch   English   Français   Italiano  
<667bd654$1@news.ausics.net>

View for Bookmarking (what is this?)
Look up another Usenet article

Date: Wed, 26 Jun 2024 18:50:28 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: 0 SET-ORDER why?
Newsgroups: comp.lang.forth
References: <v5fjkr$1p13i$1@dont-email.me>
 <2024Jun26.094910@mips.complang.tuwien.ac.at>
Content-Language: en-GB
From: dxf <dxforth@gmail.com>
In-Reply-To: <2024Jun26.094910@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: news.ausics.net
Message-ID: <667bd654$1@news.ausics.net>
Organization: Ausics - https://newsgroups.ausics.net
Lines: 63
X-Complaints: abuse@ausics.net
Path: ...!weretis.net!feeder8.news.weretis.net!news.swapon.de!news.bbs.nz!news.ausics.net!not-for-mail
Bytes: 3281

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