> On 11 Dec 2015, at 20:13 , Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > > On 11/12/2015 1:52 PM, Mario José Marques-Azevedo wrote: >> Hi Duncan and David, >> >> Thank you for explanation. I'm really disappointed with this R "resource". >> I think that partial match, mainly in function args, must be optional and >> not default. We can have many problems and lost hours find errors (it occur >> with me). I tried to find a solution to disable partial match, but it seems >> that is not possible. Program with hacks for this will be sad. > > Nowadays with smart editors, I agree that partial matching isn't really > necessary. However, R has been around for 20 years, and lots of existing > code depends on it. Eventually you'll get to know the quirks of the design.
Yes, partial matching is largely regretted by its inventors, but it is hard to get rid of due to various arcane bits of history. For instance, have you noticed that seq() doesn't have a "length" argument? I.e. > seq(2, length=3) [1] 2 3 4 actually only works due to partial matching -- the argument is really "length.out". Now, looking that the code for seq.default offers a hint at the: It uses things like length(by) internally. In ancient times (in S) that would give you a type mismatch, but one of the things that R changed was to have function lookup disregard non-function objects. In other places, some argument names have a period added for similar reasons. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see 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.
