Re: qsh from cl

[Evan Harris <auctionitis@xxxxxxxxx>]

I'd be OK with one parameter per line.

I was arguing *for* the use of *GT, *TCAT etc in preference to pipes,
greater than's etc so I think we are agreeing.

On Wed, Mar 7, 2018 at 10:10 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

> Fans of rolling their own CL-pretty won't like it much, but I use the RDi
> formatter a lot - and I choose to put each parameter on its own line - at
> least to start on its own line.

> Indentation is also available in CL in EDi - it indents decision blocks
> where is a DO, basically. Now other kinds of indentation, well, again, if
> you do your own, you can turn formatting off in RDi.
>
> Evan, you mention "...gets moved around..." - in fact, the pipe characters
> are NOT invariant in the various EBCDIC CCSIDs - the asterisk and the
> letters are in the same place in all of them, so they are safer when
> working in various national languages.
>
> Besides, I never remember which direction which arrow really controls -
> it's almost as bad as the buttons on an elevator for opening and closing
> the doors - I never get them right!!
>
> Cheers
> Vern
>
>
> On 3/6/2018 2:44 PM, Evan Harris wrote:
>
> > Personally I think the idea of a whole pile of parameters with no keywords
> > would be even uglier than the verbose string the CL prompter produces.
> > Despite the perceived ugliness including the keywords removes pretty much
> > all the possible ambiguity.
> >
> > If I was that horrified I think I would write a CL "prettifier" in Python,
> > but I've been looking at CL so long I find the prompts comforting.
> >
> > One argument for *BCAT and *TCAT vs pipes etc is that there is no
> > possibility of a character translation error if the source gets moved
> > around.