LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2001, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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)))
Comments: To: Howard_Schreier@ITA.DOC.GOV
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


Back to: Top of message | Previous page | Main SAS-L page