Re: make: new modifyer :Y

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Nov 09, 2011 at 09:10:10PM +0100, Anthony Mallet wrote:
 > On Wednesday, at 03:45, David Holland wrote:
 > |    A = "Yes"
 > |    B = "yes"
 > |     ...
 > |    A == B
 > | 
 > | suddenly the comparison is done as strings and becomes false, and the
 > | program logic fails, probably (by Murphy's Law) in a subtle and
 > | aggravating way.
 > 
 > I see (or at least I get an idea of what you mean).
 > I think that in this particular example the ambiguity comes from
 > the fact that the semantic of == is not well defined. Would you
 > have two different operators for strcmp() and yescmp(), there would
 > probably be no problem, right?

The semantics of == are (or can be) well defined. The problem arises
from it being (implicitly in this case) defined to be polymorphic.
Anything that nails the types down (different equality operators,
explicit type declarations, etc.) makes the problem go away. This
problem, at least.

 > Anyway, you've convinced me that this should be avoided in make
 > context.

I haven't convinced myself yet. This sort of issue is not necessarily
fatal; it just has to be approached carefully. For example, try
running the following:

   awk < /dev/null 'END { print ("1" == 1); }'
   awk < /dev/null 'END { print (1 == 1.0); }'
   awk < /dev/null 'END { print (1.0 == "1.0"); }'
   awk < /dev/null 'END { print ("1.0" == "1"); }'

   awk < /dev/null 'END { print ("1"+0 == 1); }'
   awk < /dev/null 'END { print (1 == 1.0); }'
   awk < /dev/null 'END { print (1.0 == "1.0"+0); }'
   awk < /dev/null 'END { print ("1.0"+0 == "1"+0); }'

Surprised by any of that?

 > My original idea was not to go that far and just replace the
 > interpretation of a string in a boolean context (like in ".if
 > ${X}") by the extended interpretation of "Yes" "1" etc.

That is exactly that far. Remember that && is also a boolean context,
and == inherently produces a boolean value.

 > So == should always mean strcmp() and not try to interpret the strings, and
 > ".if ${X} && ${Y}" should be "yes"-aware (because && uses boolean operands).
 > No matter how much you wire stuff down, the result of a &&-like operator is
 > always a boolean and can never be a string.

This doesn't actually solve the problem I outlined, unless you
completely prohibit == on boolean values. If you do, then that
particular problem doesn't arise... but then you need to introduce
other syntax for comparing boolean values. And this isn't necessarily
the only such problem, it's just the one I happened to come up with as
an example.

-- 
David A. Holland
dholland%netbsd.org@localhost