R-beta: S Compatibility (again)

[Peter Dalgaard BSA]

Bill Venables <wvenable at attunga.stats.adelaide.edu.au> writes:

> While I think total compatibility is not possible or even very
> important

- or desirable... Part of the incentive for R was to try to avoid some
of the design problems of S, so we don't want to go to the extremes of
cloning everything! We try to be compatible in little things, though,
even when S seems quirky.

>    I think S has the better convention since dump files are in
>    printable ascii and so not so susceptable to email
>    transmission problems.  R dump files should be treated as
>    binaries and alpha encoded.

Agreed. Note however, that complete dump/restore compatibility is
probably not to be expected unless the internal representation of
everything is the same.

> 2. substring(...., first = 0, ...) is not the same.
> 
> R:                                 S:                            
> 				                                 
> > n				   > n                           
> [1] ""  "a" "b" "c"		   [1] ""  "a" "b" "c"           
> > nchar(n)			   > nchar(n)                    
> [1] 0 1 1 1			   [1] 0 1 1 1                   
> > substring(n, 0, nchar(n))	   > substring(n, 0, nchar(n))   
> [1] "@" ""  ""  "" 		   [1] ""  "a" "b" "c"           
> > substring(n, 1, nchar(n))	   > substring(n, 1, nchar(n))   
> [1] ""  "a" "b" "c"		   [1] ""  "a" "b" "c"           

Should get fixed - or R should protest about an invalid argument. If
for nothing else, then because

> substring(n, -2000, nchar(n))
Segmentation fault (core dumped)

(Current devel. snapshot, but most likely the same in the other
versions.) 

> 3. Language manipulation within R seems to be impossible.  I
>    realise this may be a design limitation that nobody can do
>    anything about, but it may be worth noting.
> 
>    To be more specific, the R substitute() is much more limited
>    than the S version and coercion to mode "{", "call" or
>    "function" are unavailable, and function objects are not
>    subsetable.  as.call is useless and as.function only exists to
>    issue a rather tetchy error message.

As Thomas already noted, you can in fact do a substantial amount of
expression manipulation, but some things aren't quite the same as in
S. It might be useful if you could provide some examples of things
that (you think) can be done in S but not in R. 

> 4. I miss find() and data.dump() in R very badly, and the
>    curiously different argument sequence for objects() is
>    disconcerting to someone who has to use both systems.

You're not alone there, certainly. 

Find() is probably fairly simple to write, either as an interpreted
function or by copying code from .Internal(get(...)) which needs to
search along the same path anyway.

Data.dump() has been on several peoples wishlist for a while - as far
as I can see, it's simply an efficient representation of the output of
dput(), so again most likely fairly easy, once someone finds the time
to sit down with a sample dump file and do the actual coding.

Objects(), however, owes some of its differences from S to the
different scoping rules, so I suspect that it can never have the same
semantics. We *do* need to do a better writeup on how these things
works (or should work ;) ) though, some of it is currently only poorly
understood by members of the core group...

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._