[Info-vax] SDL header generator, was: Re: Error Messages in Basic - %BASIC-E-PARMODNOT, mode for parameter <n> of routine <procedure-name> not as declared

[Stephen Hoffman]

On 2019-06-10 05:05:02 +0000, Simon Clubley said:

> If you are going to make changes to the SDL header generator, can you 
> _please_ get it to generate C header files which are much more 
> intelligent than they currently are ?

You're effectively looking at compiled code.

> You commented earlier about people using their own headers instead of 
> the system supplied ones. One reason for that is that some of the 
> system supplied headers are _horrible_.

Yep.

> ...the whole approach of SDL using a 64 bit integer (new definitions) 
> or an array of 2 32-bit integers (old definitions) to hold an inline 
> descriptor within a control block is _extremely_ yucky and offers no 
> type-checking (not even C language level type-checking) at compile time.

Welcome to the pernicious effects of compatibility.
The double longword is commonly used for VAX source code compatibility.
In various definitions, there's the mess that is the 32- and 64-bit 
addressing and APIs on OpenVMS.
That 32- and 64-bit "hybrid" design that's such a clever and elegant 
design for existing code, and that's so, so, so messy for new work.

> SDL has clearly been written to do a literal translation of what 
> low-level languages such as Macro-32 would see, and to deal with 
> low-level memory locations only without making use of any of the higher 
> level abstractions
> available in higher level languages, including C.

Part of the fun was that SDL itself largely targeted Macro32 and Bliss.

SDL support for C is a bit hackish, without the /C_DEV and /VMS_DEV 
qualifiers added.
> 
> Surely SDL in the 21st century should be expected to do better than that ?

Might want to consider OO here too, if updates the whole of SDL 
definitions and the related APIs are to be in play.

Because changing SDL incompatibly is probably going to mean yet more 
compilation modes.

#undef __NEW_STARLET
#define __NEW_STARLET
#define __NEWER_STARLET
#define __NEWEST_STARLET
#define __NEW_NEWEST_STARLET

Or tools to translate old to new.  Or manual translations.

In OpenVMS terms, going OO is a much bigger break from existing, but 
puts everything "behind" a descriptor.  And a descriptor that's more 
flexible and more capable and more opaque than what OpenVMS uses.

Adds compiler requirements for the various programming languages.  
Objective C and Objective C++ support is latent in clang, so there's 
that.  BASIC would be a good fit here, too.

Also adds a few different messes elsewhere too, but that's the way of 
the world.  Yes, if run-time profiling shows you're really hammering on 
a critical code path or two, you might want a different approach.  If.  
Etc.

This also ties back to my earlier comments around a wholesale 
retirement and replacement of the existing C and C++ environments on 
OpenVMS.  Give folks a ~decade to migrate to the newer designs, then 
remove the old.

The OpenVMS development tooling and OpenVMS API discussions are a deep, 
deep, deep rabbit hole...  This area hasn't been substantially updated 
in ~twenty years.  A state which isn't all that competitive.

-- 
Pure Personal Opinion | HoffmanLabs LLC