bug in match object?

I don't know if it's a bug but it's strange.

The behavior you mention only seems to occur when [match] has a wildcard (nn) as the first argument. What's interesting is that given your match arguments of nn 1 nn and your input of $1 1 1 - you can have ANY value in the first position and you won't get the -2147483648 error.. UNLESS the first value is a 1. ANY other value (symbol, int, float, whatever) will not give you the -2147483648 output. So why would that be?

Keep in mind that while -2147483648 is the lowest possible 32-bit number, it's also not always treated as number, but as an expression that refers to an undefined value.. something larger than Max can handle.

It's almost as if [match] defines the first nn as the positive limit of all possible integer values (2147483647) and at some point along the line internally "adds" the first input received to nn. So if the input is a 0, it's within the 32-bit range (2147483647 + 0 = 2147483647) . If it's a 2... 2147483647 + 2 is 2147483649 (too large) so it 'flips' to -2147483647 which is within the 32-bit range. If it's a -1.. 2147483647 + -1 = 2147483646. No problem. But if it's a 1.. 2147483647 + 1 is 2147483648.. which is too big for 32-bit so it flips to -2147483648 which Max interprets as 'undefined'. Or something like that. I'm curious about other thoughts on this.

If you need your output free of -2147483648, you can append a symbol at the end of your input list and remove it after the match object. For some reason [match] handles the first input differently if the final argument is a symbol.