Re: "The Best Programming Language for the End of the World"

On 5/04/2025 6:12 pm, mhx wrote:

On Sat, 5 Apr 2025 6:40:15 +0000, albert@spenarnc.xs4all.nl wrote:
 

In article <cf9dc70297223ad4a39ba1a4ba2c072c8737e306@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:

On 4/04/2025 10:36 pm, albert@spenarnc.xs4all.nl wrote:

In article <nnd$4e8dcfed$6eb3f489@d30798298ac0a139>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:

On 27-03-2025 06:05, Alexis wrote:

[..]

I'm not so sure.  10 definitions and 2 comments.  Does it need more?
>
\ Encountered file error, display msg, filename then quit
: FERR ( ? ior a u -- ? )  rot 0= if  2drop  end
 cr ." File error: "  type  ."  - "  @fname type  abort ;
>
: FOPEN  ( a n fam -- )  open-file  s" open"  ferr  cf ! ;
: FCREAT ( a n fam -- )  create-file  s" create"  ferr  cf ! ;
: FREAD  ( a n -- n' )  cf @ read-file  s" read"  ferr ;
: FWRITE ( a n -- )  cf @ write-file  s" write"  ferr ;
: FSEEK  ( ud -- )  cf @ reposition-file  s" position"  ferr ;
: FCLOSE ( -- )  cf @ close-file  s" close"  ferr ;

 
Well... What are @fname and cf ? What message do I get when I
open file1, then file2, start processing file1, and encounter a
FSEEK error? Are both file2 and file1 closed?
When doing a load of a deeply nested file, what are the
diagnostics when there is an error in a definition? Are errors
in definitions mentioning the file name / line numbers when the
definition executes, not only when it is being compiled? Can I
use FSEEK in case a few files are open? Which file closes when
FCLOSE is executed in case of a nested load?
 
Clearly some documentation is missing on the WHAT, but also
with respect to the HOW : is this interface doing what I
expect from it and/or can I adapt it to my demands.

While this may be the response of an armchair critic, the maintainer of
the app has encountered no issues after many updates and decades of use.

"In particular you need to avoid writing code for situations that will
 never arise in practice. You need to avoid writing code to handle a
 general problem that you are never going to encounter. I don't need
 to solve the general problem when I only have to solve these specific
 cases." -- Chuck Moore