Re: Back & Forth - 4tH I/O and You

On 20/05/2025 2:13 am, Hans Bezemer wrote:

On 19-05-2025 15:22, dxf wrote:

Those are console functions which traditionally went to serial ports and bear little
resemblance to disk file I/O.  For implementer it's not simpler - it's a layer on top
of DOS functions.  Even as an end-user I'm not sure I'd like it.  How does one handle
seeks, read and writing to the same file etc?  The ANS functions were designed to
handle random access.  Console functions were not.

 
Originally, yeah - that was all. And then we enter the wondrous world of "feature requests". So a few more calls were added, like delete-file, reposition-file and the likes.
 
If you read the documentation you will see that some I/O devices are out of bounds. So we devised tiny little macros for that:
 
#define UDEV(a)    if(((a)<=COUT)||((a)>=MAXDEVS))throw(M4BADDEV)
 
That's how we handle things around here.

I think we both felt some simplification of file-handling at the application
programmer level was desirable.  For me it's been quite a while since I've
used e.g. READ-FILE directly.  The ubiquitous 'filecopy' application for me
would look like this:

  : OPENFILES ( -- )
    cr .ifile  ." -> " .ofile
    r/o openin  r/w makeout  cr
  ;

  : (RUN) ( -- )
    openfiles
    begin  pad 128 read  dup while  write  repeat 2drop
    closefiles
  ;

I believe the 4tH manual illustrates something similar.

I don't have to worry about overwrite checks, user interrupt, error messages
and so on as it's handled under the hood.  Was it all necessary?  Is it
'anti-Forth'?  Folks can decide for themselves.