Skip to content

Infinite recursion in getGeneric (PR#4561)

5 messages · Saikat DebRoy, John Chambers

Original
Saikat DebRoy
# 
[1] "foo"
 > setMethod('is.logical', 'foo', function(x) TRUE)
[1] "is.logical"
 > getGeneric('is.integer')
Error in options(x) : evaluation is nested too deeply: infinite 
recursion?
 >

--please do not edit the information below--

Version:
  platform = i686-pc-linux-gnu
  arch = i686
  os = linux-gnu
  system = i686, linux-gnu
  status =
  major = 1
  minor = 8.0
  year = 2003
  month = 10
  day = 08
  language = R

Search Path:
  .GlobalEnv, package:methods, package:ctest, package:mva, 
package:modreg, package:nls, package:ts, Autoloads, package:base
John Chambers
#
saikat@stat.wisc.edu wrote:
This is one of a number of potential problems when methods are specified
for  primitive functions used in the R code that dispatches methods.

There is a fix for this particular example -- I will commit it to
r-patched.

However, the only real safety will come when primitives are not
dispatched from a global structure (a change planned for 1.9).  Then the
version of primitives used in method dispatch can be separated from any
methods defined in a different namespace.

For example, a quick test showed that even after the above fix, setting
methods for "is.null" causes similar problems.

As a heuristic, setting methods for language-related primitives is
dangerous (also a little strange?).

John

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Saikat DebRoy
    

    

      
      #
    

  


  

      
On Monday, Oct 13, 2003, at 16:17 US/Eastern, John Chambers wrote:

        

            

      
      
      
    

        
Yes. But if it is allowed, someone will do it. It may actually make 
sense to come up with an appropriate (and preferably small) list of 
primitive functions and say that you can not define methods for them 
(at least easily).

  
  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
Saikat DebRoy wrote:

            

      
      
      
    

        
If we're talking about r-devel, not r-patched, we can do better.  The
inherent problem is that a global table is used for dispatching methods
for primitives.  For 1.9, the plan is to replace this with more-or-less
real generic functions  (the less part is that the version of is.logical
the evaluator calls will still be a primitive; the generic will be found
by another mechanism).  Once methods are dispatched from valid generic
functions, then a call to is.logical within method dispatch will be
unaffected by methods defined for is.logical in another namespace.

As for r-patched, it would be easy to prohibit methods for those that
generate infinite loops, if we knew which ones they were.

John

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
John Chambers wrote:

            

      
      
      
    

        
Committed to r-patched.

            

      
      
      
    

        
A list of primitives has been set up that are known or suspected to
cause this sort of problem (is.null, is.primitive, is.function,
is.object).  Until the general fix is in place, an attempt to set
methods for these functions will cause an error.

If you encounter any other primitives that produce symptoms such as
above (an "evaluation nested" error after setting a method for the
function), please report them.

John