On Wed, Apr 07, 2004 at 12:17:26PM +0200, Alan Barrett wrote:
> 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.

Scary...I don't think doing this unless absolutely required...

> 
> > 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.

Except for looking extremely ugly :-)

> 
> > 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.

Yeah. this would be hard to debug possibly if you don't grok internally
how make is doing things. We've already got weird enough bugs w. .for 
expansions and cond.c

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

I like this one the best myself. Where is $n coming from in this case, a 
.for expansion?

James