Re: R-alpha: S vs. R

Robert Gentleman (
Mon, 3 Jun 1996 16:32:58 +1200

Date: Mon, 3 Jun 1996 16:32:58 +1200
From: Robert Gentleman <>
Message-Id: <>
Subject: Re: R-alpha: S vs. R

A while back Mike Meyer wrote:

> 2) Manipulation of functions.  In S I can do
> S> glm[["control"]]
> glm.control(...)
> whereas in R I get,
> R> glm[["control"]]
> Error in glm[["control"]] : object is not subsettable
> The second difference is a real nuisance in porting code that does its
> own argument matching.
While it may be a nuisance I don't think that this is the best way to
write code like this. The reason is that it takes advantage of the fact that 
in S (currently) functions are represented by lists. If there are n formal 
arguments then the list is n+1 long. The first n components are the named
arguments (hence you get the behaviour as above) and the last one is the
body of the function. This list is of mode function and deparses into its
usual form. Now what happens if the method of storing functions changes?
All of your code breaks. That's sort of what happened between S and R.
It is based on an implementation decision and not a design decision. I
don't think that it is a good idea to make use of implementation decisions
in any language.
What you need is a small layer of abstraction to get you away from the
implementation. A function, such as formals (a prototype is given below)
that when applied to a function returns the formal arguments is a better
way to handle this. Then if CBW decide to change their implementation you
need only change one thing.

	else stop("formals can only be applied to a function")

This function will do more or less the same thing as the new function formals
in R. Using it to do your own argument matching will be portable across both
R and S (and S versions should they ever decide to change how functions are

r-testers mailing list -- To (un)subscribe, send
subscribe	or	unsubscribe
(in the "body", not the subject !)  To: