Polar Humenn wrote:
>It is not a mistake. The *Match constructs take the match function and
>apply it between each element in the bag and the explicit value.
>
>Currently, the equivalent expression to a Match element that would appear
>in the condition as:
>
>( any-of matchId-function primitive bag<primitive> ).
>
Firstly, this needs to be very clearly pointed ont in the specification.
I've read the
spec maybe six times in the past three months and I only just noticed
that the
signatures differed in the specifications. [I was probably blinded by
the natural
assumption that the signature would not depend upon the context of the
expression.
I can't think of another language that does this.]
Secondly, this is definitly going to catch users out who have to write
this stuff.
They'll happily cut an expression from a condition and paste it into a
target, or
vis-versa, and get upset. They'll be screwed unless they hack out, or
in, the
calls to 'only-one-of'.
Wouldn't it be simpler for everyone to just make the signature the same
in both
places?
You've got polymorphism based on the context of the call. How about adopting
the more usual approach of basing the polymorphism on the type of the
arguments?
If I pass a primitive and a bag it does the match thing, if I pass a
primitive and a
primitive it compares them.
Or, how about using two different names to reflect the fact there are
two different
behaviours... string-equal, string-match, double-match, double-equal, ...
I think that polymorphism on argument type is the best approach, then
changing
the condition signature to be the same as the target signature, and then
finally
having different names for the behaviours.
John
