Re: Parser issues and and [[ $var ]]

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 11,  6:01pm, Peter Stephenson wrote:
} Subject: Re: Parser issues and and [[ $var ]]
}
} On Sat, 10 May 2014 18:01:44 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > I've found a couple of other bugs with 32604, so it's probably just as
} > well that I didn't commit/push it.  Does anyone know why the lexer
} > sometimes sets (tok = DOUTBRACK, tokstr = "\220\220") and other times
} > (tok = DOUTBRACK, tokstr = NULL) ?
} 
} It must surely be an oversight. I think a long time ago the lexer
} didn't bother setting tokstr when there was a unique token, since the
} string could in principle be deduced; however, it proverd much more
} convenient just to be able to use tokstr in any case.

In this instance it's actually easier for the caller if tokstr = NULL
consistently, rather than the other way around ...

} > Thus it would seem that the parser does need a way to explicitly test
} > for module-defined operators to also support non-operator non-empty
} > strings evaluating as true.  Or, we can decree that any string that
} > starts with a "-" is treated as an operator, since all module-defined
} > operators must start with "-", which would differ from ksh93 but not
} > from previous zsh.  (foo=-m; [[ $foo ]]) would still test as a string.
} 
} I think the latter is probably acceptable, but maybe there should be an
} interface saying a condition code defined by a module has been called with
} zero arguments (which might on failure alternatively confirm that there
} was no such condition code, allowing a different interpretation).

Hmm.

It turns out that because you can define a function that uses an operator
before you have loaded the module ...

zsh% foo() { [[ -m 1 2 3 ]] && echo OK }
zsh% foo
zsh: unknown condition: -m
zsh% zmodload zsh/example
The example module has now been set up.
zsh% foo
OK

... that it also won't work to cause a parse error on unknown operators.

I'm beginning to suspect that from a syntax perspective prefix operators
that accept multiple arguments are already a problem.  Suppose you have
defined an operator that takes 0 to 4 arguments, call it "-uptofour".
Isn't the following an intractable syntax problem?

  [[ -uptofour -a -n $foo ]]

Or do the "arguments" have to be things that don't look like operators?
What if another module defines an infix operator "-both" and you write

  [[ -uptofour -both -n $foo ]]

?  Is -both an operator or an argument?  Before the module is loaded, how
do you tell?

Incidentally, even before any of my patching attempts:

zsh% [[ -n 1 2 3 ]]
zsh: unknown condition: -n

Not parse error, not "wrong number of arguments", but "uknown condition".
Whereas:

$ [[ -n 1 2 3 ]]
ksh: syntax error: `2' unexpected