problem with sub in graphs

[Peter Dalgaard BSA]

Martin Maechler <maechler@stat.math.ethz.ch> writes:

>     PD> The purpose of '...' is that a function does not  need to know
>     PD> about certain parameters that are being handled by lower level
>     PD> routines. It can just pass them along.
> 
> Yes,  but......
> 
> The problem here is really about catching user typos.
> S-plus has been  quite lazy here which has driven people into despair, 
> more than once in my epxerience:
> 
> Consider the person (especially non-pro statistician) who does
> 
> 	summary(glm(y~x,familiy=poisson(link="identity")))
> 

Point taken, but I still have reservations, mainly in the
division-of-labour department. 

The obvious counterargument is that in Splus, glm internally calls its
method= argument (glm.fitter) with the ..., and there is no way for
glm to know that "familiy" is not a valid argument for a user-supplied
method (-short of some kind of AI proximity testing, I suppose).
Conversely, *if* argument checking was performed in glm, and a user
wanted to use his own supersmart fitting method with some special
arguments, he'd have to modify glm as well. Now take *two* packages,
each modifying glm in their own way...

One way out - but this requires considerable changes - could be to
implement a convention that routines using ... returns a component
called $unmatched. The caller could then take the intersection of
those and if it is non-empty, complain. (If a routine does not
return $unmatched one must assume that everything *is* matched.)

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._