[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