The problem with having methods for "<-" is a practical one, not one of principle.
1. The current code does not evaluate the <- operator as a function (This is less serious than it sounds, since certain "functions" are intercepted specially in the C code for method dispatch already.) 2. Assignments take place everywhere, in virtually every S language function definition. It's hard to imagine a version of method dispatch efficient enough not to slow computation dramatically if every local assignment had to check for methods. Point 2 almost certainly rules out methods for <- now and for the imaginable future. And in fact, it's unlikely one really wants to interfere with every single local assignment. Aside from reality in this sense, none of the other objections are crippling. - why would you want them? Because of a need to do some checking and/or adjustment of the object being assigned, perhaps. For example, a class can have a "validity" method, but this is not invoked automatically when the object is assigned, for the same practical efficiency reason. One might want to force validity checking for some class of objects. But, again, would you really want to do this every time the object is assigned in any function? - not evaluating the left side of the operator. This is no problem in principle, since generic functions can have a signature (see ?setGeneric); if the signature omits the first argument, methods can be dispatched without evaluating that argument. - As Richard O'Keefe points out, replacement expressions (dim(x) <- NULL, e.g.) are handled as simple assignments of the result of "replacement functions" (x <- "dim<-"(x, NULL)). In fact this means that defining methods for "<-" would catch ALL assignments. Replacement functions are not methods but essentially a syntactic shorthand and a way of defining replacement operations in a language that doesn't allow pointers. But given practical constraints, the methods will have to be methods for some other operator or function, or the solution found some other way. Whatever the solution, it will involve the software calling some function or operator other than "<-", or using "<-" in a special way (e.g., x <- validObject(x) if validity checking was the goal). Regards, John Chambers Patrick Burns wrote: > > I think Brian's question --- what are you trying to do? -- should > be the first order of business. > > Someone can make R do just about anything, but it is better to > do a few things very well than lots of things in a muddled way. > > So. What is the advantage of using assignment as a generic? > I'm open-minded about there being such an advantage, but I > don't see any right off. > > Patrick Burns > > Burns Statistics > [EMAIL PROTECTED] > +44 (0)20 8525 0696 > http://www.burns-stat.com > (home of S Poetry and "A Guide for the Unwilling S User") > > Thomas Koenig wrote: > > >Am Samstag, 26. Juli 2003 11:38 schrieb Peter Dalgaard BSA: > > > > > >>Peter Dalgaard BSA <[EMAIL PROTECTED]> writes: > >> > >> > >>>Prof Brian Ripley <[EMAIL PROTECTED]> writes: > >>> > >>> > >>>>What are you trying to do with this? Assignment (<-) is not a > >>>>function, > >>>> > >>>> > > > >But what the difference between <- and e.g. the function length or "[<-"? As I > >understood in "methods" everything has a class. And R says me with is(...) > >(hope that the results are correct): > >< is(get("<-")) > >[1] "function" "OptionalFunction" "PossibleMethod" > >< is(get("length")) > >[1] "function" "OptionalFunction" "PossibleMethod" > > > > > >>is(get("[<-")) > >> > >> > >[1] "function" "OptionalFunction" "PossibleMethod" > > > > > >>## test for the correct result of get(...) ? > >>x <- 10 > >>is(get("x")) > >> > >> > >[1] "numeric" "vector" > > > > > >>## and > >>setGeneric("<-") > >> > >> > >[1] "<-" > >Warning message: > >"<-" is a primitive function; its generic definition is built in and > >automatically included. in: setGeneric("<-") > > > > > > > >>>>and the language grammar does not convert a <- b into "<-"(a, > >>>>b) (as it would with the binary operator functions). You could call it > >>>>that way, and then it will probably work. > >>>> > >>>> > >>>Eh? Are you sure about that??? > >>> > >>> > >>> > >>>>quote("<-"(a,b)) > >>>> > >>>> > >>>a <- b > >>> > >>> > >>Adding on to this, I think the point is that assignment bypasses the > >>usual *evaluation* rules, even though it is syntactically a binop. > >> > >>I think it basically has to be so: For one thing, it is kind of > >>difficult to check for a signature match without evaluating the > >>arguments and the left hand side of an assignment will not in general > >>exist at that point. > >> > >> > > > >In the methods is the class "missing". Could that help? > >for one thing : signature=c("missing","A") (only allowed for <- ?) > >for both things: signature=c("A","B") > >for nothing ;-) : signature=c("missing","missing") > > > >Thanks and Best Regards > > > >Thomas König > > > >______________________________________________ > >[EMAIL PROTECTED] mailing list > >https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > > > > > > > > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help -- John M. Chambers [EMAIL PROTECTED] Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help