Date: Tue, 11 Dec 2001 08:35:18 -0500
Reply-To: mark.k.moran@CENSUS.GOV
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Mark Moran <mark.k.moran@CENSUS.GOV>
Subject: Re: upper(trim(left(myvar)))
Content-type: text/plain; charset=us-ascii
> 1. When a particular behavior is implemented as the default, there can
and should be devices to allow the opposite to be specified. So, for
example, if SAS were to make TRIMming implicit when a character variable is
referenced in an expression, I would expect them to introduce an UNTRIM
function to preserve trailing blanks.
Of course! That would be the only reasonable thing to do (at least, as far
as I can think of).
> 2. The better course depends rather strongly on the starting point. The
fact that changing default behavior now would break a lot of existing code
is, I believe, a compelling reason to leave things as they are.
Actually, the precedent existed long before SAS came along. The norm in
society for hundreds of years has been to ignore upper/lower case issues
and ignore blanks to the left of numbers for anything that is tabulated
like data. The exception to the norm has been to treat upper/lower case as
important and to treat blanks to the left of the entry in the tabulation as
important. The only reason SAS broke with the status quo was that it was a
technological hurdle that it couldn't cross at the time. Today it is
extraordinarily klunky and clutzy. It is no longer justifiable to continue
breaking the precedent. I think it is exactly the opposite of what number
2 says above. To "leave things as they are" is to fix SAS to conform to
what has been the established precedent for hundreds of years. It makes no
sense to make everyone else in the world have to change to fit SAS; it
makes more sense to change SAS to fit the precedent for the rest of the
world.
> On balance, I would oppose changes in the defaults.
On balance, I would strongly oppose SAS's 30+ year defiance of the default
that the world adopted long before SAS came along. In the early years, it
was a tragic necessesity. Today, it is an outmoded quirk.
> I would like to see a case-insensitivity modifier for character
comparison operator; it would be a single character which could be appended
to the operator to make it case insensitive, much as the colon reverses the
padding default when operands
are of different lengths. Then one would not have to code UPCASE or LOWCASE
on both sides.
This is exactly the wrong approach. SAS should not expect the rest of the
world to change established precedent to fit SAS's shortcomings. Things
like an UNTRIM approach are much better.
IMHO,
Mark
