I am envious of John Gilmore. He must have a far better memory than do I.
To me, this comes down to readability, as that, in my opinion,is the most
important legacy that a coder can leave for those who follow him/her in
trying to deal with a module.
Consider an example where my macro accepts
Thus I agree completely with EJ. You are not overly concerned about someone
reading what command you entered (as they would likely be doing so only if
analyzing a dump or trying to figure out what command was actually
entered that did something you did not appreciate). But you should be
Subject:Re: The rationale for using macros i
Sent by:IBM Mainframe Assembler List
ASSEMBLER-LIST@listserv.uga.edu
I am envious of John Gilmore. He must have a far better memory than do I.
To me, this comes down to readability, as that, in my opinion,is the most
important legacy
All of the comments on and objections to the use of CIDTs of
keyword-parameter values were interesting, and some of them were
drôle.
The notion that coding say action=C instead of action=cancel is
justified|justifiable if a comment explaining that C really means
CANCEL is provided is, I think,
John Gilmore stated:
Worse, attempts to dispense with such documentation are ill-advised.
COBOL is the notorious example of an attempt to make a programming
language self-documenting. The attempt failed abjectly, with
pernicious side effects because prolixity was misidentified with
clarity.
I
On 7/25/2014 8:17 AM, Paul Gilmartin wrote:
On 2014-07-25, at 08:40, John Gilmore wrote:
We disagree, sharply. The abbreviation of long keyword/set element
values using the notion of a case-independent disambiguating
truncation is 1) convenient and 2) easy to teach in the sense that
EJ's distinction between, say, command-language option values and
macro-instruction keyword-parameter values is not always a firm one.
I often make a CL available for use in generating macro instructions.
Consider a simple table-gerneration situation in which, say, the macro
definition TABGEN has
continuing . .
is functionally e
On 7/28/14, John Gilmore jwgli...@gmail.com wrote:
EJ's distinction between, say, command-language option values and
macro-instruction keyword-parameter values is not always a firm one.
I often make a CL available for use in generating macro instructions.
continuing again . . .
is functionally equivalent to any other element in its row, I do not
really see the rationale for not making this facility available to the
writer or generator of TABGEN macro instructions.
Others may agree with EJ, and perhaps this is a visceral rather than
an
On 2014-07-28 14:30, Ed Jaffe wrote:
On 7/25/2014 8:17 AM, Paul Gilmartin wrote:
On 2014-07-25, at 08:40, John Gilmore wrote:
We disagree, sharply. The abbreviation of long keyword/set element
values using the notion of a case-independent disambiguating
truncation is 1) convenient and 2)
On 7/28/2014 6:43 PM, Paul Gilmartin wrote:
I think we agree to a point. What about in a pedagogic context?
If you were writing an example in a manual for a novice operator,
would you write:
CANCEL J(1234)
or:
C J(1234)
My preference in documentation tends toward using the
We disagree, sharply. The abbreviation of long keyword/set element
values using the notion of a case-independent disambiguating
truncation is 1) convenient and 2) easy to teach in the sense that
programmers and others come to understand it quickly.
The
start, stop, status
problem that Fred
On 2014-07-25, at 08:40, John Gilmore wrote:
We disagree, sharply. The abbreviation of long keyword/set element
values using the notion of a case-independent disambiguating
truncation is 1) convenient and 2) easy to teach in the sense that
programmers and others come to understand it
We are dealing now in questions of taste, for which tradition hath it
that there is no accounting.
I do think, however, that one distinction needs to be made. The use
of CIDTs has four important merits. They are derived algorithmically:
no element of the arbitrary or historical enters into the
/07/23 10:44:17:
From: John Gilmore jwgli...@gmail.com
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: 2014/07/23 10:44
Subject: The rationale for using macros i
Sent by: IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU
What follows, in a sequence of posts having this same title
Robert Ngan's scheme makes [only] yes|no case-insensitive.
I was using yes|no a a VERY simple example of recognizing CIDTs of one
of the elements of a set.
For his announced purposes his scheme is, of course, unobjectionable.
I personally would still strongly prefer the use of a macro to meet
And in principle I much prefer the communication between invoker and macro te
be as explicit as possible. I see no value at all in
allowing the programmer to omit one or two letters (or any amount) from the
value of a keyword. The time saved by not having to
press those few keys cannot
17 matches
Mail list logo
