[Info-vax] Removing the leading $ from commands in a new DCL language

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri May 1 12:03:32 EDT 2015


On 2015-05-01 15:01:12 +0000, John Reagan said:

> On Friday, May 1, 2015 at 10:12:08 AM UTC-4, Stephen Hoffman wrote:
> 
>> 
>> DCL has areas where errant syntax is accepted.   That certain lexical 
>> functions are processed inside comments was another, and that "bug" 
>> then became a "feature".
> 
> I've had lines without leading dollar signs for years and then when I 
> make a change a dozen lines away, DCL starts to complain.  Go figure.

That's typical of the DCL parser, unfortunately.   At various points in 
its history, DCL would even silently eat specific command lines based 
on earlier commands, and the parser has occasionally manifested other 
untoward behavior.

>> What some hypothetical replacement command language might choose to do 
>> here?  If that new language happens, hopefully there's a formal syntax 
>> specification and some related testing.
> 
> A command language with a formal, well-designed, consistent syntax?  
> That would be a first.

DCL had that, to a reasonable degree.  It was pretty good, compared 
with what went before.  Alas, DCL lost some of that over the years, 
slowly and incrementally.   PIPE, for instance, was more a bag on the 
side than a consistent implementation.  That was for good reason and 
compatibility, and — in retrospect — the reasons ended up being wrong.  
But then I've previously ranted^Wcommented on the fondness for a 
foolish compatibility.

If not a wholesale replacement, it'd be interesting to see a new DCL 
parser with tightened syntax checks, for that matter.   Unfortunately — 
and as you know from your long experience with compilers, and the 
morass that was VAX C code — loose specifications and sloppy parsers 
make extensions and updates that much more difficult and disruptive.   
There's already a DCL lint tool around — DCL_CHECK from Freeware V8 — 
and it'd be interesting to see that integrated into some potential / 
eventual / replacement / migration DCL parser.

Similarly to the various DCL messes, SCSI got into similar messes in 
its early years, due to the ambiguities.  But I digress.

> Seriously, doing a new command language is quite an undertaking and 
> just would make OpenVMS yet again different than the systems it is 
> trying to complete with.

True.  Choosing bash or sufficiently-compatible language would avoid 
that.   Not that bash or sh have a formally-specified syntax or are a 
shining beacon of design, though.   This potentially via DEC/shell or 
otherwise.

> Just like we all have our complaints about C, C++, and JAVA, they are 
> the lingua franca in the industry today.

Alas, VMS has ancient C, ancient C++, ancient Java, no Objective C, no 
C#, ancient JavaScript, ancient php, etc.   Of the others 
<http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>, 
Python and Perl are in good shape on OpenVMS, but they're maintained by 
others.




-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list