[Info-vax] Suggestion: Adding a /SORT option to DIRECTORY and F$SEARCH ?

[Dave Froble]

On 1/28/2022 12:31 PM, John Reagan wrote:

> 1) The shear number of compiler toolchain pieces needed to build (or port) the system
>
> 2) Engineer portability.  It is difficult enough for an engineer to bounce around and find
> C code, BLISS code, and Macro-32 code.  Somebody people are not familiar with all of
> the languages and end up asking me questions about each.  Adding another language
> like BASIC (or Pascal or Ada) simply makes it more difficult to find and train engineers
> to be productive and independent.

Yep, I now consider myself incompetent to work with Macro-32, due to 
insufficient recent use.

> 3) Languages like BASIC which is very dependent on heap storage would be difficult to
> use in the kernel (yes, I know we started talking about DIRECTORY) since memory allocation
> and stack usage are difficult.  We recently had an issue with some kernel code (written
> in C) wanting to turn an integer into a character string.  A C program says "I'll use sprintf".
> Of course sprintf() may do things like "open a locale file", "write an errno back into your
> thread's errno variable", malloc() some temporary storage and even if free()'d you'd now
> have kernel-owned pages in your LIB$VM's cache, etc.  [All you Macro/BLISS users know
> that $FAO is a nice, low-overhead, safe to use anywhere service to convert an integer into
> a string.]

Just to be clear, the current implementation of VSI Basic is not useful for 
such.  But, another implementation could be.

> 4) As we've discussed the BASIC cross-compiler is still not available due to G2L not being
> able to totally handle how the BASIC MAP statement is described to GEM.  The GEM to
> LLVM module for common blocks is radically different.  Could you write a DIRECTORY
> replacement in BASIC without using MAP?

Why, yes, I'm rather sure I could.  For example, from one of my routines:

         RECORD FABBLK                                   !
         RECORD NAMBLK                                   !
         RECORD FIBBLK                                   !  FIB structure

And now I'm waiting for you to say that the Basic RECORD statement has the same 
problems as MAP.

:-(


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486