[R] about the char _

[Timothy H. Keitt]

I personally would like to see underscore assignment removed. Perhaps it 
could be temporarily a global option whether this is accepted. It might 
also help to issue lots of warnings whenever it is parsed. The 
"make.names" function isn't as useful as one might think. I used it to 
do automatic conversion between SQL and R names, but ran into things like:

dbListTables(conn)

[1] my.table                                    % converted from my_table

dbGetQuery(conn, "select * from my.table") % Oops, forgot that its 
really my_table

ERROR: invalid SQL

You can really scan the SQL and remove the dots because that is used to 
indicate table fields, e.g., my_table.my_column.

Let's kill that bit of cruft (underscore assignment) asap.

Tim

Philippe Grosjean wrote:

>Well, you are totally right. Backward compatibility *is* very important.
>That is probably a reason why the R team keeps _ as a synonym of <- for
>assignation. And still, there is the nice function make.names() to eliminate
>improper characters from name strings. Yet, I still believe that not using .
>(dot) in names strings would easy to decrypt the "object hierarchy" in R as
>in Splus. make.names() replaces any improper character by ... a dot. Thus,
>you got dots everywhere in variables names when you import data from SAS, or
>any external source.
>
>
>-----Message d'origine-----
>De : Patrick Connolly [mailto:P.Connolly at hortresearch.co.nz]
>Envoye : vendredi 5 octobre 2001 14:33
>A : Philippe Grosjean
>Cc : R-help
>Objet : Re: [R] about the char _
>
>
>According to Philippe Grosjean:
>|>
>
>.....
>
>|> If _ was allowed in variables names, we could use print.my_var
>|> (which should, perhaps, be recommended) and it would be easier to spot
>where
>|> is the "object hierarchy" and where is the variable name.
>
>Here is one stick-in-the-mud who does not share the enthusiasm for
>such a change.  I started using Splus almost 10 years ago, and being a
>confirmed lazy typist ever since I started using unix, I immediately
>adopted the '_' shortform instead of the clumsy '<-' sequence.  It's
>an ingrained habit now which will be hard for an old codger to get out
>of.  Some esteemed contributors to this list have strong feelings
>against its use, but for my own use, I don't encounter any problems.
>If I make my code public I change it, but at the time of writing it in
>the first place, I'm very attached to lazy typing.
>
>There are hundreds of files of code which I have written the lazy way
>and I periodically source those.  Perhaps it wouldn't be difficult to
>search and replace in those files, but I'd prefer not to edit them
>since the date of the files is important information.
>
>Of course, such a stick-in-the-mud attitude does make it difficult to
>make progress by insisting on backward compatibility, but I offer a
>suggestion.
>
>You could get a similar effect with names such as my..variable which
>would be visually distinctive from my.variable and still work with the
>current convention, but I don't know if SAS could deal with such a
>name. There could be a problem with ..myfun.x1 because it would not be
>available to the likes of objects(), but there could well be a way
>around that.
>
>best
>
>
>--
>*************************************************************
>   ___      Patrick Connolly
> {~._.~}    HortResearch             Great minds discuss ideas;
> _( Y )_    Mt Albert                Average minds discuss events;
>(:_~*~_:)   Auckland                 Small minds discuss people.
> (_)-(_)    New Zealand                                    .... Anon
>            Ph: +64-9 815 4200 x 7188
>*************************************************************
>
>
>______________________________________________________
>The contents of this e-mail are privileged and/or confidential to the
>named recipient and are not to be used by any other person and/or
>organisation. If you have received this e-mail in error, please notify
>the sender and delete all material pertaining to this e-mail.
>______________________________________________________
>
>
>-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
>r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
>Send "info", "help", or "[un]subscribe"
>(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
>_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>

-- 
Timothy H. Keitt
Department of Ecology and Evolution
State University of New York at Stony Brook
Stony Brook, New York 11794 USA
Phone: 631-632-1101, FAX: 631-632-7626
http://life.bio.sunysb.edu/ee/keitt/



-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._