Date: Sat, 29 Sep 2001 17:27:11 +0100
Reply-To: John Whittington <John.W@MEDISCIENCE.CO.UK>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: John Whittington <John.W@MEDISCIENCE.CO.UK>
Subject: Re: VALUE
In-Reply-To: <E15n4vB-0007wB-00@relay1.netnames.net>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 17:01 28/09/01 -0400, Ian Whitlock wrote:
>SELECT operates like IF/ELSE. Try the first if it fails try the second.
>Keep on until one passes then get out. It is the "get out" that is
>usually implemented as a GOTO in the underlying machine language.
I rather feared that someone was going to tell me that! I wonder how
you/we 'know' - is it simply because we are told that by people who know
about the inside of the compiler? I can't imagine that there is any way
one could test it. It therefore seems to be the case that, apart from
fractionally less typing, SELECT is actually identical to a series of
IF/THEN/ELSE statements; is that correct? Would not an 'indexed', rather
than 'sequential', SELECT-like construct (such as I postulated) be a good idea?
>The war against GOTO was originally fought on the grounds that it is
>harder to prove an algorithm correct when GOTO is used in the expression
>of the algorithm.
Yes, I understand that. An apparent irony is that if people sketch out an
algorithm as a 'flow chart' prior to writing code, they very often will do
so using GOTO-like branching, and then convert to more 'structured' style
when they actually code it!
>This does not mean that the code can be implemented without
>GOTOs in the underlying machine code. One might say that one of the big
>advantages of higher level languages is that they offer many forms of very
>restricted GOTOs so that the code will be easier to read.
Indeed. Variations on the theme of GOTO must be amongst the most commonly
used of machine code instructions. I take your point about the increased
readability that results from 'restricted GOTOs' - but it seems that the
'structured programming' (whatever that may be) 'purists' try to reject
anything which is related to GOTO, more-or-less as a 'matter of principle'
>The problem with a GOTO is that in can go to anywhere. The restrictive
>forms cannot.
That is indeed true - but I guess that some people might call that
'versatility', rather than 'a problem'. As I've been at pains to point out
in this discussion, I use unrestricted GOTOs very very rarely - but would
not associate myself with a view that they should 'never' be used.
>On the subject of whether a particular construct should not be used
>because a naive programmer might not understand it. One should note the
>implicit assumption that all problems can be solved by naive
>programmers. That assumption is blatantly false.
Indeed - and, similarly, I don't like arguments against certain types of
programming constructs or practices on the grounds that they facilitate
errors or 'allow messy code to be written'. Any 'versatile tool' can be
blamed for the way in which some inept people might attempt to use it.
Kind Regards,
John
----------------------------------------------------------------
Dr John Whittington, Voice: +44 (0) 1296 730225
Mediscience Services Fax: +44 (0) 1296 738893
Twyford Manor, Twyford, E-mail: John.W@mediscience.co.uk
Buckingham MK18 4EL, UK mediscience@compuserve.com
----------------------------------------------------------------
