On 2014-08-03, at 13:23, John Gilmore wrote: > > One of the HLASM's notional eccentricities, shared with its > immediate predecessors, is that string comparisons consider first > length and only then code-point bit-string values. ... > That's an abomination. It can be explained but not forgiven on the presumtion of a false economy of either bytes of code or CPU cycles in days of yore. Or perhaps it was a blunder in implementation, sanctified by usage before a change could be made, now prohibited by compatibility. It could be resolved by a new set of comparison operators, preferable to a macro implementation which would need to be more verbose in expression in application.
> The question how to compare two simple strings of, in general, > different lengths to obtain traditional lexicographic- or > dictionary-sequence results is thus reducible to the question how to > pad the shorter of comparand and comparans to make their lengths > equal. There are two 'reasonable' choices of a padding character, > > o a blank or space, ASCII x'20' or EBCDIC x'40', or > > o a nul, ASCII and EBCDIC x'00'. > That's a CLCL mindset. There's a third option, used by Rexx, of first comparing through the length of the shorter string, and if they match so far, returning the result of comparing the lengths: 503 $ rxx "say x2c( 414200 ) << x2c( 4142 )" 0 504 $ rxx "say x2c( 414200 ) == x2c( 4142 )" 0 505 $ rxx "say x2c( 414200 ) >> x2c( 4142 )" 1 This is functionally equivalent to padding with a fictitious code point which corresponds to no character and is less than any. (In the C/UNIX/PC world, NUL comes close to having this trait, but here I sympathize with John Walker in that the idiosyncrasies of some environments should not dictate the design choices of others.) And in some implementations, char is treated as a signed type, so low-value is not NUL but 0x80. Ugh! -- gil
