Re: Aliasing separators (Re: grammar triviality with '&&')

[Ray Andrews <rayandrews@eastlink.ca>]

On 03/09/2015 10:03 AM, Bart Schaefer wrote:
> My vote (perhaps obviously) would be to back it out, fix the issue with
> "{" / catenation and the history, and then consider whether aliasing of
> other tokens can be re-introduced.
>
I'm not competent to vote, but my hope will be that whatever happens
will make the code more consistent, reliable,understandable and intuitive,
and make usage more predicable and friendly and not open any cans of worms.


[ -e file1 ] &&
do-this

... from the start, I understood that this was friendly ... the parser
might have been crabby and demand a complete statement but it
is considerate enough to wrap and see what's on the next line before
throwing an error. In the same spirit I thought that:


[ -e file1 ]
&& do-this

... would be the same sort of friendliness, with the '&&' automatically
checking the previous errorlevel. I thought that is would be impossible
for it to parse as anything but it's naive reading, therefore it need not
be an error.  But if not, it's simply nothing of a real
world difficulty.  The 'alias' thing seems very scary. I might one day
understand aliasing fundamental syntax, but for now the mind reels. Are
not things tricky enough already?

I hope something good comes from my trivial question ;-)