[R] Does S inherit the enhancements in R language?

[William Dunlap]

> -----Original Message-----
> From: r-help-bounces at r-project.org 
> [mailto:r-help-bounces at r-project.org] On Behalf Of Paul Johnson
> Sent: Friday, March 19, 2010 1:44 PM
> To: R-help
> Subject: [R] Does S inherit the enhancements in R language?
> 
> I don't know anybody who has S-plus these days, but I expect some of
> you might, and perhaps you won't mind telling me something.

TIBCO Software Inc takes care of S+ these days.

We do try to avoid gratuitous incompatibilities between
R and S+.  When we implement new functionality we check
to see if R has the same thing and will use R's name for
it if so.   When R does something a bit differently we
sometimes ask if it was intended and might even suggest a change.

As for the underscore, a few years ago we
introduced a mode="R" or "Splus" argument to parse()
whose main effect is how the underscore is treated (assignment
operator in Splus mode and part of a name in R mode).
In the latest release, the parser emits a deprecation
warning whenever it sees the underscore while in Splus mode
(the user cannot turn off this warning).  Soon it will
not be an assignment operator.

S+ does not now have namespaces.  However, your rep example
is mainly a problem when your rep is the name of a function,
not the name of a nonfunction, as they are looked up differently.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com  

> 
> I'm working on my presentation about R for the general audience.  As I
> survey the suggestions from this list about that project, I find
> myself wondering whether S-plus benefits from R.  Does S-plus syntax
> change like R's does.  I can take code for S and run it through R, but
> if I took some R code to an S-plus system, would it work?
> 
> Example 1. _, <-, =
> 
> The old S documents I find emphasize assigment with "_".
> 
> When I started with R, that was deprecated, then forbidden. "_" was
> not allowed in file names, now it is.  It was absolutely necessary to
> use <-. = caused errors.  Around the time of R-2.1 or so, it became
> possible to run R code that has = for assignments. It's not encouraged
> by R core team, but = is allowed.
> 
> Does S+ now accept either
> 
> <-
> 
> or
> 
> =
> 
> ?
> 
> For that matter, in S+ is it now forbidden to use underscore for
> assignment, as it is in R?
> 
> Example 2. Semicolons now discouraged in R code.
> 
> We used to require ; to end commands.
> 
> Now the R parser is smart enough to spot line breaks and interpret
> them accordingly. R's been that way for as long as I can remember, but
> I think the ; was required in earliest R releases.
> 
> I rather liked the definitive ; at the end of every command.  That
> looks right to me, probably because of my SAS and C background.
> 
> Would S+ have a panic attack?
> 
> Example 3.  Namespace.  Does S-plus get better as R does?
> 
> Years ago, I was modeling US Democrats and Republicans and I created
> an indicator variable called "rep".  regression models would not work
> after that because the rep function had been blocked. It was very
> frustrating to me.
> Professor Ripley spotted the error and posed a message called "Don't
> use the names of R functions as variable names"
> http://www.mail-archive.com/r-help@stat.math.ethz.ch/msg11585.html.
> 
> After that, I was terrified that any name I used might conflict with a
> built in R function name.
> 
> Last month, i saw a student here with a political model and he used
> rep as a variable in a regression model, it seemed to work just fine.
> I surmise that the rise in usage of namespaces in R packages accounts
> for that?
> 
> I'm sorry if this is too OT for r-help.
> 
> pj
> -- 
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>