Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: marketing vs. demerit
Message-ID: <2725@bsu-cs.UUCP>
Date: 25 Apr 88 14:17:44 GMT
References: <1988Apr11.201934.20594@utzoo.uucp> <451@goofy.megatest.UUCP> <1988Apr24.004626.3209@utzoo.uucp> <2605@ttrdc.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 28
Summary: VMS design

In article <2605@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>Likewise, any supposed
>"technical opposition" to gotos in DCL AND ESPECIALLY THE ABSENCE OF
>ALTERNATIVE STRUCTURES are not enough, in DEC's view, to warrant support of
>such structures.  DEC has indeed revised DCL many times in the recent past.
>Alternatives to the goto appear to be at the bottom of the list of things
>they worry about...

Based on a superficial (and rather skeptical, raised-eyebrow) look
at VMS, I conclude as follows.

VMS's design makes it very difficult to include structured control
structures in DCL.  The UNIX shells can save their context between
commands because they execute other programs as subprocesses.  Under
VMS subprocess creation is so painfully slow that it is seldom done.
Thus the DCL interpreter cannot save its entire context when executing
another program.  To use while loops and if-then statements the DCL
interpreter would have to save quite a bit of the current context so it
could continue executing the current control structure.  Nested control
structures would require even more information to be saved.  Alas, the
DCL interpreter and VMS make this nearly impossible.

This is also the reason why VMS does not allow multiple commands
on the same line.  Doing so would mean saving the command line
between executions of different programs so the command interpreter
could then pick the next command on the same line.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi