Re: Bug in case stmt with '('

[segal@xxxxxxxxxx (Morris M. Siegel)]

> There is no whitespace token.  Whitespace is a separator and not a token.

I know that whitespace is a separator, not a token.  My proposed description
of the parsing of a case-prefix did not distinguish lexical from syntactic
analysis.

> Allowing space around | makes the script more readable.

I agree, and did not even think of forbidding it (more on this below).

> This means that your new syntax would introduce an ambiguity:
> 
> case foo in
> f* | echo echo yes;;
> esac
> 
> The question is wether the first echo is part of the pattern of a command
> and | denotes an empty pattern.  Of course you may say that if a pattern
> ends in a trailing | it must be followed by a ).

I confess to having forgotten about the empty pattern.  Using null syntax
to implicitly denote the empty pattern in a script doesn't enhance readability
in any case, and I think zsh syntax would be safer and less confusing if the
empty pattern had to be denoted with the explicit syntax "()".

I would suggest that your above sample case statement be interpreted
as though it were

	case foo in
	f* | echo) echo yes;;
	esac

(following my proposed parsing of a case-prefix), and that the alternative
interpretation with the empty pattern would have to be written either as

	case foo in
	f* | ) echo echo yes;;
	esac

as you suggest (if implicit empty pattern are allowed), or better (with an
explicit empty pattern) as

	case foo in
	f* | () echo echo yes;;
	esac

> It ... would make the syntax more complicated.

I assume you mean the logical syntax (the grammer), not {lex,parse}.c .
If implicit empty patterns are disallowed, I think that the syntax becomes
less, not more, confusing.

> Unfortunately there is still an incompatibility in case:
> 
> case foo in
> ( f* | b* ) echo yes
> esac
> 
> should print yes but in zsh it works as
> 
> case foo in
> \ f*\ |\ b*\ ) echo yes;;
> esac
> 
> To fix this would be really difficult I think.

Perl5 enhances the readability of its regular expressions by introducing
the "/x" modifier, which makes unescaped whitespace syntactically insignificant.
Considering the fact that glob patterns in general are supposed to generate
file names, which usually do not contain blanks, zsh might also ignore
unescaped whitespace in glob patterns (in general, not just in 'case'
statements).  This would clearly solve this last-mentioned incompatibility,
allow blanks around '|' in case-prefixes (referred to above),
and in general improve readability.  Non-trivial whitespace could always
be escaped.  Since file names rarely contain blanks, this should not be
likely to break existing code; if you're worried about the possibility,
you could introduce a new zsh option (say) IGNORE_GLOB_WHITESPACE .

-- Morrie Siegel