On Tue, 06 Apr 2004, Simon J. Gerraty wrote:
> Expressions like:
> 
> echo "${NUMBERS:@n@$n is ${(${PRIMES:M$n} == ""):?not:} prime,@}"
>
> don't work because ${PRIMES} is expanded to nothing before being
> passed to the conditional logic - which insists on having a variable
> reference and so chokes.

This works:

PRIMES=2 3 5 7
NUMBERS=1 2 3 4 5 6 7 8 9 10
foo:
	echo ${NUMBERS:@n@$n is ${PRIMES:M$n:C/..*/prime/W:C/^$/not prime/W},@}


> 1. Allow something like:
> 
>    ${NUMBERS:${PRIMES:S,^,N,:ts}}
> 
>    Which would be treated as
> 
>    ${NUMBERS:N1:N3:N5:N...}
 
This looks powerful enough to be used in very confusing ways.

> 2. Make cond.c not require a variable reference for string
>    comparisons.  This would allow:
> 
>    ${NUMBERS:@n@${("${PRIMES:M$n}" == ""):?$n:}@}
> 
>    to work.

This seems like a good idea.

> 3. Provide a means of saying "don't" expand yet, so that ${PRIMES:M$n}
>    could be passed down to cond.c - or perhaps make that implicit if
>    :? is present.

Perhaps make backslashes work in ${\${PRIMES:M\$n} == "":?yes:no}

I don't like the idea of making the delayed expansion implicitly
depend on something else in the expression.

> 4. Make:
> 
>    ${PRIMES:M$n:?:$n}
> 
>    work as expected?  Ie. if ${PRIMES:M$n} is empty, then :? should
>    eval false.

This also seems reasonable.

--apb (Alan Barrett)